Andrew Cooper [Thu, 2 Mar 2017 11:41:17 +0000 (11:41 +0000)]
x86/emul: Hold x86_emulate() to strict X86EMUL_EXCEPTION requirements
All known paths raising faults behind the back of the emulator have been
fixed. Reinstate the original intended assertion concerning the behaviour of
X86EMUL_EXCEPTION and ctxt->event_pending.
As x86_emulate_wrapper() now covers both PV and HVM guests properly, there is
no need for the PV assertions following calls to x86_emulate().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 2 Mar 2017 12:41:38 +0000 (12:41 +0000)]
x86/hvm: Don't raise #GP behind the emulators back for CR writes
hvm_set_cr{0,4}() are reachable from the emulator, but use
hvm_inject_hw_exception() directly.
Alter the API to make the callers of hvm_set_cr{0,3,4}() responsible for
raising #GP, and apply this change to all existing callers.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Issues identified which I am purposefully not fixing in this patch:
(I will try to get around to them, but probably not in the 4.9 timeframe, at
this point.)
* hvm_set_cr3() doesn't handle bad 32bit PAE PDPTRs properly, as it doesn't
actually have a path which raises #GP.
* There is a lot of redundancy in our HVM CR setting routines, but not enough
to trivially dedup at this point.
* Both nested VT-x and SVM are liable raise #GP with L1, rather than failing
the virtual vmentry/vmexit. This is not a change in behaviour, but is far
more obvious now.
* The hvm_do_resume() path for vm_event processing has the same bug as the
MSR side, where exceptions are raised after %rip has moved forwards. This
is also not a change in behaviour.
Quan Xu [Fri, 3 Mar 2017 11:00:35 +0000 (12:00 +0100)]
x86/apicv: fix wrong IPI suppression during posted interrupt delivery
__vmx_deliver_posted_interrupt() wrongly used a softirq bit to decide whether
to suppress an IPI. Its logic was: the first time an IPI was sent, we set
the softirq bit. Next time, we would check that softirq bit before sending
another IPI. If the 1st IPI arrived at the pCPU which was in
non-root mode, the hardware would consume the IPI and sync PIR to vIRR.
During the process, no one (both hardware and software) will clear the
softirq bit. As a result, the following IPI would be wrongly suppressed.
This patch discards the suppression check, always sending an IPI.
The softirq also need to be raised. But there is a little change.
This patch moves the place where we raise a softirq for
'cpu != smp_processor_id()' case to the IPI interrupt handler.
Namely, don't raise a softirq for this case and set the interrupt handler
to pi_notification_interrupt()(in which a softirq is raised) regardless of
VT-d PI enabled or not. The only difference is when an IPI arrives at the
pCPU which is happened in non-root mode, the code will not raise a useless
softirq since the IPI is consumed by hardware rather than raise a softirq
unconditionally.
Signed-off-by: Quan Xu <xuquan8@huawei.com> Signed-off-by: Chao Gao <chao.gao@intel.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 3 Mar 2017 11:00:05 +0000 (12:00 +0100)]
x86emul: assert no duplicate mappings of stub space
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Fix this by adding appropriate checks for vmcs id during vmptrld
emulation.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Fix this by emulating VMfailInvalid if the address is invalid.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Feng Wu [Fri, 3 Mar 2017 10:58:13 +0000 (11:58 +0100)]
VMX: make sure PI is in proper state before install the hooks
We may hit the last ASSERT() in vmx_vcpu_block in the current code,
since vmx_vcpu_block() may get called before vmx_pi_switch_to()
has been installed or executed. Here We use cmpxchg to update
the NDST field, this can make sure we only update the NDST when
vmx_pi_switch_to() has not been called. So the NDST is in a
proper state in vmx_vcpu_block().
Suggested-by: Jan Beulich <JBeulich@suse.com> Signed-off-by: Feng Wu <feng.wu@intel.com> Signed-off-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Feng Wu [Fri, 3 Mar 2017 10:57:30 +0000 (11:57 +0100)]
VMX: permanently assign PI hook vmx_pi_switch_to()
PI hook vmx_pi_switch_to() is needed even after any previously
assigned device is detached from the domain. Since 'SN' bit is
also used to control the CPU side PI and we change the state of
SN bit in vmx_pi_switch_to() and vmx_pi_switch_from(), then
evaluate this bit in vmx_deliver_posted_intr() when trying to
deliver the interrupt in posted way via software. The problem
is if we deassign the hooks while the vCPU is runnable in the
runqueue with 'SN' set, all the furture notificaton event will
be suppressed. This patch makes the hook permanently assigned.
Signed-off-by: Feng Wu <feng.wu@intel.com> Signed-off-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>). Acked-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Tue, 5 Jul 2016 09:40:21 +0000 (10:40 +0100)]
x86/hvm: Adjust hvm_nx_enabled() to match how Xen behaves
On Intel hardware, EFER is not fully switched between host and guest contexts.
In practice, this means that Xen's EFER.NX setting leaks into guest context,
and influences the behaviour of the hardware pagewalker.
When servicing a pagefault, Xen's model of guests behaviour should match
hardware's behaviour, to allow correct interpretation of the pagefault error
code, and to avoid creating observable difference in behaviour from the guests
point of view.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andy Lutomirski [Fri, 9 Dec 2016 18:24:07 +0000 (10:24 -0800)]
x86/microcode: Replace sync_core() with cpuid_eax()
The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1".
Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Borislav Petkov <bp@alien8.de>
[Linux commit 484d0e5c7943644cc46e7308a8f9d83be598f2b9]
[Ported to Xen] Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
keios [Tue, 3 Oct 2006 08:13:49 +0000 (01:13 -0700)]
xen/common: low performance of lib/sort.c
It is a non-standard heap-sort algorithm implementation because the index
of child node is wrong . The sort function still outputs right result, but
the performance is O( n * ( log(n) + 1 ) ) , about 10% ~ 20% worse than
standard algorithm.
Signed-off-by: keios <keios.cn@gmail.com>
[Linux commit: d3717bdf8f08a0e1039158c8bab2c24d20f492b6]
[Ported to Xen] Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Juergen Gross [Thu, 2 Mar 2017 05:13:16 +0000 (06:13 +0100)]
tools: add pkg-config file for libxc
When configuring the build of qemu the configure script is building
various test programs to determine the exact version of libxencontrol.
Instead of a try and error approach needing updates for nearly each
new version of Xen just provide xencontrol.pc to be used via
pkg-config.
In the end we need two different variants of that file: one for the
target system where eventually someone wants to build qemu, and one
for the local system to be used for building qemu as part of the Xen
build process.
The local variant is created in a dedicated directory in order to be
able to collect more pkg-config files used for building tools there.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Juergen Gross [Thu, 2 Mar 2017 05:13:15 +0000 (06:13 +0100)]
stubdom: set xen interface version for stubdom apps using xenctrl.h
A stubdom app using xenctrl.h must use the latest interface version of
Xen in order to avoid compatibility issues. Add the related config
item to the stubdom config files where needed.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them and
returns a value to the frontend and acts on the function call.
This version of the document covers networking function calls, such as
connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but
the protocol is meant to be easily extended to cover different sets of
calls. Unimplemented commands return ENOTSUP.
Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
simple and describes a series of commands and responses. It is
completely independent from the communication channels, in fact many
clients and servers support multiple channels, usually called
"transports". For example the Linux client supports tcp and unix
sockets, fds, virtio and rdma.
This design document outlines the transport protocol for
9pfs payload.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
Dario Faggioli [Wed, 1 Mar 2017 16:56:35 +0000 (16:56 +0000)]
xen/tools: tracing: Report next slice time when continuing as well as switching
We record trace information about the next timeslice when
switching to a different vcpu, but not when continuing to
run the same cpu:
csched2:schedule cpu 9, rq# 1, idle, SMT idle, tickled
csched2:runq_candidate d0v3, 0 vcpus skipped, cpu 9 was tickled
sched_switch prev d32767v9, run for 991.186us
sched_switch next d0v3, was runnable for 2.515us, next slice 10000.0us
sched_switch prev d32767v9 next d0v3 ^^^^^^^^^^^^^^^^^^^^
runstate_change d32767v9 running->runnable
...
csched2:schedule cpu 2, rq# 0, busy, not tickled
csched2:burn_credits d1v5, credit = 9996950, delta = 502913
csched2:runq_candidate d1v5, 0 vcpus skipped, no cpu was tickled
runstate_continue d1v5 running->running
?????????????
This information is quite useful; so add a trace including
that information on the 'continue_running' path as well,
like this:
csched2:schedule cpu 1, rq# 0, busy, not tickled
csched2:burn_credits d0v8, credit = 9998645, delta = 12104
csched2:runq_candidate d0v8, credit = 9998645, 0 vcpus skipped, no cpu was tickled
sched_switch continue d0v8, run for 1125.820us, next slice 9998.645us
runstate_continue d0v8 running->running ^^^^^^^^^^^^^^^^^^^^^
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
When traversing a Credit2 runqueue to select the
best candidate vCPU to be run next, show in the
trace which vCPUs we consider.
A bit verbose, but quite useful, considering that
we may end up looking at, but then discarding, one
of more vCPU. This will help understand which ones
are skipped and why.
Also, add how much credits the chosen vCPU has
(in the TRC_CSCHED2_RUNQ_CANDIDATE record). And,
while there, fix a bug in tools/xentrace/formats
(still in the output of TRC_CSCHED2_RUNQ_CANDIDATE).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 1 Mar 2017 16:56:35 +0000 (16:56 +0000)]
xen: credit2: tidy up functions names by removing leading '__'.
There is no reason for having pretty much all of the
functions whose names begin with double underscores
('__') to actually look like that.
In fact, that is misleading and makes the code hard
to read and understand. So, remove the '__'-s.
The only two that we keep are __runq_assign() and
__runq_deassign() (althought they're converted to
single underscore). In fact, in those cases, it is
indeed useful to have those sort of a "raw" variants.
In case of __runq_insert(), which is only called
once, by runq_insert(), merge the two functions.
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 1 Mar 2017 16:56:34 +0000 (16:56 +0000)]
xen: credit2: don't miss accounting while doing a credit reset.
A credit reset basically means going through all the
vCPUs of a runqueue and altering their credits, as a
consequence of a 'scheduling epoch' having come to an
end.
Blocked or runnable vCPUs are fine, all the credits
they've spent running so far have been accounted to
them when they were scheduled out.
But if a vCPU is running on a pCPU, when a reset event
occurs (on another pCPU), that does not get properly
accounted. Let's therefore begin to do so, for better
accuracy and fairness.
In fact, after this patch, we see this in a trace:
Which shows how d1v5 actually executed for ~9.796 ms,
on pCPU 10, when reset_credit() is executed, on pCPU
12, because of d1v6's credits going below 0.
Without this patch, this 9.796ms are not accounted
to anyone. With this patch, d1v5 is charged for that,
and its credits drop down from 9796548 to 201805.
And this is important, as it means that it will
begin the new epoch with 10201805 credits, instead
of 10500000 (which he would have, before this patch).
Basically, we were forgetting one round of accounting
in epoch x, for the vCPUs that are running at the time
the epoch ends. And this meant favouring a little bit
these same vCPUs, in epoch x+1, providing them with
the chance of execute longer than their fair share.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 1 Mar 2017 16:56:34 +0000 (16:56 +0000)]
xen: credit2: always mark a tickled pCPU as... tickled!
In fact, whether or not a pCPU has been tickled, and is
therefore about to re-schedule, is something we look at
and base decisions on in various places.
So, let's make sure that we do that basing on accurate
information.
While there, also tweak a little bit smt_idle_mask_clear()
(used for implementing SMT support), so that it only alter
the relevant cpumask when there is the actual need for this.
(This is only for reduced overhead, behavior remains the
same).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Boris Ostrovsky [Wed, 1 Mar 2017 16:51:16 +0000 (17:51 +0100)]
x86/vpmu: disable VPMU if guest's CPUID indicates no PMU support
When toolstack overrides Intel CPUID leaf 0xa's PMU version with an
invalid value VPMU should not be available to the guest.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Boris Ostrovsky [Wed, 1 Mar 2017 16:50:48 +0000 (17:50 +0100)]
x86/vpmu: add get/put_vpmu() and VPMU_AVAILABLE
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests VPMU context is allocated lazily, during the first
access to VPMU MSRs. Since the leaf is typically queried before guest
attempts to read or write the MSRs it is likely that CPUID will report
no PMU support
* For PV guests the context is allocated eagerly but only in responce to
guest's XENPMU_init hypercall. There is a chance that the guest will
try to read CPUID before making this hypercall.
This patch introduces VPMU_AVAILABLE flag which is set (subject to vpmu_mode
constraints) during VCPU initialization for both PV and HVM guests. Since
this flag is expected to be managed together with vpmu_count, get/put_vpmu()
are added to simplify code.
vpmu_enabled() (renamed to vpmu_available()) can now use this new flag.
(As a side affect this patch also fixes a race in pvpmu_init() where we
increment vcpu_count in vpmu_initialise() after checking vpmu_mode)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 1 Mar 2017 16:49:57 +0000 (17:49 +0100)]
x86/mm: switch away from temporary 32-bit register names
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Andrew Cooper [Tue, 28 Feb 2017 14:07:09 +0000 (14:07 +0000)]
efi/boot: Don't free ebmalloc area at all
Freeing part of the BSS back for general use proves to be problematic. It is
not accounted for in xen_in_range(), causing errors when constructing the
IOMMU tables, resulting in a failure to boot.
Other smaller issues are that tboot treats the entire BSS as hypervisor data,
creating and checking a MAC of it on S3, and that, by being 1MB in size,
freeing it guarentees to shatter the hypervisor superpage mappings.
This is a stopgap fix to unblock master, while alternatives are discussed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 1 Mar 2017 09:40:48 +0000 (10:40 +0100)]
x86/Viridian: switch away from temporary 32-bit register names
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Jan Beulich [Wed, 1 Mar 2017 09:40:22 +0000 (10:40 +0100)]
x86/SVM: switch away from temporary 32-bit register names
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Jan Beulich [Wed, 1 Mar 2017 09:39:44 +0000 (10:39 +0100)]
x86/HVMemul: switch away from temporary 32-bit register names
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Haozhong Zhang [Wed, 1 Mar 2017 09:29:57 +0000 (10:29 +0100)]
x86: ensure copying runstate/time to L1 rather than L2
For a HVM domain, if a vcpu is in the nested guest mode,
__raw_copy_to_guest(), __copy_to_guest() and __copy_field_to_guest()
used by update_runstate_area() and update_secondary_system_time() will
copy data to L2 guest rather than the L1 guest.
This commit temporally clears the nested guest flag before all guest
copies in update_runstate_area() and update_secondary_system_time(),
and restores the flag after those guest copy operations.
The flag clear/restore is combined with the existing
smap_policy_change() which is renamed to update_guest_memory_policy().
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. It is not clear what a better default value could be.
Instead, loudly warn the user when dom0_mem is unspecified and wait 3
secs. Then use 512M.
Update the docs to specify that dom0_mem is required on ARM. (The
current xen-command-line document does not actually reflect the current
behavior of dom0_mem on ARM correctly.)
Andrew Cooper [Tue, 28 Feb 2017 15:17:17 +0000 (15:17 +0000)]
x86/layout: Correct Xen's idea of its own memory layout
c/s b4cd59fe "x86: reorder .data and .init when linking" had an unintended
side effect, where xen_in_range() and the tboot S3 MAC were no longer correct.
In practice, it means that Xen's .data section is excluded from consideration,
which means:
1) Default IOMMU construction for the hardware domain could create mappings.
2) .data isn't included in the tboot MAC checked on resume from S3.
Adjust the comments and virtual address anchors used to define the regions.
Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Juergen Gross [Fri, 24 Feb 2017 06:21:44 +0000 (07:21 +0100)]
xenstore: make memory report available via XS_CONTROL
Add a XS_CONTROL command to xenstored for doing a talloc report to a
file. Right now this is supported by specifying a command line option
when starting xenstored and sending a signal to the daemon to trigger
the report.
To dump the report to the standard log file call:
xenstore-control memreport
To dump the report to a new file call:
xenstore-control memreport <file>
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross [Fri, 24 Feb 2017 06:21:43 +0000 (07:21 +0100)]
xenstore: add support for changing log functionality dynamically
Today Xenstore supports logging only if specified at start of the
Xenstore daemon. As it can't be disabled during runtime it is not
recommended to start xenstored with logging enabled.
Add support for switching logging on and off at runtime and to
specify a (new) logfile. This is done via the XS_CONTROL wire command
which can be sent with xenstore-control.
To switch logging on just use:
xenstore-control log on
To switch it off again:
xenstore-control log off
To specify a (new) logfile:
xenstore-control logfile <file>
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross [Fri, 24 Feb 2017 06:21:42 +0000 (07:21 +0100)]
xenstore: enhance control command support
The Xenstore protocol supports the XS_CONTROL command for triggering
various actions in the Xenstore daemon. Enhance that support by using
a command table and adding a help function.
Support multiple control commands in the associated xenstore-control
program used to issue XS_CONTROL commands.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross [Fri, 24 Feb 2017 06:21:41 +0000 (07:21 +0100)]
xenstore: Split out XS_CONTROL action to dedicated source file
Move the XS_CONTROL handling of xenstored to a new source file
xenstored_control.c.
In order to avoid making get_string() in xenstored_core.c globally
visible use strlen() instead, which is save in this context due to
xs_count_strings() before returned a value > 1.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross [Fri, 24 Feb 2017 06:21:40 +0000 (07:21 +0100)]
xenstore: rename XS_DEBUG wire command
In preparation to support other than pure debug functionality via the
Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
XS_DEBUG an alias of it.
Add an alias xs_control_command for the associated xs_debug_command,
too.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Mon, 27 Feb 2017 11:47:10 +0000 (11:47 +0000)]
x86/shadow: Fix build with CONFIG_SHADOW_PAGING=n following c/s 45ac805
c/s 45ac805 "x86/paging: Package up the log dirty function pointers" neglected
the case when CONFIG_SHADOW_PAGING is disabled. Make a similar adjustment to
the none stubs.
Spotted by a Travis RANDCONFIG run.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
- When capturing branches, LBR H/W will always clear bits 61:62
regardless of the sign extension
- For WRMSR, bits 61:62 are considered the part of the sign extension
This bug affects only certain pCPUs (e.g. Haswell) with vCPUs that
use LBR. Fix it by sign-extending TSX bits in all LBR entries during
VM entry in affected cases.
LBR MSRs are currently not Live Migrated. In order to implement such
functionality, the MSR levelling work has to be done first because
hosts can have different LBR formats.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
projects / xen.git / log