[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |