Re: [PATCH v2 2/3] vfio-pci/zdev: Add VFIO FMB device feature

[Alex Williamson]

On Wed, 3 Jun 2026 08:35:43 -0400
Omar Elghoul <oelghoul@xxxxxxxxxxxxx> wrote:

> On 6/2/26 6:24 PM, Alex Williamson wrote:
> >
> > Why does the user need to be able to control these?  
> We want the user (e.g. QEMU) to be able to control these so that when a
> guest enables or disables the FMB, this state gets cascaded to the host and
> all the way to the firmware.
> >
> > Doesn't allowing the user to disable FMB remove guaranteed host-based
> > monitoring?  
> Yes it does, but this one isn't an oversight and is intentional behavior
> to achieve the functionality mentioned above. The host-based monitoring is
> not necessarily guaranteed and is treated as a device-specific state, so it
> makes sense in the case of passthrough to have that state reflect the state
> of the guest that is actually using the device.

If we really need a SET for enable/disable, I think it should be a
separate feature.  It really makes no sense to pass a giant structure
into a SET operation to look at the state of one flag bit.

> > Since this is already provided via debugfs, why not make this a
> > userspace problem to interact with the existing interface?  
> It might be possible but it would undoubtedly be really ugly and harder to
> maintain. I think what we'd dislike most about using debugfs is parsing
> text data into the FMB structure. If any of the text representations of the
> fields were to change, we would need to update them anywhere that uses them
> (e.g., in QEMU or any other user driver). The ABI would be super fragile.
> >
> > Alternatively, couldn't the existing zpci mediation be extended to
> > support the guest registering a fmb buffer to be written at regular
> > intervals (the interface here seems to drop the reporting interval).  
> The firmware only writes the FMB into one buffer every firmware-specified
> interval. If we wanted to write the FMB directly into guest memory, we
> would either 1) lose host access to the FMB or 2) have to run a periodic
> worker in the kernel to copy the host FMB into the guest-provided buffer
> every time the firmware does an update. I don't believe either of these
> approaches are favorable.
> 
> WRT reporting interval, I intentionally dropped that one as it is already
> provided by VFIO_DEVICE_INFO_CAP_ZPCI_GROUP.

Hmm, I also see fmb_length in VFIO_DEVICE_INFO_CAP_ZPCI_BASE.  If we
have that, do we really need structured data in the GET feature?  Maybe
GET just provides a user pointer and the raw fmb data is copied to it.
Thanks,

Alex