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

Re: [PATCH v7 1/2] xen/vpci: header: status register handler


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Tue, 21 Nov 2023 11:46:27 -0500
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.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 (0)
  • 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=51h6ikenRbA7/yvAIBigL3HsbnsM7f4fXylpyQ4Whw8=; b=a9tavqT1x2fDm6QOdQ+axYdLJ5J4aY9aHHpFULHEYIWWRmi2hHDutLwAPHBy0ongFOdTqA4SZmXwjiAek5GxhoTwaI4q7EyWU22MUZE9lfwOny0L1Wd69thCyOKNKy8PkBiufkO0T9DY5zc8StqlrDL9pJKP6tt96WG6DluVmGpimLYUNg3+sfssBsL9G4uxlhuBtC2cXs+hj3XJgFHDSGI6PZ1kcjUN4J6yYw52Q7ADdNMpjkFWQmVO2jEGr2K29d4piECxogsULq7CfPzsYnJmorysdNMgeTy+UTz37iFVMvzkWopTqz0huAdCyKbqlmLyN1HPrVbCjHHyMGb4oQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X6XTvLhdE0akYRHKVh7afRuej25WWcd4EstRpUKgULRp7ha78gdFc3rWDxzdjaozCvhpm4WR9hG6tbzr3SV4Neqh8toWQ7MkIuxFg6kHnUBomZAJYkbWL0EZqGV6ZaUppab2vHbsxW7QFVFYvjGbmIXCp1ffHyfJo2L0INSleY7NMiGsvbguQbmlaWBI6xchaEW7sCY6GIku4by4KhYm861p6XQKZ+/H0QEQTrUs1o/XEpPBvdijoo2ir6CZICAS5pWaF1qfbr76O+0bv4WX+uNPk2ySqkzZFqSPYZxitJtiQ3xfYiyEZ817RA3Mv5axO5Oh79LSVFaZ2Xz4lg1zxQ==
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 21 Nov 2023 16:46:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11/21/23 11:27, Stewart Hildebrand wrote:
> On 11/21/23 10:18, Roger Pau Monné wrote:
>> On Tue, Nov 21, 2023 at 10:03:01AM -0500, Stewart Hildebrand wrote:
>>> On 11/21/23 09:45, Roger Pau Monné wrote:
>>>> On Wed, Sep 13, 2023 at 10:35:46AM -0400, Stewart Hildebrand wrote:
>>>>> @@ -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);
>>>>> +    data |= val & r->ro_mask;
>>>>
>>>> I've been thinking about this, and the way the ro_mask is implemented
>>>> (and the way we want to handle ro bits) is the same behavior as RsvdP.
>>>> I would suggest to rename the ro_mask to rsvdp_mask and note
>>>> that for resilience reasons we will handle RO bits as RsvdP.
>>>
>>> But the reads behave differently. RO should return the value, RsvdP should 
>>> return 0 when read (according to the PCIe Base Spec 4.0).
>>
>> Hm, right, sorry for the wrong suggestion.  We should force bits to 0
>> for guests reads, but make sure that for writes the value on the
>> hardware is preserved.
>>
>> So we need the separate mask for RsvdP, which will be handled like
>> ro_mask in vpci_write_helper() and like rsvdz_mask in vpci_read().
> 
> Agreed. The only reason I didn't add RsvdP support in this patch was that it 
> wasn't needed for the status register... Since RsvdP will be needed for the 
> command register, I think I may as well implement it as part of this series, 
> perhaps in a separate patch following this one. Stay tuned for v8.

I just remembered that RsvdP would actually be useful for the 
PCI_STATUS_CAP_LIST bit in the status register. So I'll implement it directly 
in this patch afterall, not a separate one.



 


Rackspace

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