From: Alex Williamson <alex.williamson@redhat.com>
To: Thanos Makatos <thanos.makatos@nutanix.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Swapnil Ingle <swapnil.ingle@nutanix.com>,
Felipe Franciosi <felipe@nutanix.com>
Subject: Re: [Qemu-devel] QEMU tries to register to VFIO memory that is not RAM
Date: Fri, 31 May 2019 09:40:02 -0600 [thread overview]
Message-ID: <20190531094002.29030716@x1.home> (raw)
In-Reply-To: <MN2PR02MB620549D68EB53487C6FCF51F8B190@MN2PR02MB6205.namprd02.prod.outlook.com>
On Fri, 31 May 2019 15:28:07 +0000
Thanos Makatos <thanos.makatos@nutanix.com> wrote:
> > > When configuring device pass-through via VFIO to a VM, I noticed that
> > > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > > only RAM). That includes firmware regions like "pc.rom". Would a
> > > physical device ever need access to those?
> >
> > Probably not, but are those things not in the address space of the
> > device on a physical system?
>
> They are. I'm wondering whether it makes sense in a virtualized environment.
>
> >
> > > Am I missing something?
> >
> > Does this cause a problem?
>
> It does in my use case. We're experimenting with devices backed by another
> userspace application. We can configure QEMU to allocate shared memory
> (MAP_SHARED) for guest RAM (which we can register in the other process) but not
> for anything else.
>
> > It's not always easy to identify regions
> > that should not be mapped to a device, clearly we're not going to
> > create a whitelist based on the name of the region. Thanks,
>
> Indeed. Could we decide whether or not to register an address space with
> VFIO in a more intelligent manner? E.g. the following simplistic patch solves
> our problem:
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 4374cc6176..d9d3b1277a 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -430,6 +430,9 @@ static void vfio_listener_region_add(MemoryListener *listener,
> VFIOHostDMAWindow *hostwin;
> bool hostwin_found;
>
> + if (!section->mr->ram_device)
> + return;
> +
Nope, this would prevent IOMMU mapping of assigned device MMIO regions
which would prevent peer-to-peer DMA between assigned devices. Thanks,
Alex
next prev parent reply other threads:[~2019-05-31 15:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 13:32 [Qemu-devel] QEMU tries to register to VFIO memory that is not RAM Thanos Makatos
2019-05-31 14:37 ` Alex Williamson
2019-05-31 15:28 ` Thanos Makatos
2019-05-31 15:40 ` Alex Williamson [this message]
2019-06-04 16:08 ` Thanos Makatos
2019-06-14 15:56 ` Thanos Makatos
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=20190531094002.29030716@x1.home \
--to=alex.williamson@redhat.com \
--cc=felipe@nutanix.com \
--cc=qemu-devel@nongnu.org \
--cc=swapnil.ingle@nutanix.com \
--cc=thanos.makatos@nutanix.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).