On Tue, 17 Mar 2020 12:54:54 +0100 Janosch Frank <fran...@linux.ibm.com> wrote:
> On 3/17/20 12:05 PM, Cornelia Huck wrote:
> > On Fri, 13 Mar 2020 14:14:35 +0100
> > Christian Borntraeger <borntrae...@de.ibm.com> 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 <fran...@linux.ibm.com>
> >>> Reviewed-by: David Hildenbrand <da...@redhat.com>
> >>> ---
> >>> 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 <borntrae...@de.ibm.com>
> >>
> >>> + 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;
> >>> +}
> >>> +
> >
> >
>
>
pgpN_2y40OwF0.pgp
Description: OpenPGP digital signature
