On 18.05.2023 12:34, Roger Pau Monné wrote: > On Wed, May 17, 2023 at 05:59:31PM -0700, Stefano Stabellini wrote: >> 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?
No, Dom0 should still be able to see them in a (mostly) r/o fashion. Hence my earlier RFC patch making vPCI actually deal with them. Jan
