Re: [PATCH v6 18/24] iommu/amd: Init and clear vIOMMU DevID and DomID maps

[Jason Gunthorpe]

> Before using a vIOMMU instance, prefill the mapping tables so hardware
> never sees an unknown guest ID. Map every gdom_id to the nest parent
> domain ID, and write every gdev_id with hdev_id 0. Init cannot be
> scoped to IDs in use; INVALIDATE_IOMMU_ALL walks the HW table.
> 
> Yield vfctrl_lock every 256 doorbells so the 128K MMIO loop can
> resched. Attach cannot run until viommu->ops is set after init_one().
> 
> On destroy, drain CONTROL0/CONTROL1 WRITE and unmap. Do not rewrite
> the full tables: that would start 128K DMA writes into pages about
> to be freed. vDevice destroy and nested_domain_free already restored
> idle entries.
> 
> Skip VFCTRL access when CONTROL_CMDBUF_EN is already clear, matching
> viommu_priv_unmap_free() on the same uninit_one() path.

I didn't see any explanation what happens if the guest issues an
invalidate to a gdomid without a host domid?

This is related to my questions about when the IOTLB is cleaned. Given
this patch I would expect that once the mapping is removed the hdomid
is cleaned and any invalidations for the gdomid are NOPd

If the gdomis is used again it is assigned to a clean hdomid and those
NOP'd invalidations don't matter.

Is this how it works?

I have to say the commit messages are no good in this series, do not
summarize what the patch is doing, explain why this patch is necessary
in the first place.

-- 
Jason