The NMC93xx EEPROM is only used by few NIC cards and the
Am53C974 SCSI controller.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Stefan Weil
---
hw/net/Kconfig | 2 ++
hw/nvram/Kconfig | 4
hw/nvram/Makefile.objs | 2 +-
hw/scsi/Kconfig| 1 +
4 files changed, 8 insert
On Tue, Dec 31, 2019 at 07:32:07PM +0100, Philippe Mathieu-Daudé wrote:
> The System Management Bus is more or less a derivative of the I2C
> bus, thus the Kconfig entry depends of I2C.
> Not all boards providing an I2C bus support SMBus.
> Use two different Kconfig entries to be able to select I2C
When configured with --without-default-devices and setting
MC146818RTC=n, the build fails:
LINKx86_64-softmmu/qemu-system-x86_64
/usr/bin/ld: qapi/qapi-commands-misc-target.o: in function
`qmp_marshal_rtc_reset_reinjection':
qapi/qapi-commands-misc-target.c:46: undefined reference to
Only the OpenBIOS and SLOF firmwares use the CHRP NVRAM layout.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/nvram/Kconfig | 4
hw/nvram/Makefile.objs | 2 +-
hw/ppc/Kconfig | 1 +
hw/sparc/Kconfig | 1 +
hw/sparc64/Kconfig | 1 +
5 files changed, 8 insertions(+), 1
When configured with --without-default-devices, the build fails:
LINKppc-softmmu/qemu-system-ppc
/usr/bin/ld: hw/ppc/virtex_ml507.o: in function `ppc440_init_xilinx':
hw/ppc/virtex_ml507.c:112: undefined reference to `ppcuic_init'
collect2: error: ld returned 1 exit status
make[1]:
The fw_cfg helpers are only used by machines using OpenBIOS.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Mark Cave-Ayland
Cc: "Hervé Poussineau"
---
hw/ppc/Kconfig | 6 ++
hw/ppc/Makefile.objs | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/Kconfig b/h
Only the PowerPC e500-based platforms use the MPC I2C controller.
Do not build it for the other machines.
Signed-off-by: Philippe Mathieu-Daudé
---
default-configs/ppc-softmmu.mak | 1 -
hw/ppc/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/default-c
The CONFIG_PSERIES already selects CONFIG_PCI.
Simplify the Makefile rules.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/ppc/Makefile.objs | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 101e9fc591..79adf06aa3 100644
--- a
apic_eoi() calls ioapic_eoi_broadcast(), so APIC has to
select the IOAPIC Kconfig.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: "Michael S. Tsirkin"
RFC because I'm not sure the design is correct (meanwhile the fix is, however).
---
hw/intc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff
When configured with --without-default-devices, the build fails:
LINKx86_64-softmmu/qemu-system-x86_64
/usr/bin/ld: hw/i386/microvm.o: in function `microvm_devices_init':
hw/i386/microvm.c:157: undefined reference to `serial_hds_isa_init'
collect2: error: ld returned 1 exit status
When configured with --without-default-devices, the build fails:
LINKppc-softmmu/qemu-system-ppc
/usr/bin/ld: hw/ppc/sam460ex.o: in function `sam460ex_init':
hw/ppc/sam460ex.c:313: undefined reference to `ppc4xx_plb_init'
/usr/bin/ld: hw/ppc/sam460ex.c:353: undefined reference to `pp
The 8259 Interrupt Controller sits on a ISA bus.
Add the missing dependency to fix:
LINKx86_64-softmmu/qemu-system-x86_64
/usr/bin/ld: ../hw/intc/i8259_common.o: in function `pic_common_realize':
hw/intc/i8259_common.c:84: undefined reference to `isa_register_ioport'
/usr/bin/ld: hw/
Only the PC-based machines use the fw_cfg device. In particular,
the MicroVM machine does not use it. Only compile/link it when
machines require it.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Sergio Lopez
---
hw/i386/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Not all machines use the ppc_create_page_sizes_prop() helper.
Signed-off-by: Philippe Mathieu-Daudé
---
Can Kconfig can restrict to TARGET_PPC64?
---
hw/ppc/Kconfig | 10 ++
hw/ppc/Makefile.objs | 3 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/Kconfig
Various fixes when configured with --without-default-devices
and building each machine individually.
Adding the corresponding CI tests is out of the scope of this
series.
This series is pushed on top of "hw/i386: Allow building
machines without IOMMU" [*] here:
https://gitlab.com/philmd/qemu/commi
The System Management Bus is more or less a derivative of the I2C
bus, thus the Kconfig entry depends of I2C.
Not all boards providing an I2C bus support SMBus.
Use two different Kconfig entries to be able to select I2C without
selecting SMBus.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Corey
The 'usb-redir' device requires the USB core code to work. Do not
link it when there is no USB support. This fixes:
$ qemu-system-tricore -M tricore_testboard -device usb-redir
qemu-system-tricore: -device usb-redir: No 'usb-bus' bus found for device
'usb-redir'
Signed-off-by: Philippe Mathi
>From 2d85b4a0edba0bf3fa3c221dcbde7e82a6a771fa Mon Sep 17 00:00:00 2001
From: Nikola Pavlica
Date: Tue, 31 Dec 2019 18:16:28 +0100
Subject: [PATCH v3] display/gtk: get proper refreshrate
Hi,
QEMU mailing list.
This is the third revision of the patch involving the GTK display
output getting the p
On 12/30/19 7:43 PM, Wainer dos Santos Moschetta wrote:
Currently build and test commands are a single step in a
Travis's `script` block. In order to see the output
of the tests one needs to scroll down the log to find where
the build messages ended and the limit is not clear. If
they were in dif
On 12/30/19 7:43 PM, Wainer dos Santos Moschetta wrote:
The acceptance tests build on Travis is configured to print
the entire Avocado's job log in case any test fail. Usually one is
interested on failed tests only though. So this change the Travis
configuration in order to show the log of tests
On 12/19/19 11:11 PM, Brad Smith wrote:
ping.
On 11/13/2019 10:33 PM, Brad Smith wrote:
Thanks.
Reviewed-by: Brad Smith
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
On 10/18/2019 6:24 AM, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann
---
tests/vm/openbsd |
On Tue, 31 Dec 2019 16:58:10 +0100
Philippe Mathieu-Daudé wrote:
> Hi Igor,
>
> On 12/31/19 2:02 PM, Igor Mammedov wrote:
> > Series removes ad hoc RAM allocation API
> > (memory_region_allocate_system_memory)
> > and consolidates it around hostmem backend. It allows to
> > * resolve conflict
On 12/31/19 2:02 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:04 PM, Igor Mammedov wrote:
With default_ram_id is always defined, simplify
'if' conditions in vl.c and numa.c
while at it set
MachineClass::default_ram_id = "ram"
and clean up several boards that use "ram" id
Signed-off-by: Igor Mammedov
Reviewed-by: Philippe Mathieu-Daudé
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
Hi Igor,
On 12/31/19 2:02 PM, Igor Mammedov wrote:
Series removes ad hoc RAM allocation API (memory_region_allocate_system_memory)
and consolidates it around hostmem backend. It allows to
* resolve conflicts between global -mem-prealloc and hostmem's "policy" option
fixing premature alloca
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to f
On 12/31/19 2:03 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using Mac
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-
The kvm irqchip notifier is only registered if the device supports
INTx, however it's unconditionally removed. If the assigned device
does not support INTx, this will cause QEMU to crash when unplugging
the device from the system. Change it to conditionally remove the
notifier only if the notify
Follow up patches will remove automatic RAM distribution
between nodes and will make default machine types require
"memdev" option instead of legacy "mem" option.
Make tests to follow new rules and add an additional test
for legacy "mem" option on old machine type, to make sure
it won't regress in
Feature has been deprecated since 4.1 (4bb4a273),
remove it.
As result if RAM distribution wasn't specified explicitly,
the machine won't start and CLI should be changed to explicitly
assign RAM to nodes using options:
-node node,memdev (5.0 and newer machine types)
-node node,mem (4.2 an
Hi Nikola,
Cc'ing the qemu-devel list.
On 12/31/19 1:38 AM, Nikola Pavlica wrote:
On Mon, 2019-12-30 at 23:59 +0100, Philippe Mathieu-Daudé wrote:
Hi Nikola,
Thanks for your patch!
On 12/30/19 6:28 PM, Nikola Pavlica wrote:
From 70c95b18fa056b2dd0ecc202ab517bc775b986da Mon Sep 17 00:00:00
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-
Signed-off-by: Igor Mammedov
---
hw/core/numa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/core/numa.c b/hw/core/numa.c
index beb6d2e..96776ff 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -421,7 +421,7 @@ void numa_complete_configuration(MachineState *ms)
Signed-off-by: Igor Mammedov
---
hw/ppc/virtex_ml507.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c
index 6862552..651d8db 100644
--- a/hw/ppc/virtex_ml507.c
+++ b/hw/ppc/virtex_ml507.c
@@ -89,10 +89,7 @@ static void mmub
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
Use GString to pass argument to make_cli() so that it would be easy
to dynamically change test case arguments from main(). The follow up
patch will use it to change RAM size options depending on target.
While at it cleanup 'cli' freeing, using g_autofree annotation.
Signed-off-by: Igor Mammedov
When option -mem-prealloc is used with one or more memory-backend
objects, created backends may not obey configured bind policy or
creation may fail after kernel attempts to move pages according
to bind policy.
Reason is in file_ram_alloc(), which will pre-allocate
any descriptor based RAM if globa
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
It's no longer used anywhere beside main(),
so make it local variable that is used for CLI compat
purposes to keep -mem-path option working.
Under hood QEMU will use it to create
memory-backend-file,mem-path=...
backend and use its MemoryRegion as main RAM.
Signed-off-by: Igor Mammedov
---
in
Deprecation period is ran out and it's a time to flip the switch
introduced by cd5ff8333a.
Disable legacy option for new machine types and amend documentation.
Signed-off-by: Igor Mammedov
---
hw/arm/virt.c| 2 +-
hw/core/numa.c | 6 ++
hw/i386/pc.c | 1 -
hw/i386/pc
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
all boards were switched to using memdev backend for main RAM,
so we can drop no longer used memory_region_allocate_system_memory()
Signed-off-by: Igor Mammedov
---
include/hw/boards.h | 32
hw/core/numa.c | 34 --
2 files cha
the property will allow user to specify number of threads to use
in pre-allocation stage. It also will allow to reduce implicit
hostmem dependency on current_machine.
On object creation it will default to 1, but via machine
compat property it will be updated to MachineState::smp::cpus
to keep curre
Since all RAM is backed by hostmem backends, drop
global -mem-path invariant and simplify code.
Signed-off-by: Igor Mammedov
---
exec.c | 51 +--
1 file changed, 5 insertions(+), 46 deletions(-)
diff --git a/exec.c b/exec.c
index d4b769d..7b6e376
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
Function will report error that will mention global mem_path,
which was valid the only if legacy -mem-path was used and
only in case of main RAM.
However it doesn't work with hostmem backends
(for example:
"
qemu: -object memory-backend-file,id=ram0,size=128M,mem-path=foo:
backing store (nul
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
With default_ram_id is always defined, simplify
'if' conditions in vl.c and numa.c
while at it set
MachineClass::default_ram_id = "ram"
and clean up several boards that use "ram" id
Signed-off-by: Igor Mammedov
---
hw/alpha/dp264.c | 1 -
hw/arm/aspeed.c| 1 -
hw/arm/digic_board
If user provided non-sense RAM size, board will ignore it
and continue running with fixed RAM size.
Also RAM is going to be allocated by generic code, so it
won't be possible for board to fix CLI.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
PS
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov
---
hw/
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away,
so replace it with memdev allocated MemoryRegion.
The later is initialized by generic code, so board only
needs to opt in to memdev scheme by providing
MachineClass::default_ram_id
and then map memory region provided by
MachineState::ram
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializi
1 - 100 of 129 matches
Mail list logo
