From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Pankaj Gupta <pankaj.gupta@cloud.ionos.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
teawater <teawaterz@linux.alibaba.com>,
qemu-devel@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Marek Kedzierski <mkedzier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>,
Wei Yang <richard.weiyang@linux.alibaba.com>
Subject: Re: [PATCH v2 5/6] migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the destination
Date: Thu, 29 Jul 2021 18:15:58 +0200 [thread overview]
Message-ID: <5ede7b00-1048-c124-e239-eeff21d9adb0@redhat.com> (raw)
In-Reply-To: <YQLO1QoOIu8dlaEq@t490s>
On 29.07.21 17:52, Peter Xu wrote:
> On Thu, Jul 29, 2021 at 02:14:41PM +0200, David Hildenbrand wrote:
>> On 24.07.21 00:10, Peter Xu wrote:
>>> On Fri, Jul 23, 2021 at 09:01:42PM +0200, David Hildenbrand wrote:
>>>> It can happen in corner cases and is valid: with the current virtio-mem
>>>> spec, guests are allowed to read unplugged memory. This will, for example,
>>>> happen on older Linux guests when reading /proc/kcore or (with even older
>>>> guests) when dumping guest memory via kdump. These corner cases were the
>>>> main reason why the spec allows for it -- until we have guests properly
>>>> adjusted such that it won't happen even in corner cases.
>>>>
>>>> A future feature bit will disallow it for the guest: required for supporting
>>>> shmem/hugetlb cleanly. With that in place, I agree that we would want to
>>>> warn in this case!
>>>
>>> OK that makes sense; with the page_size change, feel free to add:
>>
>> I just realized that relying on the page_size would be wrong.
>>
>> We migrate TARGET_PAGE_SIZE chunks and the offset might not be page_size
>> aligned. So if we were to replace TARGET_PAGE_SIZE by rb->page_size, we
>> might accidentally cover a "too big" range.
>
> I'm wondering whether we should make the offset page size aligned instead. For
> example, note that postcopy_place_page_zero() should only take page_size
> aligned host addr or UFFDIO_COPY could fail (hugetlb doesn't support
> UFFDIO_ZEROPAGE yet).
That is true indeed. I'd assume in that case that we would get called
with the proper offset already, right? Because uffd would only report
properly aligned pages IIRC.
>
> Btw, does virtio-mem supports hugetlbfs now? When with it, the smallest unit
> to plug/unplug would the huge page size (e.g., for 1g huge page, sounds not
> helpful to unplug 2M memory), am I right?
It supports it to 99.9 % I'd say (especially with the dump/tpm/migration
fixes upstream). The units are handled properly: the unit is at least as
big as the page size.
So with 1 GiB pages, you have a unit of 1 GiB.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-07-29 16:32 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 9:27 [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager David Hildenbrand
2021-07-21 9:27 ` [PATCH v2 1/6] memory: Introduce replay_discarded callback for RamDiscardManager David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-21 9:27 ` [PATCH v2 2/6] virtio-mem: Implement replay_discarded RamDiscardManager callback David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-21 9:27 ` [PATCH v2 3/6] migration/ram: Handle RAMBlocks with a RamDiscardManager on the migration source David Hildenbrand
2021-07-21 9:27 ` [PATCH v2 4/6] virtio-mem: Drop precopy notifier David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-21 9:27 ` [PATCH v2 5/6] migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the destination David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-23 18:36 ` David Hildenbrand
2021-07-23 18:52 ` Peter Xu
2021-07-23 19:01 ` David Hildenbrand
2021-07-23 22:10 ` Peter Xu
2021-07-29 12:14 ` David Hildenbrand
2021-07-29 15:52 ` Peter Xu
2021-07-29 16:15 ` David Hildenbrand [this message]
2021-07-29 19:20 ` Peter Xu
2021-07-29 19:22 ` David Hildenbrand
2021-07-21 9:27 ` [PATCH v2 6/6] migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots David Hildenbrand
2021-07-23 16:37 ` Peter Xu
2021-07-22 11:29 ` [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager Dr. David Alan Gilbert
2021-07-22 11:43 ` David Hildenbrand
2021-07-23 16:12 ` Peter Xu
2021-07-23 18:41 ` David Hildenbrand
2021-07-23 22:19 ` Peter Xu
2021-07-27 9:25 ` David Hildenbrand
2021-07-27 17:10 ` Peter Xu
2021-07-28 17:39 ` David Hildenbrand
2021-07-28 19:42 ` Peter Xu
2021-07-28 19:46 ` David Hildenbrand
2021-07-28 20:19 ` Peter Xu
2021-07-29 8:14 ` David Hildenbrand
2021-07-29 16:12 ` Peter Xu
2021-07-29 16:19 ` David Hildenbrand
2021-07-29 19:32 ` Peter Xu
2021-07-29 19:39 ` David Hildenbrand
2021-07-29 20:00 ` Peter Xu
2021-07-29 20:06 ` David Hildenbrand
2021-07-29 20:28 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ede7b00-1048-c124-e239-eeff21d9adb0@redhat.com \
--to=david@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=andrey.gruzdev@virtuozzo.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mkedzier@redhat.com \
--cc=mst@redhat.com \
--cc=pankaj.gupta@cloud.ionos.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.weiyang@linux.alibaba.com \
--cc=teawaterz@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.