On 03.04.19 14:09, David Hildenbrand wrote: > On 03.04.19 13:28, Christian Borntraeger wrote: >> >> >> On 02.04.19 19:46, Collin Walling wrote: >>> Execution of DIAGNOSE 0x318 is fenced by checking an SCLP bit >>> for the availability of hardware support for the instruction. >>> >>> In order to support this instruction for a KVM/QEMU guest, we >>> would need to provide modifications to the SCLP Read SCP Info >>> data, which will in turn reduce the maximum number of CPUs that >>> may be provided to the guest. This issue introduces compatability >>> and legacy concerns. >>> >>> Let's circumvent this issue by removing the bit check and blindly >>> executing the instruction. An exception table rule is in place to >>> catch the case where hardware does not support this instruction. >> >> >> No, please keep the check. We have to extend the read scp field anyway >> for future extensions. > > Wasn't there already an SCLP-way of telling the guest that the read-scp > info response is bigger than 4k? Somehow rings a bell ... Yes, that would be a future extension (the Linux guest does not support this). Until then we probably have to go back to a smaller cpu number (e.g. 240 for machine type 4.1 and newer).
