| Message ID | 20191129094809.26684-8-frankja@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | s390x: Protected Virtualization support | expand |
On 29.11.19 10:48, Janosch Frank wrote: > SCLP for a protected guest is done over the SIDAD, so we need to use > the s390_cpu_virt_mem_* functions to access the SIDAD instead of guest > memory when reading/writing SCBs. ... Can you elaborate a bit more how that is going to be used? Did you hack in special memory access to something called "SIDAD" via s390_cpu_virt_mem_*? I'd suggest a different access path ... especially because a) it's confusing b) it's unclear how exceptions apply ... > > 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 <frankja@linux.ibm.com> > --- > hw/s390x/sclp.c | 17 +++++++++++++++++ > include/hw/s390x/sclp.h | 2 ++ > target/s390x/kvm.c | 5 +++++ > 3 files changed, 24 insertions(+) > > diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c > index f57ce7b739..ca71ace664 100644 > --- a/hw/s390x/sclp.c > +++ b/hw/s390x/sclp.c > @@ -193,6 +193,23 @@ static void sclp_execute(SCLPDevice *sclp, SCCB *sccb, uint32_t code) > } > } > > +#define SCLP_PV_DUMMY_ADDR 0x4000 > +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); > + > + s390_cpu_virt_mem_read(env_archcpu(env), 0, 0, &work_sccb, sccb_len); > + sclp_c->execute(sclp, &work_sccb, code); > + s390_cpu_virt_mem_write(env_archcpu(env), 0, 0, &work_sccb, > + be16_to_cpu(work_sccb.h.length)); this access itself without handling exceptions looks dangerous as it is completely unclear what's happening here. > + sclp_c->service_interrupt(sclp, SCLP_PV_DUMMY_ADDR); > + return 0; > +} > + > int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code) > { > SCLPDevice *sclp = get_sclp_device(); > diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h > index c54413b78c..c0a3faa37d 100644 > --- a/include/hw/s390x/sclp.h > +++ b/include/hw/s390x/sclp.h > @@ -217,5 +217,7 @@ void s390_sclp_init(void); > void sclp_service_interrupt(uint32_t sccb); > void raise_irq_cpu_hotplug(void); > int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code); > +int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb, > + uint32_t code); > > #endif > diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c > index 3d9c44ba9d..b802d02ff5 100644 > --- a/target/s390x/kvm.c > +++ b/target/s390x/kvm.c > @@ -1174,6 +1174,11 @@ static void kvm_sclp_service_call(S390CPU *cpu, struct kvm_run *run, > sccb = env->regs[ipbh0 & 0xf]; > code = env->regs[(ipbh0 & 0xf0) >> 4]; > > + if (run->s390_sieic.icptcode == ICPT_PV_INSTR) { isn't checking against env->pv easier and cleaner?
On 11/29/19 11:43 AM, David Hildenbrand wrote: > On 29.11.19 10:48, Janosch Frank wrote: >> SCLP for a protected guest is done over the SIDAD, so we need to use >> the s390_cpu_virt_mem_* functions to access the SIDAD instead of guest >> memory when reading/writing SCBs. > > ... Can you elaborate a bit more how that is going to be used? Did you > hack in special memory access to something called "SIDAD" via > s390_cpu_virt_mem_*? For secure guests we can't ever access virtual guest memory, since we have no access to the guest translation tables. Hence we have the satellite block (SIDA) as a bounce buffer. SIE will bounce referenced blocks of data (like the SCCB) over the SIDA. The virt_mem functions go through the KVM mem op API. A KVM patch reroutes mem op access to the SIDA. The alternative would be to map the SIDA into vcpu_run. > > I'd suggest a different access path ... especially because > > a) it's confusing Granted, there's a lot of inherent knowledge behind these patches. And looking at my past answers to the KVM intercept patch I already forgot lots of it. > b) it's unclear how exceptions apply There are no PGM exceptions, as they are pre-checked and reported by SIE. There are however errors that the mem op API can return. > > ... > >> >> 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 <frankja@linux.ibm.com> >> --- >> hw/s390x/sclp.c | 17 +++++++++++++++++ >> include/hw/s390x/sclp.h | 2 ++ >> target/s390x/kvm.c | 5 +++++ >> 3 files changed, 24 insertions(+) >> >> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c >> index f57ce7b739..ca71ace664 100644 >> --- a/hw/s390x/sclp.c >> +++ b/hw/s390x/sclp.c >> @@ -193,6 +193,23 @@ static void sclp_execute(SCLPDevice *sclp, SCCB *sccb, uint32_t code) >> } >> } >> >> +#define SCLP_PV_DUMMY_ADDR 0x4000 >> +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); >> + >> + s390_cpu_virt_mem_read(env_archcpu(env), 0, 0, &work_sccb, sccb_len); >> + sclp_c->execute(sclp, &work_sccb, code); >> + s390_cpu_virt_mem_write(env_archcpu(env), 0, 0, &work_sccb, >> + be16_to_cpu(work_sccb.h.length)); > > this access itself without handling exceptions looks dangerous as it is > completely unclear what's happening here. See above > >> + sclp_c->service_interrupt(sclp, SCLP_PV_DUMMY_ADDR); >> + return 0; >> +} >> + >> int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code) >> { >> SCLPDevice *sclp = get_sclp_device(); >> diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h >> index c54413b78c..c0a3faa37d 100644 >> --- a/include/hw/s390x/sclp.h >> +++ b/include/hw/s390x/sclp.h >> @@ -217,5 +217,7 @@ void s390_sclp_init(void); >> void sclp_service_interrupt(uint32_t sccb); >> void raise_irq_cpu_hotplug(void); >> int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code); >> +int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb, >> + uint32_t code); >> >> #endif >> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c >> index 3d9c44ba9d..b802d02ff5 100644 >> --- a/target/s390x/kvm.c >> +++ b/target/s390x/kvm.c >> @@ -1174,6 +1174,11 @@ static void kvm_sclp_service_call(S390CPU *cpu, struct kvm_run *run, >> sccb = env->regs[ipbh0 & 0xf]; >> code = env->regs[(ipbh0 & 0xf0) >> 4]; >> >> + if (run->s390_sieic.icptcode == ICPT_PV_INSTR) { > > isn't checking against env->pv easier and cleaner? Hmm, I dislike checking a global state for a CPU icpt. > >
On 29.11.19 12:15, Janosch Frank wrote: > On 11/29/19 11:43 AM, David Hildenbrand wrote: >> On 29.11.19 10:48, Janosch Frank wrote: >>> SCLP for a protected guest is done over the SIDAD, so we need to use >>> the s390_cpu_virt_mem_* functions to access the SIDAD instead of guest >>> memory when reading/writing SCBs. >> >> ... Can you elaborate a bit more how that is going to be used? Did you >> hack in special memory access to something called "SIDAD" via >> s390_cpu_virt_mem_*? > > For secure guests we can't ever access virtual guest memory, since we > have no access to the guest translation tables. > > Hence we have the satellite block (SIDA) as a bounce buffer. SIE will > bounce referenced blocks of data (like the SCCB) over the SIDA. > > The virt_mem functions go through the KVM mem op API. A KVM patch > reroutes mem op access to the SIDA. The alternative would be to map the > SIDA into vcpu_run. > I'd prefer *anything* over going via s390_cpu_virt_mem_*, because as you say "For secure guests we can't ever access virtual guest memory". Introduce a new interface or go via vcpu_run. IMHO that's much cleaner.
diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c index f57ce7b739..ca71ace664 100644 --- a/hw/s390x/sclp.c +++ b/hw/s390x/sclp.c @@ -193,6 +193,23 @@ static void sclp_execute(SCLPDevice *sclp, SCCB *sccb, uint32_t code) } } +#define SCLP_PV_DUMMY_ADDR 0x4000 +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); + + s390_cpu_virt_mem_read(env_archcpu(env), 0, 0, &work_sccb, sccb_len); + sclp_c->execute(sclp, &work_sccb, code); + s390_cpu_virt_mem_write(env_archcpu(env), 0, 0, &work_sccb, + be16_to_cpu(work_sccb.h.length)); + sclp_c->service_interrupt(sclp, SCLP_PV_DUMMY_ADDR); + return 0; +} + int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code) { SCLPDevice *sclp = get_sclp_device(); diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h index c54413b78c..c0a3faa37d 100644 --- a/include/hw/s390x/sclp.h +++ b/include/hw/s390x/sclp.h @@ -217,5 +217,7 @@ void s390_sclp_init(void); void sclp_service_interrupt(uint32_t sccb); void raise_irq_cpu_hotplug(void); int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code); +int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb, + uint32_t code); #endif diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c index 3d9c44ba9d..b802d02ff5 100644 --- a/target/s390x/kvm.c +++ b/target/s390x/kvm.c @@ -1174,6 +1174,11 @@ static void kvm_sclp_service_call(S390CPU *cpu, struct kvm_run *run, sccb = env->regs[ipbh0 & 0xf]; code = env->regs[(ipbh0 & 0xf0) >> 4]; + if (run->s390_sieic.icptcode == ICPT_PV_INSTR) { + sclp_service_call_protected(env, sccb, code); + return; + } + r = sclp_service_call(env, sccb, code); if (r < 0) { kvm_s390_program_interrupt(cpu, -r);
SCLP for a protected guest is done over the SIDAD, so we need to use the s390_cpu_virt_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 <frankja@linux.ibm.com> --- hw/s390x/sclp.c | 17 +++++++++++++++++ include/hw/s390x/sclp.h | 2 ++ target/s390x/kvm.c | 5 +++++ 3 files changed, 24 insertions(+)