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

[Tim Deegan <tim@xxxxxxx>]

At 16:51 +0100 on 15 Aug (1376585469), George Dunlap wrote:
> On Wed, Aug 7, 2013 at 10:54 AM, Tim Deegan <tim@xxxxxxx> wrote:
> > 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.
> 
> Are you in particular saying that you think PVH guests should be
> allowed to use the PV CPUID as a prerequisite for the patch series to
> go in?
> 
> Correct me if I'm wrong, but:
> 1. CPUID is the only forced_emulated op at the moment
> 2. The kernel is the only caller we can reasonably expect to use the
> forced_emulated ops

No - the forced-invalid-op CPUID is used from userspace too, e.g. in
tools/misc/xen-detect.c.  The current patch keeps support for userspace
but not for kernel users.  I would prefer to keep it for both, on the
grounds that even in the kernel there may be users of it that the person
porting the kernel does not control (e.g. in third-party modules).

Tim.

> If so, then if *were* to go Mukesh's way on this, we should just
> forget the whole forced_emulated op thing anyway.
> 
> It seems to me that one of the advantages of using HVM containers is
> not needing to do any tricks like this.  I'm inclined to say we should
> not do any forced_emulated ops at all to begin with; and to add
> support if we actually find that there are callers that need it.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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