[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
On 09/16/09 14:12, Ian Campbell wrote:
>>> Based on our data, what we would want in PV 64-bit guests are,
>>> - have the kernel run in ring 0 (so that it can regain the performance
>> 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.
>> 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?
Xen-devel mailing list