All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 4/6] xen/vpci: header: status register handler
Date: Thu, 31 Aug 2023 17:25:44 -0400	[thread overview]
Message-ID: <f7457387-e8df-ae80-327b-2a7ba7428266@amd.com> (raw)
In-Reply-To: <4a082785-7da1-caf9-3193-eb0a9a77a7bc@suse.com>

On 8/30/23 10:05, Jan Beulich wrote:
> On 28.08.2023 19:56, Stewart Hildebrand wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -413,6 +413,18 @@ static void cf_check cmd_write(
>>          pci_conf_write16(pdev->sbdf, reg, cmd);
>>  }
>>
>> +static uint32_t cf_check status_read(const struct pci_dev *pdev,
>> +                                     unsigned int reg, void *data)
>> +{
>> +    struct vpci_header *header = data;
>> +    uint32_t status = pci_conf_read16(pdev->sbdf, reg);
>> +
>> +    if ( header->mask_cap_list )
>> +        status &= ~PCI_STATUS_CAP_LIST;
>> +
>> +    return status;
>> +}
> 
> Imo we also cannot validly pass through any of the reserved bits. Doing so
> is an option only once we know what purpose they might gain.

OK. I think in the long term, having a res_mask in struct vpci_register for the reserved bits will be more flexible.

> (In this
> context I notice our set of PCI_STATUS_* constants isn't quite up-to-date.)

I'll add these 2 new constants in the next version of the series (in a separate patch):
#define  PCI_STATUS_IMM_READY  0x01    /* Immediate Readiness */

#define  PCI_STATUS_INTERRUPT  0x08    /* Interrupt status */

>> @@ -544,6 +556,11 @@ static int cf_check init_bars(struct pci_dev *pdev)
>>      if ( rc )
>>          return rc;
>>
>> +    rc = vpci_add_rw1c_register(pdev->vpci, status_read, vpci_hw_write16,
>> +                                PCI_STATUS, 2, header, 0xF900);
> 
> Rather than a literal number, imo this wants to be an OR of the respective
> PCI_STATUS_* constants (which, if you like, could of course be consolidated
> into a new PCI_STATUS_RW1C_MASK, to help readability).

OK.

>> @@ -167,6 +174,7 @@ int vpci_add_register(struct vpci *vpci, vpci_read_t *read_handler,
>>      r->size = size;
>>      r->offset = offset;
>>      r->private = data;
>> +    r->rw1c_mask = rw1c_mask;
> 
> To avoid surprises with ...
> 
>> @@ -424,6 +443,7 @@ static void vpci_write_helper(const struct pci_dev *pdev,
>>          uint32_t val;
>>
>>          val = r->read(pdev, r->offset, r->private);
>> +        val &= ~r->rw1c_mask;
>>          data = merge_result(val, data, size, offset);
> 
> ... the user of this field, should you either assert that no bits beyond
> the field size are set, or simply mask to the respective number of bits?

Good point, I'll mask it (in add_register()).

Stew


  reply	other threads:[~2023-08-31 21:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-28 17:56 [PATCH v4 0/6] vPCI capabilities filtering Stewart Hildebrand
2023-08-28 17:56 ` [PATCH v4 1/6] x86/msi: remove some unused-but-set-variables Stewart Hildebrand
2023-08-29  6:58   ` Jan Beulich
2023-08-28 17:56 ` [PATCH v4 2/6] xen/pci: convert pci_find_*cap* to pci_sbdf_t Stewart Hildebrand
2023-08-30 13:48   ` Jan Beulich
2023-08-28 17:56 ` [PATCH v4 3/6] x86/msi: rearrange read_pci_mem_bar slightly Stewart Hildebrand
2023-08-30 13:51   ` Jan Beulich
2023-08-28 17:56 ` [PATCH v4 4/6] xen/vpci: header: status register handler Stewart Hildebrand
2023-08-30 14:05   ` Jan Beulich
2023-08-31 21:25     ` Stewart Hildebrand [this message]
2023-08-28 17:56 ` [RFC PATCH v4 5/6] xen/vpci: support ro mask Stewart Hildebrand
2023-08-31 11:58   ` Jan Beulich
2023-08-28 17:56 ` [PATCH v4 6/6] xen/vpci: header: filter PCI capabilities Stewart Hildebrand
2023-08-29  2:07   ` Stewart Hildebrand
2023-08-31 12:11   ` Jan Beulich
2023-09-01  4:14     ` Stewart Hildebrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7457387-e8df-ae80-327b-2a7ba7428266@amd.com \
    --to=stewart.hildebrand@amd.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.