From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: virtio-dev@lists.oasis-open.org,
"David Hildenbrand" <david@redhat.com>,
jan.kiszka@siemens.com,
"Srivatsa Vaddagiri" <vatsa@codeaurora.org>,
"Azzedine Touzni" <atouzni@qti.qualcomm.com>,
"François Ozog" <francois.ozog@linaro.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Soni, Trilok" <tsoni@quicinc.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: [virtio-dev] Re: Constraining where a guest may allocate virtio accessible resources
Date: Fri, 19 Jun 2020 10:02:28 +0200 [thread overview]
Message-ID: <20200619080228.GA2530@myrica> (raw)
In-Reply-To: <87a7194kgt.fsf@linaro.org>
On Wed, Jun 17, 2020 at 06:31:15PM +0100, Alex Bennée wrote:
[...]
> Option 2 - Additional Platform Data
> ===================================
>
> This would be extending using something like device tree or ACPI tables
> which could define regions of memory that would inform the low level
> memory allocation routines where they could allocate from. There is
> already of the concept of "dma-ranges" in device tree which can be a
> per-device property which defines the region of space that is DMA
> coherent for a device.
They are regions that are accessible to a device for DMA, coherency is
described through other methods.
Thinking more about this, dma-ranges (and ACPI _DMA) don't exactly
describe what you need. They describe addressing limitation from a
bridge's perspective, for example from the PCI root complex. So there are
at least two issues:
1. They apply to the whole downstream bus, so you can't define per-device
DMA windows. Although with PCIe I suppose you could put one on each
downstream port.
2. More importantly, they only describe addressing limitations locally.
When the device directly accesses memory, it emits guest-physical
addresses (GPA) so you can use DMA ranges to describe which memory it
can access. However, if there is an IOMMU in between, the device emits
I/O virtual addresses (IOVA), which are translated by the IOMMU into
GPA. In this case the DMA ranges apply to the IOVA, and there doesn't
exist a way to describe limitations on the GPA.
There are other mechanisms describing addressing limitations such as
Intel's RMRR, but those also apply to IOVAs as far as I know.
Thanks,
Jean
>
> There is the question of how you tie regions declared here with the
> eventual instantiating of the VirtIO devices?
>
> For a fully distributed set of backends (one backend per device per
> worker VM) you would need several different regions. Would each region
> be tied to each device or just a set of areas the guest would allocate
> from in sequence?
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
prev parent reply other threads:[~2020-06-19 8:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 17:31 [virtio-dev] Constraining where a guest may allocate virtio accessible resources Alex Bennée
2020-06-17 18:01 ` [virtio-dev] " Jan Kiszka
2020-06-18 13:29 ` Stefan Hajnoczi
2020-06-18 13:59 ` Jan Kiszka
2020-06-18 14:52 ` Michael S. Tsirkin
2020-06-18 14:58 ` Jan Kiszka
2020-06-18 15:05 ` Michael S. Tsirkin
2020-06-18 15:22 ` Jan Kiszka
2020-06-18 15:29 ` Michael S. Tsirkin
2020-07-03 12:22 ` Stefan Hajnoczi
2020-06-18 13:53 ` Laszlo Ersek
2020-06-19 15:16 ` Alex Bennée
2020-06-18 7:30 ` Michael S. Tsirkin
2020-06-19 18:20 ` Alex Bennée
2020-06-18 13:25 ` Stefan Hajnoczi
2020-06-19 17:35 ` Alex Bennée
2020-07-03 13:14 ` Stefan Hajnoczi
2020-06-19 8:02 ` Jean-Philippe Brucker [this message]
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=20200619080228.GA2530@myrica \
--to=jean-philippe@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=atouzni@qti.qualcomm.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=francois.ozog@linaro.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jan.kiszka@siemens.com \
--cc=mst@redhat.com \
--cc=stefanha@redhat.com \
--cc=tsoni@quicinc.com \
--cc=vatsa@codeaurora.org \
--cc=virtio-dev@lists.oasis-open.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.