On 30/07/2018 18:10, Alex Williamson wrote:
On Mon, 30 Jul 2018 08:05:32 +0200
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
On 07/27/2018 06:53 PM, Alex Williamson wrote:
On Fri, 27 Jul 2018 12:59:50 +0200
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
On 07/27/2018 10:38 AM, Cornelia Huck wrote:
On Thu, 26 Jul 2018 21:54:07 +0200
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
* The mediated device gained an 'activate' attribute. Sharing conflicts are
checked on activation now. If the device was not activated, the mdev
open still implies activation. An active ap_matrix_mdev device claims
it's resources -- an inactive does not.
This means we have a 'commit' workflow?
Yes. We want to be able to "overcommit" definitions. For example when you
have 2 guests that you never start at the same time. Then you can give both
guests the same disks. If you start at the same time, libvirt will complain.
Now: you want to do the same for matrixes. Allocation at definition time
would limit that flexibility. When we check at "commit" this allows overcommit.
I raised an eyebrow to this 'activate' attribute as well and I think we
struggled through the same sort of thing when defining mdev initially
with NVIDIA. IIRC there was a proposal that mdev devices could
effectively be overcommitted on the parent and only when they were
opened, would the allocation count against the available instances.
The trouble is then that libvirt has no guarantee that a given mdev
device is usable. I believe we decided that the creation of the mdev
device is the point at which we want to reserve resources because it
provides a better synchronization point. I don't really see what
advantage we have by having these matrices on 'standby', shouldn't
userspace be able to manipulate these dynamically and on-demand of
starting a VM? Thanks,
We had this discussion as well and there is a case where not-predefining
things might complicate matters:
Daniel, please correct me if this is not so:
As far as I understand the libvirt folks want to have host devices and guest
instances decoupled. So a guest startup will not trigger a define of the mdev
instance. (instead it has to be a separate step). This might work with virsh
(but it now requires two steps as you can not predefine instances) but it
might break things like virt-manager.
If this is a libvirt requirement, then it's creating a different model
for AP mdev devices since existing mdev devices do not allow
overcommit. libvirt currently does no mdev lifecycle management, it's
entirely left to the user to decide on a static configuration or
dynamic creation. Dynamic creation can be done via qemu hooks until
libvirt decides how/if they'll take on creation. So I don't think it
makes sense to make AP mdev devices behave different from others in
this respect. Thanks,
Alex
The problem we have with the AP matrix is that we have a complex entity,
APCB (part of CRYCB) which defines 2 masks, cards and card's access queues
which cross product produces a matrix in which each point is a AP device.
The firmware policies has restrictions about the concurrent access to these
devices and it is much simpler for us to pass a subset of the matrix to
a guest instead of passing the AP devices.
To handle security issues we want to use mediated devices.
Two architectures can be build to achieve this.
The first one uses a single host device representing the matrix
and multiple mediated device.
In this case the matrix subset we want to configure for a guest
can only be configured inside the mediated device and
therefore the configuration can only happen after the creation
of the mediated device.
The second one uses one host devices per configuration
and creates the mediated device on it once
the configuration is done.
This patch set presents the first architecture.
Do you have any advice how to make this architecture more
conform to the current mdev device behavior?
Would the second architecture be more acceptable?
Best regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
--
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
