On 13.12.18 11:21, Cornelia Huck wrote: > On Thu, 13 Dec 2018 10:12:49 +0100 > David Hildenbrand <david@xxxxxxxxxx> wrote: > >> 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. > > Maybe always allow to write it, for simplicity's sake? Does it matter > much whether it will get used by HW? > Usually it does not matter. I remember that there were some fields that should not be touched if the feature is not available (otherwise you might get undefined behavior). -- Thanks, David / dhildenb
