[PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device

Vivek Kasireddy posted 8 patches 2 weeks, 3 days ago
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, "Alex Bennée" <alex.bennee@linaro.org>, Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>, Dmitry Osipenko <dmitry.osipenko@collabora.com>, Alex Williamson <alex@shazbot.org>, "Cédric Le Goater" <clg@redhat.com>
There is a newer version of this series
[PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Vivek Kasireddy 2 weeks, 3 days ago
If the Guest provides a DMA address that is associated with a ram
device (such as a PCI device region and not its system memory),
then we can obtain the hva (host virtual address) by invoking
address_space_translate() followed by memory_region_get_ram_ptr().

This is because the ram device's address space is not accessible
to virtio-gpu directly and hence dma_memory_map() cannot be used.
Therefore, we first need to identify the memory region associated
with the DMA address and add the offset to the pointer returned
from memory_region_get_ram_ptr() to obtain the host address.

Note that we take a reference on the memory region but we would
still eventually call dma_memory_unmap() (to unref the mr).

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Alex Bennée <alex.bennee@linaro.org>
Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
 hw/display/virtio-gpu.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 3d58cebf4b..9930a21317 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -798,6 +798,23 @@ static void virtio_gpu_set_scanout_blob(VirtIOGPU *g,
                               &fb, res, &ss.r, &cmd->error);
 }
 
+static void *virtio_gpu_dma_memory_map(VirtIOGPU *g,
+                                       struct virtio_gpu_ctrl_command *cmd,
+                                       uint64_t a, hwaddr *len)
+{
+    MemoryRegion *mr;
+    hwaddr xlat;
+
+    mr = address_space_translate(VIRTIO_DEVICE(g)->dma_as, a, &xlat, len,
+                                 DMA_DIRECTION_TO_DEVICE,
+                                 MEMTXATTRS_UNSPECIFIED);
+    if (memory_region_is_ram(mr)) {
+        memory_region_ref(mr);
+        return memory_region_get_ram_ptr(mr) + xlat;
+    }
+    return NULL;
+}
+
 int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
                                   uint32_t nr_entries, uint32_t offset,
                                   struct virtio_gpu_ctrl_command *cmd,
@@ -839,9 +856,7 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
 
         do {
             len = l;
-            map = dma_memory_map(VIRTIO_DEVICE(g)->dma_as, a, &len,
-                                 DMA_DIRECTION_TO_DEVICE,
-                                 MEMTXATTRS_UNSPECIFIED);
+            map = virtio_gpu_dma_memory_map(g, cmd, a, &len);
             if (!map) {
                 qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map MMIO memory for"
                               " element %d\n", __func__, e);
-- 
2.50.1


Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Akihiko Odaki 2 weeks, 3 days ago
On 2026/01/23 15:17, Vivek Kasireddy wrote:
> If the Guest provides a DMA address that is associated with a ram
> device (such as a PCI device region and not its system memory),
> then we can obtain the hva (host virtual address) by invoking
> address_space_translate() followed by memory_region_get_ram_ptr().
> 
> This is because the ram device's address space is not accessible
> to virtio-gpu directly and hence dma_memory_map() cannot be used.

This description is a bit confusing.

The first problem is with the phrase "the ram device's address space". 
The address space we are dealing with is always 
VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region, not 
address space.

The second problem is that it says the ram device's memory region is not 
directly accessible. It is usually true, but here we are directly 
accessing it anyway because the guest knows how to do so.

Regards,
Akihiko Odaki

> Therefore, we first need to identify the memory region associated
> with the DMA address and add the offset to the pointer returned
> from memory_region_get_ram_ptr() to obtain the host address.
> 
> Note that we take a reference on the memory region but we would
> still eventually call dma_memory_unmap() (to unref the mr).
> 
> Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> Cc: Alex Bennée <alex.bennee@linaro.org>
> Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Cc: Alex Williamson <alex@shazbot.org>
> Cc: Cédric Le Goater <clg@redhat.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>   hw/display/virtio-gpu.c | 21 ++++++++++++++++++---
>   1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> index 3d58cebf4b..9930a21317 100644
> --- a/hw/display/virtio-gpu.c
> +++ b/hw/display/virtio-gpu.c
> @@ -798,6 +798,23 @@ static void virtio_gpu_set_scanout_blob(VirtIOGPU *g,
>                                 &fb, res, &ss.r, &cmd->error);
>   }
>   
> +static void *virtio_gpu_dma_memory_map(VirtIOGPU *g,
> +                                       struct virtio_gpu_ctrl_command *cmd,
> +                                       uint64_t a, hwaddr *len)
> +{
> +    MemoryRegion *mr;
> +    hwaddr xlat;
> +
> +    mr = address_space_translate(VIRTIO_DEVICE(g)->dma_as, a, &xlat, len,
> +                                 DMA_DIRECTION_TO_DEVICE,
> +                                 MEMTXATTRS_UNSPECIFIED);
> +    if (memory_region_is_ram(mr)) {
> +        memory_region_ref(mr);
> +        return memory_region_get_ram_ptr(mr) + xlat;
> +    }
> +    return NULL;
> +}
> +
>   int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
>                                     uint32_t nr_entries, uint32_t offset,
>                                     struct virtio_gpu_ctrl_command *cmd,
> @@ -839,9 +856,7 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
>   
>           do {
>               len = l;
> -            map = dma_memory_map(VIRTIO_DEVICE(g)->dma_as, a, &len,
> -                                 DMA_DIRECTION_TO_DEVICE,
> -                                 MEMTXATTRS_UNSPECIFIED);
> +            map = virtio_gpu_dma_memory_map(g, cmd, a, &len);
>               if (!map) {
>                   qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map MMIO memory for"
>                                 " element %d\n", __func__, e);


RE: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Kasireddy, Vivek 1 week, 6 days ago
Hi Akihiko,

> Subject: Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr
> associated with a ram device
> 
> On 2026/01/23 15:17, Vivek Kasireddy wrote:
> > If the Guest provides a DMA address that is associated with a ram
> > device (such as a PCI device region and not its system memory),
> > then we can obtain the hva (host virtual address) by invoking
> > address_space_translate() followed by memory_region_get_ram_ptr().
> >
> > This is because the ram device's address space is not accessible
> > to virtio-gpu directly and hence dma_memory_map() cannot be used.
> 
> This description is a bit confusing.
I agree; the description does seem ambiguous.

> 
> The first problem is with the phrase "the ram device's address space".
> The address space we are dealing with is always
> VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region, not
> address space.
> 
> The second problem is that it says the ram device's memory region is not
> directly accessible. It is usually true, but here we are directly
> accessing it anyway because the guest knows how to do so.
Does this look better:
   "virtio-gpu: Find hva for Guest's DMA addr associated with a ram device

    If the Guest provides a DMA address that is associated with a ram
    device (such as a PCI device region and not its system memory),
    then we can obtain the hva (host virtual address) by invoking
    address_space_translate() followed by memory_region_get_ram_ptr().

    We cannot use dma_memory_map() in this case to get the hva because
    it can only be used with addresses that are associated with the
    system (or physical) memory region. Therefore, in order to handle
    addresses associated with ram devices, we need to use the
    address_space_translate() API to first identify the right memory
    region and the appropriate offset within that region and then use
    memory_region_get_ram_ptr() to get the hva. This approach also
    works for addresses associated with the system memory region.

    Note that, although we take an explicit reference on the memory
    region, we would still rely on dma_memory_unmap() to drop that
    reference when the dma mapping is eventually unmapped."

Thanks,
Vivek

> 
> Regards,
> Akihiko Odaki
> 
> > Therefore, we first need to identify the memory region associated
> > with the DMA address and add the offset to the pointer returned
> > from memory_region_get_ram_ptr() to obtain the host address.
> >
> > Note that we take a reference on the memory region but we would
> > still eventually call dma_memory_unmap() (to unref the mr).
> >
> > Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Cc: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Cc: Alex Williamson <alex@shazbot.org>
> > Cc: Cédric Le Goater <clg@redhat.com>
> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> > ---
> >   hw/display/virtio-gpu.c | 21 ++++++++++++++++++---
> >   1 file changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> > index 3d58cebf4b..9930a21317 100644
> > --- a/hw/display/virtio-gpu.c
> > +++ b/hw/display/virtio-gpu.c
> > @@ -798,6 +798,23 @@ static void
> virtio_gpu_set_scanout_blob(VirtIOGPU *g,
> >                                 &fb, res, &ss.r, &cmd->error);
> >   }
> >
> > +static void *virtio_gpu_dma_memory_map(VirtIOGPU *g,
> > +                                       struct virtio_gpu_ctrl_command *cmd,
> > +                                       uint64_t a, hwaddr *len)
> > +{
> > +    MemoryRegion *mr;
> > +    hwaddr xlat;
> > +
> > +    mr = address_space_translate(VIRTIO_DEVICE(g)->dma_as, a, &xlat,
> len,
> > +                                 DMA_DIRECTION_TO_DEVICE,
> > +                                 MEMTXATTRS_UNSPECIFIED);
> > +    if (memory_region_is_ram(mr)) {
> > +        memory_region_ref(mr);
> > +        return memory_region_get_ram_ptr(mr) + xlat;
> > +    }
> > +    return NULL;
> > +}
> > +
> >   int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
> >                                     uint32_t nr_entries, uint32_t offset,
> >                                     struct virtio_gpu_ctrl_command *cmd,
> > @@ -839,9 +856,7 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU
> *g,
> >
> >           do {
> >               len = l;
> > -            map = dma_memory_map(VIRTIO_DEVICE(g)->dma_as, a, &len,
> > -                                 DMA_DIRECTION_TO_DEVICE,
> > -                                 MEMTXATTRS_UNSPECIFIED);
> > +            map = virtio_gpu_dma_memory_map(g, cmd, a, &len);
> >               if (!map) {
> >                   qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map
> MMIO memory for"
> >                                 " element %d\n", __func__, e);
Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Akihiko Odaki 1 week, 5 days ago
On 2026/01/27 15:07, Kasireddy, Vivek wrote:
> Hi Akihiko,
> 
>> Subject: Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr
>> associated with a ram device
>>
>> On 2026/01/23 15:17, Vivek Kasireddy wrote:
>>> If the Guest provides a DMA address that is associated with a ram
>>> device (such as a PCI device region and not its system memory),
>>> then we can obtain the hva (host virtual address) by invoking
>>> address_space_translate() followed by memory_region_get_ram_ptr().
>>>
>>> This is because the ram device's address space is not accessible
>>> to virtio-gpu directly and hence dma_memory_map() cannot be used.
>>
>> This description is a bit confusing.
> I agree; the description does seem ambiguous.
> 
>>
>> The first problem is with the phrase "the ram device's address space".
>> The address space we are dealing with is always
>> VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region, not
>> address space.
>>
>> The second problem is that it says the ram device's memory region is not
>> directly accessible. It is usually true, but here we are directly
>> accessing it anyway because the guest knows how to do so.
> Does this look better:
>     "virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
> 
>      If the Guest provides a DMA address that is associated with a ram
>      device (such as a PCI device region and not its system memory),
>      then we can obtain the hva (host virtual address) by invoking
>      address_space_translate() followed by memory_region_get_ram_ptr().
> 
>      We cannot use dma_memory_map() in this case to get the hva because
>      it can only be used with addresses that are associated with the
>      system (or physical) memory region. Therefore, in order to handle
>      addresses associated with ram devices, we need to use the
>      address_space_translate() API to first identify the right memory
>      region and the appropriate offset within that region and then use
>      memory_region_get_ram_ptr() to get the hva. This approach also
>      works for addresses associated with the system memory region.

Sorry but I don't think it's improved much. It still contains a phrase 
not well-established ("system (or physical) memory region").

The description of what the logic does is expanded, but it's not really 
useful; it says the logic is to add the offset and the retrieved 
pointer, but it's obvious if you read the code. So let's focus on "why" 
the logic is added instead of what the logic does.

Below is my analysis on "why":
First, let's stick to the phrase "direct access"; its meaning is 
established in include/system/memory.h.

With the concept of "direct access", the underlying problem being solved 
can be understood as follows: dma_memory_map() automatically determines 
what is directly accessible, and VFIO devices are considered not 
directly accessible because such accesses may be part of MMIO. But 
virtio-gpu is not doing MMIO, which leads to a disagreement with the 
function and virtio-gpu.

Regards,
Akihiko Odaki
RE: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Kasireddy, Vivek 1 week, 4 days ago
Hi Akihiko,

> Subject: Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr
> associated with a ram device
> 
> >>
> >> On 2026/01/23 15:17, Vivek Kasireddy wrote:
> >>> If the Guest provides a DMA address that is associated with a ram
> >>> device (such as a PCI device region and not its system memory),
> >>> then we can obtain the hva (host virtual address) by invoking
> >>> address_space_translate() followed by
> memory_region_get_ram_ptr().
> >>>
> >>> This is because the ram device's address space is not accessible
> >>> to virtio-gpu directly and hence dma_memory_map() cannot be used.
> >>
> >> This description is a bit confusing.
> > I agree; the description does seem ambiguous.
> >
> >>
> >> The first problem is with the phrase "the ram device's address space".
> >> The address space we are dealing with is always
> >> VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region, not
> >> address space.
> >>
> >> The second problem is that it says the ram device's memory region is
> not
> >> directly accessible. It is usually true, but here we are directly
> >> accessing it anyway because the guest knows how to do so.
> > Does this look better:
> >     "virtio-gpu: Find hva for Guest's DMA addr associated with a ram
> device
> >
> >      If the Guest provides a DMA address that is associated with a ram
> >      device (such as a PCI device region and not its system memory),
> >      then we can obtain the hva (host virtual address) by invoking
> >      address_space_translate() followed by
> memory_region_get_ram_ptr().
> >
> >      We cannot use dma_memory_map() in this case to get the hva
> because
> >      it can only be used with addresses that are associated with the
> >      system (or physical) memory region. Therefore, in order to handle
> >      addresses associated with ram devices, we need to use the
> >      address_space_translate() API to first identify the right memory
> >      region and the appropriate offset within that region and then use
> >      memory_region_get_ram_ptr() to get the hva. This approach also
> >      works for addresses associated with the system memory region.
> 
> Sorry but I don't think it's improved much. It still contains a phrase
> not well-established ("system (or physical) memory region").
I think it is well-established given this line in include/system/memory.h:
/* address_space_map: map a physical memory region into a host virtual address
and considering the fact that address_space_map() is called by
dma_memory_map().

> 
> The description of what the logic does is expanded, but it's not really
> useful; it says the logic is to add the offset and the retrieved
> pointer, but it's obvious if you read the code. So let's focus on "why"
> the logic is added instead of what the logic does.
> 
> Below is my analysis on "why":
> First, let's stick to the phrase "direct access"; its meaning is
> established in include/system/memory.h.
> 
> With the concept of "direct access", the underlying problem being solved
> can be understood as follows: dma_memory_map() automatically
> determines
> what is directly accessible, and VFIO devices are considered not
> directly accessible because such accesses may be part of MMIO. But
> virtio-gpu is not doing MMIO, which leads to a disagreement with the
> function and virtio-gpu.
Here is another try:
    "virtio-gpu: Find hva for Guest's DMA addr associated with a ram device

    If the Guest provides a DMA address that is associated with a ram
    device (such as a VFIO PCI device region and not its system memory),
    then we can obtain the hva (host virtual address) by invoking
    address_space_translate() followed by memory_region_get_ram_ptr().

    We cannot use dma_memory_map() in this case to get the hva because
    it can only be used with addresses that are associated with memory
    regions that support direct access. Since VFIO device regions are
    not considered directly accessible (because they are mostly MMIO based),
    dma_memory_map() would fail to return the hva for such addresses
    when invoked by virtio-gpu.

    Therefore, in order to handle addresses associated with VFIO devices,
    we need to use the address_space_translate() API to first identify
    the right memory region and the appropriate offset within that
    region and then use memory_region_get_ram_ptr() to get the hva.
    This approach also works for addresses associated with the system
    memory region.

    Note that, although we take an explicit reference on the memory
    region, we would still rely on dma_memory_unmap() to drop that
    reference when the dma mapping is eventually unmapped."

Thanks,
Vivek


> 
> Regards,
> Akihiko Odaki
Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Akihiko Odaki 1 week, 4 days ago
On 2026/01/29 15:44, Kasireddy, Vivek wrote:
> Hi Akihiko,
> 
>> Subject: Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr
>> associated with a ram device
>>
>>>>
>>>> On 2026/01/23 15:17, Vivek Kasireddy wrote:
>>>>> If the Guest provides a DMA address that is associated with a ram
>>>>> device (such as a PCI device region and not its system memory),
>>>>> then we can obtain the hva (host virtual address) by invoking
>>>>> address_space_translate() followed by
>> memory_region_get_ram_ptr().
>>>>>
>>>>> This is because the ram device's address space is not accessible
>>>>> to virtio-gpu directly and hence dma_memory_map() cannot be used.
>>>>
>>>> This description is a bit confusing.
>>> I agree; the description does seem ambiguous.
>>>
>>>>
>>>> The first problem is with the phrase "the ram device's address space".
>>>> The address space we are dealing with is always
>>>> VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region, not
>>>> address space.
>>>>
>>>> The second problem is that it says the ram device's memory region is
>> not
>>>> directly accessible. It is usually true, but here we are directly
>>>> accessing it anyway because the guest knows how to do so.
>>> Does this look better:
>>>      "virtio-gpu: Find hva for Guest's DMA addr associated with a ram
>> device
>>>
>>>       If the Guest provides a DMA address that is associated with a ram
>>>       device (such as a PCI device region and not its system memory),
>>>       then we can obtain the hva (host virtual address) by invoking
>>>       address_space_translate() followed by
>> memory_region_get_ram_ptr().
>>>
>>>       We cannot use dma_memory_map() in this case to get the hva
>> because
>>>       it can only be used with addresses that are associated with the
>>>       system (or physical) memory region. Therefore, in order to handle
>>>       addresses associated with ram devices, we need to use the
>>>       address_space_translate() API to first identify the right memory
>>>       region and the appropriate offset within that region and then use
>>>       memory_region_get_ram_ptr() to get the hva. This approach also
>>>       works for addresses associated with the system memory region.
>>
>> Sorry but I don't think it's improved much. It still contains a phrase
>> not well-established ("system (or physical) memory region").
> I think it is well-established given this line in include/system/memory.h:
> /* address_space_map: map a physical memory region into a host virtual address
> and considering the fact that address_space_map() is called by
> dma_memory_map().

I guess not that particular phrase is wrong but the expression "it can 
only be used with addresses that are associated with the system (or 
physical) memory region" is not quite precise as whole.

address_space_map() or dma_memory_map() can actually be used with any 
memory region. It however creates a bounce buffer if not directly 
accessible.

> 
>>
>> The description of what the logic does is expanded, but it's not really
>> useful; it says the logic is to add the offset and the retrieved
>> pointer, but it's obvious if you read the code. So let's focus on "why"
>> the logic is added instead of what the logic does.
>>
>> Below is my analysis on "why":
>> First, let's stick to the phrase "direct access"; its meaning is
>> established in include/system/memory.h.
>>
>> With the concept of "direct access", the underlying problem being solved
>> can be understood as follows: dma_memory_map() automatically
>> determines
>> what is directly accessible, and VFIO devices are considered not
>> directly accessible because such accesses may be part of MMIO. But
>> virtio-gpu is not doing MMIO, which leads to a disagreement with the
>> function and virtio-gpu.
> Here is another try:
>      "virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
> 
>      If the Guest provides a DMA address that is associated with a ram
>      device (such as a VFIO PCI device region and not its system memory),
>      then we can obtain the hva (host virtual address) by invoking
>      address_space_translate() followed by memory_region_get_ram_ptr().
> 
>      We cannot use dma_memory_map() in this case to get the hva because
>      it can only be used with addresses that are associated with memory
>      regions that support direct access. Since VFIO device regions are
>      not considered directly accessible (because they are mostly MMIO based),
>      dma_memory_map() would fail to return the hva for such addresses
>      when invoked by virtio-gpu.
> 
>      Therefore, in order to handle addresses associated with VFIO devices,
>      we need to use the address_space_translate() API to first identify
>      the right memory region and the appropriate offset within that
>      region and then use memory_region_get_ram_ptr() to get the hva.
>      This approach also works for addresses associated with the system
>      memory region.
> 
>      Note that, although we take an explicit reference on the memory
>      region, we would still rely on dma_memory_unmap() to drop that
>      reference when the dma mapping is eventually unmapped."

This is better. Can you also address the inaccuracy of the statement "We 
cannot use dma_memory_map()..." which I noted above?

Regards,
Akihiko Odaki
RE: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Kasireddy, Vivek 1 week, 3 days ago
Hi Akihiko,

> Subject: Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr
> associated with a ram device
> >>>> On 2026/01/23 15:17, Vivek Kasireddy wrote:
> >>>>> If the Guest provides a DMA address that is associated with a ram
> >>>>> device (such as a PCI device region and not its system memory),
> >>>>> then we can obtain the hva (host virtual address) by invoking
> >>>>> address_space_translate() followed by
> >> memory_region_get_ram_ptr().
> >>>>>
> >>>>> This is because the ram device's address space is not accessible
> >>>>> to virtio-gpu directly and hence dma_memory_map() cannot be
> used.
> >>>>
> >>>> This description is a bit confusing.
> >>> I agree; the description does seem ambiguous.
> >>>
> >>>>
> >>>> The first problem is with the phrase "the ram device's address
> space".
> >>>> The address space we are dealing with is always
> >>>> VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region,
> not
> >>>> address space.
> >>>>
> >>>> The second problem is that it says the ram device's memory region is
> >> not
> >>>> directly accessible. It is usually true, but here we are directly
> >>>> accessing it anyway because the guest knows how to do so.
> >>> Does this look better:
> >>>      "virtio-gpu: Find hva for Guest's DMA addr associated with a ram
> >> device
> >>>
> >>>       If the Guest provides a DMA address that is associated with a ram
> >>>       device (such as a PCI device region and not its system memory),
> >>>       then we can obtain the hva (host virtual address) by invoking
> >>>       address_space_translate() followed by
> >> memory_region_get_ram_ptr().
> >>>
> >>>       We cannot use dma_memory_map() in this case to get the hva
> >> because
> >>>       it can only be used with addresses that are associated with the
> >>>       system (or physical) memory region. Therefore, in order to handle
> >>>       addresses associated with ram devices, we need to use the
> >>>       address_space_translate() API to first identify the right memory
> >>>       region and the appropriate offset within that region and then use
> >>>       memory_region_get_ram_ptr() to get the hva. This approach also
> >>>       works for addresses associated with the system memory region.
> >>
> >> Sorry but I don't think it's improved much. It still contains a phrase
> >> not well-established ("system (or physical) memory region").
> > I think it is well-established given this line in include/system/memory.h:
> > /* address_space_map: map a physical memory region into a host
> virtual address
> > and considering the fact that address_space_map() is called by
> > dma_memory_map().
> 
> I guess not that particular phrase is wrong but the expression "it can
> only be used with addresses that are associated with the system (or
> physical) memory region" is not quite precise as whole.
> 
> address_space_map() or dma_memory_map() can actually be used with
> any
> memory region. It however creates a bounce buffer if not directly
> accessible.
> 
> >
> >>
> >> The description of what the logic does is expanded, but it's not really
> >> useful; it says the logic is to add the offset and the retrieved
> >> pointer, but it's obvious if you read the code. So let's focus on "why"
> >> the logic is added instead of what the logic does.
> >>
> >> Below is my analysis on "why":
> >> First, let's stick to the phrase "direct access"; its meaning is
> >> established in include/system/memory.h.
> >>
> >> With the concept of "direct access", the underlying problem being
> solved
> >> can be understood as follows: dma_memory_map() automatically
> >> determines
> >> what is directly accessible, and VFIO devices are considered not
> >> directly accessible because such accesses may be part of MMIO. But
> >> virtio-gpu is not doing MMIO, which leads to a disagreement with the
> >> function and virtio-gpu.
> > Here is another try:
> >      "virtio-gpu: Find hva for Guest's DMA addr associated with a ram
> device
> >
> >      If the Guest provides a DMA address that is associated with a ram
> >      device (such as a VFIO PCI device region and not its system memory),
> >      then we can obtain the hva (host virtual address) by invoking
> >      address_space_translate() followed by
> memory_region_get_ram_ptr().
> >
> >      We cannot use dma_memory_map() in this case to get the hva
> because
> >      it can only be used with addresses that are associated with memory
> >      regions that support direct access. Since VFIO device regions are
> >      not considered directly accessible (because they are mostly MMIO
> based),
> >      dma_memory_map() would fail to return the hva for such addresses
> >      when invoked by virtio-gpu.
> >
> >      Therefore, in order to handle addresses associated with VFIO devices,
> >      we need to use the address_space_translate() API to first identify
> >      the right memory region and the appropriate offset within that
> >      region and then use memory_region_get_ram_ptr() to get the hva.
> >      This approach also works for addresses associated with the system
> >      memory region.
> >
> >      Note that, although we take an explicit reference on the memory
> >      region, we would still rely on dma_memory_unmap() to drop that
> >      reference when the dma mapping is eventually unmapped."
> 
> This is better. Can you also address the inaccuracy of the statement "We
> cannot use dma_memory_map()..." which I noted above?
Just to confirm if my rewrite matches with what you have in mind, here is
how I am planning to replace the 2nd paragraph that starts with
"We cannot use dma_memory_map()" in the next version:
So, instead of
  "We cannot use dma_memory_map() in this case to get the hva because
    it can only be used with addresses that are associated with memory
    regions that support direct access. Since VFIO device regions are
    not considered directly accessible (because they are mostly MMIO based),
    dma_memory_map() would fail to return the hva for such addresses
    when invoked by virtio-gpu."

I am going to replace it with
  "We cannot use dma_memory_map() because for memory regions that do
    not support direct access, it would create bounce buffers instead
    of returning the actual hva, which is not desirable here.
    And, since VFIO device regions are not considered directly accessible
    (because they are mostly MMIO based), virtio-gpu cannot invoke
    dma_memory_map() to obtain the hva in this case."

Thanks,
Vivek

> 
> Regards,
> Akihiko Odaki
Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
Posted by Akihiko Odaki 1 week, 3 days ago
On 2026/01/30 14:57, Kasireddy, Vivek wrote:
> Hi Akihiko,
> 
>> Subject: Re: [PATCH v4 2/8] virtio-gpu: Find hva for Guest's DMA addr
>> associated with a ram device
>>>>>> On 2026/01/23 15:17, Vivek Kasireddy wrote:
>>>>>>> If the Guest provides a DMA address that is associated with a ram
>>>>>>> device (such as a PCI device region and not its system memory),
>>>>>>> then we can obtain the hva (host virtual address) by invoking
>>>>>>> address_space_translate() followed by
>>>> memory_region_get_ram_ptr().
>>>>>>>
>>>>>>> This is because the ram device's address space is not accessible
>>>>>>> to virtio-gpu directly and hence dma_memory_map() cannot be
>> used.
>>>>>>
>>>>>> This description is a bit confusing.
>>>>> I agree; the description does seem ambiguous.
>>>>>
>>>>>>
>>>>>> The first problem is with the phrase "the ram device's address
>> space".
>>>>>> The address space we are dealing with is always
>>>>>> VIRTIO_DEVICE(g)->dma_as. More precisely it is a memory region,
>> not
>>>>>> address space.
>>>>>>
>>>>>> The second problem is that it says the ram device's memory region is
>>>> not
>>>>>> directly accessible. It is usually true, but here we are directly
>>>>>> accessing it anyway because the guest knows how to do so.
>>>>> Does this look better:
>>>>>       "virtio-gpu: Find hva for Guest's DMA addr associated with a ram
>>>> device
>>>>>
>>>>>        If the Guest provides a DMA address that is associated with a ram
>>>>>        device (such as a PCI device region and not its system memory),
>>>>>        then we can obtain the hva (host virtual address) by invoking
>>>>>        address_space_translate() followed by
>>>> memory_region_get_ram_ptr().
>>>>>
>>>>>        We cannot use dma_memory_map() in this case to get the hva
>>>> because
>>>>>        it can only be used with addresses that are associated with the
>>>>>        system (or physical) memory region. Therefore, in order to handle
>>>>>        addresses associated with ram devices, we need to use the
>>>>>        address_space_translate() API to first identify the right memory
>>>>>        region and the appropriate offset within that region and then use
>>>>>        memory_region_get_ram_ptr() to get the hva. This approach also
>>>>>        works for addresses associated with the system memory region.
>>>>
>>>> Sorry but I don't think it's improved much. It still contains a phrase
>>>> not well-established ("system (or physical) memory region").
>>> I think it is well-established given this line in include/system/memory.h:
>>> /* address_space_map: map a physical memory region into a host
>> virtual address
>>> and considering the fact that address_space_map() is called by
>>> dma_memory_map().
>>
>> I guess not that particular phrase is wrong but the expression "it can
>> only be used with addresses that are associated with the system (or
>> physical) memory region" is not quite precise as whole.
>>
>> address_space_map() or dma_memory_map() can actually be used with
>> any
>> memory region. It however creates a bounce buffer if not directly
>> accessible.
>>
>>>
>>>>
>>>> The description of what the logic does is expanded, but it's not really
>>>> useful; it says the logic is to add the offset and the retrieved
>>>> pointer, but it's obvious if you read the code. So let's focus on "why"
>>>> the logic is added instead of what the logic does.
>>>>
>>>> Below is my analysis on "why":
>>>> First, let's stick to the phrase "direct access"; its meaning is
>>>> established in include/system/memory.h.
>>>>
>>>> With the concept of "direct access", the underlying problem being
>> solved
>>>> can be understood as follows: dma_memory_map() automatically
>>>> determines
>>>> what is directly accessible, and VFIO devices are considered not
>>>> directly accessible because such accesses may be part of MMIO. But
>>>> virtio-gpu is not doing MMIO, which leads to a disagreement with the
>>>> function and virtio-gpu.
>>> Here is another try:
>>>       "virtio-gpu: Find hva for Guest's DMA addr associated with a ram
>> device
>>>
>>>       If the Guest provides a DMA address that is associated with a ram
>>>       device (such as a VFIO PCI device region and not its system memory),
>>>       then we can obtain the hva (host virtual address) by invoking
>>>       address_space_translate() followed by
>> memory_region_get_ram_ptr().
>>>
>>>       We cannot use dma_memory_map() in this case to get the hva
>> because
>>>       it can only be used with addresses that are associated with memory
>>>       regions that support direct access. Since VFIO device regions are
>>>       not considered directly accessible (because they are mostly MMIO
>> based),
>>>       dma_memory_map() would fail to return the hva for such addresses
>>>       when invoked by virtio-gpu.
>>>
>>>       Therefore, in order to handle addresses associated with VFIO devices,
>>>       we need to use the address_space_translate() API to first identify
>>>       the right memory region and the appropriate offset within that
>>>       region and then use memory_region_get_ram_ptr() to get the hva.
>>>       This approach also works for addresses associated with the system
>>>       memory region.
>>>
>>>       Note that, although we take an explicit reference on the memory
>>>       region, we would still rely on dma_memory_unmap() to drop that
>>>       reference when the dma mapping is eventually unmapped."
>>
>> This is better. Can you also address the inaccuracy of the statement "We
>> cannot use dma_memory_map()..." which I noted above?
> Just to confirm if my rewrite matches with what you have in mind, here is
> how I am planning to replace the 2nd paragraph that starts with
> "We cannot use dma_memory_map()" in the next version:
> So, instead of
>    "We cannot use dma_memory_map() in this case to get the hva because
>      it can only be used with addresses that are associated with memory
>      regions that support direct access. Since VFIO device regions are
>      not considered directly accessible (because they are mostly MMIO based),
>      dma_memory_map() would fail to return the hva for such addresses
>      when invoked by virtio-gpu."
> 
> I am going to replace it with
>    "We cannot use dma_memory_map() because for memory regions that do
>      not support direct access, it would create bounce buffers instead
>      of returning the actual hva, which is not desirable here.
>      And, since VFIO device regions are not considered directly accessible
>      (because they are mostly MMIO based), virtio-gpu cannot invoke
>      dma_memory_map() to obtain the hva in this case."

That looks good to me. Thanks you for improving this.

Regards,
Akihiko Odaki