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

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



>>> On 04.07.13 at 04:02, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 03 Jul 2013 11:25:49 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 03.07.13 at 03:40, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> > On Fri, 28 Jun 2013 10:44:08 +0100
>> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
>> >> >>> On 28.06.13 at 04:28, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >> >>> wrote:
>> >> > On Tue, 25 Jun 2013 11:49:57 +0100 "Jan Beulich"
>> >> > <JBeulich@xxxxxxxx> wrote:
>> > ...... 
>> >> And btw., looking at that patch again I'm also getting the
>> >> impression that the GS base handling in that function is lacking
>> >> consideration of VGCF_in_kernel.
>> > 
>> > I still fail to see what VGCF_in_kernel has to do with GS base for 
>> > PVH guest. The flag should be irrelevant for PVH IMO. Can you kindly
>> > elaborate a bit?
>> 
>> VGCF_in_kernel specifies whether a guest wants to start its vCPU
>> in user of kernel mode (why the interface permits that is another
>> question, but you have to play by what is there).
> 
> My understanding is because of the trap bounce, we need to keep track
> of kernel/user mode 64bit PV guest in ring3. Fortunatley, nothing of
> that for PVH.

That's correct, but is largely unrelated to the point I was making.
If anything you might sanity check RPL and/or DPL of CS and SS
against that flag, and return an error if they're inconsistent.

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®.