Re: [PATCH v5 11/13] KVM: s390: implement mediated device open callback

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

 



On 06/07/2018 01:15 PM, Pierre Morel wrote:



We have internal structures like the ap_matrix and kvm_ap_matrix
which look like the bus/devices we had previously but are differently
or not at all integrated with the LDD.

What is LDD? Are you talking about dependencies between the vfio_ap device
driver and KVM? If so, see my arguments below.



Also I think that with a little data structure refactoring you can avoid most of
the code in the arch/s390/kvm.

How will structure refactoring help us avoid the code for updating the CRYCB
in the guest's SIE state description.



For example, storing the kvm pointer inside the kvm_ap_matrix and
maintaining a list of the kvm_ap_matrix structures allows to easily know
if a guest already has an associated mediated device.

How is that easier than storing the kvm pointer inside of the mediated matrix device (i.e., struct ap_matrix_mdev) which also contains the struct kvm_ap_matrix?

you can put it in ap_matrix_mdev but just the name "kvm_ap_matrix" make the
last one a better candidate for my opinion.

It's been in ap_matrix_mdev since v2, but I'll consider moving it to kvm_ap_matrix.



How does that allow us to avoid the code in arch/s390/kvm?

This alone does not.

We still need the code
to update the CRYCB in the SIE block. I can obviously avoid placing that code in kvm-ap.c and move it to the driver, but I already explained my reasoning for keeping it in KVM. Let's face it, there is no way around the dependency between the vfio_ap device driver and KVM unless guest matrix configuration is managed
solely by KVM through KVM interfaces.

We get the pointer to KVM from the VFIO interface.
That we both discuss on this is sterile.
The only one who could say what is right is a S390 KVM maintainer.
This would end the discussion.
My point was just to say that we have an alternative.



Why maintain a list of kvm_ap_matrix structures if we don't have to; it is stored with the mediated matrix device which is passed in to all of the vfio_ap driver
callbacks.

Because using the vm_list which is a static in kvm makes you stick inside the kvm code.

I understand your point here, but even if we did maintain a list of kvm_ap_matrix structures, we still need the kvm code to configure the guest's CRYCB and eventually ECA.28. There is also code in kvm-ap.c that is called from KVM. The idea behind kvm-ap.c is that all code
related to configuration of AP structures in KVM is in this one spot.








[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