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

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

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)

-- 
regards
Yang, Sheng