Hi keir, I have two questions about the new qemu interrupt deliver mechanism. 1. Why is the interrupt router table put inside hypervisor other than Qemu? 2. Why is the relationship of PCI device interrupt pin to IOAPIC input pin put inside hypervisor other than Qemu? Thanks, Anthony _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/11/06 7:57 am, "Xu, Anthony" <anthony.xu@intel.com> wrote:> 1. Why is the interrupt router table put inside hypervisor other than > Qemu? > > 2. Why is the relationship of PCI device interrupt pin to IOAPIC input > pin put > inside hypervisor other than Qemu?Since the PICs live in Xen it seems cleaner to move interrupt steering there too and have a clean device-level interface to device models. It also means that this core piece of chipset infrastructure is available for use by PCI devices that we may implement in Xen or anywhere else outside the qemu-dm process in future, so in this respect it is more flexible rather than less. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser write on 2006年11月29日 16:11:> On 29/11/06 7:57 am, "Xu, Anthony" <anthony.xu@intel.com> wrote: > >> 1. Why is the interrupt router table put inside hypervisor other >> than Qemu? >> >> 2. Why is the relationship of PCI device interrupt pin to IOAPIC >> input pin put inside hypervisor other than Qemu? > > Since the PICs live in Xen it seems cleaner to move interrupt > steering there too and have a clean device-level interface to device > models. It also means that this core piece of chipset infrastructure > is available for use by PCI devices that we may implement in Xen or > anywhere else outside the qemu-dm process in future, so in this > respect it is more flexible rather than less.Thanks, This answered the first question. How about the second one? #define hvm_pci_intx_gsi(dev, intx) \ (((((dev)<<2) + ((dev)>>3) + (intx)) & 31) + 16) Why this logic is implemented inside hypervisor? Thanks, Anthony> > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/11/06 08:21, "Xu, Anthony" <anthony.xu@intel.com> wrote:> How about the second one? > #define hvm_pci_intx_gsi(dev, intx) \ > (((((dev)<<2) + ((dev)>>3) + (intx)) & 31) + 16) > > Why this logic is implemented inside hypervisor?Since the hypervisor exposes a device-level interface for interrupt assertion, the mapping from device INTx line to GSI naturally ends up in the hypervisor. This makes sense IMO -- GSIs can be shared and to correctly implement wire-OR semantics the guest needs to disambiguate which devices are (or are not) asserting a particular GSI at any time. Obviously all interrupt-capable PCI devices are currently implemented in qemu-dm so this could be worked around and a GSI-level interface exposed by Xen. But I think putting it in Xen is cleaner and more flexible long term. There is always the option of allowing the mapping to be dynamically specified to Xen in future (e.g., hvmloader could make a choice, install the appropriate ACPI DSDT and use a new hypercall to dynamically modify PCI->link and PCI->GSI information). It''s not clear that level of flexibility will be warranted though -- 32 non-legacy GSIs should be plenty to avoid sharing even with a static barber-pole INTx->GSI mapping. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/11/06 10:20, "Keir Fraser" <keir@xensource.com> wrote:> There is always > the option of allowing the mapping to be dynamically specified to Xen in > future (e.g., hvmloader could make a choice, install the appropriate ACPI > DSDT and use a new hypercall to dynamically modify PCI->link and PCI->GSI > information). It''s not clear that level of flexibility will be warranted > though -- 32 non-legacy GSIs should be plenty to avoid sharing even with a > static barber-pole INTx->GSI mapping.Actually I can be more precise than this. I *would* have allowed dynamic INTx->GSI mapping if it were easy to generate the _PRT in the ACPI DSDT. Then hvmloader could walk the PCI bus, find all INTx lines, and map them all to unique GSIs. That would be very nice. *But* the _PRT is embedded in the DSDT and so generating it during boot is (as far as I am aware) basically impossible. So since the _PRT is static, the mapping in Xen may as well be static too. I''d be very interested in knowing if there are any tricks to inject dynamic info into the DSDT (e.g., could the _PRT be dynamically generated in AML based on memory values poked by hvmloader?). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser write on 2006年11月29日 18:28:> On 29/11/06 10:20, "Keir Fraser" <keir@xensource.com> wrote: > >> There is always >> the option of allowing the mapping to be dynamically specified to >> Xen in future (e.g., hvmloader could make a choice, install the >> appropriate ACPI DSDT and use a new hypercall to dynamically modify >> PCI->link and PCI->GSI information). It''s not clear that level of >> flexibility will be warranted though -- 32 non-legacy GSIs should be >> plenty to avoid sharing even with a static barber-pole INTx->GSI >> mapping. > > Actually I can be more precise than this. I *would* have allowed > dynamic INTx->GSI mapping if it were easy to generate the _PRT in the > ACPI DSDT. Then hvmloader could walk the PCI bus, find all INTx > lines, and map them all to unique GSIs. That would be very nice. > *But* the _PRT is embedded in the DSDT and so generating it during > boot is (as far as I am aware) basically impossible. So since the > _PRT is static, the mapping in Xen may as well be static too. > > I''d be very interested in knowing if there are any tricks to inject > dynamic info into the DSDT (e.g., could the _PRT be dynamically > generated in AML based on memory values poked by hvmloader?). >Hi Keir, Thanks for your detailed description But I have below concerns. 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. Anthony> -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel