On 01/17/2018 12:28 PM, Christian Borntraeger wrote: > > > On 01/17/2018 12:22 PM, Paolo Bonzini wrote: >>> while this is kvm code, my current plan is to submit the "final" >>> version after review and probably some fixes/renames via Martin >>> together with the other patches. Are you ok with that? Right now it >>> seems that the CAP number is still fine. >> Sure, though there will be a capability introduced by PPC for similar >> purposes, so check for conflicts. >> >> On 17/01/2018 12:18, Christian Borntraeger wrote: >>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c >>> index 2c93cbb..0c18f73 100644 >>> --- a/arch/s390/kvm/kvm-s390.c >>> +++ b/arch/s390/kvm/kvm-s390.c >>> @@ -421,6 +421,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) >>> case KVM_CAP_S390_GS: >>> r = test_facility(133); >>> break; >>> + case KVM_CAP_S390_SEB: >>> + r = test_facility(82); >>> + break; >>> default: >>> r = 0; >> >> Can you add a generic "test facility" capability and ioctl? > > The problem is not that I announce the facility, I in fact announce that the > programmatic interface is available (the sebc sync reg and the usage of that field). > (So the CAP is part of this patch to have both in lockstep) > A non-existing facility will then just disable that programmatic interface. To put it differently. CAP_S390_GS and CAP_S390_SEB could also just do a return 1; and the QEMU has to check both (which it probably does anyway) Christian -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
