Hi - Should this patch work with your cleanerbtf branch? My console hangs when I run it. Maybe there's a .config setting I'm missing? I'll poke around some more.
Just to clarify a few things for my own knowledge: On 2016-06-17 at 08:57 Kyle Milka <[email protected]> wrote: > + .bus = 0, .source_irq = 0, .global_irq = 2, .inti_flags = 0}, > .bus = 0, .source_irq = 1, .global_irq = 1, .inti_flags = 0}, > .bus = 0, .source_irq = 3, .global_irq = 3, .inti_flags = 0}, > .bus = 0, .source_irq = 4, .global_irq = 4, .inti_flags = 0}, We give the guest these interrupt overrides. IIUC, that means the PIT is routed to global IRQ 2, the keyboard identity mapped to 1, COM2 to 3, and COM1 to 4. Not sure why we're mapping PIT to 2, but that's probably not relevant right now. I've read that some people do that. Since we don't provide serial or keyboard directly, overrides for 1, 3, and 4 are probably doing nothing, right? Perhaps we're just changing flags? Or are these overrides being used elsewhere? > static struct virtio_mmio_dev cons_mmio_dev = { > - .poke_guest = virtio_poke_guest > + .poke_guest = virtio_poke_guest, > + /* At the moment irq numbers cannot be below 24; this is a problem with > + * the IOAPIC and Interrupt Source Override Structure. */ > + .irq = 26, > }; We picked 26, such that it is >= 24. Any reason we didn't go with 24? We basically took the third IRQ available in the [24,xxx] space (how high does it go?) > +/* The problem with the IOAPIC and ISOR Structure means all irq numbers > + * must be at least 24, so this is used to correct that offset. */ > +#define IOAPIC_LAST_IRQ 23 I'd like to know where this 24 comes from. Is that the lowest value that Linux will allow us to allocate an IRQ for? Perhaps the others are pre-defined, and thus busy, on x86? The closest thing I found in Linux is this: arch/x86/kernel/apic/io_apic.c: /* * Need special handling for ISA IRQs because there may be multiple IOAPIC pins * sharing the same ISA IRQ number and irqdomain only supports 1:1 mapping * between IOAPIC pin and IRQ number. A typical IOAPIC has 24 pins, pin 0-15 are * used for legacy IRQs and pin 16-23 are used for PCI IRQs (PIRQ A-H). * When ACPI is disabled, only legacy IRQ numbers (IRQ0-15) are available, and * some BIOSes may use MP Interrupt Source records to override IRQ numbers for * PIRQs instead of reprogramming the interrupt routing logic. Thus there may be * multiple pins sharing the same legacy IRQ number when ACPI is disabled. */ Incidentally, it's a little odd (but OK) that we track the LAST_IRQ (meaning, we can't use this one) instead of FIRST_VIRTIO_IRQ or something. If I want the first IRQ (the zero-th?) I'd need to do IOAPIC_LAST_IRQ + irq_nr + 1. Perhaps instead of using '26' up above, we should use something based off of the LAST_IRQ / FIRST_IRQ. > + for (int i = 0; i < VIRTIO_MMIO_MAX_NUM_DEV; i++) { > + if (vm->virtio_mmio_devices[i] == NULL) > + continue; > + > + /* The first IRQ register starts at 0x10, and there are two > 32-bit > + * registers for each IRQ. The first 8 bits of the value > assigned to > + * 'reg' is the interrupt vector. */ > + irqreg = (vm->virtio_mmio_devices[i]->irq - IOAPIC_LAST_IRQ) * > 2 + 0x10; > + if (reg == irqreg && (value & 0xff) != 0) { > + vm->virtio_mmio_devices[i]->vec = value & 0xff; > + DPRINTF("irq vector for irq number %d is: %lx\n", > + vm->virtio_mmio_devices[i]->irq, value); Btw, in this DPRINTF, value should be & 0xff. > + } > + } Then we determine and set the vector at runtime by looking at the guest's IOAPIC access. For the console, that will be slot (26 - 23) = slot 3. How did Linux know to convert IRQ 26 to IOREDTBL3 (which is the *fourth* entry btw? Did they know to subtract the ISA and PCI IRQs space? In which case, I'd have expected them to subtract 24, not 23. As I imagine you've already done, when I set the IRQ to 24 (the lowest allowed), I get (edited): virtio-mmio: Registering device virtio-mmio.0 at 0x8000000000-0x80000003ff, IRQ 24. virtio mmio device reset: console ioapic: ioapic_write ix 0 set reg 0x13 ioapic: IOAPIC 0: set 00000013 to 0000000001000000 ioapic: ioapic_write ix 0 set reg 0x12 ioapic: IOAPIC 0: set 00000012 to 0000000000000931 ioapic: ioapic_write ix 0 set reg 0x12 ioapic: IOAPIC 0: set 00000012 to 0000000000000931 That's table entry 1 (24 - 23). If the lowest allowed IRQ is 24, then how can they ever access IOREDTBL0? Seems odd. Anyway, I can merge this, but if you all can shed a little light on things, that'd be great. Barret p.s. - we're ignoring the IOAPIC destination for now. looks like the writes above were trying to route to logical apic group 1. interesting... -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
