Re: [Xen-devel] [PATCH 10/18 V2]: PVH xen: introduce vmx_pvh.c and pvh.c

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.04.13 at 03:01, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Mon, 18 Mar 2013 12:32:06 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> 
>> On Fri, Mar 15, 2013 at 05:41:45PM -0700, Mukesh Rathor wrote:
>> > +            return 1;
>> > +        }
>> > +
>> > +        new_cr0 &= ~HVM_CR0_GUEST_RESERVED_BITS;
>> > +        /* ET is reserved and should be always be 1. */
>> > +        new_cr0 |= X86_CR0_ET;
>> > +
>> > +        /* pvh cannot change to real mode */
>> > +        if ( (new_cr0 & (X86_CR0_PE|X86_CR0_PG)) !=
>> > (X86_CR0_PG|X86_CR0_PE) ) {
>> > +            printk("PVH attempting to turn off PE/PG. CR0:%lx\n",
>> > new_cr0);
>> > +            return 1;
>> > +        }
>> > +        /* TS going from 1 to 0 */
>> > +        if ( (old_cr0 & X86_CR0_TS) && ((new_cr0 &
>> > X86_CR0_TS)==0) )
>> > +            vmx_fpu_enter(vp);
>> 
>> Does this really happen? I thought in the PV mode you would be using
>> the hypercalls for the fpu swap? Should it be print out an error
>> saying something to the effect:
>> 
>>      "PVH guest is using cr0 instead of the paravirt lazy FPU
>> switch!" and include the EIP?
> 
> Yes. At present in linux PVH, we use native_clts and not xen_clts pv
> ops call. But another PVH guest might not want to use hypercalls, right?

Correct. Even more so with there being CR read/write emulation
for PV guests, including for the CLTS instruction. So this case
needs to be handled in any case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel