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. > 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.
