Re: PVH Dom0 related UART failure

[Jan Beulich <jbeulich@xxxxxxxx>]

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