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

Re: [PATCH v4 4/6] xen/vpci: header: status register handler


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Thu, 31 Aug 2023 17:25:44 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); 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=gaBWwXpf658zMtoukGSiLI8p7aWcUQD9GY28Ew0Ng+0=; b=hRXnjKqCudAY2eS+E1Lq9x74x5MZFaT8YKyDz/cN1eNV4mIdSljgia3tZbbVhFDZlHwfDtw8bKs51G16xSJkB42g30kjspaSXj8eeBcKz3H+2tnmISgVyvFJpUoT2RRHRj/5VytI7hEpfx4EmUhPdoEoKTFPUwU+vwj3nsVWMluxqchGTMTSJKXfNUJWC80jv51rpxKyf1ih7SNtUFPJ9i9nxcnyqRT/62sYLtwcGuWtn03YhW12jaLl91h4qBBUiHv7EQTN61rPGBcw9ozJ3AlQfgxMijJvHqXH0es2//DPM0gf4i7Y3N+sn7FMGvC1DLPs99zMonjEhs4LSBQIvw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZXgp1CGWv546XmMZyt3danyIQpe91MQ2E1vY/e16YI2kx9vM6b7kIYBoDLjHzEK3QGohzyVB5g3mEN8+EedGACcwYzwPZoW1Trw1Y21yisKJfiwOx+kqUT1WSPqHrFkLeYU3pXj2092l3bBf/tt9EhTSnaDNEt2MkJAsmWSKjC/pM4kTVQAstm7jhECgxy8DAC745Xy5X3p7xptEpQ+hQnWZ72ztHcGYgo6Zx+NWPuIb3cLhxOKMhdkaLYhZeh6U82u2e9ZGvtGBkiNcvAUHtilKVtm00xnEgw+YXA+eaqcU2SWk9jE13iflRMQ0sJXQ/PR8gZGgkI2/2a7Lw8jcg==
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 31 Aug 2023 21:26:07 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

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