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

[Simon Horman <horms@xxxxxxxxxxxx>]

On Fri, Mar 06, 2009 at 10:29:59AM +0900, Yuji Shimada wrote:
> On Thu, 5 Mar 2009 20:42:32 +1100
> Simon Horman <horms@xxxxxxxxxxxx> wrote:
> 
> > On Thu, Mar 05, 2009 at 09:22:28AM +0000, Keir Fraser wrote:
> > > On 05/03/2009 09:05, "Simon Horman" <horms@xxxxxxxxxxxx> wrote:
> > > 
> > > > * pass-through devices may not share a GSI with another pass-through
> > > >   device, and its better if they don't share a GSI with an ioemu
> > > >   device either
> > > 
> > > Why is such sharing disallowed? Is this a problem with mapping multiple 
> > > MSI
> > > sources to a single level-triggered GSI? If we can reliably map one MSI to
> > > an emulated GSI, I would have thought that wire-ORing them would be easy,
> > > but perhaps the emulation is dodgy to begin with, even without sharing?
> > 
> > Shimada-san mentioned it in a previous post, hopefully he can explain 
> > further.
> 
> Please read hvm_dpci_eoi in xen/drivers/passthrough/io.c.
> 
> void hvm_dpci_eoi(struct domain *d, unsigned int guest_gsi,
>                   union vioapic_redir_entry *ent)
> {
>     ....
>     device = hvm_irq_dpci->girq[guest_gsi].device;
>     intx = hvm_irq_dpci->girq[guest_gsi].intx;
>     hvm_pci_intx_deassert(d, device, intx);
> 
>     machine_gsi = hvm_irq_dpci->girq[guest_gsi].machine_gsi;
> 
> Current hypervisor assumes only one pass-throughed device is connected
> to a guest gsi.

Hi Shimada-san,

Thanks, that is very helpful.

> It is possible to enhance to connect more than one pass-throughed
> device to a guest gsi, I think. If expanding guest GSI to 143 is not
> acceptable, sharing guest GSI between pass-throughed devices is one
> approach.

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
   - 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.

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 ?
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.

> In my understanding, Windows 2003 does not support MSI/MSI-X. So
> supporting INTx is still important, I think.

Understood.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en


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