I looked at it, and there seems to be no difference. Looks like my
installation is rotten.
Let's close this bug as invalid.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1916394
Title:
[git] Canno
On Wed, 3 Mar 2021 17:08:32 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Mar 03, 2021 at 10:46:43PM +0100, Philippe Mathieu-Daudé wrote:
> > Introduce the cpu_virtio_is_big_endian() generic helper to avoid
> > calling CPUClass internal virtio_is_big_endian() one.
> >
> > Signed-off-by: Philippe M
On 3/1/2021 11:50 PM, Michael S. Tsirkin wrote:
On Mon, Mar 01, 2021 at 10:39:19AM +0100, Andrew Jones wrote:
On Fri, Feb 26, 2021 at 10:23:03AM +0800, Ying Fang wrote:
On 2/25/2021 7:47 PM, Andrew Jones wrote:
On Thu, Feb 25, 2021 at 04:56:26PM +0800, Ying Fang wrote:
Add the processor
On 03/03/2021 19.22, Philippe Mathieu-Daudé wrote:
We already have the 'run' variable holding 'cs->kvm_run' value.
Signed-off-by: Philippe Mathieu-Daudé
---
target/s390x/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index
On 02/03/2021 11.27, Philippe Mathieu-Daudé wrote:
We will restrict the s390_cpu_has_work() function to TCG.
First declare it in "internal.h" and move it to excp_helper.c.
Signed-off-by: Philippe Mathieu-Daudé
---
target/s390x/internal.h| 1 +
target/s390x/cpu.c | 17 ---
On 02/03/2021 11.27, Philippe Mathieu-Daudé wrote:
We can only check if a vCPU has work with TCG.
Restrict the has_work() handler to TCG by moving it to
the TCGCPUOps structure, and adapt all the targets.
Signed-off-by: Philippe Mathieu-Daudé
---
RFC: PPC target incomplete
---
[...]
diff --gi
docker_arch_qemu_build.log.xz shows the output from the docker build via
arch linux
** Attachment added: "docker_arch_qemu_build.log.xz"
https://bugs.launchpad.net/qemu/+bug/1916394/+attachment/5472326/+files/docker_arch_qemu_build.log.xz
--
You received this bug notification because you are
Still having trouble reproducing the issue.
I don't have an arch system so I used Docker. Would you be willing to
check whether the Dockerfile represents a close enough match to your
build process?
Also, if you can think of anything particularly unique about your
configuration, maybe I can try t
On 03/03/2021 19.46, Philippe Mathieu-Daudé wrote:
Follow the inclusive terminology from the "Conscious Language in your
Open Source Projects" guidelines [*] and replace the word "blacklist"
appropriately.
[*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
Acked-by: Alex
On 03/03/2021 19.46, Philippe Mathieu-Daudé wrote:
Follow the inclusive terminology from the "Conscious Language in your
Open Source Projects" guidelines [*] and replace the word "blacklist"
appropriately.
[*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
Reviewed-by: D
On 03/03/2021 19.46, Philippe Mathieu-Daudé wrote:
Follow the inclusive terminology from the "Conscious Language in your
Open Source Projects" guidelines [*] and replace the word "blacklist"
appropriately.
[*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
Reviewed-by: D
I have encountered a number of devices (mostly mobile phones) which seem to
get very confused if a "SET CONFIGURATION" control transfer (for the same
interface) is performed twice.
Specifically, after receiving a 2nd SET CONFIGURATION (for the same
interface) the device times out on future bulk ou
QEMU has had options to enable control-flow integrity features
for a few months now. Add two sets of build/check/acceptance
jobs to ensure the binary produced is working fine.
The three sets allow testing of x86_64 binaries for x86_64, s390x,
ppc64 and aarch64 targets
Signed-off-by: Daniele Buono
Define a new variable LD_JOBS, that can be used to select
the maximum number of linking jobs to be executed in parallel.
If the variable is not defined, maintain the default given by
make -j
Currently, make parallelism at build time is based on the number
of cpus available.
This doesn't work well
For a few months now QEMU has had options to enable compiler-based
control-flow integrity if built with clang.
While this feature has a low maintenance, It's probably still better to
add tests to the CI environment to check that an update doesn't break it.
The patchset allow gitlab testing of:
*
For CFI, we need to compile slirp as a static library together with qemu.
This is because we register slirp functions as callbacks for QEMU Timers.
When using a system-wide shared libslirp, the type information for the
callback is missing and the timer call produces a false positive with CFI.
With
On 2/19/21 6:45 AM, Peter Maydell wrote:
The Clock framework allows users to specify a callback which is
called after the clock's period has been updated. Some users need to
also have a callback which is called before the clock period is
updated.
As the first step in adding support for notifyin
On 2/15/21 3:51 AM, Peter Maydell wrote:
Update old infocenter.arm.com URLs to the equivalent developer.arm.com
ones (the old URLs should redirect, but we might as well avoid the
redirection notice, and the new URLs are pleasantly shorter).
This commit covers the links to the MPS2 board TRM, the
On 2/15/21 3:51 AM, Peter Maydell wrote:
Add brief documentation of the new mps3-an524 board.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
docs/system/arm/mps2.rst | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
Reviewed-by: Richard He
On 2/15/21 3:51 AM, Peter Maydell wrote:
The AN524 has a PL031 RTC, which we have a model of; provide it
rather than an unimplemented-device stub.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/mps2-tz.c | 22 --
1 file changed, 20 insertions(+
Quote docs/devel/style.rst (section "Automatic memory deallocation"):
* Variables declared with g_auto* MUST always be initialized,
otherwise the cleanup function will use uninitialized stack memory
Initialize @name properly to get rid of the compilation error:
../hw/remote/proxy.c: In functio
On 2/15/21 3:51 AM, Peter Maydell wrote:
The AN524 has a USB controller (an ISP1763); we don't have a model of
it but we should provide a stub "unimplemented-device" for it. This
is slightly complicated because the USB controller shares a PPC port
with the ethernet controller.
Implement a make_
On 2021/3/3 18:17, Daniel P. Berrangé wrote:
This is a bit wierd. There should only be risk of uninitialized
variable if there is a 'return' or 'goto' statement between the
variable declaration and and initialization, which is not the
case in either scenario here.
What OS distro and compiler +
Thank you Pavel.
Your answers make the clock record-replay process much clearer to me now.
Best Regards,
Arnab
On Tue, Mar 2, 2021 at 12:49 PM Pavel Dovgalyuk
wrote:
> On 01.03.2021 20:16, Arnabjyoti Kalita wrote:
> > Hello all,
> >
> > I am really thankful for the wonderful answers in my last
On 2/15/21 3:51 AM, Peter Maydell wrote:
Add support for the mps3-an524 board; this is an SSE-200 based FPGA
image, like the existing mps2-an521. It has a usefully larger amount
of RAM, and a PL031 RTC, as well as some more minor differences.
In real hardware this image runs on a newer generati
On 2/15/21 3:51 AM, Peter Maydell wrote:
In the mps2-tz board code, we handle devices whose interrupt lines
must be wired to all CPUs by creating IRQ splitter devices for the
AN521, because it has 2 CPUs, but wiring the device IRQ directly to
the SSE/IoTKit input for the AN505, which has only 1 C
On 3/3/21 1:46 PM, Philippe Mathieu-Daudé wrote:
Patches 1-6 are generic cleanups.
Patches 7-15 move from CPUClass to SysemuCPUOps
Patch 16 restricts SysemuCPUOps to sysemu
Patches 17-26 remove watchpoint code from user emulation
Patches 27-28 remove USER_ONLY #ifdef'ry from "cpu.h"
Patches 1
>> After Linux 5.10, write zeros to a multipath device using
>> ioctl(fd, BLKZEROOUT, range) with cache none or directsync will return EBUSY.
>>
>> Similar to handle_aiocb_write_zeroes_unmap, handle_aiocb_write_zeroes_block
>> allow -EBUSY errors during ioctl(fd, BLKZEROOUT, range).
>>
>> Reference
On 3/3/21 1:47 PM, Philippe Mathieu-Daudé wrote:
Since we remove all access to the watchpoint methods from user-mode
code, we can now remove them, as they are not used anymore.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 34 +-
1 file chan
> -Original Message-
> From: Philippe Mathieu-Daudé On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Tuesday, March 2, 2021 4:28 AM
> To: qemu-devel@nongnu.org
> Cc: Yoshinori Sato ; Chris Wulff
> ; qemu-...@nongnu.org; Marcel Apfelbaum
> ; Greg Kurz ; qemu-
> ri...@nongnu.org; Richard Hend
On Sun, Feb 28, 2021 at 6:18 AM Asherah Connor wrote:
>
> This is version 3 of the series to bring fw_cfg support to riscv's virt
> machine, including ramfb support. It is tested as working against a
> modified U-Boot with ramfb support.
Thanks!
Applied to riscv-to-apply.next
Alistair
>
>
> C
On Tue, Mar 2, 2021 at 6:12 AM Edgar E. Iglesias
wrote:
>
> From: "Edgar E. Iglesias"
>
> Add a model of the Xilinx Versal Accelerator RAM (XRAM).
> This is mainly a stub to make firmware happy. The size of
> the RAMs can be probed. The interrupt mask logic is
> modelled but none of the interrups
On Tue, Mar 2, 2021 at 6:10 AM Edgar E. Iglesias
wrote:
>
> From: "Edgar E. Iglesias"
>
> Connect the support for the Versal Accelerator RAMs (XRAMs).
>
> Signed-off-by: Edgar E. Iglesias
Acked-by: Alistair Francis
Alistair
> ---
> docs/system/arm/xlnx-versal-virt.rst | 1 +
> include/hw/a
On 3/3/21 1:47 PM, Philippe Mathieu-Daudé wrote:
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 844db08bd57..ed3f22d78a5 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -4849,6 +4849,7 @@ void sve_ldnfff1_r(CPUARMState *env, void *vg, const
target_ulon
On Sun, Feb 28, 2021 at 6:45 AM Bin Meng wrote:
>
> On Sun, Feb 28, 2021 at 7:17 PM Asherah Connor wrote:
> >
> > Provides fw_cfg for the virt machine on riscv. This enables
> > using e.g. ramfb later.
> >
> > Signed-off-by: Asherah Connor
Reviewed-by: Alistair Francis
Alistair
> > ---
> >
On Sun, Feb 28, 2021 at 6:20 AM Asherah Connor wrote:
>
> Allow ramfb on virt. This lets `-device ramfb' work.
>
> Signed-off-by: Asherah Connor
> Reviewed-by: Bin Meng
Reviewed-by: Alistair Francis
Alistair
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> * Add ramfb as allowed on ri
> -Original Message-
> From: Philippe Mathieu-Daudé On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Wednesday, March 3, 2021 3:47 PM
> To: qemu-devel@nongnu.org
> Cc: Claudio Fontana ; qemu-...@nongnu.org; Peter
> Maydell ; Paolo Bonzini
> ; Richard Henderson
> ; qemu-s3...@nongnu.org; Tho
On 3/3/21 2:18 PM, Richard Henderson wrote:
On 3/3/21 2:15 PM, Michael S. Tsirkin wrote:
On Wed, Mar 03, 2021 at 05:08:36PM -0500, Michael S. Tsirkin wrote:
On Wed, Mar 03, 2021 at 10:46:43PM +0100, Philippe Mathieu-Daudé wrote:
Introduce the cpu_virtio_is_big_endian() generic helper to avoid
On 3/3/21 2:15 PM, Michael S. Tsirkin wrote:
On Wed, Mar 03, 2021 at 05:08:36PM -0500, Michael S. Tsirkin wrote:
On Wed, Mar 03, 2021 at 10:46:43PM +0100, Philippe Mathieu-Daudé wrote:
Introduce the cpu_virtio_is_big_endian() generic helper to avoid
calling CPUClass internal virtio_is_big_endia
On Wed, Mar 03, 2021 at 05:08:36PM -0500, Michael S. Tsirkin wrote:
> On Wed, Mar 03, 2021 at 10:46:43PM +0100, Philippe Mathieu-Daudé wrote:
> > Introduce the cpu_virtio_is_big_endian() generic helper to avoid
> > calling CPUClass internal virtio_is_big_endian() one.
> >
> > Signed-off-by: Philip
On 3/3/21 3:45 PM, Nir Soffer wrote:
I'll wait a few days for any other reviewer commentary before taking
this through my NBD tree.
>>
>> And thanks for CCing me. Hmm, maybe, I'll suggest myself as co-maintainer
>> for NBD?
Vladimir, I'd be happy if you want to do that in a s
On Wed, Mar 03, 2021 at 10:46:43PM +0100, Philippe Mathieu-Daudé wrote:
> Introduce the cpu_virtio_is_big_endian() generic helper to avoid
> calling CPUClass internal virtio_is_big_endian() one.
>
> Signed-off-by: Philippe Mathieu-Daudé
Using virtio in the name here probably because virtio wants
We can not use watchpoints in user-mode emulation because we
need the softmmu slow path to detect accesses to watchpointed
memory. Add #ifdef'ry around it.
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i38
We can not use watchpoints in user-mode emulation because we
need the softmmu slow path to detect accesses to watchpointed
memory. Add #ifdef'ry around it.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/internals.h| 2 ++
target/arm/cpu.c | 4 ++--
target/arm/debug_helper.c
On Wed, Mar 03, 2021 at 02:50:11PM +, Alex Bennée wrote:
> Make the language about feature negotiation explicitly clear about the
> handling of the VHOST_USER_F_PROTOCOL_FEATURES feature bit. Try and
> avoid the sort of bug introduced in vhost.rs REPLY_ACK processing:
>
> https://github.com/
All these prototypes and declarations don't need to be exposed
on user-mode emulation. Move them to "sysemu-cpu-ops.h".
Suggested-by: Claudio Fontana
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 164 ---
include/hw/core/sysemu-cpu-ops.
Somehow similar to commit 78271684719 ("cpu: tcg_ops: move to
tcg-cpu-ops.h, keep a pointer in CPUClass"):
We cannot in principle make the SysEmu Operations field definitions
conditional on CONFIG_SOFTMMU in code that is included by both
common_ss and specific_ss modules.
Therefore, what we can d
We can not use watchpoints in user-mode emulation because we
need the softmmu slow path to detect accesses to watchpointed
memory. Add #ifdef'ry around it.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/cpu-exec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/accel
Since we remove all access to the watchpoint methods from user-mode
code, we can now remove them, as they are not used anymore.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/i
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 3 ---
include/hw/core/sysemu-cpu-ops.h | 5 +
hw/core/cpu.c| 4 ++--
target/i386/cpu.c| 2 +-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/hw/core/cpu.h
We are going to move this code, fix its style first.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index b708f365a7a..79dcc9a4e42 100644
--- a/include/hw/core/cpu
We can not use watchpoints in user-mode emulation because we
need the softmmu slow path to detect accesses to watchpointed
memory. Add #ifdef'ry around it.
Signed-off-by: Philippe Mathieu-Daudé
---
target/xtensa/helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/xtensa/helpe
We are going to move this code, fix its style first.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/internals.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/target/arm/internals.h b/target/arm/internals.h
index 05cebc8597c..d6ace004855 100644
---
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 3 ---
include/hw/core/sysemu-cpu-ops.h | 5 +
hw/core/cpu.c| 4 ++--
target/arm/cpu.c | 2 +-
target/i386/cpu.c| 2 +-
5 files changed, 9 insertions(+), 7 deletion
To simplify later #ifdef'ry, move some code around.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/internals.h| 16
target/arm/debug_helper.c | 22 +++---
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/target/arm/internals.h b/target/a
Refactor few fonctions body to ease #ifdef'ry review
in the next commit. No logical change intented.
Signed-off-by: Philippe Mathieu-Daudé
---
Patch easier to review using:
'git-diff --color-moved-ws=allow-indentation-change'
---
target/arm/debug_helper.c | 72 +++
We can not use watchpoints in user-mode emulation because we
need the softmmu slow path to detect accesses to watchpointed
memory. This code is expanded as empty stub in "hw/core/cpu.h"
anyway, so we can drop it.
Reviewed-by: Laurent Vivier
Signed-off-by: Philippe Mathieu-Daudé
---
linux-user/m
The write_elf*() handlers are used to dump vmcore images.
This feature is only meaningful for system emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 17 -
include/hw/core/sysemu-cpu-ops.h | 24
hw/core/cpu.c
cpu_get_crash_info() is called on GUEST_PANICKED events,
which only occur in system emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 1 -
include/hw/core/sysemu-cpu-ops.h | 5 +
hw/core/cpu.c| 4 ++--
target/i386/cpu.c
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 8
include/hw/core/sysemu-cpu-ops.h | 13 +
hw/core/cpu.c| 6 +++---
target/alpha/cpu.c | 2 +-
target/arm/cpu.c | 2 +-
target/avr/cpu.c
gdbserver_fork() is only used in user emulation where we can not
use watchpoints because we need the softmmu slow path to detect
accesses to watchpointed memory. This code doesn't do anything as
declared as stubs in "hw/core/cpu.h". Drop it.
Signed-off-by: Philippe Mathieu-Daudé
---
gdbstub.c |
VirtIO devices are only meaningful with system emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 5 -
include/hw/core/sysemu-cpu-ops.h | 8
hw/core/cpu.c| 4 ++--
target/arm/cpu.c | 2 +-
target/ppc/translate_
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 2 --
include/hw/core/sysemu-cpu-ops.h | 4
hw/core/cpu.c| 4 ++--
target/i386/cpu.c| 4 +++-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/hw/core/cpu.h
No code uses CPUClass::get_paging_enabled() outside of hw/core/cpu.c:
$ git grep -F -- '->get_paging_enabled'
hw/core/cpu.c:74:return cc->get_paging_enabled(cpu);
hw/core/cpu.c:438:k->get_paging_enabled = cpu_common_get_paging_enabled;
target/i386/cpu.c:7418:cc->get_paging_enab
No code directly accesses CPUClass::write_elf*() handlers out
of hw/core/cpu.c (the rest are assignation in target/ code):
$ git grep -F -- '->write_elf'
hw/core/cpu.c:157:return (*cc->write_elf32_qemunote)(f, cpu, opaque);
hw/core/cpu.c:171:return (*cc->write_elf32_note)(f, cpu, cpu
Migration is specific to system emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 2 --
include/hw/core/sysemu-cpu-ops.h | 4
cpu.c| 18 --
target/alpha/cpu.c | 2 +-
target/arm/cpu.c
Introduce the cpu_virtio_is_big_endian() generic helper to avoid
calling CPUClass internal virtio_is_big_endian() one.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 9 +
hw/core/cpu.c | 8 ++--
hw/virtio/virtio.c| 4 +---
3 files changed, 16 insertions
To be able to later extract the cpu_get_phys_page_debug() and
cpu_asidx_from_attrs() handlers from CPUClass, un-inline them
from "hw/core/cpu.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 33 -
hw/core/cpu.c | 32 +++
Introduce a structure to hold handler specific to sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h| 5 +
include/hw/core/sysemu-cpu-ops.h | 21 +
target/alpha/cpu.c | 6 ++
target/arm/cpu.c | 6 ++
No code uses CPUClass::get_memory_mapping() outside of hw/core/cpu.c:
$ git grep -F -- '->get_memory_mapping'
hw/core/cpu.c:87:cc->get_memory_mapping(cpu, list, errp);
hw/core/cpu.c:439:k->get_memory_mapping = cpu_common_get_memory_mapping;
target/i386/cpu.c:7422:cc->get_memory
The cpu model is the single device available in user-mode.
Since we want to restrict some fields to user-mode emulation,
we prefer to set the vmsd field of CPUClass, rather than the
DeviceClass one.
Signed-off-by: Philippe Mathieu-Daudé
---
target/alpha/cpu.c | 2 +-
target/cris/cpu.c
Hi,
This series is inspired on Claudio TCG work.
Instead of separate TCG from other accelerators, here we
separate sysemu operations (system VS user).
Patches 1-6 are generic cleanups.
Patches 7-15 move from CPUClass to SysemuCPUOps
Patch 16 restricts SysemuCPUOps to sysemu
Patches 17-26 remov
On Thu, Feb 25, 2021 at 8:51 PM Vladimir Sementsov-Ogievskiy <
vsement...@virtuozzo.com> wrote:
> 19.02.2021 19:58, Eric Blake wrote:
> > On 2/19/21 10:42 AM, Eric Blake wrote:
> >
> >>> To me, data=false looks compatible with NBD_STATE_HOLE. From user point
> >>> of view, getting same results fro
On 3/3/21 1:22 PM, David Hildenbrand wrote:
Am 03.03.2021 um 22:19 schrieb Richard Henderson :
On 3/3/21 1:11 PM, David Hildenbrand wrote:
MMIO on s390x? :)
hw/s390x/s390-pci-bus.c, memory_region_init_io*().
... part of system address space where a CPU could stumble over it?
Impossibl
Am 03.03.21 um 19:47 schrieb Jason Dillaman:
> On Wed, Mar 3, 2021 at 12:41 PM Stefano Garzarella
> wrote:
>> Hi Jason,
>> as reported in this BZ [1], when qemu-img creates a QCOW2 image on RBD
>> writing data is very slow compared to a raw file.
>>
>> Comparing raw vs QCOW2 image creation with R
> Am 03.03.2021 um 22:19 schrieb Richard Henderson
> :
>
> On 3/3/21 1:11 PM, David Hildenbrand wrote:
>> MMIO on s390x? :)
>
> hw/s390x/s390-pci-bus.c, memory_region_init_io*().
>
... part of system address space where a CPU could stumble over it?
> r~
>
On 3/3/21 1:11 PM, David Hildenbrand wrote:
MMIO on s390x? :)
hw/s390x/s390-pci-bus.c, memory_region_init_io*().
r~
> Am 03.03.2021 um 22:05 schrieb Richard Henderson
> :
>
> On 3/3/21 11:39 AM, David Hildenbrand wrote:
>> Should we start wrapping that stuff into #ifdef CONFIG_TCG ?
>>> +uint64_t tlb_fill_tec; /* translation exception code during tlb_fill
>>> */
>>> +int tlb_fill_exc;/* e
On 3/3/21 11:39 AM, David Hildenbrand wrote:
Should we start wrapping that stuff into #ifdef CONFIG_TCG ?
+ uint64_t tlb_fill_tec; /* translation exception code during tlb_fill */
+ int tlb_fill_exc; /* exception number seen during tlb_fill */
Eh, probably not. At least not un
From: Jagannathan Raman
Runs the Avocado acceptance test to check if a
remote lsi53c895a device gets identified by the guest.
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
Reviewed-by: Wainer dos Santos Moschetta
Reviewed-by: Marc-André Lureau
This series is a respin to the "multi-process: Acceptance test for
multiprocess QEMU" patch sent in December which, runs an Avocado
functional test to check if a remote lsi53c895a device gets identified
by the guest:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg769188.html
First, we intro
Sometimes a test needs to send a command to a console without waiting
for a pattern as a result, or the command issued do not produce any kind
of output, like, for example, a `mount` command.
This introduces the `exec_command` function to the avocado_qemu,
allowing the test to send a command to th
W dniu 03.03.2021 o 19:06, Peter Maydell pisze:
On Wed, 3 Mar 2021 at 17:48, Leif Lindholm wrote:
It would be good if we could get 6.0 closer to SBSA compliance.
How far away are we at the moment ?
Hard to tell me how many of those things are missing in QEMU and how
many in EDK2 we use as
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> When the MacOS toolbox ROM transfers data from a target device to an unaligned
> memory address, the first/last byte of a 16-bit transfer needs to be handled
> separately. This means that the first byte is preloaded into the FIFO before
> the tran
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> The MacOS toolbox ROM uses non-DMA TI commands to handle the first/last byte
> of an unaligned 16-bit transfer to memory.
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/scsi/esp.c | 133 ++
> incl
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> The bottom 5 bits contain the number of bytes remaining in the FIFO which is
> trivial to implement with Fifo8 (the remaining bits are unimplemented and left
> as 0 for now).
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/scsi/esp.c | 4
>
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> Rename ESP_CMDBUF_SZ to ESP_CMDFIFO_SZ and cmdbuf_cdb_offset to
> cmdfifo_cdb_offset
> to indicate that the command buffer type has changed from an array to a Fifo8.
>
> This also enables us to remove the ESPState field cmdlen since the command
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> Rename TI_BUFSZ to ESP_FIFO_SZ since this constant is really describing the
> size
> of the FIFO and is not directly related to the TI size.
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/scsi/esp.c | 117 ++
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> The SCSI bus should remain in the message out phase after the SATN and stop
> command rather than transitioning to the command phase. A new ESPState
> variable
> cmdbuf_cdb_offset is added which stores the offset of the CDB from the start
> of cm
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> Some guests use a mixture of DMA and non-DMA transfers in combination with the
> SATN and stop command to transfer message out phase and command phase bytes to
> the target. Prepare for the next commit by adding a maxlen parameter to
> get_cmd() t
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> This matches the description in the datasheet and is required as support for
> non-DMA transfers is added.
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/scsi/esp.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/scsi/esp.c b
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> Commit ea84a44250 "scsi: esp: Defer command completion until previous
> interrupts
> have been handled" provided a mechanism to delay the command completion
> interrupt
> until ESP_RINTR is read after the command has completed.
>
> With the pre
Option "-V" currently displays the fuse protocol version virtiofsd is
using. For example, I see this.
$ ./virtiofsd -V
"using FUSE kernel interface version 7.33"
People also want to know software version of virtiofsd so that they can
figure out if a certain fix is part of currently running virtio
Le 18/02/2021 à 18:25, Mark Cave-Ayland a écrit :
> On 09/02/2021 19:30, Mark Cave-Ayland wrote:
>
>> The MacOS toolbox ROM issues a command to the ESP controller as part of its
>> "FAST" SCSI routines and then proceeds to read the incoming data soon after
>> receiving the command completion inter
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> Currently the ESP_RINTR register is set to a specific value as required within
> the ESP state machine. In order to implement the upcoming deferred interrupt
> functionality it is necessary to set individual bits within ESP_RINTR so that
> a defer
On 03.03.21 14:28, Thomas Huth wrote:
From: Richard Henderson
If the CCO bit is set, MVPG should not generate an exception but
report page translation faults via a CC code.
Create a new helper, access_prepare_nf, which can use probe_access_flags
in non-faulting mode, and then handle watchpoint
Le 09/02/2021 à 20:30, Mark Cave-Ayland a écrit :
> At this point it is now possible to properly implement the FIFO flush command
> without causing guest errors.
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/scsi/esp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/scsi/esp.c b/
I forgot to specify the version, I built qemu sha
c40ae5a3ee387b13116948cbfe7824f03311db7e
$ qemu-system-riscv64 --version
QEMU emulator version 5.2.50 (v5.2.0-2392-gc40ae5a3ee-dirty)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
h
Public bug reported:
Step to reproduce:
1. run qemu-system-riscv64 in gdb mode
2. attach gdb
3. set a breakpoint and run
4. print register-groups using "maintenance print register-groups" command
...
sbadaddr 4162 4162 1628 8 longall,general
msounteren 4163 4163 1636
From: Bin Meng
Now that we have implemented unified short frames padding in the
QEMU networking codes, remove the same logic in the NIC codes.
Signed-off-by: Bin Meng
Message-Id: <1614763306-18026-9-git-send-email-bmeng...@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé
---
hw/net/sungem.c |
1 - 100 of 369 matches
Mail list logo
