On Thu, 16 Nov 2017 10:23:25 -0500 Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> 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? See the patches. As a rule, I find it more sensible to introduce interface + implementation together rather than separate. > > - 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. Sounds good. > > - 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. > > - some minor stuff > > >
