On Fri, May 19, 2023 at 09:22:58AM +0200, Jan Beulich wrote: > 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.
What's the difference between a hidden device and one that's marked RO then? Thanks, Roger.
