similar to: [PATCH] svm: allow guest to use EFER.FFXSE and EFER.LMSLE

Now that the feature is officially documented (see http://support.amd.com/us/Processor_TechDocs/24593.pdf), I think it makes sense to also allow HVM guests to make use of it. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Andre Przywara <andre.przywara@amd.com> --- 2010-05-04.orig/xen/arch/x86/hvm/hvm.c 2010-04-22 14:43:25.000000000 +0200 +++ 2010-05-04/xen/arch/x86/hvm/hvm.c

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list

[SVM] Clear VMCB''s EFER.LME when guest disables paging Since the guest''s CR0.PG is always set (in shadow paging), EFER.LME must be cleared along with EFER.LMA when the guest is disabling paging. Signed-off-by: Travis Betak <travis.betak@amd.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

I recently realized that the original way of dealing with the DebugCtl MSR on VMX failed to make use of the dedicated guest VMCS field. This is being fixed with this patch. What is puzzling me to a certain degree is that while there is a guest VMCS field for this MSR, there''s no equivalent host load field, but there''s also no indication that the MSR would be cleared during a

Implement tsc adjust feature IA32_TSC_ADJUST MSR is maintained separately for each logical processor. A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows: 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0; 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts) value X from the TSC, the logical processor also adds (or subtracts) value X

>>> On 22.05.14 at 19:19, <mike at estone.ca> wrote: > "Jan Beulich" <JBeulich at suse.com> writes: > #Okay, this at least clarifies there is a (relatively big) RMRR. There is > #a change to the handling of these among the ones that'll become > #4.3.3 - mind giving > #http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=6c63041428cc348bcb2 >

"Jan Beulich" <JBeulich at suse.com> writes: #Okay, this at least clarifies there is a (relatively big) RMRR. There is #a change to the handling of these among the ones that'll become #4.3.3 - mind giving #http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=6c63041428cc348bcb2887afabd606bc4bd5523f #a try on top of your 4.3.2 (or trying the tip of the stable-4.3 branch)? #

.. for both 32-bit apps in 64-bit pv guests and 32on64. This patch depends on more than just guest_context saved/restored as guest state during save/restore/migrate (namely the new fields holding callback addresses). Since the 32-bit kernel doesn''t make use of syscall (it would be possible to do so now, when running on a 64-bit hv), the compat mode guest code path for syscall

We really don''t want the mmconf window to move/disappear whenever we use is ourselves, not only when we enabled it. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2297,8 +2297,7 @@ static int emulate_privileged_op(struct goto fail; if ( #ifdef CONFIG_X86_64 - (pci_probe

From: Yang Zhang <yang.z.zhang@Intel.com> We exposed the xsave feature to guest, but we didn''t allow guest to set CR4.OSXSAVE when guest running in nested mode. This will cause win 7 guest fail to use XP mode. In this patch, we allow guest to set CR4.OSXSAVE in nested mode when it has the xsave feature. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> ---

hvm_enable() copies the table contents rather than storing the pointer, so there''s no need to keep these tables post-boot. Also constify the return values of the per-vendor initialization functions, making clear that once the per-vendor initialization is complete, the vendor specific tables won''t get modified anymore. Finally, in hvm_enable(), use the returned pointer for all

x86:x2apic: Disable x2apic on x86-32 permanently x2apic initialization on x86_32 uses vcpu pointer before it is initialized. As x2apic is unlikely to be used on x86_32, this patch disables x2apic permanently on x86_32. It also asserts the sanity of vcpu pointer before dereference to prevent further misuse. Signed-off-by: Fengzhe Zhang <fengzhe.zhang@intel.com> diff -r 02c0af2bf280

From eb20603913ff7350cd25b39d1eb37b8fddd16053 Mon Sep 17 00:00:00 2001 From: Zhang Xiantao <xiantao.zhang@intel.com> Date: Sat, 25 Aug 2012 04:11:08 +0800 Subject: [PATCH 2/2] Nested: VM_ENTRY_IA32E_MODE shouldn''t be in default1 class for IA32_VM_ENTRY_CTLS_MSR. If set to 1, L2 guest''s paging mode maybe mis-judged and mis-set. Signed-off-by: Zhang Xiantao

TPR shadow/threshold feature is important to speedup the boot time for Windows guest. Besides, it is a must feature for certain VMM. We map virtual APIC page address and TPR threshold from L1 VMCS, and synch it into shadow VMCS in virtual vmentry. If TPR_BELOW_THRESHOLD VM exit is triggered by L2 guest, we inject it into L1 VMM for handling. Besides, this commit fixes an issue for apic access

Utilize some of the additions in the prior patches to clean up other code: - keep track of REP prefixes in only one variable - use REX_W in a few more places (instead of a literal number) Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -304,6 +304,10 @@ union vex { ptr[1] = rex |

Is it intentional that - under SVM, 32-bit guests can freely set EFER.LME - under VMX, 32-bit guests can''t access EFER at all? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

From: Yang Zhang <yang.z.zhang@Intel.com> With virtual unrestricted guest feature, L2 guest is allowed to run with PG cleared. Also, allow PAE not set during virtual vmexit emulation. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> --- xen/arch/x86/hvm/hvm.c | 3 ++- xen/arch/x86/hvm/vmx/vvmx.c | 3 +++ 2 files changed, 5 insertions(+), 1 deletions(-) diff --git

Add the new MEM_EVENT_REASON_MSR event type. Works similarly to the other register events, except event.gla always contains the MSR address (in addition to event.gfn, which holds the value). MEM_EVENT_REASON_MSR does not honour the HVMPME_onchangeonly bit, as doing so would complicate the hvm_msr_write_intercept() switch-based handling of writes for different MSR addresses, with little added

Direct calls perform better, so we should prefer them and use indirect ones only when there indeed is a need for indirection. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg void pmu_apic_interrupt(struct cpu_user_regs *regs) { ack_APIC_irq(); -

The first patch really isn''t as much of a follow-up than what triggered the security issues to be noticed in the first place. 1: x86: preserve FPU selectors for 32-bit guest code 2: x86: fix XCR0 handling 3: x86/xsave: adjust state management 4: x86/fxsave: bring in line with recent xsave adjustments The first two I would see as candidates for 4.3 (as well as subsequent backporting,