[libvirt] [PATCH v2 RESEND 00/12] PCI passthrough support on s390

Daniel P. Berrangé berrange at redhat.com
Thu Jul 26 11:52:08 UTC 2018


On Thu, Jul 26, 2018 at 01:47:52PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-07-26 at 12:22 +0100, Daniel P. Berrangé wrote:
> > On Thu, Jul 26, 2018 at 07:17:03PM +0800, Yi Min Zhao wrote:
> > > 在 2018/7/26 下午7:00, Andrea Bolognani 写道:
> > > > From the test cases I see a zpci devices, with its own uid and fid,
> > > > is created for the pci-bridge as well... Is that intentional?
> > > 
> > > Firstly pci bridge can be auto-generated if a pci device is to be plugged to
> > > non-existing pci bus.
> > > IIUC, pci-bridge is treated as a controller device in libvirt. So I think,
> > > it's pretty readable not only
> > > in libvirt xml but also in qtree, if we assign zpci device for it. Otherwise
> > > address type of pci-bridge
> > > is pci type but has no uid and fid. Isn't it odd?
> 
> Everything about zPCI is odd ;)
> 
> I guess there's no harm in creating an additional zpci device,
> and as you say it will keep things a bit more consistent, which
> is good.
> 
> > From the libvirt side we must avoid any scenario where QEMU auto-adds
> > devices behind our back. If adding a device requires adding a controller
> > libvirt must do this explicitly and record it in the XML.
> 
> Definitely. My question was whether the corresponding zpci device
> should be created as well...

I'm not sure I understand it fully, but it sounds like  zpci devices are
providing info that is guest ABI sensitive, which would mean libvirt must
control and record it. So from that POV we should create zpci devices

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list