[libvirt] [PATCH v3 01/12] conf: Add definitions for 'uid' and 'fid' PCI address attributes

Andrea Bolognani abologna at redhat.com
Thu Aug 23 11:04:58 UTC 2018


On Thu, 2018-08-23 at 16:46 +0800, Yi Min Zhao wrote:
> 在 2018/8/23 下午4:12, Andrea Bolognani 写道:
> > This got me thinking that the extension flags *also* belongs to
> > virPCIDeviceAddress, since we need them to know whether the zPCI
> > part should be taken into account when formatting and such: you
> > used to check whether the zpci pointer was NULL, but of course you
> > can no longer do that once the pointer is gone; moreover, checking
> > for a flag is more explicit so that's also an improvement. Using
> > the flags stored into virDomainDeviceInfo would be ugly because it
> > would make it so virPCIDeviceAddress is no longer a stand-alone
> > object, so we should avoid that.
> > 
> > I'm not sure you can get away with not storing the extension flags
> > in virDomainDeviceInfo, though, because IIRC you might need to use
> > them *before* you have figured out that you're going to assign a
> > PCI address to the device. We might just have to store them twice,
> > which is not great but I think preferable to introducing a reverse
> > dependency from virPCIDeviceAddress to virDomainDeviceInfo. But I
> > haven't really looked too closely into it, so perhaps there's a
> > way to avoid that duplication after all :)
> 
> I think it's enough to store extension flags in virDomainDeviceInfo in 
> my new code.

As explained above, that would cause virPCIDeviceAddress to no
longer be usable on its own, which I don't think is a good idea.

If you have to store the flags in virDomainDeviceInfo for address
allocation purposes that's fine, but once address allocation has
been performed you should no longer need to look at those and
should use virPCIDeviceAddress on its own instead.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list