[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: PVH set vcpu info context in vmcs....



>>> On 15.08.13 at 02:25, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 14 Aug 2013 10:12:18 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 14.08.13 at 04:12, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> > On Tue, 13 Aug 2013 11:56:36 +0100
>> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
> ...
>> >> >     if ( v->vcpu_id == 0 )
>> >> >         return 0;
>> >> 
>> >> Bogus/pointless.
>> > 
>> > No, we don't have anything for the boot vcpu. It's totally coming up
>> > on the flat address space. For non boot, the vcpu is coming up on
>> > the kernel GDT. Recall it's a PV guest (coming up in an HVM
>> > container).
>> 
>> No, that's the wrong perspective. You either should never get here
>> for vCPU 0, or you should refuse this for all already initialized
>> vCPU-s.
> 
> Ok, i'll move the check to caller. FWIW, the vcpu->is_initialised is
> inapplicable here because this is relevant for non-boot vcpus only.

That won't make the check any better. Can you please explain in
detail why this check is necessary, and why the ->is_initialised one
would be wrong?

>>>     if ( ctxtp->user_regs.cs == 0 || (ctxtp->user_regs.cs & 3) == 3 )
>>>         return -EINVAL;  
> 
>>Perhaps better check for any non-zero RPL, as the RPL needs
>>to match of the (enforced) CS hidden fields?
> 
> Well, we now load the descriptor provided by the guest in the GDT
> so that's kinda un needed now.. thats why i thought we don't need to
> enforce RPL or check VGCF_in_kernel. But, that would work too...

Of course you don't need to duplicate anything that
hvm_load_segment_selector() does; anything that's not obvious
would of course warrant a code comment to that effect.

> Final(hopefully) version:

Looks okay, but we'll certainly need to see the changes to
hvm_load_segment_selector() too.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.