From: Avi Kivity <avi@qumranet.com>
To: Alexander Graf <agraf@suse.de>
Cc: "Xu, Anthony" <anthony.xu@intel.com>, Jes Sorensen <jes@sgi.com>,
kvm-ia64@vger.kernel.org, "Zhang,
Xiantao" <xiantao.zhang@intel.com>,
kvm@vger.kernel.org
Subject: Re: [kvm-ia64-devel] IRQ assignment
Date: Wed, 21 May 2008 19:34:34 +0300 [thread overview]
Message-ID: <48344F1A.8090305@qumranet.com> (raw)
In-Reply-To: <1284E411-576E-498A-A1D2-4B9F37E72533@suse.de>
Alexander Graf wrote:
>
> On May 21, 2008, at 6:07 PM, Xu, Anthony wrote:
>
>> Avi Kivity wrote:
>>> Xu, Anthony wrote:
>>>> Xiantao and I have found the root cause,
>>>> Qemu emulates PIIX chipset, all pci devices can only use irq 10.11,
>>>> which is confiured inside chipset interrupt routing table. Even
>>>> though IOAPIC have 24 interrupt pins.
>>>> While KVM/IA64 use the same Guest Firmware with what XEN/IA64 which
>>>> use different "interrupt routing algorithm".
>>>> Means the pci device irq doesn't match between qemu and Guest
>>>> Firmware in KVM/IA64. So guest didn't get pci device interrupt.
>>>>
>>>> Obviously there are two ways to fix it.
>>>> 1. modify qemu side, all pci devices use irq larger than or equal to
>>>> 16, we need to come out an algorithm to calculate irq from pci
>>>> device(bus number,device number, function number),
>>>> then we also need to modify IA32 Guest BIOS to present the same
>>>> pci device irq (use same algorithm) to guest OS. Avi seems not want
>>>> to modify qemu a lot.
>>>>
>>>> 2. modify IA64 guest firmware, two pros, (1)all pci devices use only
>>>> 10,11 two irqs, so if there are many pci device, there are a lot of
>>>> interrupt sharing, which impact performance negatively
>>>> (2) We need to maintain two versions fo IA64 guest firmwares, one
>>>> for KVM/IA64, the other for XEN/IA64, which is not what I want.
>>>>
>>>>
>>>> What's your suggestion?
>>>>
>>>>
>>>
>>> Allowing qemu to use all ioapic interrupt pins will reduce interrupt
>>> sharing on x86, which is a good thing, so I prefer the first option
>>> too.
>>
>>
>> Thanks for your support, I preper option #1,
>> Any suggestion for the mapping from BDF to irq.
>>
>> In XEN both in IA64/IA32,
>>
>> BIOS provides a 48 pin IOAPIC ( usually it is 24) to reduce irq sharing.
>
> Most mainboards these days provide two IOAPICs, which would sum up to
> 48 again. I think that should be the preferred way of implementing it
> virtually too.
>
I agree. ia64 has a preference for a single 48-pin ioapic for Xen
compatibility, but x86 and ia64 needn't be exactly equal.
On the other hand, adding a new ioapic will be more difficult than
extending an existing one.
On yet another hand, two ioapics (each with its own lock) will improve
scaling.
On the fourth hand (anyone for Bridge?), if we hit ioapic scalability
problems, each pin should have its own lock.
> The idea is great! I tried extending the IRQ logic to a "full IOAPIC"
> myself recently, but failed miserably. The biggest hurdle is that
> currently the code is reversed in qemu. If an interrupt occurs, the
> PIC is asked if it's destined to go there and if not it gets rerouted
> to the IOAPIC. Unfortunately this breaks with IRQs > 16.
Shouldn't each irq be routed to *both* chips, and the OS disables one or
the other?
--
error compiling committee.c: too many arguments to function
prev parent reply other threads:[~2008-05-21 16:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <yq0zlrkkbdn.fsf@jaguar.mkp.net>
[not found] ` <yq0ve28ka20.fsf@jaguar.mkp.net>
[not found] ` <yq0bq3yjnp6.fsf@jaguar.mkp.net>
[not found] ` <yq0k5hniuld.fsf@jaguar.mkp.net>
[not found] ` <51CFAB8CB6883745AE7B93B3E084EBE201BCC43D@pdsmsx412.ccr.corp.intel.com>
[not found] ` <4834459B.1090900@qumranet.com>
[not found] ` <51CFAB8CB6883745AE7B93B3E084EBE201BCC43E@pdsmsx412.ccr.corp.intel.com>
2008-05-21 16:16 ` [kvm-ia64-devel] IRQ assignment Avi Kivity
2008-05-21 16:47 ` Xu, Anthony
2008-05-21 16:50 ` Avi Kivity
2008-05-21 16:54 ` Xu, Anthony
[not found] ` <1284E411-576E-498A-A1D2-4B9F37E72533@suse.de>
2008-05-21 16:34 ` Avi Kivity [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48344F1A.8090305@qumranet.com \
--to=avi@qumranet.com \
--cc=agraf@suse.de \
--cc=anthony.xu@intel.com \
--cc=jes@sgi.com \
--cc=kvm-ia64@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=xiantao.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox