On Wed, Jan 15, 2020 at 02:25:35PM +0800, pannengy...@huawei.com wrote:
> From: Pan Nengyuan
>
> Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
> patch save receive/transmit vq pointer in realize() and cleanup vqs
> through those vq pointers in unrealize(). The leak s
On 15/01/2020 04.10, Pan Nengyuan wrote:
>
> On 1/13/2020 10:32 AM, Pan Nengyuan wrote:
>>
>> On 1/12/2020 6:39 PM, Thomas Huth wrote:
[...]
>>> ... and now I had to unqueue the patch again. It is reproducibly causing
>>> one of the gitlab CI pipelines to fail with a timeout, e.g.:
>>>
>>> https:
Christophe de Dinechin writes:
> I started cutting some stuff out.
>
>> On 14 Jan 2020, at 14:04, Markus Armbruster wrote:
>>
>> Prior art:
>>
>>Presentation
>>KVM Forum 2017: Towards a More Expressive and Introspectable QEMU
>>Command Line
>>https://www.youtube.com/watch?v=gtp
在 2020/1/15 14:30, Michael S. Tsirkin 写道:
Problem is IASL disassembler still doesn't work on all hosts
we want to support. And its output isn't really stable enough
to act as a golden master.
Until we have a better tool, I propose the contributor just follows all
steps 1-6. The reason they ha
Thanks a bunch. This clarifies a number of my misconceptions about
how this is currently used. Most notably this one:
> On 15 Jan 2020, at 10:20, Markus Armbruster wrote:
>
>> We don’t want the QAPI to let arbitrary fields of a QOM object
>> be modified, do we?
>
> We already do: QMP command qo
Hi
On Wed, Jan 15, 2020 at 1:21 PM Markus Armbruster wrote:
>
> Christophe de Dinechin writes:
>
> >> To make this worthwhile, we'd have to replace dynamic QOM properties by
> >> static ones when possible. Monumental task.
> >
> > I’m sure you are right, but it’s hard for me to evaluate, given
Richard Henderson writes:
> We are not short of numbers for EXCP_*. There is no need to confuse things
> by having EXCP_VMEXIT and EXCP_SYSCALL overlap, even though the former is
> only used for system mode and the latter is only used for user mode.
>
> Signed-off-by: Richard Henderson
Revie
Richard Henderson writes:
> This is a bit tidier than open-coding the 5 lines necessary
> to initialize the target_siginfo_t. In addition, this zeros
> the remaining bytes of the target_siginfo_t, rather than
> passing in garbage.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
Le 14/01/2020 à 22:09, Richard Henderson a écrit :
> The x86_64 abi has a legacy vsyscall page. The kernel folk
> have been trying to deprecate this since at least v3.1, but
>
> (1) We don't implement the vdso that replaces vsyscalls,
> (2) As of v5.5, the vsyscall page is still enabled by defaul
On Wed, Jan 15, 2020 at 05:25:50PM +0800, Guoheyi wrote:
>
> 在 2020/1/15 14:30, Michael S. Tsirkin 写道:
> > Problem is IASL disassembler still doesn't work on all hosts
> > we want to support. And its output isn't really stable enough
> > to act as a golden master.
> >
> > Until we have a better t
On Wed, Jan 15, 2020 at 05:25:50PM +0800, Guoheyi wrote:
>
> 在 2020/1/15 14:30, Michael S. Tsirkin 写道:
> > Problem is IASL disassembler still doesn't work on all hosts
> > we want to support. And its output isn't really stable enough
> > to act as a golden master.
> >
> > Until we have a better t
Hi,
> On Jan 14, 2020, at 3:22 PM, Stefan Hajnoczi wrote:
>
> I haven't seen the link to the muser prototype shared on the list yet,
> so I'm taking the liberty of posting it for discussion:
> https://github.com/oracle/qemu/tree/multi-process-qemu-v0.4.1-muser
>
> Great that a lot of the multi-
> -Original Message-
> From: Thomas Huth [mailto:th...@redhat.com]
> Sent: 14 January 2020 17:08
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; imamm...@redhat.com; m...@redhat.com
> Cc: xuwei (O) ; Linuxarm
> Subject: Re: [PATCH] tests: acpi: update path in rebuild-expected-
A regression that was introduced, with the refactor to TranslatorOps,
drops two lines that update the PC when single-stepping is being performed.
Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps")
Reported-by: Lucien Murray-Pitts
Suggested-by: Lucien Murray-Pitts
Suggested-by: Richard
On Tue, Jan 14, 2020 at 12:11:34PM +0100, Thomas Huth wrote:
> On 13/01/2020 11.35, Alex Bennée wrote:
> > ..and extemporise a little about their state.
> >
> > Signed-off-by: Alex Bennée
> > ---
> > documentation.md | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > dif
> From: Liu Bo
>
> For fuse's queueinfo, both queueinfo array and queueinfos are allocated in
> fv_queue_set_started() but not cleaned up when the daemon process quits.
>
> This fixes the leak in proper places.
>
> Signed-off-by: Liu Bo
> Signed-off-by: Eric Ren
> ---
> tools/virtiofsd/fuse_
The i8042 device is part of the chipset of a machine, so it should
be selected by the machines or chipsets (e.g. SuperIO chipsets),
and not be enabled by default.
Signed-off-by: Thomas Huth
---
hw/input/Kconfig | 1 -
hw/isa/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff -
On Mittwoch, 15. Januar 2020 02:28:03 CET Pan Nengyuan wrote:
> >>> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> >>> index b5a7c03f26..b146387ae2 100644
> >>> --- a/hw/9pfs/virtio-9p-device.c
> >>> +++ b/hw/9pfs/virtio-9p-device.c
> >>> @@ -215,6 +215,7 @@ static void virt
Le 15/01/2020 à 12:37, Thomas Huth a écrit :
> The i8042 device is part of the chipset of a machine, so it should
> be selected by the machines or chipsets (e.g. SuperIO chipsets),
> and not be enabled by default.
>
> Signed-off-by: Thomas Huth
> ---
> hw/input/Kconfig | 1 -
> hw/isa/Kconfig
Stefan Hajnoczi writes:
> On Tue, Jan 14, 2020 at 12:11:34PM +0100, Thomas Huth wrote:
>> On 13/01/2020 11.35, Alex Bennée wrote:
>> > ..and extemporise a little about their state.
>> >
>> > Signed-off-by: Alex Bennée
>> > ---
>> > documentation.md | 9 ++---
>> > 1 file changed, 6 inser
> From: Vivek Goyal
>
> Caller can set FUSE_WRITE_KILL_PRIV in write_flags. Parse it and pass it
> to the filesystem.
>
> Signed-off-by: Vivek Goyal
> ---
> tools/virtiofsd/fuse_common.h | 6 +-
> tools/virtiofsd/fuse_lowlevel.c | 4 +++-
> 2 files changed, 8 insertions(+), 2 deletions(-
Benjamin Herrenschmidt writes:
> On Tue, 2020-01-14 at 09:51 +, Alex Bennée wrote:
>> > Well, one of the LCA talks wasn't that interesting so I started
>> > doing
>> > it and am almost done :-)
>> >
>> > I'll look at doing something for arm, riscv and ppc and send
>> > patches
>> > once I
On Wed, Jan 15, 2020 at 11:56:04AM +, Alex Bennée wrote:
>
> Stefan Hajnoczi writes:
>
> > On Tue, Jan 14, 2020 at 12:11:34PM +0100, Thomas Huth wrote:
> >> On 13/01/2020 11.35, Alex Bennée wrote:
> >> > ..and extemporise a little about their state.
> >> >
> >> > Signed-off-by: Alex Bennée
On Thu, 19 Dec 2019 14:47:59 +0800
Heyi Guo wrote:
> According to ACPI spec, _ADR should be used for device which is on a
> bus that has a standard enumeration algorithm. It does not make sense
> to have a _ADR object for devices which already have _HID and will be
> enumerated by OSPM.
>
> Sign
On Mon, Jan 13, 2020 at 05:36:44PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Hyperv's synic (that we emulate) is a feature that allows the guest
> to place some magic (4k) pages of RAM anywhere it likes in GPA.
> This confuses vhost's RAM section merging when
Christophe de Dinechin writes:
> Thanks a bunch. This clarifies a number of my misconceptions about
> how this is currently used. Most notably this one:
>
>> On 15 Jan 2020, at 10:20, Markus Armbruster wrote:
>>
>>> We don’t want the QAPI to let arbitrary fields of a QOM object
>>> be modified,
On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
> Christophe de Dinechin writes:
>
> > Thanks a bunch. This clarifies a number of my misconceptions about
> > how this is currently used. Most notably this one:
> >
> >> On 15 Jan 2020, at 10:20, Markus Armbruster wrote:
> >>
>
Some QMP command handlers can block the main loop for a relatively long
time, for example because they perform some I/O. This is quite nasty.
Allowing such handlers to run in a coroutine where they can yield (and
therefore release the BQL) while waiting for an event such as I/O
completion solves th
This moves the QMP dispatcher to a coroutine and runs all QMP command
handlers that declare 'coroutine': true in coroutine context so they
can avoid blocking the main loop while doing I/O or waiting for other
events.
For commands that are not declared safe to run in a coroutine, the
dispatcher dro
We want to be able to use qemu_aio_context in the monitor
initialisation.
Signed-off-by: Kevin Wolf
Reviewed-by: Marc-André Lureau
---
vl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/vl.c b/vl.c
index 86474a55c9..4c79a00857 100644
--- a/vl.c
+++ b/vl.c
@@ -29
Marc-André Lureau writes:
> Hi
>
> On Wed, Jan 15, 2020 at 1:21 PM Markus Armbruster wrote:
>>
>> Christophe de Dinechin writes:
>>
>> >> To make this worthwhile, we'd have to replace dynamic QOM properties by
>> >> static ones when possible. Monumental task.
>> >
>> > I’m sure you are right,
This patch adds a new 'coroutine' flag to QMP command definitions that
tells the QMP dispatcher that the command handler is safe to be run in a
coroutine.
Signed-off-by: Kevin Wolf
Reviewed-by: Marc-André Lureau
---
tests/qapi-schema/qapi-schema-test.json | 1 +
docs/devel/qapi-code-gen.txt
block_resize is safe to run in a coroutine, so use it as an example for
the new 'coroutine': true annotation in the QAPI schema.
Signed-off-by: Kevin Wolf
Reviewed-by: Marc-André Lureau
---
qapi/block-core.json | 3 ++-
blockdev.c | 6 +++---
2 files changed, 5 insertions(+), 4 deleti
Am 14.01.2020 um 21:41 hat no-re...@patchew.org geschrieben:
> Patchew URL: https://patchew.org/QEMU/20200114182735.5553-1-kw...@redhat.com/
>
> Hi,
>
> This series failed the docker-quick@centos7 build test. Please find the
> testing commands and
> their output below. If you have Docker install
> On 15 Jan 2020, at 14:01, Alex Bennée wrote:
>
> ... AFAIK the main users of arm linux user
> are compiler test cases for M-profile CPUs.
I confirm, generally unit tests.
But not necessarily, I used QEMU as the main development platform for the
Cortex-M port of µOS++, a C/C++ framework/R
This commit adds support of Resettable interface to buses and devices:
+ ResettableState structure is added in the Bus/Device state
+ Resettable methods are implemented.
+ device/bus_is_in_reset function defined
This commit allows to transition the objects to the new
multi-phase interface without
Hi all,
The purpose of this series is to split the current reset procedure
into multiple phases. This will help to solve some ordering
difficulties we have during reset.
This is a ready to merge version. I've rebased on master and followed
Richard's remarks on v6. All patches have been reviewed b
Adds trace events to reset procedure and when updating the parent
bus of a device.
Signed-off-by: Damien Hedde
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Cornelia Huck
---
hw/core/qdev.c | 29 ++---
hw/core/trace-events | 9 +
Provide a temporary device_legacy_reset function doing what
device_reset does to prepare for the transition with Resettable
API.
All occurrence of device_reset in the code tree are also replaced
by device_legacy_reset.
The new resettable API has different prototype and semantics
(resetting child
This commit make use of the resettable API to reset the device being
hotplugged when it is realized. Also it ensures it is put in a reset
state coherent with the parent it is plugged into.
Note that there is a difference in the reset. Instead of resetting
only the hotplugged device, we reset also
This commit defines an interface allowing multi-phase reset. This aims
to solve a problem of the actual single-phase reset (built in
DeviceClass and BusClass): reset behavior is dependent on the order
in which reset handlers are called. In particular doing external
side-effect (like setting an qemu
Add a function resettable_change_parent() to do the required
plumbing when changing the parent a of Resettable object.
We need to make sure that the reset state of the object remains
coherent with the reset state of the new parent.
We make the 2 following hypothesis:
+ when an object is put in a
Replace deprecated qbus_reset_all by resettable_cold_reset_fn for
the sysbus reset registration.
Apart for the raspi machines, this does not impact the behavior
because:
+ at this point resettable just calls the old reset methods of devices
and buses in the same order as qdev/qbus.
+ resettable
In qdev_set_parent_bus(), when changing the parent bus of a
realized device, if the source and destination buses are not in the
same reset state, some adaptations are required. This patch adds
needed call to resettable_change_parent() to make sure a device reset
state stays coherent with its parent
Replace deprecated qdev_reset_all by resettable_cold_reset_fn for
the ipl registration in the main reset handlers.
This does not impact the behavior for the following reasons:
+ at this point resettable just call the old reset methods of devices
and buses in the same order than qdev/qbus.
+ rese
Deprecate device_legacy_reset(), qdev_reset_all() and
qbus_reset_all() to be replaced by new functions
device_cold_reset() and bus_cold_reset() which uses resettable API.
Also introduce resettable_cold_reset_fn() which may be used as a
replacement for qdev_reset_all_fn and qbus_reset_all_fn().
Fo
Signed-off-by: Damien Hedde
Reviewed-by: Peter Maydell
Reviewed-by: Richard Henderson
---
docs/devel/index.rst | 1 +
docs/devel/reset.rst | 289 +++
2 files changed, 290 insertions(+)
create mode 100644 docs/devel/reset.rst
diff --git a/docs/devel/in
Hi Peter,
On 1/14/20 7:07 PM, Peter Xu wrote:
> On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
>> Hi Peter,
>
> Hi, Eric,
>
> [...]
>
>>>
+{
+VirtIOIOMMUEndpoint *ep;
+
+ep = g_tree_lookup(s->endpoints, GUINT_TO_POINTER(ep_id));
+if (ep) {
Ping.
发件人:gengdongjiu
收件人:pbonzini ;gengdongjiu ;mst
;imammedo ;shannon.zhaosl
;peter.maydell ;fam
;rth ;ehabkost
;mtosatti ;xuwei (O)
;Jonathan Cameron ;james.morse
;qemu-devel ;kvm
;qemu-arm
抄 送:zhengxiang (A) ;Linuxarm
时 间:2020-01-08 19:32:33
主题[PATCH v22 0/9] Add ARMv8 RAS virt
On 15/01/20 12:37, Thomas Huth wrote:
> The i8042 device is part of the chipset of a machine, so it should
> be selected by the machines or chipsets (e.g. SuperIO chipsets),
> and not be enabled by default.
>
> Signed-off-by: Thomas Huth
> ---
> hw/input/Kconfig | 1 -
> hw/isa/Kconfig | 1 +
>
On Tue, Jan 14, 2020 at 07:27:31PM +0100, Kevin Wolf wrote:
> Some QMP command handlers can block the main loop for a relatively long
> time, for example because they perform some I/O. This is quite nasty.
> Allowing such handlers to run in a coroutine where they can yield (and
> therefore release
Hi Peter,
On 1/14/20 8:04 PM, Peter Xu wrote:
> On Thu, Jan 09, 2020 at 03:43:15PM +0100, Eric Auger wrote:
>> The event queue allows to report asynchronous errors.
>> The translate function now injects faults when relevant.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v11 -> v12:
>> - reporti
Hi Peter,
On 1/14/20 7:07 PM, Peter Xu wrote:
> On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
>> Hi Peter,
>
> Hi, Eric,
>
> [...]
>
>>>
+{
+VirtIOIOMMUEndpoint *ep;
+
+ep = g_tree_lookup(s->endpoints, GUINT_TO_POINTER(ep_id));
+if (ep) {
+
Ping?
On 07.01.2020 13:53, Kamil Rytarowski wrote:
> Hello QEMU Community!
>
> Over the past year the NetBSD team has been working hard on a new user-mode
> API
> for our hypervisor that will be released as part of the upcoming NetBSD 9.0.
> This new API adds user-mode capabilities to create and
> -Original Message-
>
> > Linux PCI subsytem has an option resource_alignment that can be
> > applied to either a single device or all devices. Booting with
> > pci=resource_aligment=4096 will align each device to a page. Do you
> > think pciback should force resource_alignment=4096 for
On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt
wrote:
> On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote:
> > Note that semihosting is not a "here's a handy QEMU feature"
> > thing. It's an architecture-specific API and ABI, which should
> > be defined somewhere in a standard external
On Tue, Jan 14, 2020 at 04:25:44PM +0100, Max Reitz wrote:
> On 09.01.20 12:10, Stefan Hajnoczi wrote:
> > The qcow2 .bdrv_measure() code calculates the crypto payload offset.
> > This logic really belongs in block/crypto.c where it can be reused by
> > other image formats.
> >
> > The "luks" bloc
On Tue, Jan 14, 2020 at 04:43:36PM +0100, Max Reitz wrote:
> On 09.01.20 12:10, Stefan Hajnoczi wrote:
> > Add qemu-img measure support in the "luks" block driver.
> >
> > Signed-off-by: Stefan Hajnoczi
> > ---
> > block/crypto.c | 82 ++
> > 1 fil
On Wed, Jan 15, 2020 at 11:01:44AM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Thomas Huth [mailto:th...@redhat.com]
> > Sent: 14 January 2020 17:08
> > To: Shameerali Kolothum Thodi ;
> > qemu-devel@nongnu.org; imamm...@redhat.com; m...@redhat.com
> > Cc:
On Tue 14 Jan 2020 07:08:04 PM CET, Alex Bennée wrote:
>g_autoptr(GString) features = g_string_sized_new(60);
>
> will save you the clean-up later.
Ok, will send v2 now.
>> +if (features->len > 0) {
>> +g_string_append(features, ", ");
>> +
On Mon, Jan 13, 2020 at 06:45:21PM +0100, Olaf Hering wrote:
> With commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea a new member
> smbus_no_migration_support was added, and enabled in two places.
> With commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi
> got new elements, which are c
This is a bit more efficient than having to allocate and free memory
for each item.
The default size (60) is enough for all the existing incompatible
features or the "Unknown incompatible feature" message.
Suggested-by: Philippe Mathieu-Daudé
Signed-off-by: Alberto Garcia
Reviewed-by: Alex Benn
Daniel P. Berrangé writes:
> On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
>> Christophe de Dinechin writes:
>>
>> > Thanks a bunch. This clarifies a number of my misconceptions about
>> > how this is currently used. Most notably this one:
>> >
>> >> On 15 Jan 2020, at 10:2
On 1/15/20 2:56 PM, Alberto Garcia wrote:
This is a bit more efficient than having to allocate and free memory
for each item.
The default size (60) is enough for all the existing incompatible
features or the "Unknown incompatible feature" message.
Suggested-by: Philippe Mathieu-Daudé
Signed-of
On 1/14/20 10:35 PM, Alex Bennée wrote:
Philippe Mathieu-Daudé writes:
On 1/14/20 7:08 PM, Alex Bennée wrote:
Alberto Garcia writes:
This is a bit more efficient than having to allocate and free memory
for each item.
The default size (60) is enough for all the existing incompatible
featur
On Wed, Jan 15, 2020 at 2:29 PM Alistair Francis
wrote:
> > -*flags = cpu_mmu_index(env, 0);
> > -if (riscv_cpu_fp_enabled(env)) {
> > -*flags |= TB_FLAGS_MSTATUS_FS;
> > -}
> > +*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
>
> I don't think this is right,
* Misono Tomohiro (misono.tomoh...@jp.fujitsu.com) wrote:
> > From: Vivek Goyal
> >
> > Caller can set FUSE_WRITE_KILL_PRIV in write_flags. Parse it and pass it
> > to the filesystem.
> >
> > Signed-off-by: Vivek Goyal
> > ---
> > tools/virtiofsd/fuse_common.h | 6 +-
> > tools/virtiofsd
On 15.01.20 14:40, Stefan Hajnoczi wrote:
> On Tue, Jan 14, 2020 at 04:25:44PM +0100, Max Reitz wrote:
>> On 09.01.20 12:10, Stefan Hajnoczi wrote:
>>> The qcow2 .bdrv_measure() code calculates the crypto payload offset.
>>> This logic really belongs in block/crypto.c where it can be reused by
>>>
On 1/15/20 12:46 PM, Laurent Vivier wrote:
Le 15/01/2020 à 12:37, Thomas Huth a écrit :
The i8042 device is part of the chipset of a machine, so it should
be selected by the machines or chipsets (e.g. SuperIO chipsets),
and not be enabled by default.
The sentence "The i8042 device is part of t
Kevin Wolf writes:
> This patch adds a new 'coroutine' flag to QMP command definitions that
> tells the QMP dispatcher that the command handler is safe to be run in a
> coroutine.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Marc-André Lureau
> ---
> tests/qapi-schema/qapi-schema-test.json |
On Wed, Jan 15, 2020 at 02:00:22PM +0100, Auger Eric wrote:
> Hi Peter,
>
>
> On 1/14/20 7:07 PM, Peter Xu wrote:
> > On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
> >> Hi Peter,
> >
> > Hi, Eric,
> >
> > [...]
> >
> >>>
> +{
> +VirtIOIOMMUEndpoint *ep;
> +
> >
On Wed, Jan 15, 2020 at 02:12:20PM +0100, Auger Eric wrote:
> >> +static void virtio_iommu_report_fault(VirtIOIOMMU *viommu, uint8_t reason,
> >> + int flags, uint32_t endpoint,
> >> + uint64_t address)
> >> +{
[...]
> >> +
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: Ig
it was deprecated since 4.0 by commit
cb79224b7 (deprecate -mem-path fallback to anonymous RAM)
Deprecation period ran ont 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: ehabk...@re
the new field will be used by boards to get access to main
RAM memory region and will help to save boiler plate in
boards which often add a field or variable just for this
purpose.
Memory region will be equivalent to what currently used
memory_region_allocate_system_memory() is returning apart
fro
Allow a machine to opt in for hostmem backend based initial
RAM even if user used 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_i
v2:
- fix compile errors on mingw32 host by introducing RAM_ADDR_UFMT [11/86]
- replace "[PATCH 43/86] hppa: drop RAM size fixup" with alternative
patches made by Philippe (which effectively do the same thing but other
way around)
- ppc440: fix crash and add suggested valid RAM size
various foo_rambits() hardcode mapping of RAM sizes to RAM feature bits,
which is hard to reuse and repeats over and over.
Convert maps into GLib's hash tables and perform mapping using
common mapping function.
Follow up patch will reuse tables for actually checking ram-size
property.
Signed-off
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 supposed that SOC will check if "-m" provided
RAM size is valid by setting "ram-size" property and
then board would read back valid (possibly corrected
value) to map RAM MemoryReging with valid size.
Well it isn't doing so, since check is called only
indirectly from
aspeed_sdmc_reset()->asc-
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
In case of NUMA there are 2 cases to consider:
1. '-numa node,memdev', the only one that will be available
for 5.0 and newer machine types.
In this case reuse current behavior, with only difference
memdevs are put into MachineState::ram container +
a temporary glue to keep memory_
It was useless to try fixup ram_size and print warning
on guest access to config register to begin with.
Now previous patch made sure that SDMC can not be realized
with invalid RAM size, so there is no case where warning
and not used ram_size fixup could be triggered.
So remove now dead code.
Si
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-
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
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
1 - 100 of 362 matches
Mail list logo