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/
Home Products Support Community News


Re: [Xen-devel] [PATCH 0/7][v4] PV extension of HVM (Hybrid) for Xen

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/7][v4] PV extension of HVM (Hybrid) for Xen
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Tue, 2 Mar 2010 09:26:03 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 01 Mar 2010 17:29:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B8C5ED9.1040109@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>
Organization: Intel Opensource Technology Center
References: <1267436315-24486-1-git-send-email-sheng@xxxxxxxxxxxxxxx> <4B8C5ED9.1040109@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; )
On Tuesday 02 March 2010 08:42:01 Jeremy Fitzhardinge wrote:
> On 03/01/2010 01:38 AM, Sheng Yang wrote:
> > I'd like to have your comments on this patch series. We think the patches
> > are prepared for check in pv_ops domU tree.
> >
> > The PV extension of HVM is started from real mode like HVM guest, but
> > also with a a range of PV features(e.g. PV halt, PV timer, event channel,
> > as well as PV drivers). So guest with this feature can takes the
> > advantages of both H/W virtualization and Para-Virtualization.

Thanks for the comments!
> The PV device side of this has a lot of overlap with the older PV driver
> for HVM domains code.  Aside perhaps for the details of how
> interrupts/events are actually delivered, that seems like a completely
> distinct piece of work which could be done separately.

Yes. PV driver is not our core target. So leave it a little late is fine.

> Also, I'd like to see a clearer statement of what you're specifically
> trying to optimise for here.  What is inefficient in an unmodified HVM
> domain, and how do your patches address these things.  What measurements
> have you made?

The key issue we want to address is the overhead of LAPIC, especially EOI and 
other actions resulted in explicit vmexit. That is the overhead we want to 
eliminate. And evtchn seems like a perfect choice to us.

> > The first two of the patchset imported several header file from Jeremy's
> > tree and Xen tree, respect to Jeremy and Keir's works.
> >
> > The whole patchset based on Linux upstream.
> >
> > You need a line like:
> >
> > cpuid = [ '0x40000002:edx=0x3' ]
> >
> > in HVM configuration file to expose hybrid feature to guest, and
> >
> >
> > in the guest kernel configuration file to enable the hybrid support.
> >
> > And the compiled image can be used as native/pv domU/hvm guest/pv feature
> > hvm kernel.
> >
> > Current the patchset support x86_64 only.
> Please add a new config option for the new code, and make it dependent
> on x86-64, rather than scattering random #ifdef CONFIG_X86_64s around
> the code.  Make sure all the code is controlled by this CONFIG variable
> so it disappears in a 32-bit build (ideally by putting it into a new
> file where possible, and only building it when enabled).

> > I've discussed the vector-evtchn mapping with Stefano, and we agreed on
> > that it's more complex than we thought, and can't brought much benefit
> > for pvops domU. So there is no major change in this update.
> >
> > Change from v3:
> > 1. Rebase to Linux 2.6.33 release.
> Why 2.6.33?  I'm currently working on 2.6.32; I intend to move to .33
> shortly, but .32 is a much more convenient base (particularly if you're
> interested in getting these changes into any distro kernels).
> I rebased it to .32 without much effort.

> I'll make specific comments in the patches.


Yang, Sheng

>      J

Xen-devel mailing list

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