[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 3/3] hw/usb/xhci: Always expect 'dma' link property to be
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v3 3/3] hw/usb/xhci: Always expect 'dma' link property to be set |
Date: |
Fri, 27 Aug 2021 14:13:56 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 8/27/21 1:03 PM, Mark Cave-Ayland wrote:
> On 27/08/2021 11:14, Peter Maydell wrote:
>
>> On Fri, 27 Aug 2021 at 10:14, Mark Cave-Ayland
>> <mark.cave-ayland@ilande.co.uk> wrote:
>>> Ah so the plan moving forward is to always have an explicit MR passed
>>> in for DMA use.
>>> Sorry if I missed that in earlier versions of the patchset, I'm still
>>> getting back up
>>> to speed on QEMU hacking.
>>>
>>> Was there a decision as to what the property name should be? I see
>>> "dma_mr" used
>>> quite a bit, and if there will be more patches to remove the
>>> system_memory default
>>> from other devices then it would be nice to try and use the same name
>>> everywhere.
>>
>> No, I don't think we have a convention; it might be nice to add one.
>> Currently a quick git grep for DEFINE_PROP_LINK and eyeballing of
>> the results shows that we have:
>>
>> "memory" x 7
>> "dram" x 4
>> "downstream" x 3
>> "dma-memory" x 3
>> "dma" x 2
>> "source-memory"
>> "dram-mr"
>> "ddr"
>> "ddr-ram"
>> "gic"
>> "cpc"
>> "port[N]"
>> "dma_mr"
>> "ahb-bus"
>> "system-memory"
>> "main-bus"
>>
>> This list includes all our TYPE_MEMORY_REGION link properties; a few
>> of these
>> are special-purpose, and reasonably have specialized names. 2 out of 3
>> users
>> of "downstream" are devices which pass on (or filter out) memory
>> transactions
>> from the CPU (tz-msc, tz-mpc), and I think that name makes sense there.
>> (The 3rd is pl080.c, which is a plain old DMA controller, and the naming
>> there is not so well-suited.)
>>
>> "memory" is mostly SoC and CPU objects taking a link to whatever they
>> should
>> have as the CPU's view of memory.
>>
>> I don't have a strong view on what we ought to try to standardize on,
>> except that I don't like the "_mr" or "-mr" suffix -- I don't think we
>> need to try to encode the type of the link property in the property name.
>>
>> It is probably reasonable to have different naming conventions for:
>> * SoC and CPU objects, which take a link to the MR which represents
>> the CPU/SoC's view of the outside world
>> * Endpoint devices which can be DMA masters and take a link giving
>> them their view of what they can DMA to
>> * filtering/control devices which take incoming transactions from
>> an upstream port, filter some and pass the rest through to a
>> downstream port
Which category fits IOMMUs?
>>
>> In pretty much all cases, these link properties are used only internally
>> to QEMU, so if we decide on a naming convention we can fairly easily
>> rename existing properties to match.
>
> I quite like "cpu-memory" for SoC/CPU objects and "dma-memory" for
> endpoint devices that can be DMA masters. Perhaps the last case is
> specialised enough that a convention there doesn't make sense?
So "iommu-memory"?
- [PATCH v3 1/3] hw/pci: Introduce pci_dma_memory_region() helper, (continued)