On 12/05/2017 09:06 AM, Cornelia Huck wrote:
On Mon, 27 Nov 2017 19:39:32 -0500
Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote:
On 11/22/2017 08:47 AM, Cornelia Huck wrote:
On Tue, 21 Nov 2017 11:08:01 -0500
Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote:
I am not quite sure what you are asking, but I'll attempt to answer
what I think you're asking. A new type of mediated matrix device
will be introduced to configure a virtual matrix for a guest that
provides the interfaces to map a virtual adapter/domain ID to one
or more real adapter/domain IDs. If by virtualization facility,
you are talking about the VFIO AP matrix driver, then yes,
the driver will handle ioctl requests based on the type of the
mediated matrix device through which the request was submitted:
If the request is to configure the KVM guest's matrix:
* If the mediated matrix device type is passthrough:
* Do validation of matrix
* Configure the APM, AQM and ADM in the KVM guest's CRYCB
according to the configuration specified via the mediated
device's sysfs attribute files.
* If the mediated matrix device type is virtual:
* Do validation of matrix
* No need to configure CRYCB since all instructions will be
intercepted
Ok, so we would have two distinct paths here...
It depends upon what you mean by two distinct paths. Configuring the
mediated device would require a new mediated device type for virtualized
AP matrices. The ioctl for configuring the KVM guest's CRYCB would
require an additional check to determine whether the CRYCB need be
configured or not.
Yes, the new type makes this distinct enough so that we can think about
this later.
If the request is to execute an intercepted AP instruction:
* If the mediated matrix device type is passthrough:
* Forward the instruction to the AP device and return the
result to QEMU.
* If the mediated matrix device type is virtual:
* Retrieve all of the real APQNs mapped to the virtual
adapter and domain IDs configured in the mediated matrix
device's sysfs attribute files
* If there is more than one APQN mapping, then determine
which would be best to use - algorithm TBD
* Forward the instruction to the AP device and return the
result.
...and two distinct paths for most instructions here as well.
The driver would require additional ioctls to handle
interception of all AP instructions for virtual matrices and additional
code to remap virtual APQNs to real APQNs and determine which real APQN
to which intercepted instructions should be forwarded.
Of course, these are just preliminary ideas at this time.
I've only prototyped the sysfs configuration interfaces. No
back end prototyping has been undertaken yet. If the ideas do
not pan out, however; I think virtualization can be introduced
as an independent design.
Yes, let's cross that bridge when we get to it.
That is the plan. Given Pierre's objections, I thought it might help
to touch on this.
OK, so I admit that I lost track a bit. Are there any remaining issues
beyond the feature handling? Would it make sense to post a v2?
I was planning on posting a V2 once the features issue is settled.
--
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
