Re: [Xen-ia64-devel] RE: Event channel vs current scheme speed [was vIOSAPIC and IRQs delivery]

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 09 Mars 2006 10:52, Dong, Eddie a écrit :
> Tristan Gingold wrote:
> > I'd like to narrow the discussion on this problem within this thread.
> >
> > We all agree we'd like to support shared IRQs and drivers domain.
> > I am saying I can do that without event channel, while Eddie says it
> > is required.
>
> The current vIOSAPIC can't, would like to see your enhancement if you
> want.
I really think I can achieve that.  But I don't work to do duplicate work.

> > One of Eddie argument is performance, as discussed previously.  Since
> > I don't agree and things should be obvious here, I'd like to
> > understand why we don't agree.
>
> I said event channel based solution was slight better in performance,
> but I also said this was not critical reason that I didn't buy in
> vIOSAPIC.
> The critical reason is in architecture correctness, compatability to Xen
> and maintaince effort in future.
Ok, these are your main arguments.

Maybe I am wrong but event-channel do not allow priority.  An interrupt can't 
be interrupted.  Is it true ?

[...]
> With event channel based approach, TPR, IVR is read in xen, not guest.
> That is the difference. Only EOI is conditionally written by a notifier
> request
> from event channel. So vIOSPAIC needs 3 hypercalls, while event channel
> based solution needs at most 1 hypercall.
So we agree here.

Event channel also means we loose hyper-reflexion, unless you are a volunter 
to rewrite it.

Event channel is 1 hypercall *iif* callback is used.  If current event-channel 
(through IRQ) is used, this is not true.  And I am angry with callback.

> > purpose of hypercall PHYSDEVOP_IRQ_UNMASK_NOTIFY.  Xen has to know
> > when all domains have finished to handle the interrupt.
>
> I have listed in the description of X86 flow, please refer. Basically
> this is same.
So we agree too.  "this is same".

[...]
> >> 3: Stability:
> >> Event channel based solution has undergone long time well test and
> >> real deployment, but vIOSAPIC is not. BTW, IRQ is very important in
> >> OS, a race condition issue may cost people weeks or even months
> >> debug effort.
> >
> > I don't agree.  Current logic is much more tested than event channel,
> > at least on ia64!
> > Radical changes are much more worrying.
>
> Please be aware that vIOSAPIC need to change IOSAPIC code, and
> original IOSAPIC is not aware of any race condition among
> multiple VMs that is totally new.
No, this is a Xen issue, not a linux one.  And basically the code is the same.

> On the other hand, using
> event channel based solution doesn't need to change single line code for
> run time service. The dish is there already.
>
> Background for others:  Choosing IOSAPIC as hardware interrupt
> ocntroller
>  or pirq is done at initialization time. If choosing pirq, the guest IRQ
> goes
>  into event channel based approach, there is no extra changes.
Correct.

>
> >> 4: Which one change linux less ?
> >>     My answer is still event channel based solution, as all event
> >> channel code are xen common and
> >> is already in (VBD/VNIF use it).
> >
> > You will have to change iosapic.c almost like my change, see
> > io_apic-xen.c and adding new event-channel irq_type.
>
> Initialization time change is almost same (neglictable difference), but
> for runtime service changes. Event channel based solution changes less.
>
> > Checking running_on_xen costs nothing.  If you fear about that, forget
> > transparent virtualization.
>
> As previously said, although event channel based solution has slight
> better
> performance, but it is not critical even for me. Just show u how
> transparent concept is much better supported in event channel
> based solution.
>
> >> 6: Stability of future:
> >>    My answer is clear, fixing an intial time bug only costs
> >> one-tenth of runtime bug. Eventchannel based solution only change
> >> intial time code.
> >
> > Current interrupt delivery is stable.  Why changing something which
> > is working ?
>
> Because we need to support driver domain, support IRQ sharing among
> guests.
My whole point is: this can be done without using event channel.

> Maybe I should ask u why xen code supporting interrupt delivery for
> driver domain and IRQ sharing is not choosed. xen code is a working code.
Ask Dan.  I don't know why he didn't use event channel to deliver IRQs.  By 
seeing the amount of optimization for IRQs, I deduced he didn't want to 
deviler IRQs with event-channel.  Maybe I am wrong.

Tristan.


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