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

[Mukesh Rathor <mukesh.rathor@oracle.com>]

On Fri, 26 Jul 2013 11:45:19 +0100
Tim Deegan <tim@xen.org> wrote:

> At 19:30 -0700 on 25 Jul (1374780657), Mukesh Rathor wrote:
> > On Thu, 25 Jul 2013 17:28:40 +0100
> > Tim Deegan <tim@xen.org> 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 can understand an 
application would want to be ported unmodified, so we need to support
at least in the short term, but a PVH kernel would need to be modified
anyways, so why create more work, right?

> > So, couldn't come up with any real reason to support it.
> 
> Seems like there's no reason not to -- wouldn't jus
> definitiont removing the check for kernel-mode DTRT? ..

Most likely, but there's lot of code in that path, and I'd feel more
comfortable doing it after testing it. It'll be a small patch in
future anyways :).

I'll document it near XEN_CPUID definition for now.

thanks,
mukesh