RE: [Xen-devel] EFER in HVM guests

["Li, Xin B" <xin.b.li@xxxxxxxxx>]

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

>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxx> wrote:
>> 
>> > Is this the framework what you want?
>> > And we still need merge the common cases here.
>> > -Xin
>> > 
>> >> -----Original Message-----
>> >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> >> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir 
>> >> Fraser
>> >> Sent: 2006年11月30日 1:22
>> >> To: Nakajima, Jun; Jan Beulich; 
>> xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> >> http://lists.xensource.com/xen-devel
>> >> 
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@xxxxxxxxxxxxxxxxxxx
>> > http://lists.xensource.com/xen-devel
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>> 
>> 
>> 
>

Attachment: hvm_cpuid.patch
Description: hvm_cpuid.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel