John Snow writes:
> On 1/23/20 2:19 AM, Markus Armbruster wrote:
[...]
>> Any conventional parser can be made streaming by turning it into a
>> coroutine. This is probably the simplest solution for handwritten
>> streaming LL parsers, because it permits recursive descent. In Python,
>> I'd try
On 23/01/2020 22.37, Philippe Mathieu-Daudé wrote:
> On 1/23/20 7:29 PM, Philippe Mathieu-Daudé wrote:
>> On 1/23/20 5:39 AM, Thomas Huth wrote:
>>> On 23/01/2020 01.36, Philippe Mathieu-Daudé wrote:
The boot-serial test uses SeaBIOS on HPPA, and expects to read the
"SeaBIOS wants SYSTEM
When inserting breakpoints, we need to invalidate related TBs to apply
helper call. This is done by breakpoint_invalidate(). But many users
found the BPs sometimes never hit.
In system mode emulation, the BPs are global in guest but not particular
address space. The issue is that the current
>
> Chanegs for v20.
> Reorderd patches.
> Squashed v19 changes.
>
> Changes for v19.
> Follow tcg changes.
> Cleanup cpu.c.
> simplify rx_cpu_class_by_name and rx_load_image move to rx-virt.
>
> My git repository is bellow.
> git://git.pf.osdn.net/git
"Richard W.M. Jones" writes:
> On Thu, Jan 23, 2020 at 07:53:57PM +0100, Max Reitz wrote:
>> On 23.01.20 19:35, Richard W.M. Jones wrote:
>> > - NBD multi-conn. In my tests this makes a really massive
>> >performance difference in certain situations. Again, virt-v2v has
>> >a lot of
Public bug reported:
Qemu Version: 4.2.0
Launch command:
qemu-system-x86_64 -nographic -drive file=fs.img,index=1,media=disk,format=raw
-drive file=xv6.img,index=0,media=disk,format=raw -smp 2 -m 512
How to reproduce?
1.) Use/install latest release of qemu (4.2.0 at time of writing)
2.)
# chroot $root
...
# qemu-alpha-static -D logfile -d in_asm ./Bootstrap.cmk/cmake ..
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860553
Title:
cmake crashes on qemu-alpha-user with Illegal
** Description changed:
Qemu Version: 4.2.0
- Launch command:
+ Launch command:
qemu-system-x86_64 -nographic -drive
file=fs.img,index=1,media=disk,format=raw -drive
file=xv6.img,index=0,media=disk,format=raw -smp 2 -m 512
- How to reproduce?
+ How to reproduce?
1.) Use/install
On Thu, Jan 23, 2020 at 07:47:19PM -0200, Wainer dos Santos Moschetta wrote:
>
> On 1/22/20 7:02 AM, Andrew Jones wrote:
> > On Tue, Jan 21, 2020 at 10:27:51PM -0300, Wainer dos Santos Moschetta wrote:
> > > +def test_aarch64_virt_kvm(self):
> > > +"""
> > > +:avocado:
On 24/01/2020 01.51, Philippe Mathieu-Daudé wrote:
> This is the AVR port from Michael release (merge) candidate 2.
>
> Since v1 [1]:
> - Addressed Thomas comments
> - Fixed a non-critical bug in ATmega (incorrect SRAM base address)
> - Added ELF parsing requested by Aleksandar
> - Dropped
Haha, fair enough. I just copied that line from one of the other functions
in that file, which all use the same style. The check is actually a bit
worse than it looks because PRV_S is defined to be 1. Hence, the whole
thing is equivalent to just writing `env->priv == PRV_U`. I can send out a
new
Can someone remind me how I can print the disassembly in this case?
root@epyc:~> qemu-alpha-static -cpu help
Available CPUs:
ev4-alpha-cpu
ev5-alpha-cpu
ev56-alpha-cpu
ev6-alpha-cpu
ev67-alpha-cpu
ev68-alpha-cpu
pca56-alpha-cpu
root@epyc:~> export QEMU_CPU=ev68-alpha-cpu
On 1/24/20 5:39 AM, Richard Henderson wrote:
> # chroot $root
> ...
> # qemu-alpha-static -D logfile -d in_asm ./Bootstrap.cmk/cmake ..
Last one seems to be a halt instruction:
IN:
0x0040007fd988: halt
Illegal instruction
Full log in [1].
> [1]
On 24/01/2020 01.51, Philippe Mathieu-Daudé wrote:
> From: Michael Rolnik
>
> Signed-off-by: Michael Rolnik
> Message-Id: <20200118191416.19934-16-mrol...@gmail.com>
> Signed-off-by: Richard Henderson
> [PMD: Fixed typos]
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> rc2: Fixed typos,
On 01/22/20 20:07, Cornelia Huck wrote:
> On Wed, 22 Jan 2020 18:56:47 +
> Alex Bennée wrote:
>
>> Laszlo Ersek writes:
>>
>>> On 01/22/20 13:30, Alex Bennée wrote:
Stefan Hajnoczi writes:
> Around 66% of qemu.git commits since v4.1.0 include a Message-Id: tag.
On Wed, 22 Jan 2020 23:36:22 +0100
Christian Schoenebeck wrote:
> On Mittwoch, 22. Januar 2020 22:19:05 CET Greg Kurz wrote:
> > On Tue, 21 Jan 2020 01:16:21 +0100
> >
> > Christian Schoenebeck wrote:
> > > The previous, already existing readdir test simply used a 'count'
> > > parameter big
On Tue, 21 Jan 2020 01:23:55 +0100
Christian Schoenebeck wrote:
> This patch is not intended to be merged. It just provides a
Well I like the idea of having such a benchmark available.
It could probably be merged after a few changes...
> temporary benchmark foundation for coneniently A/B
On Wed, 22 Jan 2020 23:32:45 +0100
Philippe Mathieu-Daudé wrote:
$SUBJECT: s/Only test Xen as superuser/Test Xen only as superuser/ ?
> When running the test unprivileged, we get:
>
> $ avocado --show=app,machine run tests/acceptance/virtio_seg_max_adjust.py
> JOB ID :
Philippe Mathieu-Daudé writes:
> On 12/17/19 6:32 PM, Philippe Mathieu-Daudé wrote:
>> Fix some trivial warnings when building with -O3.
>> Philippe Mathieu-Daudé (6):
>>audio/audio: Add missing fall through comment
>>hw/display/tcx: Add missing fall through comments
>>
v3:
- due to libvirt not being ready, postpone till 5.1
* [PATCH v2 82/86] numa: forbid '-numa node, mem' for 5.0 and newer
machine types
and depended
[PATCH v2 86/86] numa: remove deprecated implicit RAM distribution
between nodes
- drop as not related "[PATCH v2 85/86]
I took the time and recreated a MAAS setup (latest stable 2.2) on s390x and it
looks like this:
- I could start a deployment and ran through the states:
- Power On, Commissioning (Performing PXE boot)
- Power On, Commissioning (Gathering Information)
- Power On, Ready
- Power Off,
Property will contain link to memory backend that will be
used for backing initial RAM.
Follow up commit will alias -mem-path and -mem-prealloc
CLI options into memory backend options to make memory
handling consistent (using only hostmem backend family
for guest RAM allocation).
Signed-off-by:
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
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
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
If the user provided too large a RAM size, the code used to
complain and trim it to the max size. Now tht RAM is allocated by
generic code, that's no longer possible, so generate an error and
exit instead.
Signed-off-by: Igor Mammedov
Reviewed-by: Philippe Mathieu-Daudé
---
v3:
* rephrase
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
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
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
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
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
From: Philippe Mathieu-Daudé
The firmware has to reside in the PDC range. If the Elf file
expects to load it below FIRMWARE_START, it is incorrect,
regardless the RAM size.
Acked-by: Helge Deller
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Signed-off-by: Igor
From: Philippe Mathieu-Daudé
The hardware expects DIMM slots of 1 or 2 GB, allowing up to
4 GB of memory. We want to accept the same amount of memory the
hardware can deal with. DIMMs of 768MB are not available.
However we have to deal with a firmware limitation: currently
SeaBIOS only supports
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
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
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
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
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
---
CC: ehabk...@redhat.com
CC: pbonz...@redhat.com
---
include/hw/boards.h | 32
hw/core/numa.c
Signed-off-by: Juan Quintela
---
We can't trust that error_in is not NULL. Create a local_error.
---
migration/migration.c | 4 +++-
migration/ram.c | 2 +-
migration/ram.h | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/migration/migration.c
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
Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Juan Quintela
---
migration/ram.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index d2208b5534..f95d656c26 100644
---
Be sure that we are not doing neither read/write after shutdown of the
QEMUFile.
Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Juan Quintela
---
Set error in case that there is none (dave)
---
migration/qemu-file.c | 22 +-
1 file
We need some of the fields without having to poison everything else.
Signed-off-by: Juan Quintela
---
MAINTAINERS | 1 +
include/exec/ram_addr.h | 40 +-
include/exec/ramblock.h | 64 +
3 files changed, 66
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
On 23.01.2020 02:14, John Snow wrote:
> On 12/23/19 12:51 PM, Alexander Popov wrote:
>> Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
>> using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
>> ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
On 10/01/20 16:30, Marc-André Lureau wrote:
> The following patch will need to handle properties registration during
> class_init time. Let's use a device_class_set_props() setter.
If you don't mind, I'll also rename "props" to "props_" so that we can
more easily catch conflicts (which will be
On Wed, Jan 22, 2020 at 10:08:12PM +0100, salva...@qindel.com wrote:
Existing callers like vl.c:main() do:
if (log_file) {
qemu_set_log_filename(log_file, _fatal);
}
Please fix up existing callers. They won't need to check for NULL
anymore before calling qemu_set_log_filename().
On Tue, 21 Jan 2020 01:30:10 +0100
Christian Schoenebeck wrote:
> Make top half really top half and bottom half really bottom half:
>
> Each T_readdir request handling is hopping between threads (main
> I/O thread and background I/O driver threads) several times for
> every individual directory
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
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
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
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
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
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
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
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
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
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
From: "Dr. David Alan Gilbert"
passthrough_ll is one of the examples in the upstream fuse project
and is the main part of our daemon here. It passes through requests
from fuse to the underlying filesystem, using syscalls as directly
as possible.
>From libfuse fuse-3.8.0
Signed-off-by: Dr.
From: Xiao Yang
Signed-off-by: Xiao Yang
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Dr. David Alan Gilbert
---
tools/virtiofsd/buffer.c | 7 +++--
tools/virtiofsd/fuse_common.h| 46 +---
tools/virtiofsd/fuse_lowlevel.c | 13 -
On Thu, Jan 23, 2020 at 09:27:54AM +0100, Markus Armbruster wrote:
> Alex Bennée writes:
>
> > Stefan Hajnoczi writes:
> >
> >> Around 66% of qemu.git commits since v4.1.0 include a Message-Id: tag.
> >> Hooray!
> >>
> >> Message-Id: references the patch email that a commit was merged from.
>
Hi
On Thu, Jan 23, 2020 at 3:29 PM Paolo Bonzini wrote:
>
> This patch caught my attention because of the typo in the function, but
Ah! a french "défaut".
> I also noticed that get_default is never set to anything but
> object_property_get_defval.
>
> What do you think about removing the
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
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
Allow machine to opt in for hostmem backend based initial RAM
even if user uses old -mem-path/prealloc options by providing
MachineClass::default_ram_id
Follow up patches will incrementally convert machines to new API,
by dropping memory_region_allocate_system_memory() and setting
default_ram_id
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
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
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
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
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
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
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
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
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported or sometimes
crash like this:
%QEMU -M bamboo -m 1
exec.c:1926: find_ram_offset: Assertion `size != 0' failed.
Aborted (core dumped)
Also RAM is going to be allocated by generic
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.
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
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
Signed-off-by: Igor Mammedov
Reviewed-by: Philippe Mathieu-Daudé
---
CC: da...@gibson.dropbear.id.au
CC: qemu-...@nongnu.org
CC: edgar.igles...@gmail.com
---
hw/ppc/virtex_ml507.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/ppc/virtex_ml507.c
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
---
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
From: Stefan Hajnoczi
Notify reply support is unused by virtiofsd. The code would need to be
updated to validate input buffer sizes. Remove this unused code since
changes to it are untestable.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Daniel P. Berrangé
Signed-off-by: Dr. David Alan
Signed-off-by: Juan Quintela
---
migration/ram.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 125c6d0f60..19caf5ed4d 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -929,7 +929,7 @@ struct {
* false.
*/
-static
From: "Dr. David Alan Gilbert"
All of the fuse files include config.h and define GNU_SOURCE
where we don't have either under our build - remove them.
Fixup path to the kernel's fuse.h in the QEMUs world.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Philippe Mathieu-Daudé
Tested-by:
On Wed, Jan 22, 2020 at 05:42:10PM -0500, John Snow wrote:
>
>
> On 12/24/19 8:00 AM, Daniel P. Berrangé wrote:
> > Based on experiance in libvirt, this is an even larger job than (4),
> > as the feature set here is huge. Much of it directly ties into the
> > config problem, as to deal with
v3:
- due to libvirt not being ready, postpone till 5.1
* [PATCH v2 82/86] numa: forbid '-numa node, mem' for 5.0 and newer
machine types
and depended
[PATCH v2 86/86] numa: remove deprecated implicit RAM distribution
between nodes
- drop as not related "[PATCH v2 85/86]
Property will contain link to memory backend that will be
used for backing initial RAM.
Follow up commit will alias -mem-path and -mem-prealloc
CLI options into memory backend options to make memory
handling consistent (using only hostmem backend family
for guest RAM allocation).
Signed-off-by:
it has been deprecated since 4.0 by commit
cb79224b7 (deprecate -mem-path fallback to anonymous RAM)
Deprecation period ran out and it's time to remove it
so it won't get in a way of switching to using hostmem
backend for RAM.
Signed-off-by: Igor Mammedov
---
CC:libvir-l...@redhat.com
CC:
Hi
On Thu, Jan 23, 2020 at 3:09 PM Paolo Bonzini wrote:
>
> On 10/01/20 16:30, Marc-André Lureau wrote:
> > The following patch will need to handle properties registration during
> > class_init time. Let's use a device_class_set_props() setter.
>
> If you don't mind, I'll also rename "props" to
On Mittwoch, 22. Januar 2020 23:59:54 CET Greg Kurz wrote:
> On Tue, 21 Jan 2020 01:17:35 +0100
>
> Christian Schoenebeck wrote:
> > This patch is not intended to be merged. It resembles
> > an issue (with debug messages) where the splitted
> > readdir test fails because server is interrupted
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
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
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
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
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
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
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
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
From: Philippe Mathieu-Daudé
The region in range [0xf000 - 0xf100] is the PDC area
(Processor Dependent Code), where the firmware is loaded.
This region has higher priority than the main memory.
When the machine has more than 3840MB of RAM, there is an
overlap. Since the PDC is closer
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
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
1 - 100 of 759 matches
Mail list logo
