On 7/20/23 05:20, Julien Grall wrote: > Hi, > > On 18/07/2023 18:35, Stewart Hildebrand wrote: >> On 7/13/23 14:40, Julien Grall wrote: >>> Hi Stewart, >>> >>> On 07/07/2023 02:47, Stewart Hildebrand wrote: >>>> From: Rahul Singh <[email protected]> >>>> >>>> Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM, even >>>> though >>>> the feature is not yet complete in the current upstream codebase. The >>>> purpose of >>>> this is to make it easier to enable the necessary configs (HAS_PCI, >>>> HAS_VPCI) for >>>> testing and development of PCI passthrough on ARM. >>>> >>>> Since PCI passthrough on ARM is still work in progress at this time, make >>>> it >>>> depend on EXPERT. >>> >>> While preparing the patch for committing, I noticed that HAS_PASSTHROUGH >>> will now allow the user to select one of the IOMMU quarantine options. >>> >>> There are three of them right now: >>> 1. none >>> 2. basic (i.e. faulting) >>> 3. scratch page >>> >>> The latter is unlikely to work on Arm because we don't setup the scratch >>> page. AFAIU, for that, we would need to implement the callback >>> quarantine_init(). >>> >>> I would expect 1 and 2 work. That said, I think 1. would behave like 2. >>> because on Arm the device should not be automatically re-assigned to >>> dom0. I know this is correct for platform device, but will it be valid >>> for PCI as well? >> >> In a system with dom0 where the guest is created from the xl toolstack, we >> rely on "xl pci-assignable-add". Upon domain destruction, the device >> automatically gets assigned to domIO. > > Ok. To clarify, does this mean any DMA will fault, the same as for > platform device?
Yes, when the PCI device is assigned to domIO, any DMA from the device will produce a SMMU fault. The value of the quarantine= option doesn't change this behavior. >> However, there's nothing preventing a user from attempting to invoke "xl >> pci-assignable-remove", which should assign the device back to dom0, but it >> is not automatic. > > I don't think we want to fully prevent a user to re-assign a device to > dom0. But we at least want to avoid re-assigning the device to dom0 by > default. After that a user can reset the device before it gets > re-assigned to dom0. > > Cheers, > > -- > Julien Grall
