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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1253178985.16152.26.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C6D66994.14D6A%keir.fraser@xxxxxxxxxxxxx> <C6D6AEEA.14EBF%keir.fraser@xxxxxxxxxxxxx> <0B53E02A2965CE4F9ADB38B34501A3A1940C78A8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4AB12C1F.9080502@xxxxxxxx> <1253135571.3896.4873.camel@xxxxxxxxxxxxxxxxxxxxx> <4AB15707.20305@xxxxxxxx> <1253178985.16152.26.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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 
available. 

> 
> Ian.

Jun
___
Intel Open Source Technology Center




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

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