Re: [PATCH v2 2/2] s390/kvm: handle diagnose 318 instruction call

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux