similar to: [PATCH] vmx: add the support of XSAVE/XRSTOR to VMX guest

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

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

If a guest sets a state and dirties the state, but later temporarily clears the state, and at this time if this vcpu is scheduled out, then other vcpus may corrupt the state before the vcpu is scheduled in again, thus the state cannot be restored correctly. To solve this issue, this patch save/restore all states unconditionally on vcpu context switch. Signed-off-by: Weidong Han

# HG changeset patch # User Paul Durrant <paul.durrant@citrix.com> # Date 1316781326 -3600 # Node ID 55a9ffe0ca81b9b4183626f81fa54343d378704f # Parent cc339ab1d91789ed6ff4d3d9abc1bae2e90ac294 Add save/restore support for viridian APIC assist pfn. c/s 17b754cab7b0 introduced a per-VCPU viridian structure to store the APIC assist pfn. This patch adds support for save and restore of that

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> ---

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

Hi Frank, What does --debug-only=vectorize says? You may try to get the datalayout and the triple on the IR header, just to make sure you got everything right. LLVM will honour those, and front-ends should create them correctly. --renato On 1 July 2015 at 19:06, Frank Winter <fwinter at jlab.org> wrote: > I realized that the function parameters had no alignment attributes on them.

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

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them.

From: Borislav Petkov <bp at suse.de> Using static_cpu_has() is pointless on those paths, convert them to the boot_cpu_has() variant. No functional changes. Reported-by: Nadav Amit <nadav.amit at gmail.com> Signed-off-by: Borislav Petkov <bp at suse.de> Cc: Aubrey Li <aubrey.li at intel.com> Cc: Dave Hansen <dave.hansen at intel.com> Cc: Dominik Brodowski <linux

flight 19846 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/19846/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 16 guest-start fail REGR. vs. 19177 test-i386-i386-pair 16 guest-start fail REGR. vs. 19177 build-armhf-pvops 1

X86: implement PCID/INVPCID for hvm This patch handle PCID/INVPCID for hvm: For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, and we just set INVPCID non-root behavior as running natively; For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPCID at vmm by setting INVPCID non-root behavior as vmexit. Signed-off-by: Liu, Jinsong

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,

Thank you. I notice the system then jumps to F000:FFF0 to execute. But because VMX is turned on, switching to real-mode would incur problems? I don’t find any clue to turn on the vm86 mode as Readme in the tools/firmware directory puts. Best regards, Hu Jia Yi Ext: 20430 Tel: 65-67510430 -----Original Message----- From: Cui, Dexuan [mailto:dexuan.cui@intel.com] Sent: Thursday,

Some operating systems access the local APIC TPR very frequently, and we handle that using software-based local APIC virtualization in Xen today. Such virtualization incurs a number of VM exits from the memory-access instructions against the APIC page in the guest. The attached patch enables the TPR shadow feature that provides APIC TPR virtualization in hardware. Our tests indicate it can

Clone the existing movq emulation to also support the most fundamental SIMD FP moves. Extend the testing code to also exercise these instructions. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -629,6 +629,60 @@ int main(int argc, char **argv) else

I'll explain what we see in the code. 1. The caller saves XMM registers across the call if needed (according to DEFS definition). YMMs are not in the set, so caller does not take care. 2. The callee preserves XMMs but works with YMMs and clobbering them. 3. So after the call, the upper part of YMM is gone. - Elena -----Original Message----- From: Bruno Cardoso Lopes [mailto:bruno.cardoso at

This is the wrong code: declare <16 x float> @foo(<16 x float>) define <16 x float> @test(<16 x float> %x, <16 x float> %y) nounwind { entry: %x1 = fadd <16 x float> %x, %y %call = call <16 x float> @foo(<16 x float> %x1) nounwind %y1 = fsub <16 x float> %call, %y ret <16 x float> %y1 } ./llc -mattr=+avx

On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > I'll explain what we see in the code. > 1. The caller saves XMM registers across the call if needed (according to DEFS definition). > YMMs are not in the set, so caller does not take care. This is not how the register allocator works. It saves the registers holding values, it doesn't care which alias is clobbered. Are you

Hello List, I have a problem with an Onborad scsci, that won't boot a isolinux-cd: anyone got a clue? Mainboard is ASUS-CUV4X-DLS with onboard LSI 35c1010-33 Controller. Board-Bios is Award Medaillion 6.0 and Controller Bios is Symbios SDMS v4.0 (4.18.02) The CDRW device to boot from is a Yamaha CRW2100S Rev1.0H I tried Isolinux 1.63 and 1.66 with similar "success": here's