On Mon, Jul 04 2022, Steven Price <steven.price@xxxxxxx> wrote: > On 04/07/2022 13:19, Cornelia Huck wrote: >> On Mon, Jul 04 2022, Steven Price <steven.price@xxxxxxx> wrote: >> >>> On 29/06/2022 09:45, Catalin Marinas wrote: >>>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote: >>> >>>>> [Postcopy needs a different interface, I guess, so that the migration >>>>> target can atomically place a received page and its metadata. I see >>>>> https://lore.kernel.org/all/CAJc+Z1FZxSYB_zJit4+0uTR-88VqQL+-01XNMSEfua-dXDy6Wg@xxxxxxxxxxxxxx/; >>>>> has there been any follow-up?] >>>> >>>> I don't follow the qemu list, so I wasn't even aware of that thread. But >>>> postcopy, the VMM needs to ensure that both the data and tags are up to >>>> date before mapping such page into the guest address space. >>>> >>> >>> I'm not sure I see how atomically updating data+tags is different from >>> the existing issues around atomically updating the data. The VMM needs >>> to ensure that the guest doesn't see the page before all the data+all >>> the tags are written. It does mean lazy setting of the tags isn't >>> possible in the VMM, but I'm not sure that's a worthwhile thing anyway. >>> Perhaps I'm missing something? >> >> For postcopy, we basically want to fault in any not-yet-migrated page >> via uffd once the guest accesses it. We only get the page data that way, >> though, not the tag. I'm wondering whether we'd need a 'page+metadata' >> uffd mode; not sure if that makes sense. Otherwise, we'd need to stop >> the guest while grabbing the tags for the page as well, and stopping is >> the thing we want to avoid here. > > Ah, I think I see now. UFFDIO_COPY atomically populates the (data) page > and ensures that no thread will see the partially populated page. But > there's currently no way of doing that with tags as well. Nod. > > I'd not looked at the implementation of userfaultfd before and I'd > assumed it avoided the need for an 'atomic' operation like this. But > apparently not! AFAICT either a new ioctl would be needed (which can > take a tag buffer) or a new flag to UFFDIO_COPY which would tighten the > alignment requirements of `src` and would copy the tags along with the data. I was thinking about a new flag that implies "copy metadata"; not sure how we would get the same atomicity with a separate ioctl. I've only just started looking at userfaultfd, though, and I might be on a wrong track... One thing I'd like to avoid is having something that is too ARM-specific, I think there are other architecture features that might have similar issues. Maybe someone more familiar with uffd and/or postcopy can chime in? _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
