> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Friday, September 6, 2024 7:07 AM > > On Thu, Sep 05, 2024 at 01:53:27PM -0700, Dan Williams wrote: > > > As mentioned in another thread this entry into the LOCKED state is > > likely nearly as violent as hotplug event since the DMA layer currently > > has no concept of a device having a foot in the secure world and the > > shared world at the same time. > > There is also something of a complicated situation where the VM also > must validate that it has received the complete and correct device > before it can lock it. Ie that the MMIO ranges belong to the device, > the DMA goes to the right place (the vRID:pRID is trusted), and so on. > > Further, the vIOMMU, and it's parameters, in the VM must also be > validated and trusted before the VM can lock the device. The VM and > the trusted world must verify they have the exclusive control over the > translation. Looking at the TDISP spec it's the host to lock the device (as Dan described the entry into the LOCKED state) while the VM is allowed to put the device into the RUN state after validation. I guess you actually meant the entry into RUN here? otherwise there might be some disconnect here. > > This is where AMDs model of having the hypervisor control things get a > little bit confusing for me. I suppose there will be some way that the > confidential VM asks the trusted world to control the secure DTE such > that it can select between GCR3, BLOCKED and IDENTITY. this matches what I read from the SEV-TIO spec. > > Regardless, I think everyone will need some metadata from the vIOMMU > world into the trusted world to do all of this. Agree.
