Re: [PATCH v9 08/15] s390x: protvirt: SCLP interpretation

[Janosch Frank]

On 3/17/20 12:05 PM, Cornelia Huck wrote:
> On Fri, 13 Mar 2020 14:14:35 +0100
> Christian Borntraeger <address@hidden> wrote:
> 
>> On 11.03.20 14:21, Janosch Frank wrote:
>>> SCLP for a protected guest is done over the SIDAD, so we need to use
>>> the s390_cpu_pv_mem_* functions to access the SIDAD instead of guest
>>> memory when reading/writing SCBs.
>>>
>>> To not confuse the sclp emulation, we set 0x4000 as the SCCB address,
>>> since the function that injects the sclp external interrupt would
>>> reject a zero sccb address.
>>>
>>> Signed-off-by: Janosch Frank <address@hidden>
>>> Reviewed-by: David Hildenbrand <address@hidden>
>>> ---
>>>  hw/s390x/sclp.c         | 30 ++++++++++++++++++++++++++++++
>>>  include/hw/s390x/sclp.h |  2 ++
>>>  target/s390x/kvm.c      | 24 +++++++++++++++++++-----
>>>  3 files changed, 51 insertions(+), 5 deletions(-)
> 
>>> +int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb,
>>> +                                uint32_t code)
>>> +{
>>> +    SCLPDevice *sclp = get_sclp_device();
>>> +    SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
>>> +    SCCB work_sccb;
>>> +    hwaddr sccb_len = sizeof(SCCB);
>>> +
>>> +    /*
>>> +     * Only a very limited amount of calls is permitted by the
>>> +     * Ultravisor and we support all of them, so we don't check for
>>> +     * them. All other specification exceptions are also interpreted
>>> +     * by the Ultravisor and hence never cause an exit we need to
>>> +     * handle.
>>> +     *
>>> +     * Setting the CC is also done by the Ultravisor.
>>> +     */  
>>
>> This is fine for the current architecture which specifies a list of sclp 
>> commands that are passed through (and this is fine). Question is still if
>> we replace this comment with an assertion that this is the case?
>> Or maybe even really do the same as sclp_service_call and return 0x1f0 for
>> unknown commands?
> 
> That would be a case of older QEMU on newer hardware, right? Signaling
> that the command is unsupported seems the most reasonable to me
> (depending on what the architecture allows.)

Question is if we want to check for the non-pv codes as the hardware
will currently only allow a smaller subset anyway. Then if the IO codes
are passed through by SIE we would support them right away.

> 
>>
>> Anyway, whatever you decide.
>>
>> Reviewed-by: Christian Borntraeger <address@hidden>
>>
>>> +    s390_cpu_pv_mem_read(env_archcpu(env), 0, &work_sccb, sccb_len);
>>> +    sclp_c->execute(sclp, &work_sccb, code);
>>> +    s390_cpu_pv_mem_write(env_archcpu(env), 0, &work_sccb,
>>> +                          be16_to_cpu(work_sccb.h.length));
>>> +    sclp_c->service_interrupt(sclp, SCLP_PV_DUMMY_ADDR);
>>> +    return 0;
>>> +}
>>> +
> 
>

signature.asc
Description: OpenPGP digital signature