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

[Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>]

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.

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.


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

Thanks,
--
Yuji Shimada


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