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)? > > KVM code is minimized. KVM_S390_VM_CPU_FEAT_DIAG318 in KVM is not > needed. We might even only need writing of KVM_S390_VM_MACHINE_CPC. In general, I like doing most of the implementation in QEMU. Especially if we consider the compatibility/migration implications.
