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

[Omar Elghoul <oelghoul@linux.ibm.com>]

On 6/3/26 11:55 AM, Alex Williamson wrote:
> On Wed, 3 Jun 2026 08:35:43 -0400
> Omar Elghoul <oelghoul@linux.ibm.com> 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.
> 
> [...]
> 
> 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