Re: folio_mmapped

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28.03.24 11:58, Quentin Perret wrote:
On Thursday 28 Mar 2024 at 11:32:21 (+0100), David Hildenbrand wrote:
... does that mean that for pKVM with protected VMs, "shared" pages are also
never migratable/swappable?

In our current implementation, yes, KVM keeps its longterm GUP pin on
pages that are shared back. And we might want to retain this behaviour
in the short term, even with guest_memfd or using the hybrid approach
you suggested. But that could totally be relaxed in the future, it's
"just" a matter of adding extra support to the hypervisor for that. That
has not been prioritized yet since the number of shared pages in
practice is relatively small for current use-cases, so ballooning was a
better option (and in the case of ballooning, we do drop the GUP pin).
But that's clearly on the TODO list!

Okay, so nothing "fundamental", good!


The whole reason I brought up the guest_memfd+memfd pair idea is that you
would similarly be able to do the conversion in the kernel, BUT, you'd never
be able to mmap+GUP encrypted pages.

Essentially you're using guest_memfd for what it was designed for: private
memory that is inaccessible.

Ack, that sounds pretty reasonable to me. But I think we'd still want to
make sure the other users of guest_memfd have the _desire_ to support
huge pages,  migration, swap (probably longer term), and related
features, otherwise I don't think a guest_memfd-based option will
really work for us :-)

*Probably* some easy way to get hugetlb pages into a guest_memfd would be by allocating them for an memfd and then converting/moving them into the guest_memfd part of the "fd pair" on conversion to private :)

(but the "partial shared, partial private" case is and remains the ugly thing that is hard and I still don't think it makes sense. Maybe it could be handles somehow in such a dual approach with some enlightment in the fds ... hard to find solutions for things that don't make any sense :P )

I also do strongly believe that we want to see some HW-assisted migration support for guest_memfd pages. Swap, as you say, maybe in the long-term. After all, we're not interested in having MM features for backing memory that you could similarly find under Windows 95. Wait, that one did support swapping! :P

But unfortunately, that's what the shiny new CoCo world currently offers. Well, excluding s390x secure execution, as discussed.

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux