[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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 
available. 

> 
> Ian.

Jun
___
Intel Open Source Technology Center




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