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 of 5] PV on HVM Xen

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Mon, 15 Mar 2010 16:29:12 +0800
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 15 Mar 2010 01:32:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201003151205.29964.sheng@xxxxxxxxxxxxxxx>
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: <alpine.DEB.2.00.1003101457100.28412@kaball-desktop> <alpine.DEB.2.00.1003121432460.27222@kaball-desktop> <201003151205.29964.sheng@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
On Monday 15 March 2010 12:05:29 Sheng Yang wrote:
> On Saturday 13 March 2010 00:00:42 Stefano Stabellini wrote:
> > On Fri, 12 Mar 2010, Stefano Stabellini wrote:
> > > My intentions are true so my proposal of working on a common tree is
> > > still valid, just let me know when you are interested.
> >
> > The last versions of our patch series are quite similar, I think at this
> > point we can really merge them into one.
> > If you take the time to read the last version of my patch series I
> > think you'll be able to see it by yourself (missing From: line aside,
> > again sorry for that).
> > I looked at the last version of yours and I listed the changes I would
> > like to be made on top of it, if you and Jeremy agree:
> >
> >
> > PATCH 1
> > fine as it is;
> >
> > PATCH 2
> > fine as it is;
> >
> > PATCH 3
> > I would remove it altogether because I would like to make pv drivers
> > work on HVM, but considering that at the moment they wouldn't work,
> > it makes sense to apply it for now;
> >
> > PATCH 4
> > I would remove HVMOP_enable_pv, xen_hvm_pv_clock_enabled and the
> > pvclock for the moment;
> See my comments below.
> > PATCH 5
> > I would change the entry point because I think the one I use in my
> > patch series is less controversial and probably easier to get accepted
> > upstream: look at the first part of my second patch;
> My currently evtchn mapping implementation require disable_acpi=1, which is
> the same as pv guest(and I would look into your implement to see if it's
>  still needed), so you can't do it after acpi related initialization.
>  Anyway, I don't think the position would be a issue for upstream. HV are
>  picking positions according to their requirement, and there are already
>  sparse vm enabling codes in setup_arch().

Hi Stefano

I've checked your patches. And one point puzzled me(I am looking into pv_ops 
dom0 code): seems if it depends on PIRQ, it would still require to do EOI(then 
result in vmexit) for edge triggered interrupt? (through xen_pirq_chip->end). 
And unmask is still a heavy work required vmexit?(seems it need twice vmexit, 
even heavier than current HVM solution)

Yang, Sheng

Xen-devel mailing list