Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

From: Pierre Morel
Date: Thu Nov 16 2017 - 15:25:39 EST


On 16/11/2017 18:03, Cornelia Huck wrote:
On Thu, 16 Nov 2017 17:06:58 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxxxxxxx> wrote:

On 16/11/2017 16:23, Tony Krowiak wrote:
On 11/14/2017 08:57 AM, Cornelia Huck wrote:
On Tue, 31 Oct 2017 15:39:09 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote:
On 10/13/2017 01:38 PM, Tony Krowiak wrote:
Ping
Tony Krowiak (19):
ÂÂÂ KVM: s390: SIE considerations for AP Queue virtualization
ÂÂÂ KVM: s390: refactor crypto initialization
ÂÂÂ s390/zcrypt: new AP matrix bus
ÂÂÂ s390/zcrypt: create an AP matrix device on the AP matrix bus
ÂÂÂ s390/zcrypt: base implementation of AP matrix device driver
ÂÂÂ s390/zcrypt: register matrix device with VFIO mediated device
ÂÂÂÂÂ framework
ÂÂÂ KVM: s390: introduce AP matrix configuration interface
ÂÂÂ s390/zcrypt: support for assigning adapters to matrix mdev
ÂÂÂ s390/zcrypt: validate adapter assignment
ÂÂÂ s390/zcrypt: sysfs interfaces supporting AP domain assignment
ÂÂÂ s390/zcrypt: validate domain assignment
ÂÂÂ s390/zcrypt: sysfs support for control domain assignment
ÂÂÂ s390/zcrypt: validate control domain assignment
ÂÂÂ KVM: s390: Connect the AP mediated matrix device to KVM
ÂÂÂ s390/zcrypt: introduce ioctl access to VFIO AP Matrix driver
ÂÂÂ KVM: s390: interface to configure KVM guest's AP matrix
ÂÂÂ KVM: s390: validate input to AP matrix config interface
ÂÂÂ KVM: s390: New ioctl to configure KVM guest's AP matrix
ÂÂÂ s390/facilities: enable AP facilities needed by guest
I think the approach is fine, and the code also looks fine for the most
part. Some comments:

- various patches can be squashed together to give a better
ÂÂ understanding at a glance
Which patches would you squash?
- this needs documentation (as I already said)
My plan is to take the cover letter patch and incorporate that into
documentation,
then replace the cover letter patch with a more concise summary.
- some of the driver/device modelling feels a bit awkward (commented in
ÂÂ patches) -- I'm not sure that my proposal is better, but I think we
ÂÂ should make sure the interdependencies are modeled correctly
I am responding to each patch review individually.

I think that instead of responding to each patch individually we should
have a discussion on the design because I think a lot could change and
discussing about each patch as they may be completely redesigned for the
next version may not be very useful.

So I totally agree with Conny on that we should stabilize the
bus/device/driver modeling.

I think it would be here a good place to start the discussion on things
like we started to discuss, Harald and I, off-line:
- why a matrix bus, in which case we can avoid it

I thought it had been agreed that we should be able to ditch it?

I have not see any comment on the matrix bus.


- which kind of devices we need

What is still unclear? Which card generations to support?

No, I mean the relation bus/device/driver/mdev...


- how to handle the repartition of queues on boot, reset and hotplug

That's something I'd like to see a writeup for.

yes, and it may have an influence on the bus/device/driver/mdev design


- interaction with the host drivers

The driver model should already handle that, no?

yes it should, but it is not clear for me.


- validation of the matrix for guests and host views

I saw validation code in the patches, although I have not reviewed it.


or even features we need to add like
- interruptions

My understanding is that interrupts are optional so they can be left
out in the first shot. With the gisa (that has not yet been posted), it
should not be too difficult, no?

you are right I forgot that it is optional


- PAPQ/TAPQ-t and APQI interception

I can't say anything about that, as this is not documented :(

Right we can live without these too.


- virtualization of the AP

Is this really needed? It would complicate everything a lot.

Concern has no sens without interception.

- CPU model and KVM capabilities

That already has been discussed with the individual patches.

Well, if there are no interceptions the individual patches discussions are enough.



In my understanding these points must be cleared before we really start
to discuss the details of the implementation.

The general design already looks fine to me. Do you really expect that
a major redesign is needed?


I am worry about the following:
- Will the matrix bus be accepted
- What happens on host reset and hot plug/unplug in host
- What happens with the queues on guest start/halt/restart

Regards,

Pierre

--
Pierre Morel
Linux/KVM/QEMU in BÃblingen - Germany