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
