[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PVH Dom0 related UART failure
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 18 May 2023 12:34:38 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=7BbAKP2nPjjoO3ABgLWbb/zSXYNFRcfc+NcJ53uOQQk=; b=GOLrlNQxcqMzHLWenXsKP3wHHT0DLYsq7/kzB4Ut3NUK73qCVNEeD61HdU7Zg2zpEoLBnFDOIu/w9i9XZKCF84xC/OKk+3V2fFQ0J55W2taVvpqAmJaZ/E2IrVbaAiiyUEbXQwQfJqoFTr4LPXmFjPoKkPSwHTvBpqFnh+we3RzIFxyL0RbHCjHHbNGPFnUGTUSFZgPcpTiQN5cQdNrWAw+U0uSh4+ADxIxJ3oDgqJN4CuxileFVhvIjXEbZ0R5oYlA9qOlCH9fFCNLc3h+PVUlF2Atq3Sm+nZO4d/ReJg77fhWVwiY5GlA3OqEc8DP5Mgr/1lT8O87Q14IDciqPxQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JtRwgYRa+sK56jaBCM7BJVnx5gsui4ogtJ+31uiJz4gGpKBra8dAsJ3F/M5HQxQdD3n9oSH9IWfg2LFiRo0kXT62x5XndbkMSkCGY//1C/bfgM7l8KMBl48ckamPit654RcP+wSureu+K4yf//2iGbnJoFXij9MdKBVgwEEJbyoAAv12RtO2yKc7HfH+H8qLqJ7FEpjViYnLtUP/ZprnImO8grEdlyltOQvZkSeYipHvSD/2awXQL7UDXkJSYALdLaTaIlN1SlBIvY+/nlnxdrR8MAlCfezu0sqV6LG/yrTE8hhkTiB2MqAtyLA47G6z2+1BaomFRQYWU100eGY5FQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: jbeulich@xxxxxxxx, andrew.cooper3@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, marmarek@xxxxxxxxxxxxxxxxxxxxxx, xenia.ragiadakou@xxxxxxx
- Delivery-date: Thu, 18 May 2023 10:35:09 +0000
- Ironport-data: A9a23:HOtTWqOjLBuIYFTvrR1KlsFynXyQoLVcMsEvi/4bfWQNrUolhGFTz moaDGuGP6qCZ2ShfI1/bojn9EJQucLXxt9iHQto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CU6jufQAOKnUoYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGj9SuvPrRC9H5qyo42tF5wxmP5ingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0t5HLmhl6 qASE2kcUyqzhd2z0omgd+Y506zPLOGzVG8ekldJ6GiBSNMZG9XESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+PdxujCMpOBy+OGF3N79YNuFSN8Thk+Fj mnH4374ElcRM9n3JT+tqyr83LGXwXilMG4UPIGh8fBKgh6I/0AaTz8XbGOBsaGgm3frDrqzL GRRoELCt5Ma71e3R9PwWxm5pn+svRMGXddUVeog52mlyKDZ/gKYDWgsVSNaZZots8pebSwn0 BqFks3kARRrsaaJUjSN+7GMtzSwNCMJa2gYakcsSAIf5tD5rYIbjxTRT81iGqq4kt30Hz7rx zmA6iM5gt07ncMN1qz951nIgjugr5vOUyY84wmRVWWghj6Vf6agbo2srF3Et/BJKd/BSkHb5 SBb3c+D8OoJEJeB0jSXR/kAF62o4PDDNyDAhVloHN8q8DHFF2OfQL28KQpWfC9BWvvosxezC KMPkWu9PKNuAUY=
- Ironport-hdrordr: A9a23:QN0EtK0/OHn5hoKCPcS4AgqjBNEkLtp133Aq2lEZdPU1SKylfq WV98jzuiWYtN98YhsdcLO7WZVoP0myyXcd2+B4AV7IZmXbUQWTQr1f0Q==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, May 17, 2023 at 05:59:31PM -0700, Stefano Stabellini wrote:
> Hi all,
>
> I have run into another PVH Dom0 issue. I am trying to enable a PVH Dom0
> test with the brand new gitlab-ci runner offered by Qubes. It is an AMD
> Zen3 system and we already have a few successful tests with it, see
> automation/gitlab-ci/test.yaml.
>
> We managed to narrow down the issue to a console problem. We are
> currently using console=com1 com1=115200,8n1,pci,msi as Xen command line
> options, it works with PV Dom0 and it is using a PCI UART card.
>
> In the case of Dom0 PVH:
> - it works without console=com1
> - it works with console=com1 and with the patch appended below
> - it doesn't work otherwise and crashes with this error:
> https://matrix-client.matrix.org/_matrix/media/r0/download/invisiblethingslab.com/uzcmldIqHptFZuxqsJtviLZK
Jan also noticed this, and we have a ticket for it in gitlab:
https://gitlab.com/xen-project/xen/-/issues/85
> What is the right way to fix it?
I think the right fix is to simply avoid hidden devices from being
handled by vPCI, in any case such devices won't work propewrly with
vPCI because they are in use by Xen, and so any cached information by
vPCI is likely to become stable as Xen can modify the device without
vPCI noticing.
I think the chunk below should help. It's not clear to me however how
hidden devices should be handled, is the intention to completely hide
such devices from dom0?
Roger.
---
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 652807a4a454..0baef3a8d3a1 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -72,7 +72,12 @@ int vpci_add_handlers(struct pci_dev *pdev)
unsigned int i;
int rc = 0;
- if ( !has_vpci(pdev->domain) )
+ if ( !has_vpci(pdev->domain) ||
+ /*
+ * Ignore RO and hidden devices, those are in use by Xen and vPCI
+ * won't work on them.
+ */
+ pci_get_pdev(dom_xen, pdev->sbdf) )
return 0;
/* We should not get here twice for the same device. */
|
