BTW, there is actually a bug with ATU configuration which will cause IO access failure, and we need to apply an additional patch (this patch is generated after PCI host bridge patch series) as attached to fix this. Regards, Heyi On Tue, Apr 17, 2018 at 09:20:44AM +0800, Guo Heyi wrote: > Hi Ard, > > I tested mm -io on D05, for root bridge 4 with CPU IO address starting from > 0x8_abff0000, and it worked; both mm -io 0x8abff0000 and mm 0x8abff0000 provided > the same output. It seems there is no other limit for 64bit IO address after you > fixed the issue in EFI shell mm command. > > Thanks and regards, > > Heyi > > On Mon, Apr 16, 2018 at 09:57:09PM +0800, Guo Heyi wrote: > > Thanks, I will test mm command and let you know the result. > > > > Regards, > > > > Heyi > > > > On Fri, Apr 13, 2018 at 09:19:53AM +0200, Ard Biesheuvel wrote: > > > On 13 April 2018 at 04:05, Guo Heyi wrote: > > > > Hi Ard, > > > > > > > > Any comments? > > > > > > > > > > Apologies for the delay. I have been travelling and am behind on email. > > > > > > > Anyway we can modify the code if you insist on using an intermediate CPU IO > > > > address space. > > > > > > > > > > I have not made up my mind yet, to be honest. I agree there is a > > > certain elegance to merging both translations, but I am concerned that > > > existing EDK2 code may deal poorly with I/O addresses that require > > > more than 32 bits to express. > > > > > > Did you try the mm command in the shell for instance? As you know, I > > > recently removed an artificial address range limit there, but I wonder > > > if it uses 64-bit variables for I/O ports.