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

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

Tristan Gingold wrote:
> Le Mardi 07 Mars 2006 00:34, Dong, Eddie a écrit :
>> Magenheimer, Dan (HP Labs Fort Collins) wrote:
>>> Hi Tristan --
>>> 
>>> Do you have any more design information?  I'm not very
>>> familiar with the x86 implementation but is it your intent
>>> for it to be (nearly) identical?  What would be different?
>> 
>> The difference is that should guest OS (para xen) still access the
>> IOSAPIC MMIO port? If the guest OS keeps accessing the machine
>> IOSAPIC MMIO address, multiple driver domain share same IRQ has
>> potential problem. The design in my opnion is that hypervisor own
>> the machine IOSAPIC resource exclusively including reading IVR and
>> issuing CR.EOI. All the guest is working with a pure virtual IOSAPIC
>> or virtual IO_APIC (actually doesn't matter for guest).
> [Note that IVR and CR.EOI are LSAPIC stuff.]
So should we use a new term virtual IRQ or interrupt virtualization?
Both LSAPIC and IOSAPIC need to be done in vIRQ.
BTW, RTE is still accessed by para-guest in previous patch :-)
Writing of RTE in machine resource from one domain will 
impact the correctness of other domain if they share same 
IRQ line.

> 
>>> Would all hardware I/O interrupts require queueing by
>>> Xen in an event channel?  This seems like it could be
>>> a potential high overhead performance issue.
> There are two things:
> * delivery of IRQs through event channel.  I am not sure about
> performance impact (should be almost the same).  I am sure about
> linux modification impact (new files added, interrupt low-level
> handling completly modified). 
I don't see too much Linux modifications here as most of  these files are 
already in xen.
You can find them if you compile a X86 Xen, see linux/arch/xen/kernel/** , all 
those event channel related file are there including the PIRQ dispatching.
 In some sense, the whole IOSAPIC.c file is no longer a must. 

> 
> * Use of callback for event channel (instead of an IRQ).
>   I suppose it should be slightly faster.  I suppose this is required
> (for speed reasons) if we deliver IRQs through event-channel.
> 
>> Mmm, I have different opnion here. With all guest physical IRQ
>> queueing by Xen event channel through a bitmap that is shared in
>> para-guest, the guest OS no longer needs to access IVR and EOI now,
>> that means we don't need to trap into hypervisor. Checking the
>> bitmap is defenitely higher performance than read IVR, in this way
>> the performance is improved actually.
> I really think this is not that obvious due to hyper-privop and
> hyper-reflexion.
This is basically the difference between hypercall and using share memory. 
Hard to say the amount but benefits is clear, although as this code is 
frequently accessed especially 
for driver domain where there are a lot of IRQs.

> Please start (maybe using some mails we have exchanged).  I will
> complete if necessary.
Yes, I have sent u some drafts. 
Eddie


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