Hi Andrea,
Thank you for the review.
On 6/3/20 12:58 PM, Andrea Bolognani wrote:
On Thu, 2020-04-09 at 12:31 +0200, Shalini Chellathurai Saroja wrote:
+++ b/src/conf/domain_addr.c
@@ -145,12 +145,18 @@ static void
virDomainZPCIAddressReleaseIds(virDomainZPCIAddressIdsPtr zpciIds,
virZPCIDeviceAddressPtr addr)
{
- if (!zpciIds || virZPCIDeviceAddressIsEmpty(addr))
+ if (!zpciIds)
return;
- virDomainZPCIAddressReleaseUid(zpciIds->uids, addr);
+ if (addr->uid_set) {
+ virDomainZPCIAddressReleaseUid(zpciIds->uids, addr);
+ addr->uid_set = false;
+ }
I think it would be cleaner to handle the boolean flags in the same
spot the values are taken care of, that is, in the Release{U,F}id()
functions.
ok, I will do so.
@@ -186,12 +192,16 @@ static int
virDomainZPCIAddressReserveAddr(virDomainZPCIAddressIdsPtr zpciIds,
virZPCIDeviceAddressPtr addr)
{
- if (virDomainZPCIAddressReserveUid(zpciIds->uids, addr) < 0)
+ if (addr->uid_set &&
+ virDomainZPCIAddressReserveUid(zpciIds->uids, addr) < 0)
return -1;
Same here...
- if (virDomainZPCIAddressReserveFid(zpciIds->fids, addr) < 0) {
- virDomainZPCIAddressReleaseUid(zpciIds->uids, addr);
- return -1;
+ if (addr->fid_set) {
+ if (virDomainZPCIAddressReserveFid(zpciIds->fids, addr) < 0) {
+ if (addr->uid_set)
+ virDomainZPCIAddressReleaseUid(zpciIds->uids, addr);
+ return -1;
+ }
}
return 0;
@@ -202,14 +212,28 @@ static int
virDomainZPCIAddressReserveNextAddr(virDomainZPCIAddressIdsPtr zpciIds,
virZPCIDeviceAddressPtr addr)
{
- if (virDomainZPCIAddressReserveNextUid(zpciIds->uids, addr) < 0)
- return -1;
+ bool uid_set, fid_set = false;
- if (virDomainZPCIAddressReserveNextFid(zpciIds->fids, addr) < 0) {
- virDomainZPCIAddressReleaseUid(zpciIds->uids, addr);
- return -1;
+ if (!addr->uid_set) {
+ if (virDomainZPCIAddressReserveNextUid(zpciIds->uids, addr) < 0)
+ return -1;
+ uid_set = true;
+ }
... and here. Basicall, push all handling of boolean flags one layer
down, where the actual values are taken care of.
@@ -234,7 +258,7 @@ virDomainPCIAddressExtensionReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr addr)
{
if (addr->extFlags & VIR_PCI_ADDRESS_EXTENSION_ZPCI) {
- virZPCIDeviceAddress zpci = { 0 };
+ virZPCIDeviceAddress zpci = addr->zpci;
if (virDomainZPCIAddressReserveNextAddr(addrs->zpciIds, &zpci) < 0)
return -1;
@@ -246,6 +270,7 @@ virDomainPCIAddressExtensionReserveNextAddr(virDomainPCIAddressSetPtr addrs,
return 0;
}
+
static int
virDomainPCIAddressExtensionEnsureAddr(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr addr)
@@ -253,10 +278,10 @@ virDomainPCIAddressExtensionEnsureAddr(virDomainPCIAddressSetPtr addrs,
if (addr->extFlags & VIR_PCI_ADDRESS_EXTENSION_ZPCI) {
virZPCIDeviceAddressPtr zpci = &addr->zpci;
- if (virZPCIDeviceAddressIsEmpty(zpci))
- return virDomainZPCIAddressReserveNextAddr(addrs->zpciIds, zpci);
- else
- return virDomainZPCIAddressReserveAddr(addrs->zpciIds, zpci);
+ if (virDomainZPCIAddressReserveAddr(addrs->zpciIds, zpci) < 0)
+ return -1;
+
+ return virDomainZPCIAddressReserveNextAddr(addrs->zpciIds, zpci);
}
I think the semantics for these functions need to be reconsidered.
The way they currently work, as evidenced by EnsureAddr(), is that
you either have a fully-specified address provided by the user, in
which case you want to reserve that address, or you have an empty
address because the user didn't provide ZPCI information, in which
case you allocate a new full address based on what uids and fids are
still available and use that one.
With your changes, we can now find ourselves in a hybrid situation,
where half of the ZPCI address has been provided by the user but the
remaining half is up to us... Ultimately, it might make sense to have
ReserveAddr(), ReserveNextAddr() and EnsureAddr() all call to the
same function which does something along the lines of
if (!zpci->uid_set)
AssignUid(zpci);
if (!zpci->fid_set)
AssignFid(zpci);
ReserveUid(zpci);
ReserveFid(zpci);
because that's ultimately what we're achieving anyway, only with
more obfuscation.
ok, I will do so.
+++ b/src/conf/domain_conf.c
@@ -7471,7 +7471,7 @@ virDomainDeviceInfoFormat(virBufferPtr buf,
virTristateSwitchTypeToString(info->addr.pci.multi));
}
- if (!virZPCIDeviceAddressIsEmpty(&info->addr.pci.zpci)) {
+ if (!virZPCIDeviceAddressIsIncomplete(&info->addr.pci.zpci)) {
virBufferAsprintf(&childBuf,
"<zpci uid='0x%.4x' fid='0x%.8x'/>\n",
info->addr.pci.zpci.uid,
By the time we get here, we should either have a complete ZPCI
address or no ZPCI address at all. So I would rewrite this as
if (IsIncomplete(zpci))
virReportError(VIR_ERR_INTERNAL, ...);
if (!IsPresent(zpci))
virBufferAsprintf(...);
with the first check being there just for extra safety (This Should
Never Happen™).
Sure.
+++ b/src/util/virpci.h
@@ -43,6 +43,8 @@ typedef virZPCIDeviceAddress *virZPCIDeviceAddressPtr;
struct _virZPCIDeviceAddress {
unsigned int uid; /* exempt from syntax-check */
unsigned int fid;
+ bool uid_set;
+ bool fid_set;
I believe we mostly use camelCase for struct members, although I
don't think we're too consistent with that :)
ok, I will camelCase the struct members.
I wonder if it would make sense to tie the two bits of information
together more explicitly, eg.
typedef struct _virZPCIDeviceAddressID {
unsigned int value;
bool isSet;
} virZPCIDeviceAddressID;
typedef struct _virZPCIDeviceAddress {
virZPCIDeviceAddressID uid;
virZPCIDeviceAddressID fid;
} virZPCIDeviceAddress;
I will redefine the struct as above.
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
@@ -39,7 +39,7 @@
<address domain='0x0003' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'>
- <zpci uid='0x0001' fid='0x00000001'/>
+ <zpci uid='0x0001' fid='0x00000000'/>
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
@@ -48,7 +48,7 @@
<address domain='0x0004' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'>
- <zpci uid='0x0002' fid='0x00000002'/>
+ <zpci uid='0x0002' fid='0x00000001'/>
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
@@ -57,7 +57,7 @@
<address domain='0x0005' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'>
- <zpci uid='0x0053' fid='0x00000000'/>
+ <zpci uid='0x0053' fid='0x00000002'/>
I'm not entirely clear on why these generated ZPCI addresses would
change. Can you explain that to me?
Sure:-). It changes in this version because at first the user specified
addresses are reserved and then the addresses which are not specified by
the user are assigned and reserved.
In the current master code, as uid and fid are correlated, both uid and
fid are reserved, when either one of them is specified by the user. So
for the pci device with uid = '0x0053', the code assumes that user has
specified fid as 0 (which is not true) and reserves fid as 0.
Warm Regards
Shalini C S
