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.
