Re: [qemu-s390x] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support

[Pierre Morel]

On 28/02/2018 12:40, Cornelia Huck wrote:
> On Wed, 28 Feb 2018 11:26:30 +0100
> David Hildenbrand <address@hidden> wrote:
>
> > Then I request the following change in KVM:
> >
> > If KVM_S390_VM_CPU_FEAT_AP is enabled in KVM, ECA.28 is _always_ set
> > (not just if an AP device is configured). This especially makes things a
> > lot easier when it comes to handling hotplugged CPUs and avoiding race
> > conditions when enabling these bits as mentioned in the KVM series.
> >
> > KVM_S390_VM_CPU_FEAT_AP == AP instructions available for the guest
> > (don't throw an operation exception).
> >
> > So this feature then really is guest ABI. The instructions are
> > available. If there is no device configured, bad luck.
> Sounds sensible from my POV.

I have a concern with this proposition and with the original code:

1) ap=on is a guest ABI feature saying to the guest you can use AP 
instructions

2) How we provide AP instructions to the guest can be done in three 
different ways:
 - SIE Interpretation
 - interception with VFIO
 - interception with emulation

3) We implement this with a device in QEMU and a certain level kernel 
support.

It seems possible to set or not ECA.28 , based on the type of kernel device:
- SIE interpretation -> MATRIX KVM device -> ECA.28
- Interception with VFIO and virtualization -> no ECA.28
- interception with emulation -> no ECA.28

I understand the concern with the vCPU but I think we can handle it with 
an indirect variable
like:

SIE interpretation Device + KVM_S390_VM_CPU_FEAT_AP -> set the variable  
ap_to_be_sie_interpreted=1
Then in vCPU initialization set ECA.28 based on this variable.

I think it let us more doors open, what is your opinion?

Regards,

Pierre


--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany