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
|
Home