Re: [Xen-devel] Re: [PATCH 1/5] xen: events: use irq_alloc_desc(_at) instead of open-coding an IRQ allocator.

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Hello Stefano,

Thursday, October 28, 2010, 2:43:12 PM, you wrote:

> On Tue, 26 Oct 2010, Konrad Rzeszutek Wilk wrote:
>> > In that case we should use dynamic allocation for everything.  Or try to
>> > work out distinct irq ranges for different interrupts if you really want
>> > to keep irq==gsi.
>> 
>> Some little alarm bells are ringing in the back of my head about irq != gsi.
>> 
>> I think the issue was the permission. When a PCI device is allocated to the
>> PV guest, we do a bunch of xc_* calls to allow the domain to use the BARs
>> and the IRQ. I believe when the guest boots and tries to map the
>> event channel with the physical IRQ, one of the arguments is that GSI. And
>> if we provide a bogus GSI, well, we won't get the INTx to the guest.
>> 
>> As you mentioned, Stefano's patch add a new element to the tuple that can
>> contain the GSI value. At which point we can make the guest IRQ != GSI,
>> as long as we can contain the <gsi, event channel> mapping present so
>> that for the hypercalls we can give it the right GSI.
>> 
>> The MSI/MSI-X use a completly different mechanism that does not all
>> of this complication, so we are OK with that.
>> 
>> .. snip ..
>> 
>> > d) dynamically allocate all irqs for all event channel types.
>> 
>> <nods> Ok, you sold me on this idea.
>> 


> Even though dynamic allocation might seem possible for both pirqs and
> irqs, there are some severe limitations:


> - Xen won't allocate pirq numbers lower than 16 (probably because it
> expects pirq == gsi for the first 16 gsi), so it might run out
> of pirqs if we ask Xen to always choose the pirq number for us.  As a
> consequence it is safer to keep using pirq == gsi, at least for the
> first 16 gsis. This limitation should probably be fixed in Xen, but we
> need to support older hypervisors so we cannot rely on the fix to be
> present.

I don't know if this discussion is for dom0 kernels only., if it is .. is that 
support of older hypervisors necessarily true ?

If i read the xen pvops wiki:
      NOTE! xen/stable-2.6.32.x versions after June 2010 (2.6.32.15 and newer) 
require at least Xen 4.0.1-rc2 or newer to work properly!
      xend and xenstored will fail to start if using those kernel versions with 
for example Xen 4.0.0.
      There's an issue with creating/using /dev/xen/ device nodes, which has 
been fixed in Xen 4.0.1-rc2 and newer versions.
      See this patch: 
http://xenbits.xen.org/xen-4.0-testing.hg?rev/0e1521f654f2 and discussion at: 
http://lists.xensource.com/archives/html/xen-devel/2010-06/msg01129.html for 
more information.

So a pvops dom0 kernel all ready seems to require a very recent hypervisor. So 
for a dom0 pvops kernel there has to be much less worry about support for older 
hypervisors for Xen guests it would only apply for pv domains ?
So this could perhaps also be the opportunity to change things ?

--
Sander



> - Linux expects irq == gsi, see arch/x86/kernel/acpi/boot.c:gsi_to_irq

>         /* Provide an identity mapping of gsi == irq
>          * except on truly weird platforms that have
>          * non isa irqs in the first 16 gsis.
>          */






-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


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