Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough

[Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>]

Hi Simon,

On Fri, 6 Mar 2009 13:46:40 +1100
Simon Horman <horms@xxxxxxxxxxxx> wrote:
> If we were to take the approach of allowing shared GSI,
> then I guess a naieve method would be to:
> 
> 1. Expand  hvm_irq_dpci->girq[guest_gsi] to allow it to
>    have a list of devices rather than a single device
> 
> 2. Have hvm_dpci_eoi() loop through each of these devices

I thought the same thing.

>    - A possible optimisation (suggested to me by Carsten Haitzler)
>      + Have a mechanism so that we know which device
>        actually handled the interrupt, and move it to the top
>        of the list so that it is tried first next time.
>        Assuming busy devices are likely to stay busy.

This does not seems to the optimization of sharing guest gsi for me.
This is optimization of sharing machine gsi, isn't it?

> On the other hand, looking at expanding the number of guest GSI.
> Are these actually mapped to hardware GSI, other than through
> machine_gsi = hvm_irq_dpci->girq[guest_gsi].machine_gsi ?

No, they are.

> I ask because Keir mentioned that one reason for not extending
> the range is a worry that some HW won't be able to cope with that many GSI.

"version register" of APIC in ICH9 has "maximum redirection entries"
field.  The field is equal to the number of interrupt input pins minus
one and is in the range 0 through 239. So I think virtual GSI can be
extended.

ICH9 datasheet: http://www.intel.com/assets/pdf/datasheet/316972.pdf


But I have not seen such big I/O APIC. So it is possible that guest OS
can't handle big virtual I/O APIC.

Thanks,
--
Yuji Shimada


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