> This does look like common code to me, so it might be a good idea to
> share it with ia32. AFAIK apics are the same on ia32 and ia64.
> [Anthony] I wanted to do the same thing as what you said, while
> currently KVM/ia64 doesn't include apic.c file, I tried to add
> apic.c, but failed to complie
> I'll try to make it work.
Further investigation show there are many ia32 specific codes in apic.c file.
It may incur a lot of modifications if we want to share apic.c with IA64.
For example,
s->apicbase = (val & 0xfffff000) |
(s->apicbase & (MSR_IA32_APICBASE_BSP | MSR_IA32_APICBASE_ENABLE));
/* if disabled, cannot be enabled again */
if (!(val & MSR_IA32_APICBASE_ENABLE)) {
s->apicbase &= ~MSR_IA32_APICBASE_ENABLE;
env->cpuid_features &= ~CPUID_APIC;
s->spurious_vec &= ~APIC_SV_ENABLE;
BTW IA64 is using SAPIC not APIC, there are some difference.
For KVM/IA64, only two functions ioapic_map_irq and ioapic_set_irq are needed, and
Native qemu doesn't support guest IA64 platform yet.
So, the simple way is to put these two functions in ia64 specific file, ipf.c
Thanks,
Anthony
Xu, Anthony wrote:
> ________________________________
>
> From: Alexander Graf [mailto:agraf@xxxxxxx]
> Sent: 2008年6月13日 22:31
> To: Xu, Anthony
> Cc: Avi Kivity; Marcelo Tosatti; Jes Sorensen; kvm@xxxxxxxxxxxxxxx;
> kvm-ia64@xxxxxxxxxxxxxxx
> Subject: Re: [RFC] kvm irq assignment
>
>
>
> On Jun 12, 2008, at 11:38 PM, Xu, Anthony wrote:
>
>
> Hi Avi and all
>
> This is the revised one,
>
> All PCI devices send interrupt to both PIC and IOAPIC,
> a). When PIC is enabled and IOAPIC is disabled, all redirect
> entries in IOAPIC are masked.
> B) When PIC is disabled and IPAPIC is enabled, link entry bit7 is
> set, means this link entry is disable.
> Guest OS need to guarantee PIC and IOAPIC are not enabled in the same
> time. Otherwise cause many suspicious interrupt to guest.
>
>
> At boottime the IOAPIC is completely masked, while the PIC is
> completely unmasked. Somewhere during bootup ACPI compliant OSs can
> call _PIC to switch to IOAPIC mode and somehow deactivate the PIC
> lines and activate IOAPIC lines for the devices they are interested
> in.
>
> I sent a tool called "apicdump" to this list some time ago that
> allows you to read the PIC and IOAPIC from within Linux.
>
>
> [Anthony] nice tool, I'll try that.
>
>
>
> Test by running guest linux in kvm/ia32 and kvm/ia64.
>
>
> Thanks,
> Anthony
>
>
>
> diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
> index 21fc76a..e12fd66 100755
> --- a/bios/acpi-dsdt.dsl
> +++ b/bios/acpi-dsdt.dsl
>
>
> ACPI changes look fine to me.
>
>
>
>
>
>
>
> [snip]
>
>
> diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
> index a14cab2..c3014fa 100644
> --- a/qemu/hw/apic.c
> +++ b/qemu/hw/apic.c
> @@ -1053,9 +1053,25 @@ static void ioapic_service(IOAPICState *s)
> }
> }
>
> +int ioapic_map_irq(int devfn, int irq_num)
> +{
> + int irq;
> + irq = ((devfn >> 3) & 7) + 16;
> + return irq;
> +}
> +#ifdef KVM_CAP_IRQCHIP
> +static int ioapic_irq_count[IOAPIC_NUM_PINS];
> +#endif
> +
> void ioapic_set_irq(void *opaque, int vector, int level)
> {
> IOAPICState *s = opaque;
> +#ifdef KVM_CAP_IRQCHIP
> + ioapic_irq_count[vector] += level;
> + if (kvm_enabled())
> + if (kvm_set_irq(vector, ioapic_irq_count[vector] == 0))
> + return;
> +#endif
>
> if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
> uint32_t mask = 1 << vector;
> diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
> index b11e328..4761463 100644
> --- a/qemu/hw/ipf.c
> +++ b/qemu/hw/ipf.c
> @@ -672,3 +672,23 @@ QEMUMachine ipf_machine = {
> ipf_init_pci,
> VGA_RAM_SIZE + VGA_RAM_SIZE,
> };
> +
> +#define IOAPIC_NUM_PINS 48
> +static int ioapic_irq_count[IOAPIC_NUM_PINS];
> +
> +int ioapic_map_irq(int devfn, int irq_num)
> +{
> + int irq, dev;
> + dev = devfn >> 3;
> + irq = ((((dev << 2) + (dev >> 3) + irq_num) & 31) + 16);
> + return irq;
> +}
>
>
> Why does this look different from the one in apic.c?
> [Anthony] it is used for ia64, I would like to use same guest
> Firmware of XEN/ia64 in KVM/IA64,
> I "copy" the mapping from XEN/IA64.
>
>
>
>
> +
> +void ioapic_set_irq(void *opaque, int vector, int level)
> +{
> + ioapic_irq_count[vector] += level;
> + if (kvm_enabled())
> + if (kvm_set_irq(vector, ioapic_irq_count[vector] == 0))
> + return;
> +}
> +
>
>
> This does look like common code to me, so it might be a good idea to
> share it with ia32. AFAIK apics are the same on ia32 and ia64.
> [Anthony] I wanted to do the same thing as what you said, while
> currently KVM/ia64 doesn't include apic.c file, I tried to add
> apic.c, but failed to complie
> I'll try to make it work.
>
>
>
>
> diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
> index c284bf1..ef09a78 100644
> --- a/qemu/hw/pc.h
> +++ b/qemu/hw/pc.h
> @@ -47,6 +47,7 @@ int apic_accept_pic_intr(CPUState *env);
> void apic_local_deliver(CPUState *env, int vector);
> int apic_get_interrupt(CPUState *env);
> IOAPICState *ioapic_init(void);
> +int ioapic_map_irq(int devfn, int irq_num);
> void ioapic_set_irq(void *opaque, int vector, int level);
>
> /* i8254.c */
> diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
> index a23a466..f96fbb5 100644
> --- a/qemu/hw/pci.c
> +++ b/qemu/hw/pci.c
> @@ -27,6 +27,8 @@
> #include "net.h"
> #include "pc.h"
>
> +#include "qemu-kvm.h"
> +
> //#define DEBUG_PCI
>
> struct PCIBus {
> @@ -534,12 +536,18 @@ static void pci_set_irq(void *opaque, int
> irq_num, int level)
> PCIDevice *pci_dev = (PCIDevice *)opaque;
> PCIBus *bus;
> int change;
> -
> +#ifdef KVM_CAP_IRQCHIP
> + int irq;
> +#endif
> change = level - pci_dev->irq_state[irq_num];
> if (!change)
> return;
>
> pci_dev->irq_state[irq_num] = level;
> +#ifdef KVM_CAP_IRQCHIP
> + irq = ioapic_map_irq(pci_dev->devfn, irq_num);
> + ioapic_set_irq(opaque, irq, change);
> +#endif
>
>
> So if we're not running KVM we don't trigger the APIC? I don't see
> how that helps anyone. Just modify the Qemu APIC so that it works
> fine and then hook the in-kernel APIC to that. [Anthony] agree, it
> will support native Qemu.
>
>
>
> for (;;) {
> bus = pci_dev->bus;
> irq_num = bus->map_irq(pci_dev, irq_num);
> diff --git a/qemu/hw/piix_pci.c b/qemu/hw/piix_pci.c
> index 90cb3a6..96316ca 100644
> --- a/qemu/hw/piix_pci.c
> +++ b/qemu/hw/piix_pci.c
> @@ -225,6 +226,9 @@ static void piix3_set_irq(qemu_irq *pic, int
> irq_num, int level)
> /* now we change the pic irq level according to the piix irq
> mappings */
> /* XXX: optimize */
> pic_irq = piix3_dev->config[0x60 + irq_num];
> + /* if bit7 set 1, this link is disabled */
> + if (pic_irq & 0x80)
> + return;
>
>
> Uhm ... I do remember having seen that somewhere else. Why do you
> need to add it now? [Anthony] As Avi pointed out, below check (
> pic_irq < 16) already covers this check.
>
> Thanks
> Anthony
>
>
>
> if (pic_irq < 16) {
> /* The pic level is the logical OR of all the PCI irqs mapped
> to it */
>
>
>
>
>
> Xu, Anthony wrote:
>
>
> Avi Kivity wrote:
>
>
> 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.
>
>
> I think what you described is correct.
>
>
>
>
>
> The _PIC method should disable the link interrupts if ioapic mode
> is
>
>
> disabled.
>
>
> Typo! If ioapic mode is enabled.
>
>
>
> From x86 BIOS, OS disable link interrupt through link device _DIS
>
>
> mothod.
>
>
>
>
>
> This removes the need for communication between the bios and qemu.
>
>
> Agree
>
>
>
>
>
> + /* 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'll try this way.
>
>
>
> Anthony
--
To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
