Re: [Xen-devel] [PATCH 0/6] MSI-INTx interrupt translation for HVM

[Qing He <qing.he@xxxxxxxxx>]

On Tue, 2009-01-13 at 17:05 +0800, Shohei Fujiwara wrote:
> What I understand are the followings.
> 
>     - When guest gsi isn't shared, MSI-INTx interrupt translation works fine.
>     - When guest gsi is shared between passthrough device and emulated
>       device, MSI-INTx interrupt translation work, though guest OS
>       receives spurious interrupts.
>     - Sharing guest gsi among passthrough devices isn't supported.

Yes.

>     - There are some unsuitable devices for MSI-INTx interrupt translation.

I still don't know an example of such unsuitable devices. And to be
exact, it should be device/guest OS driver combination. The improper
function may be caused by the guest driver (e.g. not cleaning irq source
before issuing EOI)

> 
> 
> May I ask you any additional questions?
> 
> First, why can't we assign more than 8 devices?
> In the view of guest OS, assigned device is always single function
> device. This means assigned devices use only INTA. And Interrupt
> routing in hypervisor is shown as follows.

Well, I just checked the code, seems I'm using the stale knowledge.
The assigned devices didn't fix to INTA a few months ago, at that time,
it was 8, since (0:3.1) collided with (0:11.0).

It's now 32, and the situation is definitely much better.

> 
> From xen/include/asm-x86/hvm/irq.c:
>     #define hvm_pci_intx_gsi(dev, intx)  \
>         (((((dev)<<2) + ((dev)>>3) + (intx)) & 31) + 16)
> 
> I think sharing guest gsi among passthrough devices doesn't
> occur if assigned device is <= 32.
> 
> 
> Second, it is nice to create blacklist of unsuitable devices for MSI-INTx
> interrupt, isn't it? The reason is the problem seems device-specific problem.

This is reasonable, however, I don't know a real unsuitable at this
time. Isn't it better to add the blacklist when there is the real need?

What do you think?

Thanks,
Qing

> 
> Thanks,
> --
> Shohei Fujiwara
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel