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
On 29/11/06 13:07, "Jan Beulich" <jbeulich@novell.com> wrote:> 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, JanI''m sure any differences are unintentional. There is obviously scope for making much of the MSR and CPUID code non-vmx/svm specific. I assume that this particular difference doesn''t really matter? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jan Beulich > Sent: 29 November 2006 13:07 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] EFER in HVM guests > > Is it intentional that > - under SVM, 32-bit guests can freely set EFER.LMEEhm, I guess you mean "on 32-bit hypervisor", as it''s impossible to distinguish a 32-bit and 64-bit guest until the guest is setting LME... ;-). The correct reaction for a 32-bit hypervisor is to react like a "non-64-bit capable processor", which means that EFER has the LME as a mbz-bit. GP-fault if it''s written as a one. We do prevent the long-mode from being advertised by CPUID when HV is in 32-bit mode, so if the guest is well-behaved, it shouldn''t try to set this bit. -- Mats> - 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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <keir@xensource.com> 29.11.06 14:09 >>> >On 29/11/06 13:07, "Jan Beulich" <jbeulich@novell.com> wrote: > >> 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 > >I''m sure any differences are unintentional. There is obviously scope for >making much of the MSR and CPUID code non-vmx/svm specific. > >I assume that this particular difference doesn''t really matter?I think it does - allowing a guest to enable EFER.LME when the hypervisor is a 32-bit one is clearly a security problem: While I haven''t tried it, I would suspect the moment you load a context with such an EFER the whole system''s dead. Not being able to access EFER is also a potential problem, as a guest should be allowed to set EFER.NX (at least) - the CPUID handling code specifically does not suppress this bit if the guest is allowed to use PAE (which we agreed a few days ago should be the default anyway). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> Is it intentional that >> - under SVM, 32-bit guests can freely set EFER.LME > >Ehm, I guess you mean "on 32-bit hypervisor", as it''s impossible to >distinguish a 32-bit and 64-bit guest until the guest is setting LME... >;-).Yes, sorry for being imprecise. I meant a 32-bit hvm guest on a 32-bit hv. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jan Beulich > Sent: 29 November 2006 14:08 > To: xen-devel@lists.xensource.com; Keir Fraser > Subject: Re: [Xen-devel] EFER in HVM guests > > >>> Keir Fraser <keir@xensource.com> 29.11.06 14:09 >>> > >On 29/11/06 13:07, "Jan Beulich" <jbeulich@novell.com> wrote: > > > >> 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 > > > >I''m sure any differences are unintentional. There is > obviously scope for > >making much of the MSR and CPUID code non-vmx/svm specific. > > > >I assume that this particular difference doesn''t really matter? > > I think it does - allowing a guest to enable EFER.LME when the > hypervisor is a 32-bit one is clearly a security problem: While I > haven''t tried it, I would suspect the moment you load a context > with such an EFER the whole system''s dead.Actually, it''s a bit more complex than that, but assuming the guest has access to EFER, it also has access to CR0, so it could try to enable long mode by: CR0.PG = 0 CR4.PAE = 1 EFER.LME = 1 CR0.PG = 1 If PAE isn''t available, it wouldn''t be possible to set long-mode (processor consistency checks for PAE=1 when LME=1). See section 14.6.3 in the AMD Programmers Manual Vol 2. I think that the setting of EFER.LME in 32-bit Hypervisor should generate GP-fault, as that''s what the real processor does...> Not being able to access EFER is also a potential problem, as a > guest should be allowed to set EFER.NX (at least) - the CPUID > handling code specifically does not suppress this bit if the guest > is allowed to use PAE (which we agreed a few days ago should > be the default anyway).This makes sense to me. As well as EFER.SCE, perhaps? -- Mats> > Jan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich wrote:>>>> Keir Fraser <keir@xensource.com> 29.11.06 14:09 >>> >> On 29/11/06 13:07, "Jan Beulich" <jbeulich@novell.com> wrote: >> >>> 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 >> >> I''m sure any differences are unintentional. There is obviously scope >> for making much of the MSR and CPUID code non-vmx/svm specific. >> >> I assume that this particular difference doesn''t really matter? > > I think it does - allowing a guest to enable EFER.LME when the > hypervisor is a 32-bit one is clearly a security problem: While I > haven''t tried it, I would suspect the moment you load a context > with such an EFER the whole system''s dead. > Not being able to access EFER is also a potential problem, as a > guest should be allowed to set EFER.NX (at least) - the CPUID > handling code specifically does not suppress this bit if the guest > is allowed to use PAE (which we agreed a few days ago should > be the default anyway). > > Jan >I agree that we should allow 32-bit guests to set EFER.NX on the PAE Xen. We''ll fix it. EFER.SCE should not be set on IA-32. Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
*Please* can you make the handling of generic CPUID leaves and architectural MSRs common HVM code? There is lots of needless code duplication right now with niggling differences that shouldn''t be necessary. -- Keir On 29/11/06 16:34, "Nakajima, Jun" <jun.nakajima@intel.com> wrote:>> I think it does - allowing a guest to enable EFER.LME when the >> hypervisor is a 32-bit one is clearly a security problem: While I >> haven''t tried it, I would suspect the moment you load a context >> with such an EFER the whole system''s dead. >> Not being able to access EFER is also a potential problem, as a >> guest should be allowed to set EFER.NX (at least) - the CPUID >> handling code specifically does not suppress this bit if the guest >> is allowed to use PAE (which we agreed a few days ago should >> be the default anyway). >> >> Jan >> > > I agree that we should allow 32-bit guests to set EFER.NX on the PAE > Xen. We''ll fix it. EFER.SCE should not be set on IA-32._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Nakajima, Jun > Sent: 29 November 2006 16:35 > To: Jan Beulich; xen-devel@lists.xensource.com; Keir Fraser > Subject: RE: [Xen-devel] EFER in HVM guests > > Jan Beulich wrote: > >>>> Keir Fraser <keir@xensource.com> 29.11.06 14:09 >>> > >> On 29/11/06 13:07, "Jan Beulich" <jbeulich@novell.com> wrote: > >> > >>> 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 > >> > >> I''m sure any differences are unintentional. There is > obviously scope > >> for making much of the MSR and CPUID code non-vmx/svm specific. > >> > >> I assume that this particular difference doesn''t really matter? > > > > I think it does - allowing a guest to enable EFER.LME when the > > hypervisor is a 32-bit one is clearly a security problem: While I > > haven''t tried it, I would suspect the moment you load a context > > with such an EFER the whole system''s dead. > > Not being able to access EFER is also a potential problem, as a > > guest should be allowed to set EFER.NX (at least) - the CPUID > > handling code specifically does not suppress this bit if the guest > > is allowed to use PAE (which we agreed a few days ago should > > be the default anyway). > > > > Jan > > > > I agree that we should allow 32-bit guests to set EFER.NX on the PAE > Xen. We''ll fix it. EFER.SCE should not be set on IA-32.Why not? If CPUID bits indicate that it''s available, it can be used in 32- or 64-bit mode. -- Mats> > Jun > --- > Intel Open Source Technology Center > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats wrote:>> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >> Nakajima, Jun Sent: 29 November 2006 16:35 >> To: Jan Beulich; xen-devel@lists.xensource.com; Keir Fraser >> Subject: RE: [Xen-devel] EFER in HVM guests >> >> Jan Beulich wrote: >>>>>> Keir Fraser <keir@xensource.com> 29.11.06 14:09 >>> >>>> On 29/11/06 13:07, "Jan Beulich" <jbeulich@novell.com> wrote: >>>> >>>>> 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 >>>> >>>> I''m sure any differences are unintentional. There is obviously >>>> scope for making much of the MSR and CPUID code non-vmx/svm >>>> specific. >>>> >>>> I assume that this particular difference doesn''t really matter? >>> >>> I think it does - allowing a guest to enable EFER.LME when the >>> hypervisor is a 32-bit one is clearly a security problem: While I >>> haven''t tried it, I would suspect the moment you load a context >>> with such an EFER the whole system''s dead. >>> Not being able to access EFER is also a potential problem, as a >>> guest should be allowed to set EFER.NX (at least) - the CPUID >>> handling code specifically does not suppress this bit if the guest >>> is allowed to use PAE (which we agreed a few days ago should >>> be the default anyway). >>> >>> Jan >>> >> >> I agree that we should allow 32-bit guests to set EFER.NX on the PAE >> Xen. We''ll fix it. EFER.SCE should not be set on IA-32. > > Why not? If CPUID bits indicate that it''s available, it can be used in > 32- or 64-bit mode. >On IA-32 (i.e. I meant Intel), it''s not available. The merged HVM code should use CPUID to handle this kind of differences. Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Is this the framework what you want? And we still need merge the common cases here. -Xin>-----Original Message----- >From: xen-devel-bounces@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser >Sent: 2006年11月30日 1:22 >To: Nakajima, Jun; Jan Beulich; xen-devel@lists.xensource.com; >Keir Fraser >Subject: Re: [Xen-devel] EFER in HVM guests > > >*Please* can you make the handling of generic CPUID leaves and >architectural >MSRs common HVM code? There is lots of needless code >duplication right now >with niggling differences that shouldn''t be necessary. > > -- Keir > >On 29/11/06 16:34, "Nakajima, Jun" <jun.nakajima@intel.com> wrote: > >>> I think it does - allowing a guest to enable EFER.LME when the >>> hypervisor is a 32-bit one is clearly a security problem: While I >>> haven''t tried it, I would suspect the moment you load a context >>> with such an EFER the whole system''s dead. >>> Not being able to access EFER is also a potential problem, as a >>> guest should be allowed to set EFER.NX (at least) - the CPUID >>> handling code specifically does not suppress this bit if the guest >>> is allowed to use PAE (which we agreed a few days ago should >>> be the default anyway). >>> >>> Jan >>> >> >> I agree that we should allow 32-bit guests to set EFER.NX on the PAE >> Xen. We''ll fix it. EFER.SCE should not be set on IA-32. > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>And we still need merge the common cases here.But that is the important part. So far you basically only renamed functions. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I have no SVM env. Can anyone help on that side? -Xin>-----Original Message----- >From: Jan Beulich [mailto:jbeulich@novell.com] >Sent: 2006年12月13日 21:08 >To: Li, Xin B >Cc: Nakajima, Jun; xen-devel@lists.xensource.com; Keir Fraser >Subject: RE: [Xen-devel] EFER in HVM guests > >>And we still need merge the common cases here. > >But that is the important part. So far you basically only >renamed functions. > >Jan >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>-----Original Message----- >From: Jan Beulich [mailto:jbeulich@novell.com] >Sent: 2006年12月13日 21:08 >To: Li, Xin B >Cc: Nakajima, Jun; xen-devel@lists.xensource.com; Keir Fraser >Subject: RE: [Xen-devel] EFER in HVM guests > >>And we still need merge the common cases here. > >But that is the important part. So far you basically only >renamed functions. >That''s the start point we can merge. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Not quite what I had in mind. Control starts from VMX/SVM so we
shouldn''t
need an extra hvm_ops hook function.
What I envisage is something like:
Vmx_cpuid() {
/* CPU-specific pre-processing goes here. */
hvm_cpuid();
/* CPU-specific post-processing goes here. */
}
So VMX/SVM calls out to HVM, not vice versa. You can see that this also
gives you full flexibility to do pre-processing (before calling hvm-generic
function) as well as post-processing.
As Jan points out, there''s little point in doing this without actually
pulling out some common code at the same time. Or hvm_cpuid() will be a
no-op. :-)
-- Keir
On 13/12/06 12:48, "Li, Xin B" <xin.b.li@intel.com> wrote:
> Is this the framework what you want?
> And we still need merge the common cases here.
> -Xin
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
>> Sent: 2006年11月30日 1:22
>> To: Nakajima, Jun; Jan Beulich; xen-devel@lists.xensource.com;
>> Keir Fraser
>> Subject: Re: [Xen-devel] EFER in HVM guests
>>
>>
>> *Please* can you make the handling of generic CPUID leaves and
>> architectural
>> MSRs common HVM code? There is lots of needless code
>> duplication right now
>> with niggling differences that shouldn''t be necessary.
>>
>> -- Keir
>>
>> On 29/11/06 16:34, "Nakajima, Jun"
<jun.nakajima@intel.com> wrote:
>>
>>>> I think it does - allowing a guest to enable EFER.LME when the
>>>> hypervisor is a 32-bit one is clearly a security problem: While
I
>>>> haven''t tried it, I would suspect the moment you load
a context
>>>> with such an EFER the whole system''s dead.
>>>> Not being able to access EFER is also a potential problem, as a
>>>> guest should be allowed to set EFER.NX (at least) - the CPUID
>>>> handling code specifically does not suppress this bit if the
guest
>>>> is allowed to use PAE (which we agreed a few days ago should
>>>> be the default anyway).
>>>>
>>>> Jan
>>>>
>>>
>>> I agree that we should allow 32-bit guests to set EFER.NX on the
PAE
>>> Xen. We''ll fix it. EFER.SCE should not be set on IA-32.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Xin, when you have a tested hvm/vmx functional patch, we can run thru SVM platforms for testing and determine if any AMD specific modifications are needed. Just post to the list the patch/changeset tested, (CC me directly if you remember). I''ll have our test group run thru the boot tests first, then our usual ltp/cerberus and windows testing over a few days. Cheers, -- Tom> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Keir Fraser > Sent: Wednesday, December 13, 2006 8:37 AM > To: Li, Xin B; Keir Fraser; Nakajima, Jun; Jan Beulich; > xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] EFER in HVM guests > > Not quite what I had in mind. Control starts from VMX/SVM so > we shouldn''t need an extra hvm_ops hook function. > > What I envisage is something like: > > Vmx_cpuid() { > /* CPU-specific pre-processing goes here. */ > hvm_cpuid(); > /* CPU-specific post-processing goes here. */ } > > So VMX/SVM calls out to HVM, not vice versa. You can see that > this also gives you full flexibility to do pre-processing > (before calling hvm-generic > function) as well as post-processing. > > As Jan points out, there''s little point in doing this without > actually pulling out some common code at the same time. Or > hvm_cpuid() will be a no-op. :-) > > -- Keir > > > > On 13/12/06 12:48, "Li, Xin B" <xin.b.li@intel.com> wrote: > > > Is this the framework what you want? > > And we still need merge the common cases here. > > -Xin > > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xensource.com > >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir > >> Fraser > >> Sent: 2006年11月30日 1:22 > >> To: Nakajima, Jun; Jan Beulich; > xen-devel@lists.xensource.com; Keir > >> Fraser > >> Subject: Re: [Xen-devel] EFER in HVM guests > >> > >> > >> *Please* can you make the handling of generic CPUID leaves and > >> architectural MSRs common HVM code? There is lots of needless code > >> duplication right now with niggling differences that shouldn''t be > >> necessary. > >> > >> -- Keir > >> > >> On 29/11/06 16:34, "Nakajima, Jun" <jun.nakajima@intel.com> wrote: > >> > >>>> I think it does - allowing a guest to enable EFER.LME when the > >>>> hypervisor is a 32-bit one is clearly a security > problem: While I > >>>> haven''t tried it, I would suspect the moment you load a context > >>>> with such an EFER the whole system''s dead. > >>>> Not being able to access EFER is also a potential problem, as a > >>>> guest should be allowed to set EFER.NX (at least) - the CPUID > >>>> handling code specifically does not suppress this bit if > the guest > >>>> is allowed to use PAE (which we agreed a few days ago > should be the > >>>> default anyway). > >>>> > >>>> Jan > >>>> > >>> > >>> I agree that we should allow 32-bit guests to set EFER.NX > on the PAE > >>> Xen. We''ll fix it. EFER.SCE should not be set on IA-32. > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Xin, when you have a tested hvm/vmx functional patch, we can >run thru SVM platforms for testing and determine if any AMD >specific modifications are needed. Just post to the list the >patch/changeset tested, (CC me directly if you remember). I''ll >have our test group run thru the boot tests first, then our >usual ltp/cerberus and windows testing over a few days. >Cheers, > -- TomHi Tom, the patch is attached, and I''ve tested it on my side, pls test your side. One thing strange to me, why your leaf 0x80000001 needs to handle PAE and APIC feature bits, seems it''s same as 0x00000001, is this intended? thanks -Xin> >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >> Keir Fraser >> Sent: Wednesday, December 13, 2006 8:37 AM >> To: Li, Xin B; Keir Fraser; Nakajima, Jun; Jan Beulich; >> xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] EFER in HVM guests >> >> Not quite what I had in mind. Control starts from VMX/SVM so >> we shouldn''t need an extra hvm_ops hook function. >> >> What I envisage is something like: >> >> Vmx_cpuid() { >> /* CPU-specific pre-processing goes here. */ >> hvm_cpuid(); >> /* CPU-specific post-processing goes here. */ } >> >> So VMX/SVM calls out to HVM, not vice versa. You can see that >> this also gives you full flexibility to do pre-processing >> (before calling hvm-generic >> function) as well as post-processing. >> >> As Jan points out, there''s little point in doing this without >> actually pulling out some common code at the same time. Or >> hvm_cpuid() will be a no-op. :-) >> >> -- Keir >> >> >> >> On 13/12/06 12:48, "Li, Xin B" <xin.b.li@intel.com> wrote: >> >> > Is this the framework what you want? >> > And we still need merge the common cases here. >> > -Xin >> > >> >> -----Original Message----- >> >> From: xen-devel-bounces@lists.xensource.com >> >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir >> >> Fraser >> >> Sent: 2006年11月30日 1:22 >> >> To: Nakajima, Jun; Jan Beulich; >> xen-devel@lists.xensource.com; Keir >> >> Fraser >> >> Subject: Re: [Xen-devel] EFER in HVM guests >> >> >> >> >> >> *Please* can you make the handling of generic CPUID leaves and >> >> architectural MSRs common HVM code? There is lots of >needless code >> >> duplication right now with niggling differences that shouldn''t be >> >> necessary. >> >> >> >> -- Keir >> >> >> >> On 29/11/06 16:34, "Nakajima, Jun" <jun.nakajima@intel.com> wrote: >> >> >> >>>> I think it does - allowing a guest to enable EFER.LME when the >> >>>> hypervisor is a 32-bit one is clearly a security >> problem: While I >> >>>> haven''t tried it, I would suspect the moment you load a context >> >>>> with such an EFER the whole system''s dead. >> >>>> Not being able to access EFER is also a potential problem, as a >> >>>> guest should be allowed to set EFER.NX (at least) - the CPUID >> >>>> handling code specifically does not suppress this bit if >> the guest >> >>>> is allowed to use PAE (which we agreed a few days ago >> should be the >> >>>> default anyway). >> >>>> >> >>>> Jan >> >>>> >> >>> >> >>> I agree that we should allow 32-bit guests to set EFER.NX >> on the PAE >> >>> Xen. We''ll fix it. EFER.SCE should not be set on IA-32. >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xensource.com >> >> http://lists.xensource.com/xen-devel >> >> >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@lists.xensource.com >> > http://lists.xensource.com/xen-devel >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Li, Xin B > Sent: 18 December 2006 15:11 > To: Woller, Thomas; Keir Fraser; Nakajima, Jun; Jan Beulich; > xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] EFER in HVM guests > > >Xin, when you have a tested hvm/vmx functional patch, we can > >run thru SVM platforms for testing and determine if any AMD > >specific modifications are needed. Just post to the list the > >patch/changeset tested, (CC me directly if you remember). I''ll > >have our test group run thru the boot tests first, then our > >usual ltp/cerberus and windows testing over a few days. > >Cheers, > > -- Tom > > Hi Tom, the patch is attached, and I''ve tested it on my side, > pls test your side. > One thing strange to me, why your leaf 0x80000001 needs to > handle PAE and APIC feature bits, seems it''s same as > 0x00000001, is this intended? > thanks > -XinXin, Good job - thanks for the patch. A few notes: The 0x80000001 leaf was originally an "AMD only" leaf for adding new "non-Intel compatible" features, such as 3DNow! and long-mode, but since x86_64 was adopted by Intel, it''s available on Intel processors too. It should be done the same on both AMD and Intel, and since 0x80000001 contains another copy of the APIC and PAE bits, they should be masked for both processors on both 1 and 0x80000001. [Of course, I doubt that anyone would "prefer" to use 0x80000001 from using 1 as the index for the leaf unless the coder is already reading 0x800000001 for some other reason - to detect LM for example]. I would like to see the handling of 0x80000001 in the common case cover PAE/PSE36/APIC features, as that''s nor arch-specific. The fact that no-one actually uses it currently isn''t a good argument for not getting it right at this time rather than fixing hard-to-find bugs later on... ;-) Clearing MWAIT bit should also be made common - I doubt anyone will notice the single instruction saved by combining it with a bunch of other bits, compared to the overall benefit of trivially seeing that it''s dealt with the same way on both architectures. Just out of curiosity, why did you change the parameters passed to svm_do_cpuid - I can see why you wouldn''t need to pass regs->eax when it''s available in regs, but digging out the vmcb again can''t be better than passing the already existing one? [Don''t worry about it, I''m just curious about why the change was made]. -- Mats> > > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xensource.com > >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > >> Keir Fraser > >> Sent: Wednesday, December 13, 2006 8:37 AM > >> To: Li, Xin B; Keir Fraser; Nakajima, Jun; Jan Beulich; > >> xen-devel@lists.xensource.com > >> Subject: Re: [Xen-devel] EFER in HVM guests > >> > >> Not quite what I had in mind. Control starts from VMX/SVM so > >> we shouldn''t need an extra hvm_ops hook function. > >> > >> What I envisage is something like: > >> > >> Vmx_cpuid() { > >> /* CPU-specific pre-processing goes here. */ > >> hvm_cpuid(); > >> /* CPU-specific post-processing goes here. */ } > >> > >> So VMX/SVM calls out to HVM, not vice versa. You can see that > >> this also gives you full flexibility to do pre-processing > >> (before calling hvm-generic > >> function) as well as post-processing. > >> > >> As Jan points out, there''s little point in doing this without > >> actually pulling out some common code at the same time. Or > >> hvm_cpuid() will be a no-op. :-) > >> > >> -- Keir > >> > >> > >> > >> On 13/12/06 12:48, "Li, Xin B" <xin.b.li@intel.com> wrote: > >> > >> > Is this the framework what you want? > >> > And we still need merge the common cases here. > >> > -Xin > >> > > >> >> -----Original Message----- > >> >> From: xen-devel-bounces@lists.xensource.com > >> >> [mailto:xen-devel-bounces@lists.xensource.com] On > Behalf Of Keir > >> >> Fraser > >> >> Sent: 2006年11月30日 1:22 > >> >> To: Nakajima, Jun; Jan Beulich; > >> xen-devel@lists.xensource.com; Keir > >> >> Fraser > >> >> Subject: Re: [Xen-devel] EFER in HVM guests > >> >> > >> >> > >> >> *Please* can you make the handling of generic CPUID leaves and > >> >> architectural MSRs common HVM code? There is lots of > >needless code > >> >> duplication right now with niggling differences that > shouldn''t be > >> >> necessary. > >> >> > >> >> -- Keir > >> >> > >> >> On 29/11/06 16:34, "Nakajima, Jun" > <jun.nakajima@intel.com> wrote: > >> >> > >> >>>> I think it does - allowing a guest to enable EFER.LME > when the > >> >>>> hypervisor is a 32-bit one is clearly a security > >> problem: While I > >> >>>> haven''t tried it, I would suspect the moment you load > a context > >> >>>> with such an EFER the whole system''s dead. > >> >>>> Not being able to access EFER is also a potential > problem, as a > >> >>>> guest should be allowed to set EFER.NX (at least) - the CPUID > >> >>>> handling code specifically does not suppress this bit if > >> the guest > >> >>>> is allowed to use PAE (which we agreed a few days ago > >> should be the > >> >>>> default anyway). > >> >>>> > >> >>>> Jan > >> >>>> > >> >>> > >> >>> I agree that we should allow 32-bit guests to set EFER.NX > >> on the PAE > >> >>> Xen. We''ll fix it. EFER.SCE should not be set on IA-32. > >> >> > >> >> > >> >> _______________________________________________ > >> >> Xen-devel mailing list > >> >> Xen-devel@lists.xensource.com > >> >> http://lists.xensource.com/xen-devel > >> >> > >> > _______________________________________________ > >> > Xen-devel mailing list > >> > Xen-devel@lists.xensource.com > >> > http://lists.xensource.com/xen-devel > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > >> > >> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >The 0x80000001 leaf was originally an "AMD only" leaf for >adding new "non-Intel compatible" features, such as 3DNow! and >long-mode, but since x86_64 was adopted by Intel, it''s >available on Intel processors too. It should be done the same >on both AMD and Intel, and since 0x80000001 contains another >copy of the APIC and PAE bits, they should be masked for both >processors on both 1 and 0x80000001. [Of course, I doubt that >anyone would "prefer" to use 0x80000001 from using 1 as the >index for the leaf unless the coder is already reading >0x800000001 for some other reason - to detect LM for example]. > >I would like to see the handling of 0x80000001 in the common >case cover PAE/PSE36/APIC features, as that''s nor >arch-specific. The fact that no-one actually uses it currently >isn''t a good argument for not getting it right at this time >rather than fixing hard-to-find bugs later on... ;-) >Mats, Leaf 0x80000001 on Intel processors only uses 4 bits in ECX and EDX, they are: LAHF/SAHF: bit 0 of ECX SYSCALL/SYSRET: bit 11 of EDX Execution Disable bit: bit 20 of EDX LM bit: bit 29 of EDX All other bits are reserved to 0.>Clearing MWAIT bit should also be made common - I doubt anyone >will notice the single instruction saved by combining it with >a bunch of other bits, compared to the overall benefit of >trivially seeing that it''s dealt with the same way on both >architectures.I did have this in mind when creating this patch, but I''m not sure if MWAIT virtualization is common on both sides, so just keep it there, and The patch attached has this fixed.> >Just out of curiosity, why did you change the parameters >passed to svm_do_cpuid - I can see why you wouldn''t need to >pass regs->eax when it''s available in regs, but digging out >the vmcb again can''t be better than passing the already >existing one? [Don''t worry about it, I''m just curious about >why the change was made].In my mind, just pass parameters you don''t have in hand. And yes, actually vmcb should be a parameter here :-) -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> >>Just out of curiosity, why did you change the parameters >>passed to svm_do_cpuid - I can see why you wouldn''t need to >>pass regs->eax when it''s available in regs, but digging out >>the vmcb again can''t be better than passing the already >>existing one? [Don''t worry about it, I''m just curious about >>why the change was made]. >In svm code, you don''t always pass vmcb as input paramter, for example, svm_do_msr_access, it''s a little bit confusing, I think you need clean it up. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
When I''m trying to merge VMX/SVM MSR access code, I''m confused by some SVM MSR access code, since quite a few MSRs have corresponding fields in vmcb, why still the access will cause VMExits? -Xin>-----Original Message----- >From: xen-devel-bounces@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser >Sent: Thursday, November 30, 2006 1:22 AM >To: Nakajima, Jun; Jan Beulich; xen-devel@lists.xensource.com; >Keir Fraser >Subject: Re: [Xen-devel] EFER in HVM guests > > >*Please* can you make the handling of generic CPUID leaves and >architectural >MSRs common HVM code? There is lots of needless code >duplication right now >with niggling differences that shouldn''t be necessary. > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Li, Xin B [mailto:xin.b.li@intel.com] > Sent: 19 December 2006 09:13 > To: Keir Fraser; Nakajima, Jun; Woller, Thomas; > xen-devel@lists.xensource.com; Petersson, Mats > Subject: RE: [Xen-devel] EFER in HVM guests > > When I''m trying to merge VMX/SVM MSR access code, I''m confused by some > SVM MSR access code, since quite a few MSRs have > corresponding fields in > vmcb, why still the access will cause VMExits?All MSR read/write operations are set to exit according to the line which sets "msrpm" to all ones around line 142 [I''m on an older changeset, so that may be quite a long while ago] in .../hvm/svm/vmcb.c. Certain MSR writes need to be tracked in the hypervisor to understand what''s going on, and most other ones should be "ignored". -- Mats> -Xin > > >-----Original Message----- > >From: xen-devel-bounces@lists.xensource.com > >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Keir Fraser > >Sent: Thursday, November 30, 2006 1:22 AM > >To: Nakajima, Jun; Jan Beulich; xen-devel@lists.xensource.com; > >Keir Fraser > >Subject: Re: [Xen-devel] EFER in HVM guests > > > > > >*Please* can you make the handling of generic CPUID leaves and > >architectural > >MSRs common HVM code? There is lots of needless code > >duplication right now > >with niggling differences that shouldn''t be necessary. > > > > -- Keir > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mats, Did you find any issue on your side? -Xin>-----Original Message----- >From: xen-devel-bounces@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Li, Xin B >Sent: Tuesday, December 19, 2006 2:45 PM >To: Petersson, Mats; Woller, Thomas; Keir Fraser; Nakajima, >Jun; Jan Beulich; xen-devel@lists.xensource.com >Subject: RE: [Xen-devel] EFER in HVM guests > >> >>The 0x80000001 leaf was originally an "AMD only" leaf for >>adding new "non-Intel compatible" features, such as 3DNow! and >>long-mode, but since x86_64 was adopted by Intel, it''s >>available on Intel processors too. It should be done the same >>on both AMD and Intel, and since 0x80000001 contains another >>copy of the APIC and PAE bits, they should be masked for both >>processors on both 1 and 0x80000001. [Of course, I doubt that >>anyone would "prefer" to use 0x80000001 from using 1 as the >>index for the leaf unless the coder is already reading >>0x800000001 for some other reason - to detect LM for example]. >> >>I would like to see the handling of 0x80000001 in the common >>case cover PAE/PSE36/APIC features, as that''s nor >>arch-specific. The fact that no-one actually uses it currently >>isn''t a good argument for not getting it right at this time >>rather than fixing hard-to-find bugs later on... ;-) >> > >Mats, >Leaf 0x80000001 on Intel processors only uses 4 bits in ECX and EDX, >they are: >LAHF/SAHF: bit 0 of ECX >SYSCALL/SYSRET: bit 11 of EDX >Execution Disable bit: bit 20 of EDX >LM bit: bit 29 of EDX >All other bits are reserved to 0. > > >>Clearing MWAIT bit should also be made common - I doubt anyone >>will notice the single instruction saved by combining it with >>a bunch of other bits, compared to the overall benefit of >>trivially seeing that it''s dealt with the same way on both >>architectures. > >I did have this in mind when creating this patch, but I''m not sure if >MWAIT virtualization is common on both sides, so just keep it >there, and >The patch attached has this fixed. > >> >>Just out of curiosity, why did you change the parameters >>passed to svm_do_cpuid - I can see why you wouldn''t need to >>pass regs->eax when it''s available in regs, but digging out >>the vmcb again can''t be better than passing the already >>existing one? [Don''t worry about it, I''m just curious about >>why the change was made]. > >In my mind, just pass parameters you don''t have in hand. And yes, >actually vmcb should be a parameter here :-) > >-Xin >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mats, which configurations did you test? Can you post those results? Xin, Attached is overnight testing on patch you sent for 32bit hv (xls spreadsheet) on top of 13078, so far looks ok, we have planned to do some 32bit PAE and 64bit hv with HVM AMD-V guest testing. With the interaction/comments from Mats, do you anticipate another patch with more consolidation of SVM/VMX code? Thanks Tom> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Li, Xin B > Sent: Tuesday, December 19, 2006 8:25 AM > To: Li, Xin B; Petersson, Mats; Woller, Thomas; Keir Fraser; > Nakajima, Jun; Jan Beulich; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] EFER in HVM guests > > Mats, Did you find any issue on your side? > > -Xin > > >-----Original Message----- > >From: xen-devel-bounces@lists.xensource.com > >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Li, Xin B > >Sent: Tuesday, December 19, 2006 2:45 PM > >To: Petersson, Mats; Woller, Thomas; Keir Fraser; Nakajima, Jun; Jan > >Beulich; xen-devel@lists.xensource.com > >Subject: RE: [Xen-devel] EFER in HVM guests > > > >> > >>The 0x80000001 leaf was originally an "AMD only" leaf for > adding new > >>"non-Intel compatible" features, such as 3DNow! and long-mode, but > >>since x86_64 was adopted by Intel, it''s available on Intel > processors > >>too. It should be done the same on both AMD and Intel, and since > >>0x80000001 contains another copy of the APIC and PAE bits, > they should > >>be masked for both processors on both 1 and 0x80000001. [Of > course, I > >>doubt that anyone would "prefer" to use 0x80000001 from > using 1 as the > >>index for the leaf unless the coder is already reading > >>0x800000001 for some other reason - to detect LM for example]. > >> > >>I would like to see the handling of 0x80000001 in the common case > >>cover PAE/PSE36/APIC features, as that''s nor arch-specific. > The fact > >>that no-one actually uses it currently isn''t a good > argument for not > >>getting it right at this time rather than fixing hard-to-find bugs > >>later on... ;-) > >> > > > >Mats, > >Leaf 0x80000001 on Intel processors only uses 4 bits in ECX and EDX, > >they are: > >LAHF/SAHF: bit 0 of ECX > >SYSCALL/SYSRET: bit 11 of EDX > >Execution Disable bit: bit 20 of EDX > >LM bit: bit 29 of EDX > >All other bits are reserved to 0. > > > > > >>Clearing MWAIT bit should also be made common - I doubt anyone will > >>notice the single instruction saved by combining it with a bunch of > >>other bits, compared to the overall benefit of trivially > seeing that > >>it''s dealt with the same way on both architectures. > > > >I did have this in mind when creating this patch, but I''m > not sure if > >MWAIT virtualization is common on both sides, so just keep it there, > >and The patch attached has this fixed. > > > >> > >>Just out of curiosity, why did you change the parameters passed to > >>svm_do_cpuid - I can see why you wouldn''t need to pass > regs->eax when > >>it''s available in regs, but digging out the vmcb again > can''t be better > >>than passing the already existing one? [Don''t worry about > it, I''m just > >>curious about why the change was made]. > > > >In my mind, just pass parameters you don''t have in hand. And yes, > >actually vmcb should be a parameter here :-) > > > >-Xin > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Xin, >Attached is overnight testing on patch you sent for 32bit hv (xls >spreadsheet) on top of 13078, so far looks ok, we have planned to do >some 32bit PAE and 64bit hv with HVM AMD-V guest testing. With the >interaction/comments from Mats, do you anticipate another patch with >more consolidation of SVM/VMX code?I think it''s enough for now. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I haven''d done any testing - I had a quick look at the patch in source form, and wrote my comments based on that. If Tom''s tests don''t show up any problems, I''m happy with the latests patch-set. -- Mats> -----Original Message----- > From: Woller, Thomas > Sent: 19 December 2006 20:38 > To: Li, Xin B; Petersson, Mats; Keir Fraser; Nakajima, Jun; > Jan Beulich; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] EFER in HVM guests > > Mats, which configurations did you test? Can you post those results? > > Xin, > Attached is overnight testing on patch you sent for 32bit hv > (xls spreadsheet) on top of 13078, so far looks ok, we have > planned to do some 32bit PAE and 64bit hv with HVM AMD-V > guest testing. With the interaction/comments from Mats, do > you anticipate another patch with more consolidation of SVM/VMX code? > > Thanks > Tom > > > > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Li, Xin B > > Sent: Tuesday, December 19, 2006 8:25 AM > > To: Li, Xin B; Petersson, Mats; Woller, Thomas; Keir Fraser; > > Nakajima, Jun; Jan Beulich; xen-devel@lists.xensource.com > > Subject: RE: [Xen-devel] EFER in HVM guests > > > > Mats, Did you find any issue on your side? > > > > -Xin > > > > >-----Original Message----- > > >From: xen-devel-bounces@lists.xensource.com > > >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf > Of Li, Xin B > > >Sent: Tuesday, December 19, 2006 2:45 PM > > >To: Petersson, Mats; Woller, Thomas; Keir Fraser; > Nakajima, Jun; Jan > > >Beulich; xen-devel@lists.xensource.com > > >Subject: RE: [Xen-devel] EFER in HVM guests > > > > > >> > > >>The 0x80000001 leaf was originally an "AMD only" leaf for > > adding new > > >>"non-Intel compatible" features, such as 3DNow! and > long-mode, but > > >>since x86_64 was adopted by Intel, it''s available on Intel > > processors > > >>too. It should be done the same on both AMD and Intel, and since > > >>0x80000001 contains another copy of the APIC and PAE bits, > > they should > > >>be masked for both processors on both 1 and 0x80000001. [Of > > course, I > > >>doubt that anyone would "prefer" to use 0x80000001 from > > using 1 as the > > >>index for the leaf unless the coder is already reading > > >>0x800000001 for some other reason - to detect LM for example]. > > >> > > >>I would like to see the handling of 0x80000001 in the common case > > >>cover PAE/PSE36/APIC features, as that''s nor arch-specific. > > The fact > > >>that no-one actually uses it currently isn''t a good > > argument for not > > >>getting it right at this time rather than fixing > hard-to-find bugs > > >>later on... ;-) > > >> > > > > > >Mats, > > >Leaf 0x80000001 on Intel processors only uses 4 bits in > ECX and EDX, > > >they are: > > >LAHF/SAHF: bit 0 of ECX > > >SYSCALL/SYSRET: bit 11 of EDX > > >Execution Disable bit: bit 20 of EDX > > >LM bit: bit 29 of EDX > > >All other bits are reserved to 0. > > > > > > > > >>Clearing MWAIT bit should also be made common - I doubt > anyone will > > >>notice the single instruction saved by combining it with > a bunch of > > >>other bits, compared to the overall benefit of trivially > > seeing that > > >>it''s dealt with the same way on both architectures. > > > > > >I did have this in mind when creating this patch, but I''m > > not sure if > > >MWAIT virtualization is common on both sides, so just keep > it there, > > >and The patch attached has this fixed. > > > > > >> > > >>Just out of curiosity, why did you change the parameters > passed to > > >>svm_do_cpuid - I can see why you wouldn''t need to pass > > regs->eax when > > >>it''s available in regs, but digging out the vmcb again > > can''t be better > > >>than passing the already existing one? [Don''t worry about > > it, I''m just > > >>curious about why the change was made]. > > > > > >In my mind, just pass parameters you don''t have in hand. And yes, > > >actually vmcb should be a parameter here :-) > > > > > >-Xin > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel