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

Re: [PATCH v6 3/4] xen/vpci: header: status register handler


  • To: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 11 Sep 2023 13:10:40 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=PW4OEFenjSDfSeRq67zrxYXWqAuzxgaqeXKtRk/IPyU=; b=lv4YVJSRpkcJ9Q5a12ScSObB4GWRG9qVrihknJMUmWsySwLaDUCOUO31arzn2+kJKFWlwlhQu7jNF8kTc+sTefdOOxySMz2WDVhhc1wJvZZdz8OFcleAeKhJ1B8KDV2yKvS/EEGJpTFzZKSY0ZdQ2g75RYqZzzhwOpC//nJBIihvGsWBkh4uRia7wvapYhPUhzraqH3JFFEw9vCOZtV8PPgL7FIIwLxQQWjwmEvFt81vlAEUgo8UUdKtQ+QufRw54Ad4mEQw4AX4DzIvzRCVjIYPQBqVxy28TRm8t/gIuCwGwyXiQKNFSRhX76tw/7PUDPJIVDKPJRjuBJOzPkKm1g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mv75hjXd0fflfj2rE7P/4a4LibjFSJ4Q/I/XulFAkqysYx2+r3w6o/obp98dwWIg5nhryDRVxKOVMKnkT255WdyhqSSgdd8QD4UvTkqvafNdHVRhGKdhGS8wNgCwSD8Kk2oPzn/drIW3z/GTKgKxbbMdkG1060bROuDCdokSR/SfyI9sVw+kjaW8obyec0Rw3rif7zQpqiDqhOUEyEvDkJ1X3exNn+DCKh6yw8UQV1xhx9V3gQ6VaW4A10ta6RU7WZdb6EX4jx964jscgif6dKtR5m26uMT8svWcQpU4Wd5+hXMX6ESgCrkYah149cr3qg0PeazAJtcoOoLKiVkQ0A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 11 Sep 2023 11:10:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09.09.2023 04:16, Stewart Hildebrand wrote:
> @@ -544,6 +545,18 @@ static int cf_check init_bars(struct pci_dev *pdev)
>      if ( rc )
>          return rc;
>  
> +    /*
> +     * If mask_cap_list is true, PCI_STATUS_CAP_LIST will be set in both
> +     * rsvdz_mask and ro_mask, and thus will effectively behave as rsvdp
> +     * (reserved/RAZ and preserved on write).
> +     */
> +    rc = vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
> +                                PCI_STATUS, 2, header, PCI_STATUS_RSVDZ_MASK 
> |
> +                                (mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
> +                                PCI_STATUS_RO_MASK, PCI_STATUS_RW1C_MASK);

While not formally disallowed by ./CODING_STYLE, I think this kind of argument
wrapping is bad practice. If an argument is too long for the current line, it
should start on a fresh one. Otherwise at the very least I think we'd want the
continuation to stand out, by parenthesizing the entire argument, thus leading
to one deeper indentation on the continuing line(s). (This may even be useful
to do when starting on a fresh line.)

> @@ -155,7 +165,8 @@ int vpci_add_register(struct vpci *vpci, vpci_read_t 
> *read_handler,
>      /* Some sanity checks. */
>      if ( (size != 1 && size != 2 && size != 4) ||
>           offset >= PCI_CFG_SPACE_EXP_SIZE || (offset & (size - 1)) ||
> -         (!read_handler && !write_handler) )
> +         (!read_handler && !write_handler) || (ro_mask & rw1c_mask) ||
> +         (rsvdz_mask & rw1c_mask) )
>          return -EINVAL;

What about rsvdz_mask and ro_mask? They better wouldn't overlap either
(requiring an adjustment to the code you add to init_bars()).

> @@ -407,26 +439,25 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, 
> unsigned int size)
>  
>  /*
>   * Perform a maybe partial write to a register.
> - *
> - * Note that this will only work for simple registers, if Xen needs to
> - * trap accesses to rw1c registers (like the status PCI header register)
> - * the logic in vpci_write will have to be expanded in order to correctly
> - * deal with them.
>   */
>  static void vpci_write_helper(const struct pci_dev *pdev,
>                                const struct vpci_register *r, unsigned int 
> size,
>                                unsigned int offset, uint32_t data)
>  {
> +    uint32_t val = 0;
> +
>      ASSERT(size <= r->size);
>  
> -    if ( size != r->size )
> +    if ( (size != r->size) || r->ro_mask )
>      {
> -        uint32_t val;
> -
>          val = r->read(pdev, r->offset, r->private);
> +        val &= ~r->rw1c_mask;
>          data = merge_result(val, data, size, offset);
>      }
>  
> +    data &= ~r->rsvdz_mask & ~r->ro_mask;

~(r->rsvdz_mask | r->ro_mask) ? But maybe that's indeed just me ...

Jan



 


Rackspace

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