On Mon, 13 Jul 2020 13:54:41 +0200
Christian Borntraeger <[email protected]> wrote:
> On 10.07.20 10:32, David Hildenbrand wrote:
>
> >>> --- a/target/s390x/misc_helper.c
> >>> +++ b/target/s390x/misc_helper.c
> >>> @@ -116,6 +116,12 @@ void HELPER(diag)(CPUS390XState *env, uint32_t r1,
> >>> uint32_t r3, uint32_t num)
> >>> uint64_t r;
> >>>
> >>> switch (num) {
> >>> + case 0x260:
> >>> + qemu_mutex_lock_iothread();
> >>> + handle_diag_260(env, r1, r3, GETPC());
> >>> + qemu_mutex_unlock_iothread();
> >>> + r = 0;
> >>> + break;
> >>> case 0x500:
> >>> /* KVM hypercall */
> >>> qemu_mutex_lock_iothread();
> >>
> >> Looking at the doc referenced above, it seems that we treat every diag
> >> call as privileged under tcg; but it seems that 0x44 isn't? (Unrelated
> >> to your patch; maybe I'm misreading.)
> >
> > That's also a BUG in kvm then?
> >
> > int kvm_s390_handle_diag(struct kvm_vcpu *vcpu)
> > {
> > ...
> > if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE)
> > return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
> > ...
> > }
>
> diag 44 gives a PRIVOP on LPAR, so I think this is fine.
>
Seems like a bug/inconsistency in CP (or its documentation), then.
