>> On Sep 4, 2020, at 1:09 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> >> On 04/09/20 21:39, Andy Lutomirski wrote: >> I'm a little concerned that it's actually too clever and that maybe a >> more straightforward solution should be investigated. I personally >> rather dislike the KVM model in which the guest address space mirrors >> the host (QEMU) address space rather than being its own thing. In >> particular, the current model means that extra-special-strange >> mappings like SEV-encrypted memory are required to be present in the >> QEMU page tables in order for the guest to see them. >> (If I had noticed that last bit before it went upstream, I would have >> NAKked it. I would still like to see it deprecated and ideally >> eventually removed from the kernel. We have absolutely no business >> creating incoherent mappings like this.) > > NACK first and ask second, right Andy? I see that nothing has changed > since Alan Cox left Linux. NACKs are negotiable. And maybe someone can convince me that the SEV mapping scheme is reasonable, but I would be surprised. Regardless, you seem to be suggesting that you want to have enclave VMs in which the enclave can see some memory that the parent VM can’t see. How does this fit into the KVM mapping model? How does this remote mapping mechanism help? Do you want QEMU to have that memory mapped in its own pagetables? As it stands, the way that KVM memory mappings are created seems to be convenient, but it also seems to be resulting in increasing bizarre userspace mappings. At what point is the right solution to decouple KVM’s mappings from QEMU’s?
