在 2018/8/22 下午4:42, Andrea Bolognani 写道:
On Wed, 2018-08-22 at 11:06 +0800, Yi Min Zhao wrote:
在 2018/8/20 下午7:14, Andrea Bolognani 写道:
So which is unique: uid, fid, or the combination of the two?
Could I have
-device zpci,uid=1,fid=1
-device zpci,uid=1,fid=2
or would that not work? What about
-device zpci,uid=1,fid=1
-device zpci,uid=2,fid=1
would that be okay?
Both can't work. FID must be unique and UID must be also unique.
They are independent.
Got it, thanks.
My point is that a funtion called fooIsBaz() should only ever
check whether the foo in question is indeed a baz, without taking
any other action such as reporting errors. Leave that to the
caller, or give the function a different name.
I think moving to the caller is proper.
qemuDomainDeviceDefValidate() looks like a reasonable entry point
for checks such as "you specified a zPCI address but this is not
an s390 guest" or "your configuration requires zPCI but the QEMU
binary doesn't support that feature". Both of the cases above
should have proper test suite coverage, by the way.
How about my idea mentioned above?
You mean moving the check to the caller?
Yes.
I think qemuDomainDeviceDefValidate() is a better choice because
it should allow you to implement the checks once, potentially with
more context such as information about the domain and QEMU
capabilities, and have them performed regardless of whether the
device is being processed eg. during regular parsing or hotplug.
IIUC, in qemuDomainDeviceDefValidate(), we have to directly access
device_info from DeviceDef to check zpci. I think direct accessing is
insecure and we have to process those device types that has device_info.
In addition, these is a special case that address is not defined and pci
address type will be chosen by default.
I found there are a lot of caps check code while building command line.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
