similar to: [PATCH 2/3 v2] XSAVE/XRSTOR: fix frozen states

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,

From eee3a3d3072651327453220876ebe9a7345d6ffe Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Tue, 19 Nov 2013 18:44:45 +0800 Subject: [PATCH 2/5] X86 architecture instruction set extension definiation Intel has released new version of Intel Architecture Instruction Set Extensions Programming Reference, add new features like AVX-512, MPX, etc. refer

Hi, Keir, The following patches refines Xen support for CPU Xsave/Xrestore support. There are four patches included. Patch 1/4: Cleaning up existing Xsave code in Xen. Replace xfeature_low and xfeature_high with a u64 variable xfeature_mask. In structure hvm_vcpu, rename xfeature_mask to xcr0 Provide EDX:EAX with all bits set to 1 for XSAVE and XRSTOR as spec recommends

From a06ea5f6960b7bfa473f5d56762ce3a06b0a2b07 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Mon, 25 Nov 2013 01:13:12 +0800 Subject: [PATCH 2/4 V2] X86: enable support for new ISA extensions Intel has released new version of Intel Architecture Instruction Set Extensions Programming Reference, adding new features like AVX-512, MPX, etc. Refer to

This patch supports xsave (CPUID:0x0000000D) enumeration for all sub-leaves. In specific, it fixes the following issues: 1. The sub-leaves of CPUID:0x0000000D aren''t contiguous. Hypervisor shouldn''t use register values to stop the enumeration. This patch moves checking on XSAVE sub-leaves out of if-else statement. It also bumps up sub-leaves to 63. 2. It creates a common

XSAVE/XRSTOR manages the existing and future processor extended states on x86 architecture. The XSAVE/XRSTOR infrastructure is defined in Intel SDMs: http://www.intel.com/products/processor/manuals/ The patch uses the classical CR0.TS based algorithm to manage the states on context switch. At present, we know 3 bits in the XFEATURE_ENABLED_MASK: FPU, SSE and YMM. YMM is defined in Intel AVX

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

The first and third patches are cleaned up versions of an earlier v3 submission by Yang. 1: Nested VMX: check VMX capability before read VMX related MSRs 2: VMX: clean up capability checks 3: Nested VMX: fix IA32_VMX_CR4_FIXED1 msr emulation 4: x86: make hvm_cpuid() tolerate NULL pointers Signed-off-by: Jan Beulich <jbeulich@suse.com>

On Tue, Apr 28, 2020 at 05:17:14PM +0200, Joerg Roedel wrote: > From: Mike Stunes <mstunes at vmware.com> > > To avoid a future VMEXIT for a subsequent CPUID function, cache the > results returned by CPUID into an xarray. > > [tl: coding standard changes, register zero extension] > > Signed-off-by: Mike Stunes <mstunes at vmware.com> > Signed-off-by: Tom

On Tue, Apr 28, 2020 at 05:17:14PM +0200, Joerg Roedel wrote: > From: Mike Stunes <mstunes at vmware.com> > > To avoid a future VMEXIT for a subsequent CPUID function, cache the > results returned by CPUID into an xarray. > > [tl: coding standard changes, register zero extension] > > Signed-off-by: Mike Stunes <mstunes at vmware.com> > Signed-off-by: Tom

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

When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. This was not done correctly, since in context_switch update_vcpu_system_time was called before vmx_do_resume,

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one

Changes from v1: - Define new struct hvm_trap to represent information of trap, include instruction length. - Renames hvm_inject_exception to hvm_inject_trap. Then define a couple of wrappers around that function for existing callers, so that their parameter lists actually *shrink*. This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP),

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the

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

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

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the default values

This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP), INTn instruction emulation. Introduce new function vmx_inject_sw_exception() which deliver the software excetion, software interrupt and privileged software exception. Split hardware exception as a seperate function(old function vmx_inject_hw_exception()). Also Passed down intruction length

Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 with debugger_attached set, I was seeing the debug traps getting lost from the EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from real to protected mode. In my codebase, I could fix this trivially by clearing the debug_state_latch and letting vmx_do_resume() reapply the setting. However, while it looks like a valid