Re: Question about qemu interrupt deliver.

Re: Question about qemu interrupt deliver.

[Keir Fraser]

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

RE: Question about qemu interrupt deliver.

[Xu, Anthony]

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

Re: Question about qemu interrupt deliver.

[Keir Fraser]

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

Re: Question about qemu interrupt deliver.

[Keir Fraser]

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

Re: Question about qemu interrupt deliver.

[Keir Fraser]

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.