[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel]Question about qemu interrupt deliver.
1a. If there is opportunity for code reuse we should aim for it. I'd be happy to see a root hvm/ directory. Clearly the IOAPIC code is already shared and that could be made more explicit by moving the source file. 1b. I don't care about the hypervisor getting bigger if the alternative is simply pushing code into other critical components. If the device models are buggy then HVM domains do not work -- it doesn't matter whether the code is in Xen or in qemu-dm. In some respects I prefer the former as I will tend to audit Xen code more aggressively. There is a downside that the effects of bad code may not be limited to a single guest but we should be aiming for high-quality code regardless of the context in which it executes. 2. I browsed a few drivers and concluded that most have correct INTx assertion behaviour. Any that don't should be fixed. Hacks like the 0-1 pulse done for periodic timers need addressing in a future patch, for example. -- Keir On 30/11/06 02:52, "Xu, Anthony" <anthony.xu@xxxxxxxxx> wrote: > 1. PCI->link and PCI->GSI are put into hypervisor. But it is under x86 > directory, > it's not convenient for other architecture to share these information. > > Seems there is a trend, we move code from other component into > hypersivor, > is there any criteria whether we should move code into hypersivor? > Otherwise > hypersivor will become bigger and bigger quickly, that's not definitely > what we want. > > 2. hypervisor uses hvm_irq->gsi_assert_count[gsi] to emulate level triggered > interrupt. > The code itself is correct, but it sets a high stardant for PCI device > emulator, it PCI device > emulator set irq_line low/hight twice continuously, that will lead to > interrupt lost or spurios > interrupt. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |