From: Alex Williamson <alex.williamson@redhat.com>
To: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Cc: izumi.taku@jp.fujitsu.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v10 10/19] vfio: improve vfio_get_group to support adding as is NULL.
Date: Thu, 18 Jun 2015 10:41:17 -0600 [thread overview]
Message-ID: <1434645677.3700.60.camel@redhat.com> (raw)
In-Reply-To: <f877a1630ae671842ac9aeaa120dda63d82737d8.1434356309.git.chen.fan.fnst@cn.fujitsu.com>
On Tue, 2015-06-16 at 16:10 +0800, Chen Fan wrote:
> Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
> ---
> hw/vfio/common.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index df3171d..15f19a2 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -808,11 +808,18 @@ VFIOGroup *vfio_get_group(int groupid, AddressSpace *as)
> VFIOGroup *group;
> char path[32];
> struct vfio_group_status status = { .argsz = sizeof(status) };
> + int ret;
>
> QLIST_FOREACH(group, &vfio_group_list, next) {
> if (group->groupid == groupid) {
> /* Found it. Now is it already in the right context? */
> - if (group->container->space->as == as) {
> + if (as && !group->container->space->as) {
> + ret = vfio_register_container_listener(group->container, as);
> + if (ret) {
> + return NULL;
> + }
> + }
> + if (!as || group->container->space->as == as) {
> group->ref++;
> return group;
> } else {
No, this is broken. Look further down where we call
vfio_connect_container(group, as). With as=NULL, that gives us a new
VFIOAddressSpace with space.as=NULL. Then we walk the list of
containers attached to that as, which is of course empty, so we create a
new container for the device. If we have more than one group attached
this way, they share this container. What happens latter if one or more
of those devices are attached to the VM? In the best case we setup a
memory listener for this container, but that breaks vfio locked memory
accounting because previously they would have shared a container and now
we have two separate containers for them. But to make things worse, any
other groups that were attached to this space.as=NULL container are
forced to share this new as, so it's impossible to add them to a
separate as.
So, this won't work. I also don't like the side-effect of taking
implicit ownership of groups. IOMMU groups are challenging enough and
changing the rules to care about not only groups but shared bus
dependencies seems like a support nightmare.
I keep trying to think how we could reduce the scope to make AER support
more manageable. Should we simply require that all device affected by a
bus reset are assigned to the VM? To do that we'd need to revert to
your machine-init-done check for compliance. But then what becomes of
hotplug? As soon as we hot-remove one of those devices, AER is broken
and we can't hot-add device individually and maintain support.
If we limit support to single function endpoints, our problems go away,
but the number of devices we could enable AER for is nearly zero. If we
include multi-function, then hotplug is a significant issue since each
function is individually hot-pluggable. But we can solve that by
requiring AER devices to have a 1:1 function mapping to the VM and
requiring all the functions of the slot to be assigned to the VM.
Hot-remove then works automatically since that's done on a slot basis.
Hot-add is not possible since QEMU doesn't support hot-add of
multi-function devices, but that's a problem that needs to be solved
anyway. Thanks,
Alex
next prev parent reply other threads:[~2015-06-18 16:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 8:10 [Qemu-devel] [RFC v10 00/19] vfio-pci: pass the aer error to guest Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 01/19] vfio: extract vfio_get_hot_reset_info as a single function Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 02/19] vfio: squeeze out vfio_pci_do_hot_reset for support bus reset Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 03/19] pcie: modify the capability size assert Chen Fan
2015-06-17 9:43 ` Marcel Apfelbaum
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 04/19] vfio: make the 4 bytes aligned for capability size Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 05/19] vfio: add pcie extanded capability support Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 06/19] aer: impove pcie_aer_init to support vfio device Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 07/19] vfio: add aer support for " Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 08/19] vfio: add ref for group to support own affected groups Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 09/19] vfio: extract vfio_register_container_listener from vfio_connect_container Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 10/19] vfio: improve vfio_get_group to support adding as is NULL Chen Fan
2015-06-18 16:41 ` Alex Williamson [this message]
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 11/19] get all affected groups for each device support aer Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 12/19] vfio: add check host bus reset is support or not Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 13/19] pci: add bus reset_notifiers callbacks for host bus reset Chen Fan
2015-06-16 10:20 ` Michael S. Tsirkin
2015-06-17 1:41 ` Chen Fan
2015-06-17 6:47 ` Michael S. Tsirkin
2015-06-17 15:19 ` Alex Williamson
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 14/19] vfio: add sec_bus_reset notifier to notify physical bus reset is needed Chen Fan
2015-06-16 8:10 ` [Qemu-devel] [RFC v10 15/19] vfio: improve vfio_pci_hot_reset to support more case Chen Fan
2015-06-16 8:11 ` [Qemu-devel] [RFC v10 16/19] vfio: do hot bus reset when do virtual secondary bus reset Chen Fan
2015-06-16 8:11 ` [Qemu-devel] [RFC v10 17/19] pcie_aer: expose pcie_aer_msg() interface Chen Fan
2015-06-17 9:46 ` Marcel Apfelbaum
2015-06-16 8:11 ` [Qemu-devel] [RFC v10 18/19] vfio-pci: pass the aer error to guest Chen Fan
2015-06-16 8:11 ` [Qemu-devel] [RFC v10 19/19] vfio: add 'aer' property to expose aercap Chen Fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1434645677.3700.60.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=chen.fan.fnst@cn.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.