[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
- To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
- From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
- Date: Thu, 17 Sep 2009 08:56:32 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: "Yang, Sheng" <sheng.yang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Keir
- Delivery-date: Thu, 17 Sep 2009 08:56:57 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: Aco3d4rmkMzEqKdVQwi/6DAVmasYzQANaUXA
- Thread-topic: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
Ian Campbell wrote on Thu, 17 Sep 2009 at 02:16:25:
> On Wed, 2009-09-16 at 22:22 +0100, Jeremy Fitzhardinge wrote:
>>>> 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...
To me, leveraging the native MMU code, rather than using existing API/ABI,
would simplify both the guest and hypervisor side if hardware MMU
virtualization is present. For example:
- today a 64-bit PV guest builds/switches page tables depending on the
kernel/user mode. It's not required anymore.
- we can automatically get large page support (2MB, 1GB)
I thought pv_xxx_ps (such as pv_time, pv_cpu_ops, pv_mmu_ops, etc.) was
designed to choose the right pv_ops accordingly depending on the features
Intel Open Source Technology Center
Xen-devel mailing list