On 11/21/19 3:07 PM, Cornelia Huck wrote: > On Wed, 20 Nov 2019 06:43:27 -0500 > Janosch Frank wrote: > >> Secure guests no longer intercept with code 4 for an instruction >> interception. Instead they have codes 104 and 108 for secure >> instruction interception and secure instruction notification >> respectively. >> >> The 104 mirrors the 4, but the 108 is a notification, that something >> happened and the hypervisor might need to adjust its tracking data to >> that fact. An example for that is the set prefix notification >> interception, where KVM only reads the new prefix, but does not update >> the prefix in the state description. >> >> Signed-off-by: Janosch Frank >> --- >> target/s390x/kvm.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c >> index 418154ccfe..58251c0229 100644 >> --- a/target/s390x/kvm.c >> +++ b/target/s390x/kvm.c >> @@ -115,6 +115,8 @@ >> #define ICPT_CPU_STOP 0x28 >> #define ICPT_OPEREXC 0x2c >> #define ICPT_IO 0x40 >> +#define ICPT_PV_INSTR 0x68 >> +#define ICPT_PV_INSTR_NOT 0x6c > > _NOTIF ? Yeah, forgot about that > >> >> #define NR_LOCAL_IRQS 32 >> /* >> @@ -151,6 +153,7 @@ static int cap_s390_irq; >> static int cap_ri; >> static int cap_gs; >> static int cap_hpage_1m; >> +static int cap_protvirt; >> >> static int active_cmma; >> >> @@ -336,6 +339,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s) >> cap_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF); >> cap_mem_op = kvm_check_extension(s, KVM_CAP_S390_MEM_OP); >> cap_s390_irq = kvm_check_extension(s, KVM_CAP_S390_INJECT_IRQ); >> + cap_protvirt = kvm_check_extension(s, KVM_CAP_S390_PROTECTED); > > You don't seem to do anything with this yet? No, I'm still a bit in the dark about how we want to tie protvirt into qemu. > >> >> if (!kvm_check_extension(s, KVM_CAP_S390_GMAP) >> || !kvm_check_extension(s, KVM_CAP_S390_COW)) { >> @@ -1664,6 +1668,8 @@ static int handle_intercept(S390CPU *cpu) >> (long)cs->kvm_run->psw_addr); >> switch (icpt_code) { >> case ICPT_INSTRUCTION: >> + case ICPT_PV_INSTR: >> + case ICPT_PV_INSTR_NOT: >> r = handle_instruction(cpu, run); > > Doesn't handle_instruction() want to know whether it got a request for > emulation vs a notification? Currently not, the sclp patch looks at the vcpu run icptcode to figure out what's going on. > >> break; >> case ICPT_PROGRAM: > >