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 12:05:29 +0800
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 14 Mar 2010 21:06:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1003121432460.27222@kaball-desktop>
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.1003121024590.27222@kaball-desktop> <alpine.DEB.2.00.1003121432460.27222@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
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:
> fine as it is;
> fine as it is;
> 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;
> I would remove HVMOP_enable_pv, xen_hvm_pv_clock_enabled and the
> pvclock for the moment;

See my comments below.

> 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().

> I would remove this patch and talk about pv clocksource again when we
> do the interrupt remapping work.

What's the reason to remove pv clocksource?

In fact, after Jeremy's reminder, I found clocksource and clockevent can be 
decoupled like I demonstrated in my code. So PV clocksource have nothing to do 
with evtchn mapping for HVM(I don't like to call it interrupt remapping 
because that reminder me of a hardware feature...). So I don't understand why 
to remove it.

> Jeremy, what do you think about it?
> If we agree on these few basic patches, I'll wait for Jeremy to apply
> them in a topic branch and then I'll send my changes on top of them,
> adding PV on HVM support (I mean the xen pci platform device driver,
> blkfront and netfront) and everybody will be happy.

I am fine with PCI platform device drivers, if they can work before evtchn 
mapping is ready.
> After this is done we can calmly discuss about how to proceed with the
> interrupt remapping stuff.


Yang, Sheng

Xen-devel mailing list