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

Re: [Xen-devel] [PATCH v2 2/2] x86/hvm: add support for pcommit instruction



> From: Zhang, Haozhong
> Sent: Tuesday, January 05, 2016 3:33 PM
> 
> On 01/05/16 15:19, Tian, Kevin wrote:
> > > From: Zhang, Haozhong
> > > Sent: Tuesday, January 05, 2016 3:15 PM
> > >
> > > On 01/05/16 15:08, Tian, Kevin wrote:
> > > > > From: Zhang, Haozhong
> > > > > Sent: Wednesday, December 30, 2015 7:49 PM
> > > > >
> > > > > Pass PCOMMIT CPU feature into HMV domain. Currently, we do not 
> > > > > intercept
> > > > > pcommit instruction for L1 guest, and allow L1 to intercept pcommit
> > > > > instruction for L2 guest.
> > > >
> > > > Could you elaborate why different policies are used for L1/L2? And 
> > > > better
> > > > add a comment in code (at least for vvmx) to describe the intention.
> > > >
> > > > Thanks
> > > > Kevin
> > >
> > > The intention is that we completely expose pcommit (both the
> > > instruction and VMEXIT caused by pcommit) to L1.
> > >
> > > Haozhong
> >
> > My question is why pcommit can't not be directly in L2 w/o interception?
> >
> > Thanks
> > Kevin
> >
> 
> Isn't it because L1 hypervisor may decide to intercept L2 pcommit?
> 

Well, I misunderstood the original statement and actual patch w/ the
impression that pcommit interception is always enabled for L2 guest.
Now I see that itt's just the intrinsic result when we don't intercept 
L1 pcommit (either a L1 guest or L1 hypervisor). So,

Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

Thanks
Kevin

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