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

>From: Doi.Tsunehisa@jp.fujitsu.com
>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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21/11/06 7:53 am, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>>  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.
On x86 the callback value is a Global System Interrupt.

 -- Keir


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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Keir,

You (keir) said:
>>>  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.
> 
> On x86 the callback value is a Global System Interrupt.
  Currently, On IA64 the callback value is External Interrupt Vector.
I want to change the value to be Global System Interupt like x86.

Thanks,
- Tsunehisa Doi

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