Re: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend in pcifront_scan

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2011-12-09 at 16:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 2 of 2] mini-os: do not wait for pci backend in 
> pcifront_scan"):
> > Even in the case where there are passthrough devices configured libxl 
> > creates
> > the stubdom and waits for it to startup _before_ adding the backend. Since 
> > the
> > stub domains main thread is blocked before it can write the "running" state 
> > to
> > xenstore the toolstack eventually times out and kills everything.
> > 
> > There is already a separate pcifront thread which waits for the backend to
> > appear and calls init_pcifront at the appropriate time should a backend ever
> > appear.
> > 
> > Unfortunately I don't have any free test boxes with VT-d so I
> > haven't been able to test the cases where PCI deivces are passed
> > through but I obviously have tested that I can now start an HVM
> > domain with stub qemu without PCI devices passed through which I
> > couldn't do before so this is an improvement. This stuff is a bit
> > like pushing the lump around the carpet :-/
> 
> Right.  The worry would be, surely, that this somehow breaks by
> unpausing the guest before everything has been set up by the stubdom.

Yes. I was a bit unclear how this ever worked though...

We could potentially add something to libxl__create_pci_backend which
interlocks against the stubdom pcifront but without a system with an
IOMMU I'm not really in a position to test such a patch.

> But I'm happy to ack this patch on the basis that it seemed to improve
> things for you and should be harmless for the non-stubdom case.

Thanks.

> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> (Not applying it yet as the patch floodgate is still closed pending a
> test pass.)

Sure.

Ian.


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