qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [PATCH v9 08/15] s390x: protvirt: SCLP interpretation
Date: Tue, 17 Mar 2020 12:05:29 +0100

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]