Re: Xen: Hybrid extension patchset for hypervisor

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 09/16/09 09:28, Nakajima, Jun wrote:
> Keir Fraser wrote on Wed, 16 Sep 2009 at 07:04:10:
>   
>>  By the way, if your intention is to speed up 64-bit guest performance,
>> then I think you should compare with running a full PV guest in a VMCS
>> container. That is runs in VMX non-root mode but still retains the usual
>> full-PV interfaces. I think that would be no more code than you are
>> proposing here, and would avoid scattering a bunch more code around the
>> guest OS, to which there is bound to be resistance.
>>     
> Do you mean running the existing 64-bit PV kernel binaries in a VMCS container?
>   

Yes.  I don't think there's any deep problem in doing that.

> Based on our data, what we would want in PV 64-bit guests are, fundamentally:
> - have the kernel run in ring 0 (so that it can regain the performance enhancements)
>   

That's no problem.  PV kernels don't currently assume they're running in
any particular ring, so they'd be happy to run in ring 0 if that's how
they're started (if there are problems, I'd consider that a bug).  We
could then check for ring 0 and enable syscall/sysenter.

> - use hardware-based MMU virtualization (e.g. EPT-based) if present
>   

We could do that with minimal API/ABI changes by:

    * Providing an identity p2m table
    * Changing the hypercall page to make pte writes simple memory
      writes (no hypercalls); xen would still keep track of pinned pages
      and trap'n'emulate on them for back-compatibility (but fast-path
      with no validation).  We could expose the presence of HAP via
      xen_features so that guests know they can avoid marking pagetables
      RO, etc.
    * Similarly, cr3 changes can be fast-pathed within the hypercall page.
    * Whatever else I've overlooked.

This would be very similar to how xenner gets PV guests running under kvm.

The tricky part might be in getting IO working, since it relies on
getting real MFNs for DMA.

At any rate, the changes need only be very localized within the
Xen-specific code.  I would not want to introduce a new or significantly
different kernel<->hypervisor ABI for any new modes (we have enough
already).

    J