[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |