Re: [PATCH v2 2/3] vfio-pci/zdev: Add VFIO FMB device feature
From: Omar Elghoul
Date: Wed Jun 03 2026 - 14:31:59 EST
On 6/3/26 11:55 AM, Alex Williamson wrote:
On Wed, 3 Jun 2026 08:35:43 -0400
Omar Elghoul <oelghoul@xxxxxxxxxxxxx> wrote:
On 6/2/26 6:24 PM, Alex Williamson wrote:
We want the user (e.g. QEMU) to be able to control these so that when a
Why does the user need to be able to control these?
guest enables or disables the FMB, this state gets cascaded to the host and
all the way to the firmware.
Yes it does, but this one isn't an oversight and is intentional behavior
Doesn't allowing the user to disable FMB remove guaranteed host-based
monitoring?
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.
[...]
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.
If we did this and passed just flags, a user ptr, and possibly a buffer
length field, what would you think of leaving them in one feature? This
way, the SET case would have possibly 8 or 16 bytes of overhead rather
than the entire FMB structs, but would still keep the uAPI simple enough
by avoiding multiple VFIO features for the same firmware feature.
Thanks.
(Apologies for the resend - the previous email was rejected for being sent in HTML format.)
Thanks,
Alex