Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

[Halil Pasic]

On 04/11/2018 03:20 PM, Tony Krowiak wrote:
>>>> 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.

That's exactly the idea, but it will only work out this way if the effective
ECA.28 bit (i.e. EECA.28) is also set.

Could you please comment the first paragraph quoted in this email?

Halil