On 7/15/19 9:30 AM, Christoph Hellwig wrote: > On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote: >>> I thought about that but couldn't put my finger on a general concept. >>> Is it "guest with memory inaccessible to the host"? >>> >> >> Well, force_dma_unencrypted() is a much better name thatn sev_active(): >> s390 has no AMD SEV, that is sure, but for virtio to work we do need to >> make our dma accessible to the hypervisor. Yes, your "guest with memory >> inaccessible to the host" shows into the right direction IMHO. >> Unfortunately I don't have too many cycles to spend on this right now. > > In x86 it means that we need to remove dma encryption using > set_memory_decrypted before using it for DMA purposes. In the SEV > case that seems to be so that the hypervisor can access it, in the SME > case that Tom just fixes it is because there is an encrypted bit set > in the physical address, and if the device doesn't support a large > enough DMA address the direct mapping code has to encrypt the pages > used for the contigous allocation. Just a correction/clarification... For SME, when a device doesn't support a large enough DMA address to accommodate the encryption bit as part of the DMA address, the direct mapping code has to provide un-encrypted pages. For un-encrypted pages, the DMA address now does not include the encryption bit, making it acceptable to the device. Since the device is now using a DMA address without the encryption bit, the physical address in the CPU page table must match (the call to set_memory_decrypted) so that both the device and the CPU interact in the same way with the memory. Thanks, Tom > >> Being on cc for your patch made me realize that things got broken on >> s390. Thanks! I've sent out a patch that fixes protvirt, but we are going >> to benefit from your cleanups. I think with your cleanups and that patch >> of mine both sev_active() and sme_active() can be removed. Feel free to >> do so. If not, I can attend to it as well. > > Yes, I think with the dma-mapping fix and this series sme_active and > sev_active should be gone from common code. We should also be able > to remove the exports x86 has for them. > > I'll wait a few days and will then feed the dma-mapping fix to Linus, > it might make sense to either rebase Thiagos series on top of the > dma-mapping for-next branch, or wait a few days before reposting. >
