On 18.10.2021 16:37, Oleksandr Andrushchenko wrote: > > > On 18.10.21 17:19, Jan Beulich wrote: >> On 18.10.2021 16:07, Oleksandr Andrushchenko wrote: >>> On 18.10.21 13:29, Jan Beulich wrote: >>>> On 18.10.2021 12:11, Bertrand Marquis wrote: >>>>>> On 18 Oct 2021, at 08:47, Jan Beulich <[email protected]> wrote: >>>>>> On 15.10.2021 18:51, Bertrand Marquis wrote: >>>>>>> --- /dev/null >>>>>>> +++ b/xen/arch/arm/vpci.c >>>>>>> @@ -0,0 +1,77 @@ >>>>>>> +/* >>>>>>> + * xen/arch/arm/vpci.c >>>>>>> + * >>>>>>> + * This program is free software; you can redistribute it and/or modify >>>>>>> + * it under the terms of the GNU General Public License as published by >>>>>>> + * the Free Software Foundation; either version 2 of the License, or >>>>>>> + * (at your option) any later version. >>>>>>> + * >>>>>>> + * This program is distributed in the hope that it will be useful, >>>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>>>>> + * GNU General Public License for more details. >>>>>>> + */ >>>>>>> +#include <xen/sched.h> >>>>>>> +#include <xen/vpci.h> >>>>>>> + >>>>>>> +#include <asm/mmio.h> >>>>>>> + >>>>>>> +static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info, >>>>>>> + register_t *r, void *p) >>>>>>> +{ >>>>>>> + pci_sbdf_t sbdf; >>>>>>> + /* data is needed to prevent a pointer cast on 32bit */ >>>>>>> + unsigned long data; >>>>>>> + >>>>>>> + /* We ignore segment part and always handle segment 0 */ >>>>>>> + sbdf.sbdf = VPCI_ECAM_BDF(info->gpa); >>>>>>> + >>>>>>> + if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa), >>>>>>> + 1U << info->dabt.size, &data) ) >>>>>>> + { >>>>>> Here it is quite clear that the SBDF you pass into vpci_ecam_read() is >>>>>> the virtual one. The function then calls vpci_read(), which in turn >>>>>> will call vpci_read_hw() in a number of situations (first and foremost >>>>>> whenever pci_get_pdev_by_domain() returns NULL). That function as well >>>>>> as pci_get_pdev_by_domain() use the passed in SBDF as if it was a >>>>>> physical one; I'm unable to spot any translation. Yet I do recall >>>>>> seeing assignment of a virtual device and function number somewhere >>>>>> (perhaps another of the related series), so the model also doesn't >>>>>> look to assume 1:1 mapping of SBDF. >>>>> This question was answered by Oleksandr I think. >>>> Yes; I continue to be sure though that I saw devfn allocation logic in >>>> one of the many patches that are related here. And I'm relatively sure >>>> that there no adjustment to logic here was made (but since it's hard >>>> to pick the right patch out of the huge pile without knowing its title, >>>> I can't reasonably go check). >>> Offtop: I was somehow dropped from the Cc.. >>> >>> Please see: >>> >>> [PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology >>> [PATCH v3 11/11] xen/arm: Translate virtual PCI bus topology for guests >>> >>> [1] >>> https://urldefense.com/v3/__https://patchwork.kernel.org/project/xen-devel/list/?series=555481__;!!GF_29dbcQIUBPA!mM8A39p8nk4UMK3YeKMMW9ua9BHj1UOWzaQcyx7G46YPdudxMpD3huqZfih0Uc8S-GyWXD_mPg$ >>> [patchwork[.]kernel[.]org] >> Ah yes, this way I can find them in my mailbox. And indeed - no translation >> from virtual to physical SBDF on the config space read/write paths afaics. > There are translations for both read and write [2] such as: > > + /* > + * For the passed through devices we need to map their virtual SBDF > + * to the physical PCI device being passed through. > + */ > + if ( priv->is_virt_ecam && !pci_translate_virtual_device(v->domain, > &sbdf) ) > + return 1; > +
Oh, that's before you even call vpci_read(). I would have expected this to live in common vPCI code ... Jan
