> -----Original Message----- > From: Qemu-devel <qemu-devel- > bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan > Raman > Sent: Tuesday, August 2, 2022 9:24 AM > To: qemu-devel@nongnu.org > Cc: stefanha@gmail.com; berrange@redhat.com > Subject: [PATCH 0/1] Update vfio-user module to the latest > > Hi, > > This patch updates the libvfio-user submodule to the latest. Just a rough idea, why not depends on linux distribution for the libvfio-user.so? It looks no libvfio-user packet in distribution's repo. Hi Thomas/Daniel: For the RFC QEMU user space eBPF support, https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? Thanks Chen > > Passed 'make check' & GitLab CI. > > Thank you! > -- > Jag > > Jagannathan Raman (1): > vfio-user: update submodule to latest > > subprojects/libvfio-user | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- > 2.20.1 >
On 02/08/2022 12.00, Zhang, Chen wrote: > > >> -----Original Message----- >> From: Qemu-devel <qemu-devel- >> bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan >> Raman >> Sent: Tuesday, August 2, 2022 9:24 AM >> To: qemu-devel@nongnu.org >> Cc: stefanha@gmail.com; berrange@redhat.com >> Subject: [PATCH 0/1] Update vfio-user module to the latest >> >> Hi, >> >> This patch updates the libvfio-user submodule to the latest. > > Just a rough idea, why not depends on linux distribution for the libvfio-user.so? > It looks no libvfio-user packet in distribution's repo. > > Hi Thomas/Daniel: > > For the RFC QEMU user space eBPF support, > https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? Fair comment. I never noticed them before, but why do we have those submodules in the subprojects/ folder (libvduse, libvfio-user and libvhost-user)? ... I don't think it's the job of QEMU to ship libraries that a user might want to use for a certain feature, so could we please remove those submodules again? If someone wants to use this, they can compile the libraries on their own or help their favorite distribution to ship them as packages. Thomas
On Fri, Aug 05, 2022 at 09:21:07AM +0200, Thomas Huth wrote: > On 02/08/2022 12.00, Zhang, Chen wrote: > > > > > > > -----Original Message----- > > > From: Qemu-devel <qemu-devel- > > > bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan > > > Raman > > > Sent: Tuesday, August 2, 2022 9:24 AM > > > To: qemu-devel@nongnu.org > > > Cc: stefanha@gmail.com; berrange@redhat.com > > > Subject: [PATCH 0/1] Update vfio-user module to the latest > > > > > > Hi, > > > > > > This patch updates the libvfio-user submodule to the latest. > > > > Just a rough idea, why not depends on linux distribution for the libvfio-user.so? > > It looks no libvfio-user packet in distribution's repo. > > > > Hi Thomas/Daniel: > > > > For the RFC QEMU user space eBPF support, > > https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ > > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? > > Fair comment. I never noticed them before, but why do we have those > submodules in the subprojects/ folder (libvduse, libvfio-user and > libvhost-user)? I don't think they are submodules are they? > ... I don't think it's the job of QEMU to ship libraries > that a user might want to use for a certain feature, so could we please > remove those submodules again? Why not? Fundamentally I don't see why would libvhost-user be less important to users than e.g. qemu-img or qemu-bridge-helper. There's no rule saying we can only ship a single binary. > If someone wants to use this, they can > compile the libraries on their own or help their favorite distribution to > ship them as packages. > > Thomas I can speak for libvhost-user at least, the main reason is simple - QEMU uses it - to be more precise, QEMU tests use it ATM, but there are also ideas to implement the device side of virtio inside a VM and that will use it more directly. Same developers are working on both qemu and libvhost-user parts. So I don't think there is much interest in first splitting it out then jumping through hoops to get it back. But there are more reasons - for example, if an application links against libvhost-user, then it's a good idea to update libvhost-user and qemu together - they have been tested together and are known to work well. I suspect the same applies to other probjects in this area but I'm not sure. -- MST
On 05/08/2022 10.55, Michael S. Tsirkin wrote: > On Fri, Aug 05, 2022 at 09:21:07AM +0200, Thomas Huth wrote: >> On 02/08/2022 12.00, Zhang, Chen wrote: >>> >>> >>>> -----Original Message----- >>>> From: Qemu-devel <qemu-devel- >>>> bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan >>>> Raman >>>> Sent: Tuesday, August 2, 2022 9:24 AM >>>> To: qemu-devel@nongnu.org >>>> Cc: stefanha@gmail.com; berrange@redhat.com >>>> Subject: [PATCH 0/1] Update vfio-user module to the latest >>>> >>>> Hi, >>>> >>>> This patch updates the libvfio-user submodule to the latest. >>> >>> Just a rough idea, why not depends on linux distribution for the libvfio-user.so? >>> It looks no libvfio-user packet in distribution's repo. >>> >>> Hi Thomas/Daniel: >>> >>> For the RFC QEMU user space eBPF support, >>> https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ >>> Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? >> >> Fair comment. I never noticed them before, but why do we have those >> submodules in the subprojects/ folder (libvduse, libvfio-user and >> libvhost-user)? > > I don't think they are submodules are they? Drat, my bad! It's only libvfio-user that is a submodule. Never mind the other two. >> ... I don't think it's the job of QEMU to ship libraries >> that a user might want to use for a certain feature, so could we please >> remove those submodules again? > > Why not? Fundamentally I don't see why would libvhost-user be less > important to users than e.g. qemu-img or qemu-bridge-helper. There's no > rule saying we can only ship a single binary. If libvhost-user does not have another home, then it's fine to have it here, I guess, but libvfio-user should rather be packaged as a proper library by the distros instead if it has a different upstream home. Thomas
On Fri, Aug 05, 2022 at 09:21:07AM +0200, Thomas Huth wrote: > On 02/08/2022 12.00, Zhang, Chen wrote: > > > > > > > -----Original Message----- > > > From: Qemu-devel <qemu-devel- > > > bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan > > > Raman > > > Sent: Tuesday, August 2, 2022 9:24 AM > > > To: qemu-devel@nongnu.org > > > Cc: stefanha@gmail.com; berrange@redhat.com > > > Subject: [PATCH 0/1] Update vfio-user module to the latest > > > > > > Hi, > > > > > > This patch updates the libvfio-user submodule to the latest. > > > > Just a rough idea, why not depends on linux distribution for the libvfio-user.so? > > It looks no libvfio-user packet in distribution's repo. > > > > Hi Thomas/Daniel: > > > > For the RFC QEMU user space eBPF support, > > https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ > > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? > > Fair comment. I never noticed them before, but why do we have those > submodules in the subprojects/ folder (libvduse, libvfio-user and > libvhost-user)? ... I don't think it's the job of QEMU to ship libraries > that a user might want to use for a certain feature, so could we please > remove those submodules again? If someone wants to use this, they can > compile the libraries on their own or help their favorite distribution to > ship them as packages. FWIW, I don't really agree with shipping libvfio-user.so as a submodule either, but the consensus was that we have to do it because there's no stable ABI committed to by libvfio-user maintainers yet. My counterpoint is that as long as QEMU ships libvfio-user as a submodule, there's no incentive to create a stable ABI, leaving a chicken & egg scenario. IOW personally I'd rather libvfio-user.so was put into the distros right now, and have the pain ABI incompatible releases act as motivation for the creation of a stable ABI. A second factor is that as long as it is a submodule, there is little pressure for the distros to actually package the library, which leaves us in a place where someone will always object to removing the submodule from QEMU because it doesn't exist in distro X. So again my preference is to not add any library as a submodule. Lets the distros handle dependancies like they always have. If we do add something as a submodule for some reason, I'd like us to say upfront that this is for a fixed time period (ie maximum of 3 releases aka 1 year) only after which we'll remove it no matter what. We are where we are with libvfio-user.so, and I don't think that is something to be used as justification for adding more libraries as submodules. Rather we should set a timeframe to remove libvfio-user submodule to put distros on notice. With 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 Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: > > > For the RFC QEMU user space eBPF support, > > > https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ > > > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? > > > > Fair comment. I never noticed them before, but why do we have those > > submodules in the subprojects/ folder (libvduse, libvfio-user and > > libvhost-user)? ... I don't think it's the job of QEMU to ship libraries > > that a user might want to use for a certain feature, so could we please > > remove those submodules again? If someone wants to use this, they can > > compile the libraries on their own or help their favorite distribution to > > ship them as packages. > > FWIW, I don't really agree with shipping libvfio-user.so as a submodule > either, but the consensus was that we have to do it because there's no > stable ABI committed to by libvfio-user maintainers yet. My counterpoint > is that as long as QEMU ships libvfio-user as a submodule, there's no > incentive to create a stable ABI, leaving a chicken & egg scenario. qemu is not the only consumer of the library, so I'm not sure removing the submodule from qemu moves the needle in either direction. We are still discovering our abstractions are not quite right in places, so we're not yet confident enough to mark the API/ABI as stable (nor do we have any testing of this in place). It would be all downside at this point. > IOW personally I'd rather libvfio-user.so was put into the distros right > now, and have the pain ABI incompatible releases act as motivation for > the creation of a stable ABI. We can't control what the distributions choose to do, but speaking for libvfio-user, we would not support this choice or anything like it. It would only cause pain for users. > A second factor is that as long as it is a submodule, there is little > pressure for the distros to actually package the library, which leaves > us in a place where someone will always object to removing the submodule > from QEMU because it doesn't exist in distro X. No distribution has even *asked* us about this. Do you have some evidence that by making this more difficult, somehow we'll start hearing from all the distros? What's the mechanism by which this will work? It seems to me that all that will happen by removing it, is make it extremely annoying for anyone wanting to use it with qemu, as every user will have to figure out which commit is needed for the qemu commit they're trying to compile. > If we do add something as a submodule for some reason, I'd like us to > say upfront that this is for a fixed time period (ie maximum of 3 > releases aka 1 year) only after which we'll remove it no matter what. I'm not clear on the costs of having the submodule: could you please explain why it's an issue exactly? I can only think of the flaky test issue (for which I'm sorry). regards john
On 07/08/2022 12.39, John Levon wrote: > On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: [...] >> If we do add something as a submodule for some reason, I'd like us to >> say upfront that this is for a fixed time period (ie maximum of 3 >> releases aka 1 year) only after which we'll remove it no matter what. > > I'm not clear on the costs of having the submodule: could you please explain why > it's an issue exactly? Some reasoning can be found here: https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/ > I can only think of the flaky test issue (for which I'm > sorry). Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this? Thomas
> On Aug 29, 2022, at 8:40 AM, Thomas Huth <thuth@redhat.com> wrote: > > On 07/08/2022 12.39, John Levon wrote: >> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: > [...] >>> If we do add something as a submodule for some reason, I'd like us to >>> say upfront that this is for a fixed time period (ie maximum of 3 >>> releases aka 1 year) only after which we'll remove it no matter what. >> I'm not clear on the costs of having the submodule: could you please explain why >> it's an issue exactly? > > Some reasoning can be found here: > > https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/ > >> I can only think of the flaky test issue (for which I'm >> sorry). > > Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this? Now that QEMU 7.1 has released, could we please pull this patch in - just so no one else has a bad experience when testing? -- Jag > > Thomas >
On 29/09/2022 03.52, Jag Raman wrote: > > >> On Aug 29, 2022, at 8:40 AM, Thomas Huth <thuth@redhat.com> wrote: >> >> On 07/08/2022 12.39, John Levon wrote: >>> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: >> [...] >>>> If we do add something as a submodule for some reason, I'd like us to >>>> say upfront that this is for a fixed time period (ie maximum of 3 >>>> releases aka 1 year) only after which we'll remove it no matter what. >>> I'm not clear on the costs of having the submodule: could you please explain why >>> it's an issue exactly? >> >> Some reasoning can be found here: >> >> https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/ >> >>> I can only think of the flaky test issue (for which I'm >>> sorry). >> >> Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this? > > Now that QEMU 7.1 has released, could we please pull this patch in - just so no one else has a bad experience when testing? You are listed as maintainer for subprojects/libvfio-user in the MAINTAINERS file, so I guess you should just go ahead and send a pull request for this? Thomas
> On Sep 29, 2022, at 2:27 AM, Thomas Huth <thuth@redhat.com> wrote: > > On 29/09/2022 03.52, Jag Raman wrote: >>> On Aug 29, 2022, at 8:40 AM, Thomas Huth <thuth@redhat.com> wrote: >>> >>> On 07/08/2022 12.39, John Levon wrote: >>>> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: >>> [...] >>>>> If we do add something as a submodule for some reason, I'd like us to >>>>> say upfront that this is for a fixed time period (ie maximum of 3 >>>>> releases aka 1 year) only after which we'll remove it no matter what. >>>> I'm not clear on the costs of having the submodule: could you please explain why >>>> it's an issue exactly? >>> >>> Some reasoning can be found here: >>> >>> https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/ >>> >>>> I can only think of the flaky test issue (for which I'm >>>> sorry). >>> >>> Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this? >> Now that QEMU 7.1 has released, could we please pull this patch in - just so no one else has a bad experience when testing? > > You are listed as maintainer for subprojects/libvfio-user in the MAINTAINERS file, so I guess you should just go ahead and send a pull request for this? OK, will do. Thank you! -- Jag > > Thomas >
On Aug 7, 2022, at 6:39 AM, John Levon <levon@movementarian.org<mailto:levon@movementarian.org>> wrote: On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: For the RFC QEMU user space eBPF support, https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? Fair comment. I never noticed them before, but why do we have those submodules in the subprojects/ folder (libvduse, libvfio-user and libvhost-user)? ... I don't think it's the job of QEMU to ship libraries that a user might want to use for a certain feature, so could we please remove those submodules again? If someone wants to use this, they can compile the libraries on their own or help their favorite distribution to ship them as packages. FWIW, I don't really agree with shipping libvfio-user.so as a submodule either, but the consensus was that we have to do it because there's no stable ABI committed to by libvfio-user maintainers yet. My counterpoint is that as long as QEMU ships libvfio-user as a submodule, there's no incentive to create a stable ABI, leaving a chicken & egg scenario. qemu is not the only consumer of the library, so I'm not sure removing the submodule from qemu moves the needle in either direction. We are still discovering our abstractions are not quite right in places, so we're not yet confident enough to mark the API/ABI as stable (nor do we have any testing of this in place). It would be all downside at this point. IOW personally I'd rather libvfio-user.so was put into the distros right now, and have the pain ABI incompatible releases act as motivation for the creation of a stable ABI. We can't control what the distributions choose to do, but speaking for libvfio-user, we would not support this choice or anything like it. It would only cause pain for users. Hi, I think we need to move forward on this item as the libvfio0user test hang is affecting some folks. Looks like libvfio-user wouldn’t ship via distros anytime soon. I’m wondering if we could consider alternatives to the distro approach? Would a standalone package be OK until libvfio-user ships as a distro? I could help with this - I’m familiar with building RPMs. A second factor is that as long as it is a submodule, there is little pressure for the distros to actually package the library, which leaves us in a place where someone will always object to removing the submodule from QEMU because it doesn't exist in distro X. No distribution has even *asked* us about this. Do you have some evidence that by making this more difficult, somehow we'll start hearing from all the distros? What's the mechanism by which this will work? It seems to me that all that will happen by removing it, is make it extremely annoying for anyone wanting to use it with qemu, as every user will have to figure out which commit is needed for the qemu commit they're trying to compile. This of course doesn’t address usability issue that John pointed out above. -- Jag If we do add something as a submodule for some reason, I'd like us to say upfront that this is for a fixed time period (ie maximum of 3 releases aka 1 year) only after which we'll remove it no matter what. I'm not clear on the costs of having the submodule: could you please explain why it's an issue exactly? I can only think of the flaky test issue (for which I'm sorry). regards john
On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote: > On Fri, Aug 05, 2022 at 09:21:07AM +0200, Thomas Huth wrote: > > On 02/08/2022 12.00, Zhang, Chen wrote: > > > > > > > > > > -----Original Message----- > > > > From: Qemu-devel <qemu-devel- > > > > bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan > > > > Raman > > > > Sent: Tuesday, August 2, 2022 9:24 AM > > > > To: qemu-devel@nongnu.org > > > > Cc: stefanha@gmail.com; berrange@redhat.com > > > > Subject: [PATCH 0/1] Update vfio-user module to the latest > > > > > > > > Hi, > > > > > > > > This patch updates the libvfio-user submodule to the latest. > > > > > > Just a rough idea, why not depends on linux distribution for the libvfio-user.so? > > > It looks no libvfio-user packet in distribution's repo. > > > > > > Hi Thomas/Daniel: > > > > > > For the RFC QEMU user space eBPF support, > > > https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/ > > > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is more appropriate? > > > > Fair comment. I never noticed them before, but why do we have those > > submodules in the subprojects/ folder (libvduse, libvfio-user and > > libvhost-user)? ... I don't think it's the job of QEMU to ship libraries > > that a user might want to use for a certain feature, so could we please > > remove those submodules again? If someone wants to use this, they can > > compile the libraries on their own or help their favorite distribution to > > ship them as packages. > > FWIW, I don't really agree with shipping libvfio-user.so as a submodule > either, but the consensus was that we have to do it because there's no > stable ABI committed to by libvfio-user maintainers yet. My counterpoint > is that as long as QEMU ships libvfio-user as a submodule, there's no > incentive to create a stable ABI, leaving a chicken & egg scenario. It's weird that the parent lumps libvfio-user which is a submodule with libvduse and libvhost-user which are not. I don't know whether moving libvfio-user to avoid confusion is justified. -- MST
© 2016 - 2024 Red Hat, Inc.