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

Re: [PATCH v3 03/11] vpci/header: Move register assignments from init_bars


  • To: Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 13 Oct 2021 15:51:35 +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=znmL2VsZyswrFXo+HvBQ3H9BhIB3br/XyfI/1dG6drc=; b=iDNk6DIBinD8rjD0rnISProp39A6t/TzBKPe5YmlYSHMX7UxFSftdUJzjRh9Ns8MIgTk5Rqk9Q1PryAVMkHu1drsZ0tUMGdErxlZa0uWqoJk3W/5o0kxPZJXkLm6M8CD181cdGiiYlfSToEE8OMiEthajeozcckamdVhFW9hZ/ebzHdbWiR9Dsqj+D8NH0crfqS5iF/XNR0Xj2qgrVpTLlooIhLBV8QDOtdiJATx+oDLJafMLdZE4VD6Bqoq01ldTcPTfZVl3sZkiL+nFGYa10U5oWUBtG5bCT/0k0cP2RiWx84QoHafHtgpWcSoweAV5v3OToawLgQbS5LO5+SEBQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y/qfGyglmEfZT2H/28720Iy6WnnDs5i59pZezPDGwlB7FV77chE8iK7FO6KP0TxbQ1brQIXoM8lhZ2+2dysF0Vics+1OLwRcePlYYtgJ5MTlq+mzPacrLhCE+eQ3Vq70m1FnS7njliXy20raCN7THgghTqCKA+WYYeaGYFjsfBk7wXxs0deVDrXE/QT+z+4gXofQXN6egYX5auUShK3zlM/A6K/OYMNCC2FZdSn46D7W0pAQ6vjqK5TiwCiKI4jM+HbL4sRIvZRlZFMPCDtRVkPMpSwgyx5IERNDC+/qeH/rKnhNcQMf+IHXkWH5yVnoiEEkC7kpWrV8nUbSjeJkLQ==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <julien@xxxxxxx>, <sstabellini@xxxxxxxxxx>, <oleksandr_tyshchenko@xxxxxxxx>, <volodymyr_babchuk@xxxxxxxx>, <Artem_Mygaiev@xxxxxxxx>, <jbeulich@xxxxxxxx>, <bertrand.marquis@xxxxxxx>, <rahul.singh@xxxxxxx>, Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
  • Delivery-date: Wed, 13 Oct 2021 13:52:20 +0000
  • Ironport-data: A9a23:c+86J6p9N4JDdzFYVQCcNgxbM7ZeBmIhYxIvgKrLsJaIsI4StFCzt garIBmPb66LMGr9e98gaN6x9ktS75HXz9Q2QVdqrCBhHi4b9JuZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlZT4vE2xbuKU5NTsY0idfic5Dnd84f5fs7Rh2Ncx2YHiW1jlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnZH3dT0gAPLmor8AD0hhInFAJJxg6paSdBBTseTLp6HHW37lwvEoB0AqJ4wIvO1wBAmi9 9RBdmpLNErawbvrnvTrEYGAhex6RCXvFJkYtXx6iynQEN4tQIzZQrWM7thdtNs1rp0TRKyHO ptHAdZpRDf5WEYIM34VMoMRpriFglfbaw1jonvA8MLb5ECMlVcsgdABKuH9eNaHWMFUlUawv X/d8iLyBRRyHPWF1TeAxVe9iebOkD3TVZobEfuz8fsCqFee3HAJARsaE16yu+Cki1WWUshab UcT/0IGqqw/91eiSNXnaBS+rGSZpR4XW9dWEOoS5RmEz+zf5APxLnINTiNFLscnssA2bTUw0 xmCmNaBLSJotLqZWHeM7ICepDm5OTUWBWIabCpCRgwAi/HzrYd2gh/RQ9JLFK+uksazCTz22 yqNriU1m/MUl8Fj/6y98Uqd22r0jpfMRw8xoA7QWwqN7B59ZYOjT5yl7x7c9/koBIGdQ1qat X4Igf+C/fsOBpGAki+KaOgVFbTv7PGAWBXHmkJmFZQl8zWr+lagcJpW7TU4I11mWvvoYhewP hWV41kIosYOYj36Nsebfr5dFewnipTaHOq6fMqPc4YfW6khSha22jNHMBv4M3/WrGAglqQ2O JG+eMmqDGoHBakP8AdaV9vxwpdwmXhgnTK7qYTTik39i+LHNSH9paItaQPWNogEALW4TBI5G jq1H/CBzAlDS6XAay3T/J97wbsifCVjW86eRyC6cIe+zuta9IMJV6G5LVAJIdUNc0FpegHgp S7VtqhwkguXuJE/AV/WAk2Pko/HU5dltm4cNicxJ1uu0HVLSd/xt/tHKcdtJeN7r7ALIRtIo x8tIJro7hNnEGWvxtjgRcOl8NwKmOqD1GpiwBZJkBBgJsU9FmQlC/fvfxf19TlmM8ZEnZBWn lFU7SuCGcBrb107VK7+Mavzp3vs7Sl1sL8jBCPgf4gMEHgABaA3ckTZlOEsGcgQJH3rn33Cv +pgKUxD/relTk5c2IShuJ1oWK/wS7EgQREAQzWChVt0XAGDlleeLUZ7eL/gVRjWVX/u+bXkY uNQzvrmN+YAkkoMuI15e4uHB4pnurMDfpdWkVZpGmvldVOuBu8yK3WKx5AX5KZM2qVYqU29X UfWootWPrCAOcXEFl8NJVV6MrTfhK9MwjSCv+4oJEja5TNs+ObVW0tlIBTR2jdWK6F4Md15z L556tIW8QG2ljEjLs2C0nJP722JI3FZC/cnu5gWDZXFkA0uzl0eM5XQBjWvuMOEaslWM1lsK TiR3fKQi7NZz0vEUnwyCXmSgrYN2cVQ4EhHlQZQKU6Il9zJgu4M8CdQqTlnHB5Iyhhn0v5oP jQ5PUNCOqjTrSxjg9JOXj7wFlgZVgGZ4EH413AAiHbdExuzTmXIIWAwZbSN8UQe/z4OdzRX5 ujFmmPsUDKsd8DtxCoiH0VirqW7H9B28wTDnuGhHtiEQMZmMWa03Pf2aDpasQbjDOMwmFbD9 Ltj8+tHYKHmMTId/v8gAI6A2LVMEB2JKQSumx26EH/lyY0ERAyP5A==
  • Ironport-hdrordr: A9a23:XqL/66prpDORU8F+9ynnUQAaV5vNL9V00zEX/kB9WHVpm5Oj+f xGzc516farslossREb+expOMG7MBXhHLpOkPQs1NaZLXPbUQ6TTb2KgrGSpgEIdxeOktK1kJ 0QD5SWa+eAfGSS7/yKmDVQeuxIqLLsndHK9IWuv0uFDzsaEJ2Ihz0JdDpzeXcGPTWua6BJc6 Z1saF81kWdkDksH46GL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftzLLhCRCX0joXTjsKmN4ZgC T4uj28wp/mn+Cwyxfa2WOWx5NKmOH5wt8GIMCXkMAaJhjllw7tToV8XL+puiwzvYiUmRsXue iJhy1lE9V46nvXcG3wiRzx2zP42DJr0HPmwU/wuwqrneXJABYBT+ZRj4NQdRXUr2A6ustn7a 5N12WF87JKEBLphk3Glpn1fiAvsnDxjWspkOYVgXAae5AZcqVtoYsW+14QOIscHRj99JssHI BVfY/hDc5tABCnhk3izytSKITGZAV3Iv7GeDlMhiWt6UkXoJgjpHFogPD2nR87heQAotd/lq P5259T5cNzp/ktHNVA7dc6MLiK41P2MGfx2UKpUBza/fI8SjnwQ6Ce2sRA2AjtQu1P8KcP
  • Ironport-sdr: KNDd8LRWFeTJSxstTAsw0ADtxOlLfRUfZPR/4Cgr1P6nuuCFJsTM38LQVI7pyTGl03DHAqUIcK BSY2RtxJjVg5wbGTrqnRQMyXrNPW3B1o8/uGycf8xIG8NQzkMnHW4NOF/gQBVzVUmMZN5d66dr yUYDoVEkZ/NKvVHyl03cyoBIgPeyHSdd7p6OVzxZaX0TUIZzNMkp2p8CKn4lqRPSoRq3KZlSzu edtJKNUPX1pB69xJfkE01aCOMNsSwQPPOBYqg6jmoBp4d1tjsLwQkztydVcinJgc2QOVr7lBSg AWhd4GHpxlR60gnuqY319EfA
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> 
> This is in preparation for dynamic assignment of the vPCI register
> handlers depending on the domain: hwdom or guest.
> The need for this step is that it is easier to have all related functionality
> put at one place. When the subsequent patches add decisions on which
> handlers to install, e.g. hwdom or guest handlers, then this is easily
> achievable.

Won't it be possible to select the handlers to install in init_bars
itself?

Splitting it like that means you need to iterate over the numbers of
BARs twice (one in add_bar_handlers and one in init_bars), which makes
it more likely to introduce errors or divergences.

Decoupling the filling of vpci_bar data with setting the handlers
seems slightly confusing.

> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> 
> ---
> Since v1:
>  - constify struct pci_dev where possible
>  - extend patch description
> ---
>  xen/drivers/vpci/header.c | 83 ++++++++++++++++++++++++++-------------
>  1 file changed, 56 insertions(+), 27 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index f8cd55e7c024..3d571356397a 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -445,6 +445,55 @@ static void rom_write(const struct pci_dev *pdev, 
> unsigned int reg,
>          rom->addr = val & PCI_ROM_ADDRESS_MASK;
>  }
>  
> +static int add_bar_handlers(const struct pci_dev *pdev)

Making this const is again misleading IMO, as you end up modifying
fields inside the pdev, you get away with it because vpci data is
stored in a pointer.

> +{
> +    unsigned int i;
> +    struct vpci_header *header = &pdev->vpci->header;
> +    struct vpci_bar *bars = header->bars;
> +    int rc;
> +
> +    /* Setup a handler for the command register. */
> +    rc = vpci_add_register(pdev->vpci, vpci_hw_read16, cmd_write, 
> PCI_COMMAND,
> +                           2, header);
> +    if ( rc )
> +        return rc;
> +
> +    if ( pdev->ignore_bars )
> +        return 0;

You can join both ifs above:

if ( rc || pdev->ignore_bars )
    return rc;

> +
> +    for ( i = 0; i < PCI_HEADER_NORMAL_NR_BARS + 1; i++ )

init_bars deals with both TYPE_NORMAL and TYPE_BRIDGE classes, yet you
seem to unconditionally assume PCI_HEADER_NORMAL_NR_BARS here (even
when below you take into account the different ROM BAR position).

> +    {
> +        if ( (bars[i].type == VPCI_BAR_IO) || (bars[i].type == 
> VPCI_BAR_EMPTY) )
> +            continue;
> +
> +        if ( bars[i].type == VPCI_BAR_ROM )
> +        {
> +            unsigned int rom_reg;
> +            uint8_t header_type = pci_conf_read8(pdev->sbdf,
> +                                                 PCI_HEADER_TYPE) & 0x7f;

Missing newline, and unsigned int preferably for header_type.

> +            if ( header_type == PCI_HEADER_TYPE_NORMAL )
> +                rom_reg = PCI_ROM_ADDRESS;
> +            else
> +                rom_reg = PCI_ROM_ADDRESS1;
> +            rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rom_write,
> +                                   rom_reg, 4, &bars[i]);
> +            if ( rc )
> +                return rc;
> +        }
> +        else
> +        {
> +            uint8_t reg = PCI_BASE_ADDRESS_0 + i * 4;

unsigned int please, we try to avoid using explicitly sized types
unless strictly necessary (ie: when dealing with hardware values for
example).

> +
> +            /* This is either VPCI_BAR_MEM32 or VPCI_BAR_MEM64_{LO|HI}. */
> +            rc = vpci_add_register(pdev->vpci, vpci_hw_read32, bar_write, 
> reg,
> +                                   4, &bars[i]);
> +            if ( rc )
> +                return rc;
> +        }
> +    }
> +    return 0;
> +}
> +
>  static int init_bars(struct pci_dev *pdev)
>  {
>      uint16_t cmd;
> @@ -470,14 +519,8 @@ static int init_bars(struct pci_dev *pdev)
>          return -EOPNOTSUPP;
>      }
>  
> -    /* Setup a handler for the command register. */
> -    rc = vpci_add_register(pdev->vpci, vpci_hw_read16, cmd_write, 
> PCI_COMMAND,
> -                           2, header);
> -    if ( rc )
> -        return rc;

I don't think you need to move the handler for the command register
inside add_bar_handlers: for once it makes the function name not
reflect what it actually does (as it then deals with both BARs and the
command register), and it would also prevent you from having to call
add_bar_handlers in if ignore_bars is set.

Thanks, Roger.



 


Rackspace

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