As a remark. I think it makes more sense to concentrate on the whole concept before doing an depth review (of course, if you have the cycles - feel free to go ahead :-) ). Let me just summarize the HW idea in a very simplified fashion, so that we can try to let everybody understand what is going on here. Implementation-wise (in LPAR and as supported by the HW-virtualization for KVM) the implementation itself is really really simple. As a satellite block of the state descriptor (sie control block) there is the crypto control block. (usually one per guest). This contains 3 256bit bitfields which allow/disallow 1. adapters by number (0-255) 2. usage domains by number (0-255) 3. control domains by number (0-255) For simplicity lets ignore the control domains, the mechanism is similar to the usage domain. The guest will then have access to ALL elements of the cross product. So adapter 1,2,3 and domain 10,11,12 will result in 9 tuples accessible by the guest (1,10) ; (1,11) ; (1,12) ; (2,10) ; (2,11) ; (2,12) ; (3,10) ; (3,11) ; (3,12) the admin (or the management instance) must ensure that each tuple is only in use by 1 guest. Setting the bits is basically all what is needed (plus some minimal glue and handling), everything else will be handled by hardware/firmware. Now if we do not need to care about security, we could just use some kvm ioctl and be done with it. As we learned for PCI, this is not going to be secure as qemu is untrusted in svirt/appamor contexts. So this is basically using vfio and mdev as a means to orchestrate things. And this is where things get complicated and multiple options are possible. Christian -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
