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

Re: [Xen-devel] [V10 PATCH 23/23] PVH xen: introduce vmexit handler for PVH



At 17:37 -0700 on 06 Aug (1375810631), Mukesh Rathor wrote:
> On Fri, 26 Jul 2013 11:45:19 +0100
> Tim Deegan <tim@xxxxxxx> wrote:
> 
> > At 19:30 -0700 on 25 Jul (1374780657), Mukesh Rathor wrote:
> > > On Thu, 25 Jul 2013 17:28:40 +0100
> > > Tim Deegan <tim@xxxxxxx> wrote:
> > > 
> > > > At 18:59 -0700 on 23 Jul (1374605971), Mukesh Rathor wrote:
> > > > > +/* Just like HVM, PVH should be using "cpuid" from the kernel
> > > > > mode. */ +static int vmxit_invalid_op(struct cpu_user_regs
> > > > > *regs) +{
> > > > > +    if ( guest_kernel_mode(current, regs)
> > > > > || !emulate_forced_invalid_op(regs) )
> > > > > +        hvm_inject_hw_exception(TRAP_invalid_op,
> > > > > HVM_DELIVER_NO_ERROR_CODE);
> > > > 
> > > > Was this discussed before?  It seems harsh to stop kernel-mode
> > > > code from using the pv cpuid operation if it wants to.  In
> > > > particular, what about loadable kernel modules?
> > > 
> > > Yes, few times on the xen mailing list. The only PVH guest, linux
> > > as of now, the pv ops got rewired to use native cpuid, which is
> > > how hvm does it.
> > 
> > Yes, but presumably you want to make it easy for other PV guests to
> > port to PVH too?
> 
> True, but how would not allowing kernel mode emulation impede that?
> I fail to understand why a new kernel would wanna use xen signature
> emulation over just plain cpuid instruction?

I'm talking about existing PV kernel code that already uses PV CPUID.
And in particular what if that kernel code is in a device driver, or
even a third-party loadable module?  Porting the core kernel from PV to
PVH shouldn't break that code if it doesn't have to.

But TBH my objection is really more aesthetic than anything else.
Restricting the PV CPUID instruction here adds another ragged edge in
the ABI that all kernel writers have to think about, and for little or
no benfit.  And, to be clear, I object to it and this patch does not
have my Ack.

Tim.

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