Re: [Xen-devel] EFER in HVM guests

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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