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

[Cornelia Huck]

On Tue, 17 Mar 2020 12:54:54 +0100
Janosch Frank <address@hidden> wrote:

> 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.

Depending on if the passed-through codes would work without any further
changes, I guess (which seems likely?) You probably have a better idea
about that :)

> 
> >   
> >>
> >> 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;
> >>> +}
> >>> +  
> > 
> >   
> 
>

pgpT98jZUycuv.pgp
Description: OpenPGP digital signature