linux-kernel - Re: [PATCH v1] s390/vfio-ap: Signal eventfd when guest AP configuration is changed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <99bc2df0-ffd2-4aaa-b658-de5ac3a77b40@linux.ibm.com>
Date: Fri, 17 Jan 2025 07:42:04 -0500
From: Anthony Krowiak <akrowiak@...ux.ibm.com>
To: freude@...ux.ibm.com
Cc: Rorie Reyes <rreyes@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org, hca@...ux.ibm.com,
        borntraeger@...ibm.com, agordeev@...ux.ibm.com, gor@...ux.ibm.com,
        pasic@...ux.ibm.com, jjherne@...ux.ibm.com, alex.williamson@...hat.com
Subject: Re: [PATCH v1] s390/vfio-ap: Signal eventfd when guest AP
 configuration is changed




On 1/17/25 3:30 AM, Harald Freudenberger wrote:
> On 2025-01-16 17:46, Anthony Krowiak wrote:
>>>
>>> Rorie, this is to inform listeners on the host of the guest.
>>> The guest itself already sees this "inside" with uevents triggered
>>> by the AP bus code.
>>>
>>> Do you have a consumer for these events?
>>
>> There is a series of QEMU patches that register a notification 
>> handler for this
>> event. When that handler gets called, it generates and queues a CRW 
>> to the guest
>> indicating there is event information pending which will cause the AP 
>> bus driver
>> to get notified of the AP configuration change via its ap_bus_cfg_chg
>> notifier call.
>>
>> The QEMU series can be seen at:
>> https://lore.kernel.org/qemu-devel/7171c479-5cb4-4748-ba37-da4cf2fac35b@linux.ibm.com/T/ 
>>
>>
>>
>> Kind regards,
>> A Krowiak
>
> Ok, so this way the AP bus of the guest finally get's it's config 
> change callback invoked :-)

Yes, and it happens pretty quickly; at least in the test environment.