On Tue, Jun 02, 2026 at 02:40:07AM -0700, Shameer Kolothum Thodi wrote: > > From: Nicolin Chen <[email protected]> > > > + * 2. Guest writes VINTF_CONFIG.ENABLE = 1: > > > + * QEMU mmap()s the offset from step 1 into its address space and > > reports > > > + * STATUS.ENABLE_OK = 1. The host VINTF was already enabled by > > > + * IOMMU_VIOMMU_ALLOC; QEMU only acks back. > > > > I wonder this mmap should be done after the > > CMDQV_CONFIG.CMDQV_EN=1 > > rather than VINTF_CONFIG.ENABLE=1. > > > > Spec says that: > > "Program the CMDQV_CMDQ_ALLOC_MAP_X register(s) to map the Virtual > > CMDQ(s) to the logical CMDQs on Virtual Interface following the > > CMDQ allocation rules. This again is an optional step and the CMDQ > > allocation can be done after the Virtual Interface is initialized." > > > > This means the LVCMDQ mapping can happen before > > VINTF_CONFIG.ENABLE=1. > > > > And the mmap info is returned with IOMMU_VIOMMU_ALLOC. So, this is > > doable? > > I think it is. We could in theory as well do it just after IOMMU_VIOMMU_ALLOC. > What you think?
Yea. That sounds right to me. > > > + * 5. Guest SMMU driver programs a Stream Table Entry for a passthrough > > > + * device: IOMMU_VDEVICE_ALLOC programs SID_MATCH/SID_REPLACE > > in this > > > > Ideally, the VDEVICE_ALLOC should happen right after the device gets > > plugged *and* its vSID is available; similarly the vdevice should be > > only freed when the device gets unplugged. So, its lifecycle should > > stay with the plugged state. > > > > We do VDEVICE_ALLOC when guest programming STE is because that's the > > only place we found in the existing functions. We could (or arguably > > maybe we should) find a better place to allocate VDEVICE. E.g., vfio > > code can call qemu_add_vm_change_state_handler_prio() to register a > > callback function, where vSID (vBDF) should be available once the VM > > start to be "running". > > > > I think your narrative fits the current design. But we might need to > > be more accurate here, since this is about "lifecycle". > > Yes, the above is based on the current design. I will add a caveat to > cover that. > > I remember discussions about use cases(CCA realm ?) requiring an early > mandatory VDEVICE_ALLOC before guest boot. Regarding the suggestion > to use qemu_add_vm_change_state_handler_prio(), it might help, > but I'm not sure it covers all the cases like, hotplug, guest PCI > re-enumeration during boot, etc. (Having _DSM #5 might help here, > but per the PCI Firmware Spec it only "indicates to an operating > system that it should preserve assignments of PCI bus numbers", > so, guests are not strictly required to honour it.) Anyway, I'll take > another look as a follow up. Yea. I am not giving a suggestion that would work perfectly here. I think we are good with what we implemented for now. REALM stuff will need to take another look. Nicolin
