Re: [Xen-devel] PCI Passthrough bug with x86 HVM

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 25 Jun 2019, Roger Pau Monné wrote:
> On Mon, Jun 24, 2019 at 11:47:09AM -0700, Stefano Stabellini wrote:
> > + xen-devel
> > 
> > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > > Hi all,
> > > 
> > > I might have found a bug with PCI passthrough to a Linux HVM guest on
> > > x86 with Xen 4.12. It is not easy for me to get access, and especially
> > > change components, on this particular system, and I don't have access to
> > > other x86 boxes at the moment, so apologies for the partial information
> > > report. The setup is as follow:
> > > 
> > > - two PCI devices have been assigned to a HVM guest, everything is fine
> > > - reboot the guest from inside, i.e. `reboot' in Linux
> > > - after the reboot completes, only one device is assigned
> 
> Can you provide the xl debug log of the whole process?

See attached.


> > > Before the reboot, I see all the appropriate xenstore entries for both
> > > devices. Everything is fine. After the reboot, I can only see the
> > > xenstore entries of one device. It is as if the other device
> > > "disappeared" without throwing any errors.
> 
> So there are no errors on the hypervisor dmesg or the xl logs at all?

Nope. Only:

[445257.718590] xen_pciback: vpci: 0000:00:0e.0: assign to virtual slot 0
[445257.733048] pciback 0000:00:0e.0: registering for 4
[445257.741257] xen_pciback: vpci: 0000:03:00.0: assign to virtual slot 1
[445257.758836] pciback 0000:03:00.0: registering for 4
[445340.380219] xen_pciback: vpci: 0000:00:0e.0: assign to virtual slot 0
[445340.391755] pciback 0000:00:0e.0: registering for 5



> > > Have you seen this before? Do you know if it has been fixed in staging?
> > > I noticed this fix which seems to be very relevant:
> > > 
> > > https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01616.html
> > > 
> > > but it is already included in 4.12.
> 
> AFAICT your issue seems related to xl/libxl not properly re-adding the
> devices on reboot. The fix above had to do with leaving devices in a
> broken state under some circumstances (ie: they where always attached
> to the guest, just not working properly).

Yes, it looks like it is as you describe.

Attachment: xl-log.txt
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel