Hi Kevin,
You (kevin.tian) said:
>>> 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.
In the Linux-world, I agree it. But... In the other OS (like Windows),
we can get only hardware IRQ with its driver interface. Thus I propose
to change the spec of callback IRQ.
>>> 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
Yes. I mean that indeed.
Thanks,
- Tsunehisa Doi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home