The SSE-300 has a Cortex-M55 (which was the whole reason for us
modelling it), but we forgot to actually update the code to let it
have a different CPU type from the IoTKit and SSE-200. Add CPU type
as a field for ARMSSEInfo instead of hardcoding it to always use a
Cortex-M33.
Buglink:
From: Paolo Bonzini
System headers may include templates if compiled with a C++ compiler,
which cause the compiler to complain if qemu/osdep.h is included
within a C++ source file's 'extern "C"' block. Add
an 'extern "C"' block directly to qemu/osdep.h, so that
system headers can be kept out of
Patchew URL:
https://patchew.org/QEMU/20210417194205.17057-1-peter.mayd...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210417194205.17057-1-peter.mayd...@linaro.org
Subject: [PULL 0/7] queue of
available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20210417
for you to fetch changes up to 277aed998ac2cd3649bf0e13b22f47769519eb61:
accel/tcg: avoid re-translating one-shot instructions (2021-04-17 18:51
From: Alex Bennée
By definition a single instruction is capable of being an IO
instruction. This avoids a problem of triggering a cpu_io_recompile on
a non-recorded translation which then fails because it expects
tcg_tb_lookup() to succeed unconditionally. The normal use case
requires a TB to be
On Wed, 14 Apr 2021 at 14:58, Mark Cave-Ayland
wrote:
>
> On 14/04/2021 13:48, Thomas Huth wrote:
> > I've seen some intermittend, non-reproducible crashes with usermode QEMU in
> > some of
> > my CI runs, e.g.:
> >
> > https://gitlab.com/thuth/qemu/-/jobs/1178256498#L3876
> >
> >
From: Paolo Bonzini
glib-compat.h is sort of like a system header, and it needs to include
system headers (glib.h) that may dislike being included under
'extern "C"'. Move it right after all system headers and before
all other QEMU headers.
Signed-off-by: Paolo Bonzini
Reviewed-by: Daniel P.
SSE-300 currently shares the SSE-200 Property array. This is
bad principally because the default values of the CPU0_FPU
and CPU0_DSP properties disable the FPU and DSP on the CPU.
That is correct for the SSE-200 but not the SSE-300.
Give the SSE-300 its own Property array with the correct
SSE-300
From: Alex Bennée
This is a left over erroneous check from the days front-ends handled
io start/end themselves. Regardless just because IO could be performed
on the last instruction doesn't obligate the front end to do so.
This fixes an abort faced by the aspeed execute-in-place support which
Mostly osdep.h puts the system includes at the top of the file; but
there are a couple of exceptions where we include a system header
halfway through the file. Move these up to the top with the rest
so that all the system headers we include are included before
we include os-win32.h or os-posix.h.
From: Michael Tokarev
While processing SCSI i/o requests in mptsas_process_scsi_io_request(),
the Megaraid emulator appends new MPTSASRequest object 'req' to
the 's->pending' queue. In case of an error, this same object gets
dequeued in mptsas_free_request() only if SCSIRequest object
On 4/18/21 7:30 AM, Philippe Mathieu-Daudé wrote:
> From: Michael Tokarev
>
> While processing SCSI i/o requests in mptsas_process_scsi_io_request(),
> the Megaraid emulator appends new MPTSASRequest object 'req' to
> the 's->pending' queue. In case of an error, this same object gets
> dequeued
Since commit 2cdfcf272d ("memory: assign MemoryRegionOps to all
regions"), all newly created regions are assigned with
unassigned_mem_ops (which might be then overwritten).
When using aliased container regions, and there is no region mapped
at address 0 in the container, the
We fixed a bug to make QEMU act more like hardware, which now means that
PMP must be configured in M-mode.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1923197
Title:
RISC-V priviledged
On 4/16/21 1:33 PM, Philippe Mathieu-Daudé wrote:
> Cc'ing maintainers.
>
> On 4/16/21 1:27 PM, Philippe Mathieu-Daudé wrote:
>> On 4/16/21 12:22 PM, Michael Tokarev wrote:
>>> During previous attempt to fix CVE-2021-3392 it was discovered
>>> that MPTSASState.pending is actually not used. So
On 4/18/21 7:14 AM, Philippe Mathieu-Daudé wrote:
> On 4/16/21 1:33 PM, Philippe Mathieu-Daudé wrote:
>> Cc'ing maintainers.
>>
>> On 4/16/21 1:27 PM, Philippe Mathieu-Daudé wrote:
>>> On 4/16/21 12:22 PM, Michael Tokarev wrote:
During previous attempt to fix CVE-2021-3392 it was discovered
On 4/17/21 9:41 PM, Peter Maydell wrote:
> This pullreq contains fixes for the remaining "not fixed yet" issues
> in the 6.0 Planning page:
> * Fix compile failures of C++ files with new glib headers
> * mps3-an547: Use correct Cortex-M55 CPU and don't disable its FPU
> * accel/tcg: Fix
** Description changed:
Building QEMU with GLib newer than 2.58.3 corrupts tap networking on macOS
hosts.
Tap device was provided by Tun/Tap kernel extension installed from brew:
brew install tuntap
Checked revisions:
553032d (v5.2.0)
6d40ce0 (v6.0.0-rc1)
Host:
Marc-André Lureau writes:
> Hi
>
> On Fri, Apr 16, 2021 at 6:59 PM Marc-André Lureau <
> marcandre.lur...@gmail.com> wrote:
>
>> Hi
>>
>> On Fri, Apr 16, 2021 at 6:51 PM Markus Armbruster
>> wrote:
>>
>>> Marc-André, I'd like your opinion for this one, in particular the use of
>>>
Li Zhang writes:
> On Fri, Apr 16, 2021 at 4:50 PM Markus Armbruster wrote:
[...]
>> As I wrote in my review of v1, this function copies from
>> monitor_data_init(), monitor_init_qmp(), and monitor_flush_locked().
>> Feels like a refactoring would be in order. Doing it on top might be
>>
John Snow writes:
[...]
> (Random aside on patch submission process: I do dislike how when I
> change the topic of a commit, I lose out on git-backport-diff
> functionality. I wish I had a persistent ID for commits that survived
> beyond title changes. Sometimes I debate scripting adding some
To be sure an AddressSpace is zero-based, forbid changing
base address of MemoryRegion used as AddressSpace container.
Signed-off-by: Philippe Mathieu-Daudé
---
Based-on: <20210417103028.601124-1-f4...@amsat.org>
---
softmmu/memory.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On 4/17/21 2:53 PM, Philippe Mathieu-Daudé wrote:
> To be sure an AddressSpace is zero-based, forbid changing
> base address of MemoryRegion used as AddressSpace container.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Based-on: <20210417103028.601124-1-f4...@amsat.org>
> ---
>
John Snow writes:
> On 4/14/21 11:04 AM, Markus Armbruster wrote:
>> John Snow writes:
>>
>
> Thanks for taking this on. I realize it's a slog.
>
> (Update: much later: AUUUGH WHY DID I DECIDE TO WRITE DOCS. MY HUBRIS)
LOL!
>>> Signed-off-by: John Snow
>>> ---
>>> scripts/qapi/expr.py
Eduardo Habkost writes:
[...]
> I would make live migration policy an enum, just to make sure
> we are explicit about the requirements:
>
> - UNKNOWN: this is the current state in QEMU 6.0, where we don't
> really know what the user expects.
> This can be the default on existing versioned
Hi,
This series is the result of a long thread with Peter:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg788366.html
and IRC chats...
AddressSpace are physical address view and shouldn't be using
non-zero base address. The correct way to map a MR used as AS
root is to use a MR alias.
The ASIC PCI bridge chipset from Motorola is named 'Raven'.
This chipset is used in the PowerPC Reference Platform (PReP),
but not restricted to it. Rename it accordingly.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/{prep.c => raven.c} | 0
MAINTAINERS | 2 +-
The flash mmio region is exposed as an AddressSpace.
AddressSpaces must not be sysbus-mapped, therefore map
the region using an alias.
Signed-off-by: Philippe Mathieu-Daudé
[ clg : Fix DMA_FLASH_ADDR() ]
Signed-off-by: Cédric Le Goater
Message-Id: <20210312182851.1922972-3-f4...@amsat.org>
---
From: Cédric Le Goater
Instead of passing the memory address space region, simply use the RAM
memory region instead. This simplifies RAM accesses.
This patch breaks migration compatibility.
Fixes: c4e1f0b48322 ("aspeed/smc: Add support for DMAs")
Reviewed-by: Philippe Mathieu-Daudé
The PCI I/O region is exposed as AddressSpace. AddressSpaces must
not be sysbus-mapped (to be zero-based), therefore map the region
using an alias.
As the new AdressSpace root memory region is now zero-based, we do not
need anymore to add the PCI I/O base address to the MemoryRegionOps
handlers.
The raven bus-master memory region is exposed as an AddressSpace.
AddressSpaces root MemoryRegion must not be mapped into other
MemoryRegion, therefore map the region using its alias.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/raven.c | 6 --
1 file changed, 4 insertions(+), 2
John Snow writes:
> On 4/16/21 8:44 AM, Markus Armbruster wrote:
>> John Snow writes:
>>
>>> PEP8's BDFL writes: "For flowing long blocks of text with fewer
>>> structural restrictions (docstrings or comments), the line length should
>>> be limited to 72 characters."
>>>
>>> I do not like this
Vitaly Kuznetsov writes:
> When a migration blocker is added nothing is reported to the user,
> inability to migrate such guest may come as a late surprise. As a bare
> minimum, we can print a warning. To not pollute the output for those, who
> have no intention to migrate their guests,
Thomas Huth writes:
> On 16/04/2021 19.53, Philippe Mathieu-Daudé wrote:
>> Hi Thomas,
>> On 4/16/21 7:13 PM, Thomas Huth wrote:
>>> Stop including hw/boards.h in files that don't need it.
>>>
>>> Signed-off-by: Thomas Huth
>>> ---
>>> accel/tcg/tcg-accel-ops-icount.c | 1 -
>>>
Commit 1ae1dc5ba24 ("raven: Set a correct PCI I/O memory region")
abused an AddressSpace API weakness which allows set non-zero base
address to AddressSpace root region. We will fix that in the next
commit. First add an assertion to ensure no regression is introduced.
As raven_io_address() is
The 'pci-io' alias (mapped with priority 0) ends up masked by
the 'pci-io-non-contiguous' I/O region (mapped with priority 1).
The flatview rendering is ('pci-io-non-contiguous' is written
'pci-io-nc'):
(base addr) [ MemoryRegion ][ FlatView ]
The RAM container is exposed as an AddressSpace.
AddressSpaces root MemoryRegion must not be mapped into other
MemoryRegion, therefore map the RAM container using an alias.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/aspeed.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
Rather than using the magic 0x8000 number for the PCI I/O BAR
physical address on the main system bus, use a definition.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/raven.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/pci-host/raven.c
From: Peter Xu
Add a bool for MR to mark whether this MR is a root MR of an AS. We bail out
asap if this MR is added as a subregion of another MR.
Signed-off-by: Peter Xu
---
include/exec/memory.h | 1 +
softmmu/memory.c | 2 ++
2 files changed, 3 insertions(+)
diff --git
Previous commit added a check in memory_region_add_subregion_common()
to ensure AS root MR can't be added as subregion (changing the MR
base address doing so). We can now remove the temporary assert in
the raven model.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/raven.c | 10
Since commit 2cdfcf272d ("memory: assign MemoryRegionOps to all
regions"), all newly created regions are assigned with
unassigned_mem_ops (which might be then overwritten).
When using aliased container regions, and there is no region mapped
at address 0 in the container, the
There is an issue when using memory_region_dispatch_read() or
memory_region_dispatch_write() on RAM memory regions.
RAM memory regions are initialized as:
memory_region_init_ram()
-> memory_region_init_ram_nomigrate()
-> memory_region_init_ram_shared_nomigrate()
->
Le 15/04/2021 à 12:04, Philippe Mathieu-Daudé a écrit :
> From: Laurent Vivier
>
> When the mem_size of the segment is bigger than the file_size,
> and if this space doesn't overlap another segment, it needs
> to be cleared.
>
> This bug is very similar to the one we had for linux-user,
>
43 matches
Mail list logo
