From: Avi Kivity <avi@qumranet.com>
To: kvm-ia64@vger.kernel.org
Subject: Re: [RFC] kvm irq assignment
Date: Thu, 12 Jun 2008 19:16:38 +0000 [thread overview]
Message-ID: <48517616.1050607@qumranet.com> (raw)
In-Reply-To: <51CFAB8CB6883745AE7B93B3E084EBE201CC9077@pdsmsx412.ccr.corp.intel.com>
Xu, Anthony wrote:
> Hi all,
> Thanks for your comments.
>
> I made this new patch based on your comments
>
> 1. use bimodal _PRT, to take advantage of IOAPIC pin 16~23
> the mapping is simple, slot -> (slot&7)+16 IOAPIC pin,
> someone may provide good mapping ?
>
I think it's fine. If we find a better one later, or if we add another
ioapic, we can easily change it since the bios and qemu are shipped as a
unit.
> 2. use ISA-bridge configure space 0x64 byte as a communication
> mechansim.
> When guest BIOS invokes _PIC, the value is passed to qemu
> through byte 0x64.
> qemu know whether it is PIC mode and APIC mode by checking
> byte 0x64.
> 3. pci_slot_get_pirq and piix3_set_irq adopt different operation based
> on PIC mode/APIC mode
>
I'm not sure how real hardware works, but I _think_ that it routes irqs
unconditionally to both the legacy path and directly to the ioapic. So
for example if slot 5 asserts an interrupt, we map it through the pci
link mapping and generate an active high interrupt to one of {5, 10, 11}
(both pic and ioapic), and simultaneously an active low interrupt to
ioapic pin 21.
The _PIC method should disable the link interrupts if ioapic mode is
disabled.
This removes the need for communication between the bios and qemu.
>
> + /* APIC and PIC flag */
> + OperationRegion (P40D, PCI_Config, 0x64, 0x01)
> +
>
This is actually SERIRQC, serial irq control.
> +
> +#ifdef KVM_CAP_IRQCHIP
>
This should be unconditional.
> +static int pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
> +{
> + int slot_addend;
> + if( piix3_dev->config[0x64]) // APIC mode
> + return ((pci_dev->devfn >> 3) & 7)+16;
> + else { // PIC mode
> + slot_addend = (pci_dev->devfn >> 3) - 1;
> + return (irq_num + slot_addend) & 3;
> + }
> +}
>
What I'm suggesting is to "fork" the interrupt into two lines, one
legacy path and the ioapic path.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@qumranet.com>
To: "Xu, Anthony" <anthony.xu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Alexander Graf <agraf@suse.de>, Jes Sorensen <jes@sgi.com>,
kvm@vger.kernel.org, kvm-ia64@vger.kernel.org
Subject: Re: [RFC] kvm irq assignment
Date: Thu, 12 Jun 2008 22:16:38 +0300 [thread overview]
Message-ID: <48517616.1050607@qumranet.com> (raw)
In-Reply-To: <51CFAB8CB6883745AE7B93B3E084EBE201CC9077@pdsmsx412.ccr.corp.intel.com>
Xu, Anthony wrote:
> Hi all,
> Thanks for your comments.
>
> I made this new patch based on your comments
>
> 1. use bimodal _PRT, to take advantage of IOAPIC pin 16~23
> the mapping is simple, slot -> (slot&7)+16 IOAPIC pin,
> someone may provide good mapping ?
>
I think it's fine. If we find a better one later, or if we add another
ioapic, we can easily change it since the bios and qemu are shipped as a
unit.
> 2. use ISA-bridge configure space 0x64 byte as a communication
> mechansim.
> When guest BIOS invokes _PIC, the value is passed to qemu
> through byte 0x64.
> qemu know whether it is PIC mode and APIC mode by checking
> byte 0x64.
> 3. pci_slot_get_pirq and piix3_set_irq adopt different operation based
> on PIC mode/APIC mode
>
I'm not sure how real hardware works, but I _think_ that it routes irqs
unconditionally to both the legacy path and directly to the ioapic. So
for example if slot 5 asserts an interrupt, we map it through the pci
link mapping and generate an active high interrupt to one of {5, 10, 11}
(both pic and ioapic), and simultaneously an active low interrupt to
ioapic pin 21.
The _PIC method should disable the link interrupts if ioapic mode is
disabled.
This removes the need for communication between the bios and qemu.
>
> + /* APIC and PIC flag */
> + OperationRegion (P40D, PCI_Config, 0x64, 0x01)
> +
>
This is actually SERIRQC, serial irq control.
> +
> +#ifdef KVM_CAP_IRQCHIP
>
This should be unconditional.
> +static int pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
> +{
> + int slot_addend;
> + if( piix3_dev->config[0x64]) // APIC mode
> + return ((pci_dev->devfn >> 3) & 7)+16;
> + else { // PIC mode
> + slot_addend = (pci_dev->devfn >> 3) - 1;
> + return (irq_num + slot_addend) & 3;
> + }
> +}
>
What I'm suggesting is to "fork" the interrupt into two lines, one
legacy path and the ioapic path.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2008-06-12 19:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 16:39 [RFC] kvm irq assignment Xu, Anthony
2008-06-12 16:39 ` Xu, Anthony
2008-06-12 19:16 ` Avi Kivity [this message]
2008-06-12 19:16 ` Avi Kivity
2008-06-13 2:45 ` Xu, Anthony
2008-06-13 2:45 ` Xu, Anthony
2008-06-13 6:38 ` Xu, Anthony
2008-06-13 6:38 ` Xu, Anthony
2008-06-13 14:22 ` Avi Kivity
2008-06-13 14:22 ` Avi Kivity
2008-06-14 23:32 ` Marcelo Tosatti
2008-06-14 23:32 ` Marcelo Tosatti
2008-06-16 1:26 ` Xu, Anthony
2008-06-16 1:26 ` Xu, Anthony
2008-06-16 1:34 ` Xu, Anthony
2008-06-16 1:34 ` Xu, Anthony
2008-06-16 1:36 ` Xu, Anthony
2008-06-16 1:36 ` Xu, Anthony
2008-06-16 5:31 ` Xu, Anthony
2008-06-16 5:31 ` Xu, Anthony
2008-06-16 5:40 ` Xu, Anthony
2008-06-16 5:40 ` Xu, Anthony
2008-06-16 15:52 ` Marcelo Tosatti
2008-06-16 15:52 ` Marcelo Tosatti
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=48517616.1050607@qumranet.com \
--to=avi@qumranet.com \
--cc=kvm-ia64@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.