Re: Xen: Hybrid extension patchset for hypervisor

["Yang, Sheng" <sheng.yang@intel.com>]

On Wednesday 16 September 2009 17:08:20 Keir Fraser wrote:
> On 16/09/2009 09:44, "Yang, Sheng" <sheng.yang@intel.com> wrote:
> > Hi Keir & Jeremy
> >
> > Here is the hypervisor part of hybrid extension support.
> >
> > Please review, thanks!
>
> The principle is okay I guess. These changes would have to be trickled in
> with a  really good explanation and justification for each one. 
>
> For
> example, I'm not clear why the enable-hybrid hypercall is needed. Why not
> just provide access to evtchn and timer hypercalls always, and guest sues
> them if it is capable of it? 

We have purposed a component independence approach, that means user can enable 
PV timer or evtchn separately. Currently we have some limit with event channel 
implementation, e.g. no passthrough device support, and SMP is also not ready 
at this time(but in progress). (And I think there would be some version issue 
later, if we support more features).

The enable-hybrid hypercall is there because we can do adjust some hypervisor 
behaviour if we know guest would be hybrid rather than hvm or pv. For example, 
HVM assume TSC is start from 0, but pv timer assume TSC is no different with 
native. So we need modify tsc offset to 0 to make pv timer work. And we may 
also do some optimization in hypervisor if we know that guest is hybrid rather 
than hvm/pv.

> I'm also not sure why PV timer events get
> routed to irq0 -- why not via an event channel as usual, now that you are
> enabling HVM guests to use the evtchn subsystem? 

As stated above, we support a mode that using PV timer without event channel. 
But I am thinking maybe we can let evtchn co-exist with IOAPIC/LAPIC, then pv 
timer use evtchn, others goes to normal hardware way. And another feature can 
replace IOAPIC/LAPIC with evtchn.

> What's a hybrid gnttab,
> and why does it need an explciit reserved e820 region? And so on.

We need some memory to map gnttab. It was provided by a QEmu emulated device 
in HVM, but we think it's not elegant that a basic feature depends on a 
device, so we got this e820 region...

> The general principle of these patches seems to be to create a set of
> individual, and perhaps largely independent, accelerations/enlightenments
> to the HVM interface. I can at least agree with and support that aim.

Thanks. :)

-- 
regards
Yang, Sheng

>
>  -- Keir