On 3/18/19 10:30 AM, Geert Uytterhoeven wrote: > Hi Marek, > > On Mon, Mar 18, 2019 at 9:39 AM Geert Uytterhoeven <[email protected]> > wrote: >> On Mon, Mar 18, 2019 at 12:39 AM Marek Vasut <[email protected]> wrote: >>> On 3/17/19 10:12 AM, Wolfram Sang wrote: >>>> On Sun, Mar 17, 2019 at 01:06:07AM +0100, [email protected] wrote: >>>>> From: Marek Vasut <[email protected]> >>>>> >>>>> 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 <[email protected]> >>>> >>>> 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
