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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 15 Mar 2010, Sheng Yang wrote:
> 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 see.
I have tested my series with acpi enable, the only problem I had is that
acpi might report more vcpus than actually present on the system so some
hypercalls to enable secondary vcpus might fail.
Is this the reason why you disable acpi?
To be sure you can add an hack to xen_cpu_up to return immediately if
cpu is greater than the number of vcpus in your VM.
If this is the only reason I think it can be fixed.
Also the new "reduced" series you sent doesn't have such limitation
anyway.


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

I like your pv clocksource implementation.
The only reason why I would defer the patch is that I don't particularly
like the "enable_pv" hypercall, so I would try to get away without it,
resetting the tsc offset automatically when enabling the VIRQ_TIMER on
an HVM domain.
But everything else is fine: as I said I would just postpone it, I would
not 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.
>  

yep, no mappings required


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel