Re: [Xen-ia64-devel] vIOSAPIC and IRQs delivery

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Mardi 07 Mars 2006 15:47, Dong, Eddie a écrit :
> Tristan:
>       Like mentioned in your early emails, you also agree the idea
> approach should use event channel. I am assuming you are still sticking on 
this, and let us work out the idea design now.
Yes, I agree with the idea.  However I don't think this is high priority and I 
also wonder wether it is worth.

>       Then the question is:
>               1: How can we get a patch for the idea design? If it
> takes us 1 month, is it worth to doing now?
>               My answer is yes, because event channel based approach
> is most efficient and well tested in Xen.
The current ia64 model is well tested too and seems efficient too (according 
to Dan measures).
Callback implementation seems to be rather tricky.

If you like to play, we can bet: work on this during one month on this but if 
it is slower than 1.7% bare iron linux using Dan measure do not integrate it.
You may waste 1 month.
Unless there are more pros.  But I don't think convergence is enough.

> Also keeping consistant with Xen architecture in IRQ virtualization will
> save future maintaince effort.
I don't fully buy this argument.
The current ia64 model closely follows the hardware.  This will never change.
The Xen architecture may change and we will have to follow.
I also think interrupt delivery is far from the Xen core.

>               2: Before the idea patch comes up, should we accept the
> previous intermediate patch?
>               I am tentative on this as I didn't see obvious value
> here but pay some regression effort as it will be eventually replaced.
As you know I have the opposite opinion.
vIOSAPIC is a small change with low impacts.  Furthermore it is required for 
driver domains and LID virtualization.
Callback + IRQ on event channel is a big change and not required.  The main 
benefits are convergence and maybe performance (if true).

I'd like to be sure we agree on definitions:
* vIOSAPIC enables driver domains.
  [My patch doesn't yet enable that because I refuse to work on it without 
being able to test it]
* Callback + IRQ on evtchn is an alternative way to deliver and handle IRQ.
  The pros are convergence and performance.

>               3: Without the intermediate patch, can we run SMP guest?
>               My answer is yes at least for Xen0. Current approach
> (dom0 own machine IOSAPIC should be OK for 1-2 month) will not block those 
ongoing effort. vIRQ stuff is a cleanup for future driver domain support.
Yes this is doable.  I have to modify my current SMP-g patch because it is 
based on my previous vIOSAPIC.

vIOSAPIC adds features while Callback+IRQs is mainly tuning.

[...]
> > Do you really think x86 para-guest doesn't program io_apic ?
>
> No, I mean part of its function can be moved to event channel especially
> for run time stuff.
> Accessing those entries at run time (each time when a guest handle the
> PIRQ) using hypercall
> is extremely expansive IMO for example a gigabyte ethernet card. We
> really need to avoid this.
I don't see the advantage here.
My patch add an hypercall for each interruption handling to do EOI; with event 
channel the same is required (Xen must know when the domain has finished with 
IRQ handling.  I don't think this can be avoided).

> > Again, you need to set up RTEs.
>
> Yes, but no interrupt handling time mask and unmask, all those operation
> can be replaced by event channel mask and unmask.
Sure but these are not frequent.

> > Furthermore, I think we don't want to break transparent
> > virtualization, so it won't be only drag and drop.
> Yes, the idea approach doesn't violate transparent virtualization too.
I didn't catch what you mean.
Of course we could continue to support Xen and bare iron, but the amount of 
modifications is signifiant (IMO).

> > BTW, I think it will be *very* hard to find an ia64 platform which
> > can share an IRQ line.  Maybe I am wrong but I don't know such a
> > platform :-(
> I don't know exactly IA64 HW implementation, but usually an level
> triggered IRQ can be shared by multiple devices.
Correct.  But can be != done.
I'd like to know an ia64 implementation with shared IRQs.

>  Any clarification, Tony (if you are online)?
>
> Eddie
Tristan.


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