Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>]

On 27.10.21 12:23, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 09:04:39AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 27.10.21 11:59, Roger Pau Monné wrote:
>>> On Wed, Oct 27, 2021 at 11:25:33AM +0300, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
>>>> enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as
>>>> the base address may not be aligned in the way that the translation
>>>> always work.
>>> I think I've already raised this during review [0]. But this is only a
>>> problem if you change the current value of GUEST_VPCI_ECAM_BASE
>>> AFAICT, as the current value has bits [0,27] clear.
>> Exactly, so we were just lucky not to hit this before
>>> I assume this is a problem for the hardware domain that needs to trap
>>> random base addresses as present on hardware, but that code hasn't
>>> been committed yet.
>> Yes, I am facing this on the real HW when Dom0's access is trapped
>> and the base is not taken into account. So, I have a patch for the
>> future upstream which subtracts the relevant base from the gpa,
>> e.g. either GUEST_VPCI_ECAM_BASE or bridge->cfg->phys_addr
>>> If that's indeed the case, please expand the commit message to contain
>>> this information.
>> I can only mention about "the current value of GUEST_VPCI_ECAM_BASE
>> AFAICT, as the current value has bits [0,27] clear" as of now because
>> Dom0 traps are not yet there.
> Indeed, I would rather mention both cases, ie:
>
> "This change is not strictly required given the current value of
> GUEST_VPCI_ECAM_BASE which has bits 0 to 27 clear, but could cause
> issues if such value is changed, or when handlers for dom0 ECAM
> regions are added as those will be mapped over existing hardware
> regions that could use non-aligned base addresses."
Sounds good, will add
>
> Regards, Roger.
Thank you,
Oleksandr