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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Fri, 18 Sep 2009 17:17:57 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yang, Sheng" <sheng.yang@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Keir
Delivery-date: Fri, 18 Sep 2009 17:18:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB2733B.6060804@xxxxxxxx>
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> <0B53E02A2965CE4F9ADB38B34501A3A1940C840B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4AB2733B.6060804@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco3vSsYbgsJ+M77SmqW/Lt5YO6ASAA9vJGg
Thread-topic: [Xen-devel] Re: Xen: Hybrid extension patchset for hypervisor
Jeremy Fitzhardinge wrote on Thu, 17 Sep 2009 at 10:34:51:

> On 09/17/09 08:56, Nakajima, Jun wrote:
>> 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.
>> 
>  Sure.  It would be easy to either use new special-purpose just plain
> native versions of those ops if that's the right thing to do; but it
> would be nice if a current unmodified PV guest worked within a HVM
> container and got at least some benefit from doing so.  Also, pagetable
> issues have repercussions beyond just the raw pagetable update functions.
> 
> Of course you can get both these features just by booting the kernel as
> an hvm guest.  But if we're talking about giving PV kernels some
> benefits from hvm/hap hardware features, I think we should looking at it
> from the perspective of starting with a PV kernel then adding
> incremental changes.
> 

Even if we start from PV kernels, I think what we should do is to implement 
ability (as "incremental changes") for PV guests to stop using PV MMU (and PV 
CPU) at boot time depending on the H/W features available rather than to keep 
using the same ABI, because we may not need them in the near future. Then, such 
PV kernels would be at par or faster/more efficient than pure HVM guests on 
machines with HAP enabled because of the other PV features. 

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>