src/conf/device_conf.c | 45 ++++++-------- src/conf/domain_addr.c | 59 +++++++++++++------ src/conf/domain_conf.c | 2 +- src/libvirt_private.syms | 4 +- src/qemu/qemu_validate.c | 26 +++++++- src/util/virpci.c | 23 ++------ src/util/virpci.h | 6 +- .../hostdev-vfio-zpci-autogenerate-fids.args | 31 ++++++++++ .../hostdev-vfio-zpci-autogenerate-fids.xml | 29 +++++++++ .../hostdev-vfio-zpci-autogenerate-uids.args | 31 ++++++++++ .../hostdev-vfio-zpci-autogenerate-uids.xml | 29 +++++++++ .../hostdev-vfio-zpci-ccw-memballoon.args | 28 +++++++++ .../hostdev-vfio-zpci-ccw-memballoon.xml | 17 ++++++ .../hostdev-vfio-zpci-duplicate.xml | 30 ++++++++++ ...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 21 +++++++ .../hostdev-vfio-zpci-multidomain-many.args | 6 +- .../hostdev-vfio-zpci-set-zero.xml | 21 +++++++ .../hostdev-vfio-zpci-uid-set-zero.xml | 20 +++++++ tests/qemuxml2argvtest.c | 25 ++++++++ .../hostdev-vfio-zpci-multidomain-many.xml | 6 +- 20 files changed, 387 insertions(+), 72 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml
The ZPCI address validation or autogeneration does not work as expected in the following scenarios 1. uid = 0 and fid = 0 2. uid = 0 and fid > 0 3. uid = 0 and fid not specified 4. uid not specified and fid > 0 5. 2 ZPCI devices with uid > 0 and fid not specified. This is because of the following reasons 1. If uid = 0 or fid = 0 the code assumes that user has not specified the corresponding address 2. If either uid or fid is provided, the code assumes that both uid and fid addresses are specified by the user. This patch fixes these issues. Shalini Chellathurai Saroja (6): conf: fix ZPCI address validation on s390 tests: qemu: add tests for ZPCI on s390 conf: fix ZPCI address auto-generation on s390 qemu: move ZPCI uid validation into device validation tests: qemu: add more tests for ZPCI on S390 tests: add test with PCI and CCW device src/conf/device_conf.c | 45 ++++++-------- src/conf/domain_addr.c | 59 +++++++++++++------ src/conf/domain_conf.c | 2 +- src/libvirt_private.syms | 4 +- src/qemu/qemu_validate.c | 26 +++++++- src/util/virpci.c | 23 ++------ src/util/virpci.h | 6 +- .../hostdev-vfio-zpci-autogenerate-fids.args | 31 ++++++++++ .../hostdev-vfio-zpci-autogenerate-fids.xml | 29 +++++++++ .../hostdev-vfio-zpci-autogenerate-uids.args | 31 ++++++++++ .../hostdev-vfio-zpci-autogenerate-uids.xml | 29 +++++++++ .../hostdev-vfio-zpci-ccw-memballoon.args | 28 +++++++++ .../hostdev-vfio-zpci-ccw-memballoon.xml | 17 ++++++ .../hostdev-vfio-zpci-duplicate.xml | 30 ++++++++++ ...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 21 +++++++ .../hostdev-vfio-zpci-multidomain-many.args | 6 +- .../hostdev-vfio-zpci-set-zero.xml | 21 +++++++ .../hostdev-vfio-zpci-uid-set-zero.xml | 20 +++++++ tests/qemuxml2argvtest.c | 25 ++++++++ .../hostdev-vfio-zpci-multidomain-many.xml | 6 +- 20 files changed, 387 insertions(+), 72 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml -- 2.21.1
On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote: > The ZPCI address validation or autogeneration does not work as > expected in the following scenarios > 1. uid = 0 and fid = 0 > 2. uid = 0 and fid > 0 > 3. uid = 0 and fid not specified > 4. uid not specified and fid > 0 > 5. 2 ZPCI devices with uid > 0 and fid not specified. > > This is because of the following reasons > 1. If uid = 0 or fid = 0 the code assumes that user has not specified > the corresponding address > 2. If either uid or fid is provided, the code assumes that both uid > and fid addresses are specified by the user. I'd have to dig up the old threads, but based on what I remember the behaviors you describe are entirely intentional. For PCI addresses, setting all parts of the address to zero or not setting it at all is equivalent, and we wanted to be consistent with that behavior for ZPCI; additionally, zero is not a valid value for uid so of course neither is the address uid=0 fid=0, which means that we're not preventing the user from specifying a valid address by conflating the all-zero address with the unspecified address. For partially-specified addresses, the behavior is also the same as PCI: any part you don't specify is considered to be zero, which results in uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid uid=0 -> uid=0 fid=0 -> address gets autogenerated fid=x -> uid=0 fid=x -> address is rejected as invalid uid=x -> uid=x fid=0 -> address is accepted So, just like for PCI addresses, you have basically two reasonable options: either don't specify any zPCI address and leave allocation entirely up to libvirt, or specify all of the addresses completely: anything in between will likely not work as you'd expect or want. Again, this is based purely on my recollection of design discussions that happened one and a half years ago, so I might have gotten some of the details wrong - in which case by all means call me out on that O:-) -- Andrea Bolognani / Red Hat / Virtualization
On 4/10/20 2:06 PM, Andrea Bolognani wrote: > On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote: >> The ZPCI address validation or autogeneration does not work as >> expected in the following scenarios >> 1. uid = 0 and fid = 0 >> 2. uid = 0 and fid > 0 >> 3. uid = 0 and fid not specified >> 4. uid not specified and fid > 0 >> 5. 2 ZPCI devices with uid > 0 and fid not specified. >> >> This is because of the following reasons >> 1. If uid = 0 or fid = 0 the code assumes that user has not specified >> the corresponding address >> 2. If either uid or fid is provided, the code assumes that both uid >> and fid addresses are specified by the user. > > I'd have to dig up the old threads, but based on what I remember the > behaviors you describe are entirely intentional. > > For PCI addresses, setting all parts of the address to zero or not > setting it at all is equivalent, and we wanted to be consistent with > that behavior for ZPCI; additionally, zero is not a valid value for > uid so of course neither is the address uid=0 fid=0, which means that > we're not preventing the user from specifying a valid address by > conflating the all-zero address with the unspecified address. > > For partially-specified addresses, the behavior is also the same as > PCI: any part you don't specify is considered to be zero, which > results in > > uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > uid=0 -> uid=0 fid=0 -> address gets autogenerated > fid=x -> uid=0 fid=x -> address is rejected as invalid > uid=x -> uid=x fid=0 -> address is accepted > > So, just like for PCI addresses, you have basically two reasonable > options: either don't specify any zPCI address and leave allocation > entirely up to libvirt, or specify all of the addresses completely: > anything in between will likely not work as you'd expect or want. > > Again, this is based purely on my recollection of design discussions > that happened one and a half years ago, so I might have gotten some > of the details wrong - in which case by all means call me out on > that O:-) > Hi Andrea, sorry for the delayed answer. I (and some others as well) lost some emails on my IMAP account and I just found your answer today. I can remember that you had a discussion with the original author of the zpci code. There are a few issues with the currently implemented "rules" which partially are not even working as you outlined above in more complex scenarios. First: Setting uid=0 or uid='0x0000' The architecture allows to do that BUT if you do than you are NOT using the uid mode which results for the guest OS to use the legacy mode for assigning PCI addresses starting with 0 increasing by one following an unpredictable order by which the pci device are presented to guest OS. Since we never ever wanted to support the legacy mode in KVM guests we decided to never allow uid=0. Allowing the uid to be set to 0 is a contradiction. Actually the user can also set uid='0x0000' which I consider very specific and one would end up with something like uid='0x0001' and even more confusing is that suddenly setting uid='0x0000' on more than one PCI device is allowed. Besides that the current zpci code still contains at least one flaw that is simply caused by the fact that there is no knowledge about which value was specified by the user. In Shalini's and your list it is case 5: This scenario runs into errors when another PCI device already has a fid set to 0 OR another PCI device exists specified with a uid > 0 and without a fid. The user gets the error message for something he did not specify: error: Failed to define domain from pci-addr-test.xml error: internal error: zPCI fid 0 is already reserved Regarding setting fid=0 or fid='0x00000000' Since it is a legal value for fid specifying it should not be considered as a wildcard or set equivalent to not specifying it at all. Doing so things like this happen and for the user it certainly seems like a bug: Specify this in the domain: pcidev1: uid='0x0000' fid='0x00000000' pcidev2: uid='0x0000' Results in a defined domain: pcidev1: uid='0x0002' fid='0x00000001' pcidev2: uid='0x0001' fid='0x00000000' Another example: Specify this in the domain: pcidev1: fid='0x00000000' pcidev2: fid='0x00000000' Results in a defined domain: pcidev1: uid='0x0002' fid='0x00000001' pcidev2: uid='0x0001' fid='0x00000000' BUT Specify this in the domain: pcidev1: uid='0x0002' fid='0x00000000' pcidev2: uid='0x0001' fid='0x00000000' Results in error: error: Failed to define domain from pci-addr-test.xml error: internal error: zPCI fid 0 is already reserved (Btw remove one of the fids results in the flaw described above.) I think that Shalini's patch series improves the zpci address generation to better meet the users expected behavior. It also removes a correlation between uid and fid that does not really exist. -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Hi Andrea, Ping, in case you missed it. On 4/20/20 9:55 PM, Boris Fiuczynski wrote: > On 4/10/20 2:06 PM, Andrea Bolognani wrote: >> On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote: >>> The ZPCI address validation or autogeneration does not work as >>> expected in the following scenarios >>> 1. uid = 0 and fid = 0 >>> 2. uid = 0 and fid > 0 >>> 3. uid = 0 and fid not specified >>> 4. uid not specified and fid > 0 >>> 5. 2 ZPCI devices with uid > 0 and fid not specified. >>> >>> This is because of the following reasons >>> 1. If uid = 0 or fid = 0 the code assumes that user has not specified >>> the corresponding address >>> 2. If either uid or fid is provided, the code assumes that both uid >>> and fid addresses are specified by the user. >> >> I'd have to dig up the old threads, but based on what I remember the >> behaviors you describe are entirely intentional. >> >> For PCI addresses, setting all parts of the address to zero or not >> setting it at all is equivalent, and we wanted to be consistent with >> that behavior for ZPCI; additionally, zero is not a valid value for >> uid so of course neither is the address uid=0 fid=0, which means that >> we're not preventing the user from specifying a valid address by >> conflating the all-zero address with the unspecified address. >> >> For partially-specified addresses, the behavior is also the same as >> PCI: any part you don't specify is considered to be zero, which >> results in >> >> uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated >> uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid >> uid=0 -> uid=0 fid=0 -> address gets autogenerated >> fid=x -> uid=0 fid=x -> address is rejected as invalid >> uid=x -> uid=x fid=0 -> address is accepted >> >> So, just like for PCI addresses, you have basically two reasonable >> options: either don't specify any zPCI address and leave allocation >> entirely up to libvirt, or specify all of the addresses completely: >> anything in between will likely not work as you'd expect or want. >> >> Again, this is based purely on my recollection of design discussions >> that happened one and a half years ago, so I might have gotten some >> of the details wrong - in which case by all means call me out on >> that O:-) >> > Hi Andrea, > sorry for the delayed answer. I (and some others as well) lost some > emails on my IMAP account and I just found your answer today. > I can remember that you had a discussion with the original author of > the zpci code. There are a few issues with the currently implemented > "rules" which partially are not even working as you outlined above in > more complex scenarios. > > First: Setting uid=0 or uid='0x0000' > The architecture allows to do that BUT if you do than you are NOT > using the uid mode which results for the guest OS to use the legacy > mode for assigning PCI addresses starting with 0 increasing by one > following an unpredictable order by which the pci device are presented > to guest OS. Since we never ever wanted to support the legacy mode in > KVM guests we decided to never allow uid=0. Allowing the uid to be set > to 0 is a contradiction. > Actually the user can also set uid='0x0000' which I consider very > specific and one would end up with something like uid='0x0001' and > even more confusing is that suddenly setting uid='0x0000' on more than > one PCI device is allowed. > > Besides that the current zpci code still contains at least one flaw > that is simply caused by the fact that there is no knowledge about > which value was specified by the user. > In Shalini's and your list it is case 5: This scenario runs into > errors when another PCI device already has a fid set to 0 OR another > PCI device exists specified with a uid > 0 and without a fid. The user > gets the error message for something he did not specify: > error: Failed to define domain from pci-addr-test.xml > error: internal error: zPCI fid 0 is already reserved > > Regarding setting fid=0 or fid='0x00000000' > Since it is a legal value for fid specifying it should not be > considered as a wildcard or set equivalent to not specifying it at all. > Doing so things like this happen and for the user it certainly seems > like a bug: > Specify this in the domain: > pcidev1: uid='0x0000' fid='0x00000000' > pcidev2: uid='0x0000' > Results in a defined domain: > pcidev1: uid='0x0002' fid='0x00000001' > pcidev2: uid='0x0001' fid='0x00000000' > Another example: > Specify this in the domain: > pcidev1: fid='0x00000000' > pcidev2: fid='0x00000000' > Results in a defined domain: > pcidev1: uid='0x0002' fid='0x00000001' > pcidev2: uid='0x0001' fid='0x00000000' > BUT > Specify this in the domain: > pcidev1: uid='0x0002' fid='0x00000000' > pcidev2: uid='0x0001' fid='0x00000000' > Results in error: > error: Failed to define domain from pci-addr-test.xml > error: internal error: zPCI fid 0 is already reserved > (Btw remove one of the fids results in the flaw described above.) > > > I think that Shalini's patch series improves the zpci address > generation to better meet the users expected behavior. It also removes > a correlation between uid and fid that does not really exist. >
On Mon, 2020-04-20 at 21:55 +0200, Boris Fiuczynski wrote: > On 4/10/20 2:06 PM, Andrea Bolognani wrote: > > On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote: > > > The ZPCI address validation or autogeneration does not work as > > > expected in the following scenarios > > > 1. uid = 0 and fid = 0 > > > 2. uid = 0 and fid > 0 > > > 3. uid = 0 and fid not specified > > > 4. uid not specified and fid > 0 > > > 5. 2 ZPCI devices with uid > 0 and fid not specified. > > > > > > This is because of the following reasons > > > 1. If uid = 0 or fid = 0 the code assumes that user has not specified > > > the corresponding address > > > 2. If either uid or fid is provided, the code assumes that both uid > > > and fid addresses are specified by the user. > > > > I'd have to dig up the old threads, but based on what I remember the > > behaviors you describe are entirely intentional. > > > > For PCI addresses, setting all parts of the address to zero or not > > setting it at all is equivalent, and we wanted to be consistent with > > that behavior for ZPCI; additionally, zero is not a valid value for > > uid so of course neither is the address uid=0 fid=0, which means that > > we're not preventing the user from specifying a valid address by > > conflating the all-zero address with the unspecified address. > > > > For partially-specified addresses, the behavior is also the same as > > PCI: any part you don't specify is considered to be zero, which > > results in > > > > uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > uid=0 -> uid=0 fid=0 -> address gets autogenerated > > fid=x -> uid=0 fid=x -> address is rejected as invalid > > uid=x -> uid=x fid=0 -> address is accepted > > > > So, just like for PCI addresses, you have basically two reasonable > > options: either don't specify any zPCI address and leave allocation > > entirely up to libvirt, or specify all of the addresses completely: > > anything in between will likely not work as you'd expect or want. > > > > Again, this is based purely on my recollection of design discussions > > that happened one and a half years ago, so I might have gotten some > > of the details wrong - in which case by all means call me out on > > that O:-) > > > Hi Andrea, > sorry for the delayed answer. I (and some others as well) lost some > emails on my IMAP account and I just found your answer today. No apologies needed: I also took a long time to reply to your message, and in my case there's no mail server malfunction that I can assign the blame to O:-) > I can remember that you had a discussion with the original author of the > zpci code. There are a few issues with the currently implemented "rules" > which partially are not even working as you outlined above in more > complex scenarios. I disagree with this assessment - they work exactly as designed and as described above. Whether we *want* them to behave that way... Now that's a different topic :) I think the disconnect lies in what the user's expectations are and what libvirt actually implements. Basically the user expects that * if either one of uid and fid is explictly assigned a value by the user, then the guest will use that value - unless such value is invalid, in which case libvirt will report an error; * if either one of uid and fid is absent from the user-provided configuration, then libvirt will automatically pick a valid value for the attribute. This is not how the current zPCI implementation works, or how PCI address assignment works in libvirt; on the other hand, I think these expectations are in fact completely reasonable, as the examples you provide illustrate quite well. I think you successfully convinced me that the current approach is not good for users and we should fix it; my only doubt at this point is whether can we safely do that without breaking libvirt's backwards compatibility guarantees. Dan, Laine, what's your take? -- Andrea Bolognani / Red Hat / Virtualization
On 5/6/20 7:48 PM, Andrea Bolognani wrote: >> I can remember that you had a discussion with the original author of the >> zpci code. There are a few issues with the currently implemented "rules" >> which partially are not even working as you outlined above in more >> complex scenarios. > I disagree with this assessment - they work exactly as designed and > as described above. Whether we*want* them to behave that way... Now > that's a different topic:) I agree that my wording was imprecise. It works exactly like you described! The problem is that even so it was designed that way it is currently working incorrect. Assigning fid the value 0 is a legal assignment. It must not be considered as wildcard or "not specified by user". -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On 5/6/20 1:48 PM, Andrea Bolognani wrote: > On Mon, 2020-04-20 at 21:55 +0200, Boris Fiuczynski wrote: >> On 4/10/20 2:06 PM, Andrea Bolognani wrote: >>> On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote: >>>> The ZPCI address validation or autogeneration does not work as >>>> expected in the following scenarios >>>> 1. uid = 0 and fid = 0 >>>> 2. uid = 0 and fid > 0 >>>> 3. uid = 0 and fid not specified >>>> 4. uid not specified and fid > 0 >>>> 5. 2 ZPCI devices with uid > 0 and fid not specified. >>>> >>>> This is because of the following reasons >>>> 1. If uid = 0 or fid = 0 the code assumes that user has not specified >>>> the corresponding address >>>> 2. If either uid or fid is provided, the code assumes that both uid >>>> and fid addresses are specified by the user. >>> >>> I'd have to dig up the old threads, but based on what I remember the >>> behaviors you describe are entirely intentional. >>> >>> For PCI addresses, setting all parts of the address to zero or not >>> setting it at all is equivalent, and we wanted to be consistent with >>> that behavior for ZPCI; additionally, zero is not a valid value for >>> uid so of course neither is the address uid=0 fid=0, which means that >>> we're not preventing the user from specifying a valid address by >>> conflating the all-zero address with the unspecified address. >>> >>> For partially-specified addresses, the behavior is also the same as >>> PCI: any part you don't specify is considered to be zero, which >>> results in >>> >>> uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated >>> uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid >>> uid=0 -> uid=0 fid=0 -> address gets autogenerated >>> fid=x -> uid=0 fid=x -> address is rejected as invalid >>> uid=x -> uid=x fid=0 -> address is accepted >>> >>> So, just like for PCI addresses, you have basically two reasonable >>> options: either don't specify any zPCI address and leave allocation >>> entirely up to libvirt, or specify all of the addresses completely: >>> anything in between will likely not work as you'd expect or want. >>> >>> Again, this is based purely on my recollection of design discussions >>> that happened one and a half years ago, so I might have gotten some >>> of the details wrong - in which case by all means call me out on >>> that O:-) >>> >> Hi Andrea, >> sorry for the delayed answer. I (and some others as well) lost some >> emails on my IMAP account and I just found your answer today. > > No apologies needed: I also took a long time to reply to your > message, and in my case there's no mail server malfunction that I > can assign the blame to O:-) > >> I can remember that you had a discussion with the original author of the >> zpci code. There are a few issues with the currently implemented "rules" >> which partially are not even working as you outlined above in more >> complex scenarios. > > I disagree with this assessment - they work exactly as designed and > as described above. Whether we *want* them to behave that way... Now > that's a different topic :) > > I think the disconnect lies in what the user's expectations are and > what libvirt actually implements. Basically the user expects that > > * if either one of uid and fid is explictly assigned a value by > the user, then the guest will use that value - unless such value > is invalid, in which case libvirt will report an error; > > * if either one of uid and fid is absent from the user-provided > configuration, then libvirt will automatically pick a valid value > for the attribute. > > This is not how the current zPCI implementation works, or how PCI > address assignment works in libvirt; on the other hand, I think these > expectations are in fact completely reasonable, as the examples you > provide illustrate quite well. > > I think you successfully convinced me that the current approach is > not good for users and we should fix it; my only doubt at this point > is whether can we safely do that without breaking libvirt's backwards > compatibility guarantees. > > Dan, Laine, what's your take? It sounds like the same semantics were applied to the zPCI address element as are applied to <address type='pci'> (if I understand correctly, while an PCI address is considered "valid and complete" if any of its attributes is non-0, for the zPCI extensions, each attribute is taken on its own. Is that correct? In any case, it sounds like current behavior for zPCI is broken for some use cases, and imo this is new enough and usage is narrow enough that if the maintainers (who I would guess represent the actual users) think fixing the bug is more important than 100% backward compatibility in a corner case, then they should be able to change it. Now if you wanted to change the way regular PCI address attributes are handled, *then* I would have a totally different opinion :-)
On 5/7/20 5:51 PM, Laine Stump wrote: > On 5/6/20 1:48 PM, Andrea Bolognani wrote: >> On Mon, 2020-04-20 at 21:55 +0200, Boris Fiuczynski wrote: >>> On 4/10/20 2:06 PM, Andrea Bolognani wrote: >>>> On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote: >>>>> The ZPCI address validation or autogeneration does not work as >>>>> expected in the following scenarios >>>>> 1. uid = 0 and fid = 0 >>>>> 2. uid = 0 and fid > 0 >>>>> 3. uid = 0 and fid not specified >>>>> 4. uid not specified and fid > 0 >>>>> 5. 2 ZPCI devices with uid > 0 and fid not specified. >>>>> >>>>> This is because of the following reasons >>>>> 1. If uid = 0 or fid = 0 the code assumes that user has not specified >>>>> the corresponding address >>>>> 2. If either uid or fid is provided, the code assumes that both uid >>>>> and fid addresses are specified by the user. >>>> >>>> I'd have to dig up the old threads, but based on what I remember the >>>> behaviors you describe are entirely intentional. >>>> >>>> For PCI addresses, setting all parts of the address to zero or not >>>> setting it at all is equivalent, and we wanted to be consistent with >>>> that behavior for ZPCI; additionally, zero is not a valid value for >>>> uid so of course neither is the address uid=0 fid=0, which means that >>>> we're not preventing the user from specifying a valid address by >>>> conflating the all-zero address with the unspecified address. >>>> >>>> For partially-specified addresses, the behavior is also the same as >>>> PCI: any part you don't specify is considered to be zero, which >>>> results in >>>> >>>> uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated >>>> uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid >>>> uid=0 -> uid=0 fid=0 -> address gets autogenerated >>>> fid=x -> uid=0 fid=x -> address is rejected as invalid >>>> uid=x -> uid=x fid=0 -> address is accepted >>>> >>>> So, just like for PCI addresses, you have basically two reasonable >>>> options: either don't specify any zPCI address and leave allocation >>>> entirely up to libvirt, or specify all of the addresses completely: >>>> anything in between will likely not work as you'd expect or want. >>>> >>>> Again, this is based purely on my recollection of design discussions >>>> that happened one and a half years ago, so I might have gotten some >>>> of the details wrong - in which case by all means call me out on >>>> that O:-) >>>> >>> Hi Andrea, >>> sorry for the delayed answer. I (and some others as well) lost some >>> emails on my IMAP account and I just found your answer today. >> >> No apologies needed: I also took a long time to reply to your >> message, and in my case there's no mail server malfunction that I >> can assign the blame to O:-) >> >>> I can remember that you had a discussion with the original author of the >>> zpci code. There are a few issues with the currently implemented "rules" >>> which partially are not even working as you outlined above in more >>> complex scenarios. >> >> I disagree with this assessment - they work exactly as designed and >> as described above. Whether we *want* them to behave that way... Now >> that's a different topic :) >> >> I think the disconnect lies in what the user's expectations are and >> what libvirt actually implements. Basically the user expects that >> >> * if either one of uid and fid is explictly assigned a value by >> the user, then the guest will use that value - unless such value >> is invalid, in which case libvirt will report an error; >> >> * if either one of uid and fid is absent from the user-provided >> configuration, then libvirt will automatically pick a valid value >> for the attribute. >> >> This is not how the current zPCI implementation works, or how PCI >> address assignment works in libvirt; on the other hand, I think these >> expectations are in fact completely reasonable, as the examples you >> provide illustrate quite well. >> >> I think you successfully convinced me that the current approach is >> not good for users and we should fix it; my only doubt at this point >> is whether can we safely do that without breaking libvirt's backwards >> compatibility guarantees. >> >> Dan, Laine, what's your take? > > It sounds like the same semantics were applied to the zPCI address > element as are applied to <address type='pci'> (if I understand > correctly, while an PCI address is considered "valid and complete" if > any of its attributes is non-0, for the zPCI extensions, each attribute > is taken on its own. Is that correct? Yes, that is correct. uid and fid can be set independently from each other within their ranges. uid (a hex value between 0x0001 and 0xffff, inclusive) fid (a hex value between 0x00000000 and 0xffffffff, inclusive) Both must be unique within a domain. > > In any case, it sounds like current behavior for zPCI is broken for some > use cases, and imo this is new enough and usage is narrow enough that if > the maintainers (who I would guess represent the actual users) think > fixing the bug is more important than 100% backward compatibility in a > corner case, then they should be able to change it. I would like to get this fixed such that the behavior is architecture compliant. The behavior change would be Current code: uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid uid=0 -> uid=0 fid=0 -> address gets autogenerated With the series applied uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid uid=0 -> uid=0 fid=0 -> address is rejected as invalid The documentation already specifies the uid value range correctly. The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is simple: Remove the zpci definition completely. My expectation is that most users not interested in defining the values never specified the two scenarios anyway. So I agree with you that it is an incompatible change in a corner case. > > Now if you wanted to change the way regular PCI address attributes are > handled, *then* I would have a totally different opinion :-) I am not asking for such change even so I have in the past asked about strange behavior when specifying a slot... :-) -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote: > On 5/7/20 5:51 PM, Laine Stump wrote: > > In any case, it sounds like current behavior for zPCI is broken for some > > use cases, and imo this is new enough and usage is narrow enough that if > > the maintainers (who I would guess represent the actual users) think > > fixing the bug is more important than 100% backward compatibility in a > > corner case, then they should be able to change it. > > I would like to get this fixed such that the behavior is architecture > compliant. > The behavior change would be > Current code: > uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > uid=0 -> uid=0 fid=0 -> address gets autogenerated IIUC, in the two cases here where the address gets auto-generated, the resulting guest VM successfully boots & runs.... > With the series applied > uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > uid=0 -> uid=0 fid=0 -> address is rejected as invalid ...so this proposed change is a functional regression for the user. > The documentation already specifies the uid value range correctly. > The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is > simple: Remove the zpci definition completely. This would be taking a users' currently working VM, intentionally breaking it, and then making the user pick up the pieces. This is an example of a behaviour regression that libvirt promises to not do to users. 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 :|
On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote: > On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote: > > The behavior change would be > > Current code: > > uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > uid=0 -> uid=0 fid=0 -> address gets autogenerated > > IIUC, in the two cases here where the address gets auto-generated, > the resulting guest VM successfully boots & runs.... > > > With the series applied > > uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > uid=0 -> uid=0 fid=0 -> address is rejected as invalid > > ...so this proposed change is a functional regression for the > user. > > > The documentation already specifies the uid value range correctly. > > The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is > > simple: Remove the zpci definition completely. > > This would be taking a users' currently working VM, intentionally > breaking it, and then making the user pick up the pieces. This is > an example of a behaviour regression that libvirt promises to not > do to users. The bit of nuance that might be missing here is that existing guests already have a full zPCI address stored in the domain XML, which means the wouldn't be affected in any way; additionally, the case where no zPCI address is provided when defining a new guest, which I assume is the most common one, will keep working. The only scenarios that would no longer work are: * the user manually specifies uid=0 fid=0; * the user manually specifies uid=0 and doesn't specify fid. In both cases the user would have gone out of their way to specify a value for the uid attribute that is documented as being invalid: PCI addresses for S390 guests will have a zpci child element, with two attributes: uid (a hex value between 0x0001 and 0xffff [...] https://libvirt.org/formatdomain.html#elementsAddress As a result, they'd now get a pretty clear error message at define time instead of confusing behavior across the board. I'm not really sure anyone would complain about such a change. -- Andrea Bolognani / Red Hat / Virtualization
On Wed, May 13, 2020 at 07:41:34PM +0200, Andrea Bolognani wrote: > On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote: > > On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote: > > > The behavior change would be > > > Current code: > > > uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated > > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > > uid=0 -> uid=0 fid=0 -> address gets autogenerated > > > > IIUC, in the two cases here where the address gets auto-generated, > > the resulting guest VM successfully boots & runs.... > > > > > With the series applied > > > uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid > > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > > uid=0 -> uid=0 fid=0 -> address is rejected as invalid > > > > ...so this proposed change is a functional regression for the > > user. > > > > > The documentation already specifies the uid value range correctly. > > > The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is > > > simple: Remove the zpci definition completely. > > > > This would be taking a users' currently working VM, intentionally > > breaking it, and then making the user pick up the pieces. This is > > an example of a behaviour regression that libvirt promises to not > > do to users. > > The bit of nuance that might be missing here is that existing guests > already have a full zPCI address stored in the domain XML, which > means the wouldn't be affected in any way; additionally, the case > where no zPCI address is provided when defining a new guest, which I > assume is the most common one, will keep working. > > The only scenarios that would no longer work are: > > * the user manually specifies uid=0 fid=0; > * the user manually specifies uid=0 and doesn't specify fid. > > In both cases the user would have gone out of their way to specify > a value for the uid attribute that is documented as being invalid: > > PCI addresses for S390 guests will have a zpci child element, with > two attributes: uid (a hex value between 0x0001 and 0xffff [...] > > https://libvirt.org/formatdomain.html#elementsAddress The effect of specifying zero though is that we perform allocation to assign a non-zero address, which is then valid. The same happens with regular PCI devices if you give slot="0". > As a result, they'd now get a pretty clear error message at define > time instead of confusing behavior across the board. I'm not really > sure anyone would complain about such a change. I don't see this existing behaviour as confusing. It looks like mostly being a docs ommission about auto-allocation taking place. 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 :|
On 5/14/20 10:37 AM, Daniel P. Berrangé wrote: > On Wed, May 13, 2020 at 07:41:34PM +0200, Andrea Bolognani wrote: >> On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote: >>> On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote: >>>> The behavior change would be >>>> Current code: >>>> uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated >>>> uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid >>>> uid=0 -> uid=0 fid=0 -> address gets autogenerated >>> >>> IIUC, in the two cases here where the address gets auto-generated, >>> the resulting guest VM successfully boots & runs.... >>> >>>> With the series applied >>>> uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid >>>> uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid >>>> uid=0 -> uid=0 fid=0 -> address is rejected as invalid >>> >>> ...so this proposed change is a functional regression for the >>> user. >>> >>>> The documentation already specifies the uid value range correctly. >>>> The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is >>>> simple: Remove the zpci definition completely. >>> >>> This would be taking a users' currently working VM, intentionally >>> breaking it, and then making the user pick up the pieces. This is >>> an example of a behaviour regression that libvirt promises to not >>> do to users. >> >> The bit of nuance that might be missing here is that existing guests >> already have a full zPCI address stored in the domain XML, which >> means the wouldn't be affected in any way; additionally, the case >> where no zPCI address is provided when defining a new guest, which I >> assume is the most common one, will keep working. >> >> The only scenarios that would no longer work are: >> >> * the user manually specifies uid=0 fid=0; >> * the user manually specifies uid=0 and doesn't specify fid. >> >> In both cases the user would have gone out of their way to specify >> a value for the uid attribute that is documented as being invalid: >> >> PCI addresses for S390 guests will have a zpci child element, with >> two attributes: uid (a hex value between 0x0001 and 0xffff [...] >> >> https://libvirt.org/formatdomain.html#elementsAddress > > The effect of specifying zero though is that we perform allocation > to assign a non-zero address, which is then valid. The same happens > with regular PCI devices if you give slot="0". > >> As a result, they'd now get a pretty clear error message at define >> time instead of confusing behavior across the board. I'm not really >> sure anyone would complain about such a change. > > I don't see this existing behaviour as confusing. It looks like mostly > being a docs ommission about auto-allocation taking place. Maybe I am repeating myself but I find e.g the below example confusing if I take into consideration that uid=0 is NOT a valid value and fid is a valid value. Please note that the valid fid is dislocated from its original device! Specify this in the domain: pcidev1: uid='0x0000' fid='0x00000000' pcidev2: uid='0x0000' Results in a defined domain: pcidev1: uid='0x0002' fid='0x00000001' pcidev2: uid='0x0001' fid='0x00000000' If the user would be tying to fix the dislocating fid... one would very likely try this: Specify this in the domain: pcidev1: uid='0x0000' fid='0x00000000' pcidev2: uid='0x0000' fid='0x00000001' Result: error: Failed to define domain from mini-pcis.xml error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000 and <= 0xffff Btw setting uid=0 is defined by architecture for a mode that we do not support in qemu AND setting fid=0 is an architectural valid assignment which in the example above is not granted to the device it was defined for. > > Regards, > Daniel > -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Thu, May 14, 2020 at 03:34:30PM +0200, Boris Fiuczynski wrote: > On 5/14/20 10:37 AM, Daniel P. Berrangé wrote: > > On Wed, May 13, 2020 at 07:41:34PM +0200, Andrea Bolognani wrote: > > > On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote: > > > > On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote: > > > > > The behavior change would be > > > > > Current code: > > > > > uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated > > > > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > > > > uid=0 -> uid=0 fid=0 -> address gets autogenerated > > > > > > > > IIUC, in the two cases here where the address gets auto-generated, > > > > the resulting guest VM successfully boots & runs.... > > > > > > > > > With the series applied > > > > > uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid > > > > > uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid > > > > > uid=0 -> uid=0 fid=0 -> address is rejected as invalid > > > > > > > > ...so this proposed change is a functional regression for the > > > > user. > > > > > > > > > The documentation already specifies the uid value range correctly. > > > > > The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is > > > > > simple: Remove the zpci definition completely. > > > > > > > > This would be taking a users' currently working VM, intentionally > > > > breaking it, and then making the user pick up the pieces. This is > > > > an example of a behaviour regression that libvirt promises to not > > > > do to users. > > > > > > The bit of nuance that might be missing here is that existing guests > > > already have a full zPCI address stored in the domain XML, which > > > means the wouldn't be affected in any way; additionally, the case > > > where no zPCI address is provided when defining a new guest, which I > > > assume is the most common one, will keep working. > > > > > > The only scenarios that would no longer work are: > > > > > > * the user manually specifies uid=0 fid=0; > > > * the user manually specifies uid=0 and doesn't specify fid. > > > > > > In both cases the user would have gone out of their way to specify > > > a value for the uid attribute that is documented as being invalid: > > > > > > PCI addresses for S390 guests will have a zpci child element, with > > > two attributes: uid (a hex value between 0x0001 and 0xffff [...] > > > > > > https://libvirt.org/formatdomain.html#elementsAddress > > > > The effect of specifying zero though is that we perform allocation > > to assign a non-zero address, which is then valid. The same happens > > with regular PCI devices if you give slot="0". > > > > > As a result, they'd now get a pretty clear error message at define > > > time instead of confusing behavior across the board. I'm not really > > > sure anyone would complain about such a change. > > > > I don't see this existing behaviour as confusing. It looks like mostly > > being a docs ommission about auto-allocation taking place. > > Maybe I am repeating myself but I find e.g the below example confusing if I > take into consideration that uid=0 is NOT a valid value and fid is a valid > value. Please note that the valid fid is dislocated from its original > device! > > Specify this in the domain: > pcidev1: uid='0x0000' fid='0x00000000' > pcidev2: uid='0x0000' > Results in a defined domain: > pcidev1: uid='0x0002' fid='0x00000001' > pcidev2: uid='0x0001' fid='0x00000000' > > If the user would be tying to fix the dislocating fid... one would very > likely try this: > Specify this in the domain: > pcidev1: uid='0x0000' fid='0x00000000' > pcidev2: uid='0x0000' fid='0x00000001' > Result: > error: Failed to define domain from mini-pcis.xml > error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000 and <= > 0xffff > > Btw setting uid=0 is defined by architecture for a mode that we do not > support in qemu AND setting fid=0 is an architectural valid assignment which > in the example above is not granted to the device it was defined for. Ok, that's the bit I didn't understand. I was assuming 0 was not a valid number, but it is valid for a feature we don't currently use. Thus we should be reporting usage as an error, such that we can implement correct semantics at a later date if desired. 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 :|
On Thu, 2020-05-14 at 15:34 +0200, Boris Fiuczynski wrote: > On 5/14/20 10:37 AM, Daniel P. Berrangé wrote: > > I don't see this existing behaviour as confusing. It looks like mostly > > being a docs ommission about auto-allocation taking place. > > Maybe I am repeating myself but I find e.g the below example confusing > if I take into consideration that uid=0 is NOT a valid value and fid is > a valid value. Please note that the valid fid is dislocated from its > original device! > > Specify this in the domain: > pcidev1: uid='0x0000' fid='0x00000000' > pcidev2: uid='0x0000' > Results in a defined domain: > pcidev1: uid='0x0002' fid='0x00000001' > pcidev2: uid='0x0001' fid='0x00000000' > > If the user would be tying to fix the dislocating fid... one would very > likely try this: > Specify this in the domain: > pcidev1: uid='0x0000' fid='0x00000000' > pcidev2: uid='0x0000' fid='0x00000001' > Result: > error: Failed to define domain from mini-pcis.xml > error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000 and > <= 0xffff And partial assignments, which one might reasonably expect to work, actually don't: fid=0 -> interpreted the same as no information provided -> valid address but probably not fid=0 fid=x -> interpreted as uid=0 fid=x -> invalid address because uid=0 is invalid Plus, if you have two devices: uid=1, uid=2 -> interpreted as uid=1 fid=0, uid=2 fid=0 -> invalid addresses because of duplicated fid Dan, please go through the entire thread and look at the other examples that Shalini, Boris and I have provided: I think you'll see why I feel like it's hard to argue that the current behavior can be considered reasonable from the user's point of view. -- Andrea Bolognani / Red Hat / Virtualization
On 5/14/20 3:59 PM, Andrea Bolognani wrote: > On Thu, 2020-05-14 at 15:34 +0200, Boris Fiuczynski wrote: >> On 5/14/20 10:37 AM, Daniel P. Berrangé wrote: >>> I don't see this existing behaviour as confusing. It looks like mostly >>> being a docs ommission about auto-allocation taking place. >> >> Maybe I am repeating myself but I find e.g the below example confusing >> if I take into consideration that uid=0 is NOT a valid value and fid is >> a valid value. Please note that the valid fid is dislocated from its >> original device! >> >> Specify this in the domain: >> pcidev1: uid='0x0000' fid='0x00000000' >> pcidev2: uid='0x0000' >> Results in a defined domain: >> pcidev1: uid='0x0002' fid='0x00000001' >> pcidev2: uid='0x0001' fid='0x00000000' >> >> If the user would be tying to fix the dislocating fid... one would very >> likely try this: >> Specify this in the domain: >> pcidev1: uid='0x0000' fid='0x00000000' >> pcidev2: uid='0x0000' fid='0x00000001' >> Result: >> error: Failed to define domain from mini-pcis.xml >> error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000 and >> <= 0xffff > > And partial assignments, which one might reasonably expect to work, > actually don't: > > fid=0 -> interpreted the same as no information provided > -> valid address but probably not fid=0 > > fid=x -> interpreted as uid=0 fid=x > -> invalid address because uid=0 is invalid > > Plus, if you have two devices: > > uid=1, uid=2 -> interpreted as uid=1 fid=0, uid=2 fid=0 > -> invalid addresses because of duplicated fid > > Dan, please go through the entire thread and look at the other > examples that Shalini, Boris and I have provided: I think you'll > see why I feel like it's hard to argue that the current behavior can > be considered reasonable from the user's point of view. > If I do not misinterpret Dan's last mail he agrees that specifying uid=0 should be considered as error. How do we proceed from here? Shalini series still can be applied on master cleanly. Do you want her to resend the series anyway? -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Wed, 2020-05-20 at 13:32 +0200, Boris Fiuczynski wrote: > If I do not misinterpret Dan's last mail he agrees that specifying uid=0 > should be considered as error. > How do we proceed from here? Shalini series still can be applied on > master cleanly. Do you want her to resend the series anyway? I checked again and it still applies cleanly, so no need to resend. And Dan seemed to be fine with the changes after all, so I'm going to go ahead and review them this week. -- Andrea Bolognani / Red Hat / Virtualization
On 6/1/20 6:49 PM, Andrea Bolognani wrote: > On Wed, 2020-05-20 at 13:32 +0200, Boris Fiuczynski wrote: >> If I do not misinterpret Dan's last mail he agrees that specifying uid=0 >> should be considered as error. >> How do we proceed from here? Shalini series still can be applied on >> master cleanly. Do you want her to resend the series anyway? > I checked again and it still applies cleanly, so no need to resend. > And Dan seemed to be fine with the changes after all, so I'm going > to go ahead and review them this week. ok, thank you. >
© 2016 - 2024 Red Hat, Inc.