From: Johannes Berg
This is really simple, since we know whether a response is
already requested or not, so we can just send a (successful)
response when there isn't one already.
Given that, it's not all _that_ useful but the master can at
least be sure the message was processed, and we can exer
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
exis
From: Johannes Berg
If we use NULL, we just get the main program default mainloop
here. Using g_main_context_get_thread_default() has basically
the same effect, but it lets us start different devices in
different threads with different mainloops, which can be useful.
Reviewed-by: Stefan Hajnoczi
Hi,
Here's a repost of all the patches I sent back in August, with the
in-band notifications rebased over the reset patch, so IDs have now
changed a bit.
I've marked this all as v5 even if it really wasn't for all of them,
just the VugDev main fd cleanup patch was at v4 before.
I've also collect
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
sendi
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according to
From: Johannes Berg
The code here is odd, for example will it print out invalid
file descriptor numbers that were never sent in the message.
Clean that up a bit so it's actually possible to implement
a device that uses polling.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost-u
Paolo Bonzini writes:
> On 22/01/20 06:41, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> Il mar 21 gen 2020, 15:22 Markus Armbruster ha scritto:
>>>
> To see it a different way, these are the "C bindings" to QMP, just that
> the implementation is an in-process call rather th
From: Aleksandar Markovic
These FS_IOC32_VERSION ioctls are identical to
FS_IOC_VERSION ioctls, but without the anomaly of their
number defined as if their third argument is of type long, while
it is treated internally in kernel as is of type int.
Reviewed-by: Laurent Vivier
Signed-off-by: Alek
From: Aleksandar Markovic
These FS_IOC32_FLAGS ioctls are identical to
FS_IOC_FLAGS ioctls, but without the anomaly of their
number defined as if their third argument is of type long, while
it is treated internally in kernel as is of type int.
Reviewed-by: Laurent Vivier
Signed-off-by: Aleksand
From: Aleksandar Markovic
kcov is kernel code coverage tracing tool. It requires kernel 4.4+
compiled with certain kernel options.
This patch checks if kcov header "sys/kcov.h" is present on build
machine, and stores the result in variable CONFIG_KCOV, meant to
be used in linux-user code related
The following changes since commit 3e08b2b9cb64bff2b73fa9128c0e49bfcde0dd40:
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20200121'
into staging (2020-01-21 15:29:25 +)
are available in the Git repository at:
git://github.com/vivier/qemu.git tags/linux-user-for-5.0
From: Xinyu Li
In init_guest_space, we need to mmap guest space. If the return address
of first mmap is not aligned with align, which was set to MAX(SHMLBA,
qemu_host_page_size), we need unmap and a new mmap(space is larger than
first size). The new size is named real_size, which is aligned_size
From: Aleksandar Markovic
KCOV_ENABLE and KCOV_DISABLE play the role in kernel coverage
tracing. These ioctls do not use the third argument of ioctl()
system call and are straightforward to implement in QEMU.
Reviewed-by: Laurent Vivier
Signed-off-by: Aleksandar Markovic
Message-Id: <157921499
From: Filip Bozuta
This patch implements functionalities of following ioctls:
RTC_IRQP_READ, RTC_IRQP_SET - Getting/Setting IRQ rate
Read and set the frequency for periodic interrupts, for RTCs
that support periodic interrupts. The periodic interrupt must
be separately enabled or di
From: Aleksandar Markovic
A very specific thing for these two ioctls is that their code
implies that their third argument is of type 'long', but the
kernel uses that argument as if it is of type 'int'. This anomaly
is recognized also in commit 6080723 (linux-user: Implement
FS_IOC_GETFLAGS and FS
From: Aleksandar Markovic
KCOV_INIT_TRACE ioctl plays the role in kernel coverage tracing.
This ioctl's third argument is of type 'unsigned long', and the
implementation in QEMU is straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Aleksandar Markovic
Message-Id: <1579214991-19602-13-
From: Filip Bozuta
This patch implements functionalities of following ioctls:
RTC_PLL_GET - Getting PLL correction
Read the PLL correction for RTCs that support PLL. The PLL correction
is returned in the following structure:
struct rtc_pll_info {
int pll_ctrl;
From: Filip Bozuta
Function "do_ioctl()" located in file "syscall.c" was missing
an option for TYPE_LONG and TYPE_ULONG. This caused some ioctls
to not be recognised because they had the third argument that was
of type 'long' or 'unsigned long'.
For example:
Since implemented ioctls RTC_IRQP_SE
From: Aleksandar Markovic
FDFMTBEG, FDFMTTRK, and FDFMTEND ioctls provide means for controlling
formatting of a floppy drive.
FDFMTTRK's third agrument is a pointer to the structure:
struct format_descr {
unsigned int device,head,track;
};
defined in Linux kernel header .
Since all fields
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.
>> This information is helpful to anyone wishing to refer back to email
>> discussion
From: Aleksandar Markovic
FDSETEMSGTRESH, FDSETMAXERRS, and FDGETMAXERRS ioctls are commands
for controlling error reporting of a floppy drive.
FDSETEMSGTRESH's third agrument is a pointer to the structure:
struct floppy_max_errors {
unsigned int
abort, /* number of errors to be
From: Filip Bozuta
This patch implements functionalities of following ioctls:
RTC_WKALM_SET, RTC_WKALM_GET - Getting/Setting wakeup alarm
Some RTCs support a more powerful alarm interface, using these
ioctls to read or write the RTC's alarm time (respectively)
with this structure:
From: Filip Bozuta
This patch implements functionalities of following ioctls:
RTC_VL_READ - Read voltage low detection information
Read the voltage low for RTCs that support voltage low.
The third ioctl's' argument points to an int in which
the voltage low is returned.
RTC_VL_CLR -
From: Filip Bozuta
This patch implements functionalities of following ioctls:
RTC_AIE_ON, RTC_AIE_OFF - Alarm interrupt enabling on/off
Enable or disable the alarm interrupt, for RTCs that support
alarms. The third ioctl's argument is ignored.
RTC_UIE_ON, RTC_UIE_OFF - Update interrup
From: Richard Henderson
With bad luck, we can wind up with no space at all for brk,
which will generally cause the guest malloc to fail.
This bad luck is easier to come by with ET_DYN (PIE) binaries,
where either the stack or the interpreter (ld.so) gets placed
immediately after the main executa
From: Filip Bozuta
This patch implements functionalities of following ioctls:
RTC_RD_TIME - Getting RTC time
Returns this RTC's time in the following structure:
struct rtc_time {
int tm_sec;
int tm_min;
int tm_hour;
int tm_mday;
On Tue, Jan 21, 2020 at 7:30 PM Stefan Berger wrote:
>
> From: Stefan Berger
>
> Extend the tpm_spapr frontend with VM suspend and resume support.
>
> Signed-off-by: Stefan Berger
Reviewed-by: Marc-André Lureau
> ---
> hw/tpm/tpm_spapr.c | 52 -
>
On 23/01/2020 16:11, David Gibson wrote:
> On Wed, Jan 22, 2020 at 06:14:37PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 22/01/2020 17:32, David Gibson wrote:
>>> On Tue, Jan 21, 2020 at 06:25:36PM +1100, Alexey Kardashevskiy wrote:
On 21/01/2020 16:11, David Gibson wrote:
>>>
This fixes a confusion in the help output. (Although, if you squint
long enough at the '-cpu help' output, you _do_ notice that
"Skylake-Client-noTSX-IBRS" is an alias of "Skylake-Client-v3";
similarly for Skylake-Server-v3.)
Without this patch:
$ qemu-system-x86 -cpu help
...
x86 Sk
On 23/01/20 10:01, Kashyap Chamarthy wrote:
> This fixes a confusion in the help output. (Although, if you squint
> long enough at the '-cpu help' output, you _do_ notice that
> "Skylake-Client-noTSX-IBRS" is an alias of "Skylake-Client-v3";
> similarly for Skylake-Server-v3.)
>
> Without this pa
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.
>>>
TBH I'd really want to see how this worked as we didn't push anything to
Bionic that would have changed this recently.
I checked and the only change in that regard is really old.
It was for bug 1790901 which was a prereq for real IPXE on s390x.
So I doubt that MAAS could have worked before that.
N
First check - as assumed - the old style config always failed.
It went into netboot, netboot fails and then it bails out.
root@testkvm-bionic-from:~# virsh start netboot --console
Domain netboot started
Connected to domain netboot
Escape character is ^]
done
Using IPv4 address: 192.168.122.33
On Thu, 23 Jan 2020 08:05:33 +0100
Thomas Huth wrote:
> The code in translate_one() leaks a stack address via "s->field" parameter:
>
> static DisasJumpType translate_one(CPUS390XState *env, DisasContext *s)
> {
> DisasJumpType ret = DISAS_NEXT;
> DisasFields f;
> [...]
> s
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 SELi
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 en
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 compar
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.
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: ehabk.
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
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] nu
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 syn
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 Wed, 22 Jan 2020 22:47:42 +0100
Philippe Mathieu-Daudé wrote:
> > This test is failing on OSX:
> >
> > TestFail: machine type pc-i440fx-2.0:
> >
> > Looking at my job-results/job-2020-01-22T17.54-92b7fae/job.log:
> >
> > Unexpected error in object_property_find() at qom/object.c:1201:
> >
On Tue, 21 Jan 2020 01:26:15 +0100
Christian Schoenebeck wrote:
> This patch is just a temporary benchmark hack, not intended
> to be merged!
>
> 9pfs synth driver's readdir() implementation has a severe
> n-square performance problem. This patch is a quick and dirty
> hack to prevent that perfo
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.
>
On Wed, 22 Jan 2020 23:32:42 +0100
Philippe Mathieu-Daudé wrote:
> Do not remove unavailable machines, this fixes:
>
> VirtioMaxSegSettingsCheck.test_machine_types: ERROR: list.remove(x): x not
> in list (0.12 s)
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/acceptance/virtio_seg
I've finally posted a patch for this:
https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05204.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1661815
Title:
Stack address is returned from
This patch caught my attention because of the typo in the function, but
I also noticed that get_default is never set to anything but
object_property_get_defval.
What do you think about removing the method and just relying on defval?
In practice there would be a new patch that squashes 7, 10 and
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
>>hw/net/imx_fe
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 : b631d5d692e49b791
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, &error_fatal);
}
Please fix up existing callers. They won't need to check for NULL
anymore before calling qemu_set_log_filenam
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
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 wit
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 method
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, Read
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
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]
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 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: ehabk.
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'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.
It isn't doing so, since check is called only
indirectly from
aspeed_sdmc_reset()->asc->comp
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 introduce a field or variable just for
this purpose.
Memory region will be equivalent to what currently used
memory_region_allocate_system_memory() is returning apa
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 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 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 comm
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
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
Reviewed
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 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
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
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
1 - 100 of 759 matches
Mail list logo
