From: David Hildenbrand <david@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
qemu-s390x@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times
Date: Thu, 18 Apr 2019 13:24:43 +0200 [thread overview]
Message-ID: <93d242cb-dcc4-a65d-a7c7-7232dd16a2f2@redhat.com> (raw)
In-Reply-To: <20190418113859.00248d07@redhat.com>
On 18.04.19 11:38, Igor Mammedov wrote:
> On Tue, 16 Apr 2019 13:09:08 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
>> This fails with more than 8TB, e.g. "-m 9T "
>>
>> [pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0, memory_size=0, userspace_addr=0x3ffc8500000}) = 0
>> [pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0, memory_size=9895604649984, userspace_addr=0x3ffc8500000}) = -1 EINVAL (Invalid argument)
>>
>> seems that the 2nd memslot gets the full size (and not 9TB-size of first slot).
>
> it turns out MemoryRegions is rendered correctly in to 2 parts (one per alias),
> but follow up flatview_simplify() collapses adjacent ranges back
> into big one.
That sounds dangerous. Imagine doing that at runtime (e.g. hotplugging a
DIMM), the kvm memory slot would temporarily be deleted to insert the
new, bigger one. Guest would crash. This could happen if backing memory
of two DIMMs would by pure luck be allocated side by side in user space.
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
qemu-s390x@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times
Date: Thu, 18 Apr 2019 13:24:43 +0200 [thread overview]
Message-ID: <93d242cb-dcc4-a65d-a7c7-7232dd16a2f2@redhat.com> (raw)
Message-ID: <20190418112443.N6reN3SoZ_2wg7KFsvi0UqyIElaKStqOGbXGtwz0JRI@z> (raw)
In-Reply-To: <20190418113859.00248d07@redhat.com>
On 18.04.19 11:38, Igor Mammedov wrote:
> On Tue, 16 Apr 2019 13:09:08 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
>> This fails with more than 8TB, e.g. "-m 9T "
>>
>> [pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0, memory_size=0, userspace_addr=0x3ffc8500000}) = 0
>> [pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0, guest_phys_addr=0, memory_size=9895604649984, userspace_addr=0x3ffc8500000}) = -1 EINVAL (Invalid argument)
>>
>> seems that the 2nd memslot gets the full size (and not 9TB-size of first slot).
>
> it turns out MemoryRegions is rendered correctly in to 2 parts (one per alias),
> but follow up flatview_simplify() collapses adjacent ranges back
> into big one.
That sounds dangerous. Imagine doing that at runtime (e.g. hotplugging a
DIMM), the kvm memory slot would temporarily be deleted to insert the
new, bigger one. Guest would crash. This could happen if backing memory
of two DIMMs would by pure luck be allocated side by side in user space.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-04-18 11:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-15 13:27 [Qemu-devel] [PATCH v1 0/5] Fix misuses of memory_region_allocate_system_memory() Igor Mammedov
2019-04-15 13:27 ` Igor Mammedov
2019-04-15 13:27 ` [Qemu-devel] [PATCH v1 1/5] sparc64: use memory_region_allocate_system_memory() only for '-m' specified RAM Igor Mammedov
2019-04-15 13:27 ` Igor Mammedov
2019-04-15 15:07 ` Philippe Mathieu-Daudé
2019-04-15 15:07 ` Philippe Mathieu-Daudé
2019-04-15 13:27 ` [Qemu-devel] [PATCH v1 2/5] ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory() Igor Mammedov
2019-04-15 13:27 ` Igor Mammedov
2019-04-16 4:13 ` David Gibson
2019-04-16 4:13 ` David Gibson
2019-04-15 13:27 ` [Qemu-devel] [PATCH v1 3/5] hppa: drop usage of memory_region_allocate_system_memory() for ROM Igor Mammedov
2019-04-15 13:27 ` Igor Mammedov
2019-04-15 15:16 ` Philippe Mathieu-Daudé
2019-04-15 15:16 ` Philippe Mathieu-Daudé
2019-04-15 13:27 ` [Qemu-devel] [PATCH v1 4/5] memory: make MemoryRegion alias migratable Igor Mammedov
2019-04-15 13:27 ` Igor Mammedov
2019-04-15 13:27 ` [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times Igor Mammedov
2019-04-15 13:27 ` Igor Mammedov
2019-04-16 11:01 ` Christian Borntraeger
2019-04-16 11:01 ` Christian Borntraeger
2019-04-16 11:02 ` Christian Borntraeger
2019-04-16 11:02 ` Christian Borntraeger
2019-04-16 11:09 ` Christian Borntraeger
2019-04-16 11:09 ` Christian Borntraeger
2019-04-17 14:30 ` Igor Mammedov
2019-04-17 14:30 ` Igor Mammedov
2019-04-18 9:38 ` Igor Mammedov
2019-04-18 9:38 ` Igor Mammedov
2019-04-18 11:24 ` David Hildenbrand [this message]
2019-04-18 11:24 ` David Hildenbrand
2019-04-18 12:01 ` Igor Mammedov
2019-04-18 12:01 ` Igor Mammedov
2019-04-18 12:06 ` David Hildenbrand
2019-04-18 12:06 ` David Hildenbrand
2019-04-18 14:56 ` Igor Mammedov
2019-04-18 14:56 ` Igor Mammedov
2019-04-18 15:01 ` David Hildenbrand
2019-04-18 15:01 ` David Hildenbrand
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=93d242cb-dcc4-a65d-a7c7-7232dd16a2f2@redhat.com \
--to=david@redhat.com \
--cc=cohuck@redhat.com \
--cc=imammedo@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).