I may be all wrong, though... can we at least have a translation of
ECA.28 and EECA.28 (the "ap is there" bit and the "ap instructions are
interpreted" bit?)
I think we have a misunderstanding here. I will wait for Tony. Maybe
he can understand this better or explain in more accessible way.
From what I get from your explanation, this approach sounds like a good
way forward. But let's wait for Tony.
I agree, this solves the problem with specifying installing AP facilities
on the guest (-cpu xxx,ap=on) and not configuring a vfio-ap device
(-device vfio-ap,sysfsdev=$path-to-mediated-device).
To recap:
The realize() function for the vfio-ap device opens the mediated matrix
device file descriptor to set up the communication pathway with the vfio_ap
kernel driver. When the fd is opened, the vfio_ap driver sets ECA.28 for the
guest to instruct SIE to interpret AP instructions. The driver also
configures the AP matrix for the guest in its SIE state description.
Consequently,
if a vfio-ap device is not configured for the guest, but AP facilities are
installed, all AP instructions will be intercepted and routed to QEMU. If there
are no interception handlers for the AP instructions, QEMU injects an operation
exception into the guest. This results in initialization of the AP bus on the
guest to terminate. This patch was intended to circumvent that problem.
With Halil's suggestion, there is no need to provide these handlers. If ECA.28
is set for the guest by default when the AP facilities are installed, then the
AP
instructions will be interpreted and the AP bus will get initialized on the
guest. Since there is no vfio-ap device to provide the AP matrix configuration
for the guest, the AP bus will not detect any devices, but that's okay. AP
instructions targeting at an APQN will execute successfully and set a response
code in the status block returned from the instruction indicating the
APQN is invalid .... but there will be no exception unless there is truly
an exception condition caused by the execution of the instruction.