Re: [Xen-devel] [PATCH][v2] Hybrid extension support in Xen

[Sheng Yang <sheng@xxxxxxxxxxxxxxx>]

On Wednesday 03 February 2010 00:15:50 Ian Campbell wrote:
> On Tue, 2010-02-02 at 14:07 +0000, Sheng Yang wrote:
> > On Tuesday 02 February 2010 21:52:44 Ian Campbell wrote:
> > > On Tue, 2010-02-02 at 13:06 +0000, Sheng Yang wrote:
> > > > On Tuesday 02 February 2010 19:26:55 Ian Campbell wrote:
> > > > > On Tue, 2010-02-02 at 08:16 +0000, Sheng Yang wrote:
> > > > > In fact, why is hybrid mode considered a separate mode by the
> > > > > hypervisor at all? Shouldn't it just be an extension to regular HVM
> > > > > mode which guests may choose to use? This seems like it would
> > > > > eliminate a bunch of the random conditionals.
> > > >
> > > > There is still something different from normal HVM guest. For
> > > > example, to use PV timer, we should clean the tsc offset in HVM
> > > > domain; and for event delivery, we would use predefined VIRQ rather
> > > > than emulated IOAPIC/APIC. These code are exclusive, we need them
> > > > wrapped with flag(which we called "hybrid"). The word "mode" here may
> > > > be is inaccuracy, a "extension" should be more proper. I would change
> > > > the phrase next time.
> > >
> > > But the old mechanisms (emulated IOAPIC etc) are still present until
> > > the enable_hybrid HVMOP is called, aren't they? Why can't you perform
> > > the switch at the point at which the new feature is requested by the
> > > guest e.g. when the VIRQ is configured?
> >
> > Yes, they are there before the enable_hybrid HVMOP called. But sorry for
> > I don't quite understand about the point "when the VIRQ is configured?"
> 
> I just meant that you should enable evtchn mode at the point at which
> the guest tries to use event channels and not in some specific "enable
> hybrid mode call", similarly for PV-timer mode etc.
> 
> Of course that presupposes that event channels and APIC etc are mutually
> exclusive, which I don't think is a given.

I would give it try. Seems I need to bind tsc offset clean in event channel 
binding hypercall(if I didn't introduce another hypercall), sounds a little 
messy.
 
> I'm of the opinion that the word "hybrid" should not occur anywhere in
> the tools or hypervisor -- instead there should simply be PV
> functionalities which are made available to HVM guest kernels which
> request them.
> 
> I'm similarly of the opinion that the hybrid-ness should not leak out of
> the core Xen-aware kernel code, for example the word hybrid should not
> be used in the front end drivers, rather the differences should be
> encapsulated in the evtchn code (etc).

That's reasonable. I would try to make them more like natural PV feature.
> 
> > But let IOAPIC/APIC coexisted with event channel is not our target. As
> > we know, the overhead brought by them, notably EOI by LAPIC, impact
> > performance badly. We want event channel that because event channel
> > have much less overhead compared to IOAPIC/LAPIC, a completely
> > virtualization aware solution which elimiate all the unnecessary
> > overhead. That's what we want Xen guest to be benefit.
> 
> It certainly makes sense to deliver interrupts to PV drivers via
> evtchns. I don't think it necessarily follows that all interrupts should
> be injected via event channels. For example for low throughput emulated
> devices I think it makes sense to continue to inject interrupts via the
> emulated *APIC paths such that the treatment of a given device is either
> consistently emulated or consistently paravirtualised but not some
> mixture.

Well, for us, we want evtchn because we want to improve interrupt intensive 
passthru device's performance(though too big for the first step, we have 
experiment patches, but would like to consolidate with the solution of pv_ops 
dom0). The situation won't change if we still use emulated APIC path...

-- 
regards
Yang, Sheng

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