quoted
On Sep 4, 2020, at 1:09 PM, Paolo Bonzini [off-list ref] 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?