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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Tristan Gingold wrote:
> Le Jeudi 09 Mars 2006 21:02, Tian, Kevin a écrit :
>> Anyway, good discussion by far though still some way to go for
>> consensus. :-) 
>> 
>> Maybe we want to look at this from another way - fairness. [...]
>> Regarding current model, there seems to be an issue about fairness
>> between physical interrupts and "xen events". Taking current 0xE9 for
>> example, it's lower than timer but higher than all external device
>> interrupts. This means "xen events" will always preempt device
>> interrupts in this case, which is unfair and not what we want.
> To my understanding, this is also true for x86.
> With event channel, real physical IRQs use events 0-255, while Xen
> events use events 256-511.
> 
> So what is the difference ?

The difference is that with event channel, IRQ (PIRQ from 0-255 and VIRQ from 
256-511)
vector itself doesn't participate in prioritization, but event channel. There 
is a map between
event channel and IRQ in evtchn.c.
With event channel solution, all the guest physical IRQ is injected/reflected 
through event 
channel instead of vLSAPIC. Event channel is a must as VBD/VNIF and Control 
Panel is using it except you rewrite all of them, I think you will not think in 
that way.If callback
itself is built on a pseudo IRQ (0xE9) in vLSAPIC, then all event channel has 
priority 0xE9 
in VLSAPIC. That has problem as some event channel need higher priority but 
some 
lower comparing with other guest device IRQ.

So the solution is to eliminate VLSAPIC and all guest PIRQ go with event 
channel. In the 
meantime, callback must go with a so called "upcall" function (callback 
function).
Hope this answer your question.

> 
> Tristan.

Eddie

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