| commit | 951f2269af2d1f559d3949c45659c65297946106 | |
| author | David Hildenbrand <david@redhat.com> | |
| Mon, 23 Apr 2018 16:51:26 +0000 (23 18:51 +0200) | ||
| committer | Eduardo Habkost <ehabkost@redhat.com> | |
| Mon, 7 May 2018 13:00:02 +0000 (7 10:00 -0300) | ||
| tree | 32680332c11cbfda260b3c339e41c8bfef1cba12 | treesnapshot (tar.gz zip) |
| parent | 0c9269a52d79aeebcfade97778ee937ab480a232 | commitdiff |
vl: allow 'maxmem' without 'slot'
We will be able to have memory devices (e.g. virtio) not requiring the
slot parameter (e.g. not exposed via ACPI). We still need the maxmem
parameter to setup a proper memory region for device memory. And some
architectures (e.g. s390x) will have to set up the maximum possible guest
address space size based on the maxmem parameter.
As far as I can see, all code (pc.c,spapr.c,ACPI code) should handle
!slots just fine, even though maxmem is set.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180423165126.15441-12-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
We will be able to have memory devices (e.g. virtio) not requiring the
slot parameter (e.g. not exposed via ACPI). We still need the maxmem
parameter to setup a proper memory region for device memory. And some
architectures (e.g. s390x) will have to set up the maximum possible guest
address space size based on the maxmem parameter.
As far as I can see, all code (pc.c,spapr.c,ACPI code) should handle
!slots just fine, even though maxmem is set.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180423165126.15441-12-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
| vl.c | diffblobblamehistory |