On 3/18/19 10:30 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Mar 18, 2019 at 9:39 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>> On Mon, Mar 18, 2019 at 12:39 AM Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>>> On 3/17/19 10:12 AM, Wolfram Sang wrote:
>>>> On Sun, Mar 17, 2019 at 01:06:07AM +0100, marek.vasut@xxxxxxxxx wrote:
>>>>> From: Marek Vasut <marek.vasut+renesas@xxxxxxxxx>
>>>>>
>>>>> The MSI address can be 64bit. Switch the data type used to hold the
>>>>> result of virt_to_phys() to phys_addr_t to reflect it's properties
>>>>> correctly and program the top 32bits of PA into PCIEMSIAUR.
>>>>>
>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@xxxxxxxxx>
>>>>
>>>> Looks sane. Not being a PCI expert, I wonder: Were we just lucky to not
>>>> hit a 64-bit MSI address before?
>>>
>>> I wonder about that, virt_to_phys(__get_free_pages(GFP_KERNEL, 0)) would
>>> happily return 64bit address, but with the cards I tested (a few intel
>>> NICs [igb, e1000e], PCIe NVME SSDs and xHCI HCD), I am getting the MSIs
>>> either way.
>>
>> No doubt you would be receiving the MSIs, if you have RAM at the truncated
>> address, but wouldn't that cause memory corruption?
>>
>> Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
>>
>> When MSI support was added, only R-Car H1 and Gen2 were supported.
>> H1 doesn't have LPAE. Gen2 has, but it might have been disabled.
>
> Correction: as this is always mapped kernel memory, LPAE doesn't matter.
> So the bug matters for arm64 only.
And since the address is in the 0x7_3xxx_xxxx range on H3 S-XS, there is
no visible memory corruption. Joy ...
--
Best regards,
Marek Vasut
