[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v9 13/16] xen/arm: translate virtual PCI bus topology for guests


  • To: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 22 Sep 2023 10:32:02 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9nvizTNSUCdJ8DtlHI8iR/2dZ0aIS4CCIf3a/DsWljM=; b=VwLf1vMPzcbWw7Y2SJXxp8yFCs2KG0A9b7Erl440FEdU5DxnXPbecC+IG5QkIoB60hHcjrj5DISYQd539kwE1EBP4Q1guU0cMCCZkKlSTMMUdEa4tKr6kBHf3E20w9yjSQEGPBpoxKTZHsbfP+Tr7dLVbU01LeaF8iifjOANJ1B1UeAnJv1lUzzsitWLHd2DO9pAlWaeQuW/hRB7c90WteWeIlD2PyyYxzZlheHSsJi9jWiw22tye91uuX50GvmrVa+dX+Rpj0YCj/BycJNwld/J8MrcCOHfKIAgXrJ8WLpeixyLyyyskpf6pZASGSl+stYVziE9RrnKQAE9TvOJlg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FNI1bLmhB410bRK96psfIweCWJt5sJpDRdVI6e0M7788vHg3FDaJhDVzwl6l8wt4BVWov6jPo8sxue0NvL7lYD+N670F174uAHDiHlNI9eCE9oPWQfzEGlL9SBUgOspJ0A8CIozkNtYXiRtikfRBlGzbRHNDu8hv9pXpmyzXmboaMW1q5SsopnZlY+ckG1fAlfuwTwdlBz3BaLSftUzIwG0p84FGwucOef+/2ip8dRwLecfKLKiRStdjvn2Fx06hjThRdmCfPREpfseT2e8C5Se5XH7vFU84T0S6R1gp0Djot5qjNDoddguPUC+/825FxycRGN20tgNavaASlpW73A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stewart Hildebrand <stewart.hildebrand@xxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
  • Delivery-date: Fri, 22 Sep 2023 08:32:21 +0000
  • Ironport-data: A9a23:a0f9HKOI+sWYFvjvrR0/lsFynXyQoLVcMsEvi/4bfWQNrUpxhWMDz DBOCGuPPPfZZWv9ed5xat/n9xlSvZHcnYQwHAto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CQ6jefQAOOkVIYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGjxSs/nrRC9H5qyo42tJ5AZmPJingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0vxYIUB18 6UIEj0yf0qm1r+5kKzlUMA506zPLOGzVG8ekldJ6GmDSM0AGNXESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+PVxvze7IA9ZidABNPLPfdOHX4NNl1uwr WPa5WXpRBodMbRzzBLcqCn93rOVwHiTtIQ6G7+eptN1smOv5HU3NTAsW1Hj8KfgsxvrMz5YA wlOksY0loAM80isQsj4TgePineOtR4BWPJdC+Q/rgqKz8L88wufQ2QJUDNFQNgnr9MtAywn0 EeTmNHkDiApt6eaIVqG6rqLpCmufygUKWMPbzUNSwct6tzv5oo0i3rnadJuE7W8iNHvLhj2z yqXtyg1h7gVjskj2r2y+BbMhDfEjoPSUgc/6wHTX2SkxgB0foioY8qv81ezxfRdKIeUSHGRs X5CnNKRhMgEAIuRjiWLTKMIFauw+veeGDTGhBhkGJxJyti203uqfIQV+zcnIk5sapwAYWWxP BCVvh5N7phOOnfsdbVwf4+6F8Uty+7nCMjhUffXKNFJZ/CdaTO6wc2nXmbIt0iFraTmufhX1 UuzGSp0MUsnNA==
  • Ironport-hdrordr: A9a23:w+OTY6uEgl3IjyYFqwUnjm/67skDeNV00zEX/kB9WHVpm62j+/ xG+c5x6faaslkssR0b9+xoWpPhfZqsz/9ICOAqVN/JMTUO01HYT72Kg7GSpgHIKmnT8fNcyL clU4UWMqyVMbGit7eZ3DWF
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Aug 29, 2023 at 11:19:46PM +0000, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> 
> There are three  originators for the PCI configuration space access:
> 1. The domain that owns physical host bridge: MMIO handlers are
> there so we can update vPCI register handlers with the values
> written by the hardware domain, e.g. physical view of the registers
> vs guest's view on the configuration space.
> 2. Guest access to the passed through PCI devices: we need to properly
> map virtual bus topology to the physical one, e.g. pass the configuration
> space access to the corresponding physical devices.
> 3. Emulated host PCI bridge access. It doesn't exist in the physical
> topology, e.g. it can't be mapped to some physical host bridge.
> So, all access to the host bridge itself needs to be trapped and
> emulated.
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> ---
> Since v9:
> - Commend about required lock replaced with ASSERT()
> - Style fixes
> - call to vpci_translate_virtual_device folded into vpci_sbdf_from_gpa
> Since v8:
> - locks moved out of vpci_translate_virtual_device()
> Since v6:
> - add pcidevs locking to vpci_translate_virtual_device
> - update wrt to the new locking scheme
> Since v5:
> - add vpci_translate_virtual_device for #ifndef CONFIG_HAS_VPCI_GUEST_SUPPORT
>   case to simplify ifdefery
> - add ASSERT(!is_hardware_domain(d)); to vpci_translate_virtual_device
> - reset output register on failed virtual SBDF translation
> Since v4:
> - indentation fixes
> - constify struct domain
> - updated commit message
> - updates to the new locking scheme (pdev->vpci_lock)
> Since v3:
> - revisit locking
> - move code to vpci.c
> Since v2:
>  - pass struct domain instead of struct vcpu
>  - constify arguments where possible
>  - gate relevant code with CONFIG_HAS_VPCI_GUEST_SUPPORT
> New in v2
> ---
>  xen/arch/arm/vpci.c     | 51 ++++++++++++++++++++++++++++++++---------
>  xen/drivers/vpci/vpci.c | 25 +++++++++++++++++++-
>  xen/include/xen/vpci.h  | 10 ++++++++
>  3 files changed, 74 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
> index 3bc4bb5508..58e2a20135 100644
> --- a/xen/arch/arm/vpci.c
> +++ b/xen/arch/arm/vpci.c
> @@ -7,31 +7,55 @@
>  
>  #include <asm/mmio.h>
>  
> -static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
> -                                     paddr_t gpa)
> +static bool_t vpci_sbdf_from_gpa(struct domain *d,

Plain bool please.

> +                                 const struct pci_host_bridge *bridge,
> +                                 paddr_t gpa, pci_sbdf_t *sbdf)
>  {
> -    pci_sbdf_t sbdf;
> +    ASSERT(sbdf);
>  
>      if ( bridge )
>      {
> -        sbdf.sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
> -        sbdf.seg = bridge->segment;
> -        sbdf.bus += bridge->cfg->busn_start;
> +        sbdf->sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
> +        sbdf->seg = bridge->segment;
> +        sbdf->bus += bridge->cfg->busn_start;
>      }
>      else
> -        sbdf.sbdf = VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
> -
> -    return sbdf;
> +    {
> +        bool translated;
> +
> +        /*
> +         * For the passed through devices we need to map their virtual SBDF
> +         * to the physical PCI device being passed through.
> +         */
> +        sbdf->sbdf = VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
> +        read_lock(&d->pci_lock);
> +        translated = vpci_translate_virtual_device(d, sbdf);
> +        read_unlock(&d->pci_lock);
> +
> +        if ( !translated )
> +        {
> +            return false;
> +        }
> +    }
> +    return true;

You could define translated = true at the top level of the function
and then set it to `translated = vpci_translate_virtual_device(d,
sbdf);` and have a single return in the function that returns
`translated`:

bool translated = true;

if ( bridge )
{
    ...
}
else
{
    ...
    translated = vpci_translate_virtual_device(d, sbdf);
    ...
}
return translated;

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.