On 21.02.20 11:54, David Hildenbrand wrote: > On 20.02.20 11:39, Christian Borntraeger wrote: >> mm people: This series contains a "pretty small" common code memory >> management change that will allow paging, guest backing with files etc >> almost just like normal VMs. It should be a no-op for all architectures >> not opting in. And it should be usable for others that also try to get >> notified on "the pages are in the process of being used for things like >> I/O". This time I included error handling and an ACK from Will Deacon. >> >> mm-related patches CCed on linux-mm, the complete list can be found on >> the KVM and linux-s390 list. >> >> Andrew, any chance to either take " mm:gup/writeback: add callbacks for >> inaccessible pages" or ACK so that I can take it? > > Summary: Mostly LGTM. Especially > - UAPI interface is minimal and clean > - Core MM changes are minimal and clean (and AFAIKT Andrea was involved > when discussing the approach, so it can't be wrong ;) ) > - Is no longer prototype quality ;) > > There are still some things I want to double check (esp. how KVM memory > slots are handled - I somewhat dislike that we cannot replace/add new > ones while in PV. One would have to fence that somehow in QEMU as long > as the guest is in PV mode e.g., once we would support memory hotplug > ... but looks like this is what the HW requires us to enforce for now), > certain races, etc. but I assume these things could be fixed later on. In fact you can do that. The hardware checks the integrity on guest physical address. So it is perfectly possible to remap a kvm slot as long as the eńcrypted content matches what counter, guest content hash and guest address tell. (It is like swapping, you move the encrypted content from one host page to another). For new pages (not unpacked and never touched by the guest) the ultravisor will bring a zeroed out page on first import. What does not work is when the user space address changes for a guest virtio indicator. But this was already broken before (we never did an adapter unmap/remap). > > Can we get a new version once the other reviewers are done, so at least > I can have a final look? Just the updated patches as reply (e.g. a 3.2 for patch 9) or the full monty?
