WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor

On Wed, 2009-09-16 at 22:22 +0100, Jeremy Fitzhardinge wrote:
> On 09/16/09 14:12, Ian Campbell wrote:
> >>> 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.
> >>     
> > XENFEAT_supervisor_mode_kernel is supposed to enable this behaviour,
> > although it hasn't been actively used for several years and never in the
> > pvops kernel so you can bet it has bit-rotted...
> >   
> 
> That tends to have a slightly different meaning, viz "dom0 really *is*
> privileged and can do anything it feels like".  It isn't necessary to
> have a specific feature/mechanism for "kernel happens to be in ring 0";
> it can look at its own cs ring number.

In practise, at least for the 2.6.18-xen tree (which is the only one
where I expect it was ever completely implemented), it is only used to
set the kernel CS and DS and to gate sysenter setup (for which I think
we have a better mechanism today) but you are right that in principle it
could be more far reaching than that.

> >> 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.
> >>     
> > Some combination of XENFEAT_writable_page_tables
> > XENFEAT_writable_descriptor_tables and XENFEAT_auto_translated_physmap
> > might be of interest for this bit.
> 
> Making use of XENFEAT_auto_translated_physmap would avoid the need for
> identity p2m/m2p tables, but I'm not sure whether it still works.  I got
> close to completely removing all references to it at one point, but I
> think ia64 uses it?

I very much expect that it'll need fixing/(re)implementing on both the
kernel and hypervisor side...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>