Re: [Xen-devel] PCI passthrough with stubdomain

[Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>]

Marek Marczykowski-Górecki, on Fri 23 Sep 2016 16:25:41 +0200, wrote:
> On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > > I'm still trying to get PCI passthrough working with stubdomain and
> > > without qemu in dom0 (even for just vfb/vkbd backends). How is this
> > > supposed to work?
> > 
> > Just as I recall from my memory:
> > 
> > > 1. Should xen-pcifront in the target domain be used (and consequently,
> > > should xen-pciback be set for it)?
> > 
> > I guess that could work.
> 
> Could, or should? ;)

I don't really remember, actually. I do remember doing some passthrough
tests, but I don't remember the exact conditions.

> In the meantime, I've found this in xen-pcifront driver:
> 
>       static int __init pcifront_init(void)
>       {
>               if (!xen_pv_domain() || xen_initial_domain())
>                       return -ENODEV;
> 
> So, it looks like pcifront is not used in PV domain.

? I read it as disabling pcifront when used in an HVM or native domain,
i.e. precisely used in PV domains.

> > So the unfortunate thing is that when using stubdom, you'd have to set
> > the pciback either on the guest (to run a PV driver in it), or on the
> > stubdom (to run a plain driver in the guest, and let mini-os use PV to
> > let qemu pass the board through)
> 
> I've tried only on Linux HVM guest and as noted above xen-pcifront
> doesn't look to be involved. Is it any different on other OSes?

I don't know, perhaps it's different on windows. Or perhaps for windows
we just rely on the qemu pass-through.

> Toolstack during (stub)domain startup setup two things, mostly
> asynchronously:
> 1. pciback/pcifront (through standard xenstore entries)
> 2. instruct qemu to attach device (by writing "pci-ins" to
> device-model/xxx/command)

Ah, since pcifront_watches runs in a separate thread, it may not have
called init_pcifront before qemu calls libpci, i.e. pcifront_scan.

I'd say that's where the fix should be: make pcifront_scan wait for
init_pcifront to be done.  It's however not so simple: we want to make
pcifront_scan do nothing if no pciback is to be launched. My memory is
rusty: is there something we are sure will show up in the xenstore when
a pciback is to be launched?  If so, pcifront_scan could do this: wait
for pcifront_watches to have checked for the potential presence of
pciback. If pciback is not to be started, just do nothing; if pciback is
to be started, wait for init_pcifront to have been called by
pcifront_watches. Then it will find the devices.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel