Re: [PATCH 0 of 5] PV on HVM Xen

[Sheng Yang <sheng@linux.intel.com>]

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

> PATCH 6
> 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.

OK.

-- 
regards
Yang, Sheng