similar to: [PATCH] MSR save/restore for x86_64 VMX domains

Ian, Keir, This patch is to boot 32-bit VMX guest on the 64-bit host. Double-compile is used to make both 64-bit guest and 32-bit guest can work, the shadow page-table uses current 64-bit shadow code''s structure to simulate 32-bit guest''s 2-level page-table. Signed-off-by: Chengyuan Li <chengyuan.li@intel.com> Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com>

Quite frankly it might make more sense to define a cross-VM *cpuid* range. The cpuid leaf can just point to the MSR. The big question is who will be willing to be the registrar. On September 18, 2014 11:35:39 AM PDT, Andy Lutomirski <luto at amacapital.net> wrote: >On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun ><jun.nakajima at intel.com> wrote: >> On Thu, Sep 18, 2014

Currently the mmio_operands assumes writing to memory when operand 0 is register or immediate, this is false for cmp/test opcode. This patch resolve this problem, please review. Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com> Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> Thanks Yunhong Jiang _______________________________________________ Xen-devel mailing list

On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at amacapital.net> wrote: > On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com> wrote: >> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at amacapital.net> wrote: >> >>> So, as a concrete straw-man: >>> >>> CPUID leaf 0x48000000 would return a maximum

Propagate guest MSR writes to machine MSRs immediately Right now, we have an exposure between the time the MSR is written and used by an instruction such as syscall. If there is a context switch and we do vmx_do_restore_msrs(), everything goes fine. But if we don''t, then we execute the syscall with the wrong MSR. Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>

On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski <luto at amacapital.net> wrote: > On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at amacapital.net> wrote: >> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com> wrote: >>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at amacapital.net> wrote: >>>

On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski <luto at amacapital.net> wrote: > On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at amacapital.net> wrote: >> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com> wrote: >>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at amacapital.net> wrote: >>>

On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: > > >> -----Original Message----- >> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >> Bonzini >> Sent: Thursday, September 18, 2014 10:18 AM >> To: Nakajima, Jun; KY Srinivasan >> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb

The patch enables x86_32 PAE unmodified guests on 64-bit Xen when the hvm feature is present. We tested only Linux at this point, and we''ll improve the functionality as we test other guests. The SVM needs the equivalent changes to the vmc.c to get this functionality working, but this patch does not break the build. Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>

> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo > Bonzini > Sent: Thursday, September 18, 2014 10:18 AM > To: Nakajima, Jun; KY Srinivasan > Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels > Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux > Virtualization

> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo > Bonzini > Sent: Thursday, September 18, 2014 10:18 AM > To: Nakajima, Jun; KY Srinivasan > Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels > Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux > Virtualization

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: >> >> >>> -----Original Message----- >>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >>> Bonzini >>> Sent: Thursday, September 18, 2014 10:18

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: >> >> >>> -----Original Message----- >>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >>> Bonzini >>> Sent: Thursday, September 18, 2014 10:18

Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. As the person who writes the RNG code in Windows, I have a few comments: DETECTION: It should be possible to detect this feature through CPUID or similar mechanism. That allows the code that uses this feature to be written without needing the ability to catch CPU exceptions. I could be

Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. As the person who writes the RNG code in Windows, I have a few comments: DETECTION: It should be possible to detect this feature through CPUID or similar mechanism. That allows the code that uses this feature to be written without needing the ability to catch CPU exceptions. I could be

On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at amacapital.net> wrote: > >> So, as a concrete straw-man: >> >> CPUID leaf 0x48000000 would return a maximum leaf number in EAX (e.g. >> 0x48000001) along with a signature value (e.g. "CrossHVPara\0") in

On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at amacapital.net> wrote: > >> So, as a concrete straw-man: >> >> CPUID leaf 0x48000000 would return a maximum leaf number in EAX (e.g. >> 0x48000001) along with a signature value (e.g. "CrossHVPara\0") in

Il 18/09/2014 19:13, Nakajima, Jun ha scritto: > In terms of the address for the MSR, I suggest that you choose one > from the range between 40000000H - 400000FFH. The SDM (35.1 > ARCHITECTURAL MSRS) says "All existing and > future processors will not implement any features using any MSR in > this range." Hyper-V already defines many synthetic MSRs in this > range, and

On 09/25/2017 07:54 PM, Paolo Bonzini wrote: > On 25/09/2017 06:44, Wei Wang wrote: >> >> +static void update_msr_autoload_count_max(void) >> +{ >> + u64 vmx_msr; >> + int n; >> + >> + /* >> + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is >> + * n, then (n + 1) * 512 is the recommended max number of MSRs to be

vmx_vmcs.c: fix inline asms for x86-64 Signed-Off-By: Benjamin Liu <benjamin.liu@intel.com> Signed-Off-By: Arun Sharma <arun.sharma@intel.com> diff -Nru a/xen/arch/x86/vmx_vmcs.c b/xen/arch/x86/vmx_vmcs.c --- a/xen/arch/x86/vmx_vmcs.c 2005-04-18 16:49:37 -07:00 +++ b/xen/arch/x86/vmx_vmcs.c 2005-04-18 16:49:37 -07:00 @@ -187,7 +187,7 @@ vmx_setup_platform(ed, ec);