This patch series creates and registers a handler that is called when
userspace is notified by the kernel that a guest's AP configuration has
changed. The handler in turn notifies the guest that its AP configuration
has changed. This allows the guest to immediately respond to AP
configuration changes rather than relying on polling or some other
inefficient mechanism for detecting config changes.

Rorie Reyes (5):
  linux-headers: NOTFORMERGE - placeholder uapi updates for AP config
    change
  hw/vfio/ap: notification handler for AP config changed event
  hw/vfio/ap: store object indicating AP config changed in a queue
  hw/vfio/ap: Storing event information for an AP configuration change
    event
  s390: implementing CHSC SEI for AP config change

 hw/vfio/ap.c                 | 74 ++++++++++++++++++++++++++++++++++++
 include/hw/s390x/ap-bridge.h | 17 +++++++++
 linux-headers/linux/vfio.h   |  1 +
 target/s390x/ioinst.c        | 11 +++++-
 4 files changed, 101 insertions(+), 2 deletions(-)

-- 
2.39.5 (Apple Git-154)

On Tue,  7 Jan 2025 13:43:49 -0500
Rorie Reyes <rreyes@linux.ibm.com> wrote:

> This patch series creates and registers a handler that is called when
> userspace is notified by the kernel that a guest's AP configuration has
> changed. The handler in turn notifies the guest that its AP configuration
> has changed. This allows the guest to immediately respond to AP
> configuration changes rather than relying on polling or some other
> inefficient mechanism for detecting config changes.

Why are configuration changes to the device allowed while the device is
in use?

Would a uevent be considered an inefficient mechanism?  Why?

Thanks,
Alex

On 1/7/25 2:06 PM, Alex Williamson wrote:
> On Tue,  7 Jan 2025 13:43:49 -0500
> Rorie Reyes <rreyes@linux.ibm.com> wrote:
>
>> This patch series creates and registers a handler that is called when
>> userspace is notified by the kernel that a guest's AP configuration has
>> changed. The handler in turn notifies the guest that its AP configuration
>> has changed. This allows the guest to immediately respond to AP
>> configuration changes rather than relying on polling or some other
>> inefficient mechanism for detecting config changes.
> Why are configuration changes to the device allowed while the device is
> in use?
>
> Would a uevent be considered an inefficient mechanism?  Why?
>
> Thanks,
> Alex
>
Hey Alex,

Sorry for the long delay, but to answer your question, the VFIO device 
is typically used to pass through a single I/O

device, like a VGPU or PCI device. VFIO allows direct access to the 
memory of the underlying device to perofrm the I/O.

Our VFIO device does not follow that model and it represents a guest's 
AP configuration, not an individual AP device. Granting

guest access to AP devices in the configuration is controlled outside of 
the VFIO. The purpose of the mdev is to provide

a means for specifying the AP configuration for the guest. When the mdev 
is attached to the guest, the vfio_ap device driver

set the AP configuration assigned to the mdev into the control blocks 
used to start the guest.

On 1/7/25 2:06 PM, Alex Williamson wrote:

> Why are configuration changes to the device allowed while the device is
> in use?
>
> Would a uevent be considered an inefficient mechanism?  Why?
>
> Thanks,
> Alex

I believe a vfio device is typically used to pass through a single I/O 
device, like a VGPU or PCI device. VFIO allows direct access to the 
memory of the underlying device to perform the I/O. Our vfio device does 
not follow that model. It represents a guest's AP configuration, not 
individual AP devices. Granting guest access to the AP devices in the 
configuration is controlled outside of VFIO. The purpose of the mediated 
device is to provide a means for specifying the AP configuration for the 
guest. When the mediated device is attached to the guest, the vfio_ap 
device driver sets the AP configuration assigned to the mdev into the 
control blocks used to start the guest.

We could use the sysfs attributes of the mediated device to do hot 
plug/unplug of devices for the guest. The vfio_ap host device driver 
would perform the hot plug/unplug via an IBM Z mechanism. It was left up 
to the AP bus driver running in the guest to detect these changes via a 
polling mechanism. My patches allow us to notify the AP bus driver 
immediately - via an eventfd to userspace - of those changes which is 
far more efficient than relying on a polling mechanism.