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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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

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