Am 02.12.2011 19:43, schrieb Anthony Liguori: > On 12/02/2011 11:45 AM, Kevin Wolf wrote: >> Am 02.12.2011 18:26, schrieb Anthony Liguori: >>> On 12/02/2011 11:25 AM, Kevin Wolf wrote: >>> So that's how you read/write memory. Likewise, for IRQs, you can poll the >>> status of a given IRQ. I thought about doing some sort of signal magic >>> around >>> but when writing tests, polling the IRQ seems easier to deal with. >> >> Okay, polling interrupts should be good enough for tests. >> >> I guess the test still needs to do everything that a guest OS would have >> to do, for example send an EOI to the PIC? We'll probably want to have a >> library for such things then, but we can add it with the first test that >> uses interrupts. > > No, right now we more or less create a fake I/O APIC. We don't have to deal > with masking in the local APIC, boot strapping, or anything like that. > > It makes writing tests easier but I think it makes supporting MSI a bit more > challenging. I'm not sure how well it will generalize to other platforms > either. > > That's one of the reasons I wanted to get an early version out to get some > feedback on this.
Hm, if it's useful to have a fake controller probably depends on what you're trying to do. For writing test code for interrupt controllers it's probably not helpful. Now I'm not familiar enough with the interrupt code to say how tight it's coupled with the actual CPU implementation and how difficult it is to reuse in the context of a test environment, but I would say that we should use as much of the real emulation as possible. Also note that this isn't the only thing that test cases would share: Most tests will probably want to find some PCI device, virtio tests will probably want to share some code, and I don't even want to think about testing USB devices... Kevin
