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

Re: [PATCH] xen/vpci: allow BAR write if value is the same


  • To: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 24 Oct 2023 09:09:45 +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=2sVVJL9gM6QUiOtMPVuB4fvd0ae2WaUfjFTUzmfgq4E=; b=SdsnWvbAg+5c5ptNx98CEIbX2rkIguVjt7+7ZpkTSpjhetNMyNAKnbIEUHn9hYEYQxfP12PSyzgjgT4iskmPxxTCi5QnNTesievhMyKZMD4VxP424tzAMUNPphtJonwYIgEbYSx46/umkH1sLtjasQU2kZWE0dR7Do6/58UUxEGDA+j1sMAuQjRMllTn8g+2LHQ8IVaWKjmUcKaekdZtUhlvap90rLIImeN0/oIRrNWoohWoeN5O4IcJy/7peu6lYWOgieK34HcGkufU7IHRekZ3ALUqUFTk0iV8+jiHyXRm1ew3kKSkR/ba1s1ZSfp7+u3jseuLxJiXNggmN4B+Gw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FEWn6qtRjXqZ5MruS5cOcPucnVUziCM8K5usxi9nTAbwTxJ5DkNEaXKxHe7Pkze5eW7SitJCE14pzE08ITZioUR9a2gitl816/RHcx2kZ4SXd2x/IhFq1CYwnPeocr0bKj6EOiPABhB/lIvlzS09weRRtUBIK2E1a6N6uVASsNvCpRc88AJiVzTram9aWkS30Ykokpsn1tL5U2AeqqvzY6gHn5aKXcD/VzuUwrio7ZpIf4hJd84J5xCuKGKvTx2aqorU6Eqnos66gITxSmfMfWh2VFMdo4kczxrXypmdOswdpLEwL9b6x+PvweVMv+r24FvNJw2CBUU50Y//GqoE9A==
  • 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>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 24 Oct 2023 07:10:03 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.10.2023 18:36, Stewart Hildebrand wrote:
> During xl pci-assignable-add, pciback may reset the device while memory 
> decoding
> (PCI_COMMAND_MEMORY) is enabled. After device reset, memory decoding may be
> disabled in hardware, and the BARs may be zeroed/reset in hardware. However, 
> Xen
> vPCI still thinks memory decoding is enabled, and BARs will remain mapped in
> p2m. In other words, memory decoding may become disabled and BARs reset in
> hardware, bypassing the respective vPCI command and BAR register handlers.
> Subsequently, when pciback attempts to restore state to the device, including
> BARs, it happens to write the BARs before writing the command register.
> Restoring/writing the BARs silently fails because Xen vPCI mistakenly thinks
> memory decoding is enabled.
> 
> Fix the BAR write by allowing it to succeed if the value written is the same 
> as
> the Xen vPCI stored value. pciback will subsequently restore the command
> register and the state of the BARs and memory decoding bit will then be in 
> sync
> between hardware and vPCI again.
> 
> While here, remove a nearby stray newline.
> 
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
> ---
> Do we need similar handling in rom_write()?

I think so, if we are to go this route. However, ...

> We may consider additionally checking during bar_write() if the memory 
> decoding
> state has become out of sync between hardware and vPCI. During bar_write(), we
> would check the device's memory decoding bit, compare it to our vPCI state, 
> and
> invoke modify_bars() if needed. Please let me know your thoughts.

... iirc we discussed earlier on that doing resets in Dom0 wants
communicating to Xen. Any way of resetting by a DomU would likely need
intercepting. This way the described situation can be avoided altogether.
We may go further and uniformly intercept resets, carrying them out on
behalf of Dom0 as well. The main issue is, as with any config-space-
based interaction with a device, that there may be device specific ways
of resetting.

Jan



 


Rackspace

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