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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home