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