Hi,
On 2/8/22 5:01 PM, Peter Maydell wrote:
> On Tue, 8 Feb 2022 at 15:56, Eric Auger <eric.au...@redhat.com> wrote:
>> Hi Peter,
>>
>> On 2/8/22 4:17 PM, Peter Maydell wrote:
>>> On Tue, 8 Feb 2022 at 15:08, Eric Auger <eric.au...@redhat.com> wrote:
>>>> Representing the CRB cmd/response buffer as a standard
>>>> RAM region causes some trouble when the device is used
>>>> with VFIO. Indeed VFIO attempts to DMA_MAP this region
>>>> as usual RAM but this latter does not have a valid page
>>>> size alignment causing such an error report:
>>>> "vfio_listener_region_add received unaligned region".
>>>> To allow VFIO to detect that failing dma mapping
>>>> this region is not an issue, let's use a ram_device
>>>> memory region type instead.
>>> This seems like VFIO's problem to me. There's nothing
>>> that guarantees alignment for memory regions at all,
>>> whether they're RAM, IO or anything else.
>> VFIO dma maps all the guest RAM.
> Well, it can if it likes, but "this is a RAM-backed MemoryRegion"
> doesn't imply "this is really guest actual RAM RAM", so if it's
> using that as its discriminator it should probably use something else.
> What is it actually trying to do here ?
We avoid outputting an error msg for something that is not an issue.
Besides, a little bit farther in hw/vfio/common.c
(vfio_listener_region_add) memory_region_is_ram_device() already is used
to avoid doing the dma_map for this type of region.
Originally, according to 21e00fa55f3 ("memory: Replace skip_dump flag
with "ram_device"), we had a skip_dump field in MemoryRegion which was
then turned into a whole ram_device type. Doing it differently would
mean that we would somehow introduce a new flag saying skip_dma_map?
Originally this was mainly meant for MMIO bars but I understood from
Alex that it could be sensible in that case too.
Thanks
Eric
>
> thanks
> -- PMM
>
