On 12.12.18 14:08, Cornelia Huck wrote: > On Wed, 12 Dec 2018 11:49:56 +0100 > David Hildenbrand <david@xxxxxxxxxx> wrote: > >> I am wondering if another way to handle this would maybe be even better. >> It would allow also new QEMU on old KVM to get access to these values. >> It will simply not be written to HW then (bad luck, there is no HW >> support eventually) >> >> >> It goes like this: >> >> 1. don't implement diag318 in the kernel, implement it in user space. >> diag318 is already forwarded to QEMU as of now. (I don't consider >> diag318 peformance relevant) >> >> 2. in user space, we can always support diag318, even without KVM/HW >> support. (could glue to machines if really needed) >> >> 3. If we get a diag318 and the CPU feature is not enabled, handle it if >> diag318 is not available (exception, just as we do now). >> >> 3. If we get a diag318 and the CPU feature is enabled, store both values >> in QEMU (for migration and e.g. DUMPs) AND ... >> >> 4. ... if KVM supports KVM_S390_VM_MACHINE_CPC, also write the new >> values (or even only the CPNC! ) to KVM. >> >> 5. During migration, if KVM supports KVM_S390_VM_MACHINE_CPC, also write >> the migrated value to KVM. > > What about that sclp thingie (I'm not quite sure what it signifies)? You mean the indication of diag318? Well we might want to check in KVM if the host has it (and therefore the CPNC in the SCB actually gets used) and only then allow to set the CPNC. Or we could simply always allow to write it to the SCB even though the value won't get used by HW. -- Thanks, David / dhildenb
