RE: [Xen-devel] [PATCH] Change spec of callback IRQ for PV-on-HVM onIA64

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Doi.Tsunehisa@xxxxxxxxxxxxxx
>Sent: 2006年11月21日 15:40
>> Maybe I'm missing something and you can help me understand. :-)
>> Whatever the value is mangled in pdev->irq, you should always
>> keep following two instances same:
>>      if ((ret = request_irq(pdev->irq, evtchn_interrupt, SA_SHIRQ,...
>> and
>>      if ((ret = set_callback_irq(pdev->irq)))
>
>  In x86-linux, two instances are same. But in IA64-linux, previous one
>is a external interrupt vector for xen-platform interruption. Although
>latter one is a hardware IRQ id. Both values are not same in IA64-linux.

The callback value is the one pending to vIRR, which should be same
as the one that platform-pci driver binds to. I'm still not sure the exact 
difference here. It should be arch-independent. You have to draw 
agreement between two sides.

>
>> Before your patch, say pdev->irq is 0x27 (ISA irq 9), platform-pci
>> driver binds handler to 0x27 and xen will inject by callback_irq 0x27.
>> However in your patch, request_irq is still using pdev->irq (0x27)
>> while set_callback_irq instead wants (0x9). In this case, how can you
>> still make things working when two sides don't match...
>
>  With the modification of hypervisor side, the callback_irq(it's hardware
>IRQ) becomes to be converted to external interrupt vector with a
>emulator
>of IOSAPIC.
>

So you are saying:

Callback_irq (0x9) ----> isa_irq_to_vector(0x27) ----> pending to 0x27 
bit of IRRs -----> xen injects external interrupt to hvm -----> hvm 
ia64_handle_irq reads IVR -----> do_IRQ (0x27) ----> evtchn_interrupt

If this is the case, today's sequence is:
Callback_irq (0x27) ----> pending to 0x27 bit of IRRs -----> xen 
Injects external interrupt to hvm -----> hvm ia64_handle_irq reads 
IVR -----> do_IRQ (0x27) ----> evtchn_interrupt

Then I still can't see exact issue you want to solve. :-)

Thanks,
Kevin

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