On Fri, Oct 15, 2021 at 10:13:24AM +0200, Jan Beulich wrote: > On 15.10.2021 09:37, Bertrand Marquis wrote: > >> On 15 Oct 2021, at 07:29, Jan Beulich <jbeul...@suse.com> wrote: > >> On 14.10.2021 19:09, Bertrand Marquis wrote: > >>>> On 14 Oct 2021, at 17:06, Jan Beulich <jbeul...@suse.com> wrote: > >>>> On 14.10.2021 16:49, Bertrand Marquis wrote: > >>>>> @@ -305,7 +291,7 @@ static int vpci_portio_read(const struct > >>>>> hvm_io_handler *handler, > >>>>> > >>>>> reg = hvm_pci_decode_addr(cf8, addr, &sbdf); > >>>>> > >>>>> - if ( !vpci_access_allowed(reg, size) ) > >>>>> + if ( !vpci_ecam_access_allowed(reg, size) ) > >>>>> return X86EMUL_OKAY; > >>>>> > >>>>> *data = vpci_read(sbdf, reg, size); > >>>>> @@ -335,7 +321,7 @@ static int vpci_portio_write(const struct > >>>>> hvm_io_handler *handler, > >>>>> > >>>>> reg = hvm_pci_decode_addr(cf8, addr, &sbdf); > >>>>> > >>>>> - if ( !vpci_access_allowed(reg, size) ) > >>>>> + if ( !vpci_ecam_access_allowed(reg, size) ) > >>>>> return X86EMUL_OKAY; > >>>>> > >>>>> vpci_write(sbdf, reg, size, data); > >>>> > >>>> Why would port I/O functions call an ECAM helper? And in how far is > >>>> that helper actually ECAM-specific? > >>> > >>> The function was global before. > >> > >> I'm not objecting to the function being global, but to the "ecam" in > >> its name. > > > > Adding ecam in the name was a request from Roger. > > This is just a consequence of this. > > Roger - did you have in mind the uses here when asking for the addition > of "ecam"?
I didn't realize it was also used by the IO ports accessors. Strictly speaking 64bit accesses (lenght == 8) shouldn't be possible/allowed from IO ports, but that's a red herring. Thanks, Roger.
