On Tue, 27 Jul 2021 at 07:12, Guenter Roeck wrote:
>
> On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
> > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> >> (cc Bjorn)
> >>
> >> On Mon, 26 Jul 2021 at 11:08, Philippe Mathieu-Daudé
> >> wrote:
> >>>
> >>> On 7/26/21 12:56 AM, Gue
Hi, Richard.
On 07/23/2021 01:44 PM, Richard Henderson wrote:
> On 7/20/21 11:53 PM, Song Gao wrote:
>> +uint64_t helper_fp_sqrt_d(CPULoongArchState *env, uint64_t fp)
>> +{
>> + fp = float64_sqrt(fp, &env->active_fpu.fp_status);
>> + update_fcsr0(env, GETPC());
>> + return fp;
>> +}
>> +
On Mon, 26 Jul 2021 at 12:05, Gerd Hoffmann wrote:
>
> The following changes since commit a2376507f615495b1d16685449ce0ea78c2caf9d:
>
> Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream'
> into staging (2021-07-24 11:04:57 +0100)
>
> are available in the Git repository at:
On Tue, 27 Jul 2021 at 01:39, Cleber Rosa wrote:
>
>
> Hi everyone,
>
> tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt
> is currently failing consistently (first found that in [1]).
>
> I've bisected it down to the following commit:
>
> ---
>
> 78ff82bb1b67c0d79113688e4b342
On 7/27/21 7:59 AM, Thomas Huth wrote:
> On 26/07/2021 17.04, Philippe Mathieu-Daudé wrote:
>> We introduced the QEMU_CI_AVOCADO_TESTING variable in commit f56bf4caf
>> ("gitlab: Run Avocado tests manually (except mainstream CI)"), but
>> forgot to document it properly. Do it now.
>>
>> Suggested-b
Hi, Richard.
On 07/23/2021 02:11 PM, Richard Henderson wrote:
> On 7/20/21 11:53 PM, Song Gao wrote:
>> +void helper_movreg2cf_i32(CPULoongArchState *env, uint32_t cd, uint32_t src)
>> +{
>> + env->active_fpu.cf[cd & 0x7] = src & 0x1;
>> +}
>> +
>> +void helper_movreg2cf_i64(CPULoongArchState
Hi Richard.
On 07/23/2021 02:16 PM, Richard Henderson wrote:
> On 7/20/21 11:53 PM, Song Gao wrote:
>> +uint64_t helper_fp_tintrm_l_d(CPULoongArchState *env, uint64_t src)
>> +{
>> + uint64_t dest;
>> +
>> + set_float_rounding_mode(float_round_down, &env->active_fpu.fp_status);
>> + des
On 7/26/21 6:33 PM, Peter Maydell wrote:
> If the user provides both a BIOS/firmware image and also a guest
> kernel filename, arm_setup_firmware_boot() will pass the
> kernel image to the firmware via the fw_cfg device. However we
> weren't checking whether there really was a fw_cfg device present
On Mon, 19 Jul 2021 at 16:02, Cédric Le Goater wrote:
>
> On 7/13/21 8:58 AM, Joel Stanley wrote:
> > The macro used to calculate the maximum memory size of the MMIO region
> > had a mistake, causing all GPIO models to create a mapping of 0x9D8.
> > The intent was to have it be 0x9D8 - 0x800.
> >
Hi, Richard.
On 07/23/2021 02:34 PM, Richard Henderson wrote:
> On 7/20/21 11:53 PM, Song Gao wrote:
>> +static bool trans_fldx_d(DisasContext *ctx, arg_fldx_d *a)
>> +{
>> + TCGv t0;
>> + TCGv_i64 fp0;
>> + TCGv Rj = cpu_gpr[a->rj];
>> + TCGv Rk = cpu_gpr[a->rk];
>> +
>> + t0 = t
Hi, Richard.
On 07/23/2021 02:29 PM, Richard Henderson wrote:
> On 7/20/21 11:53 PM, Song Gao wrote:
>> This patch implement floationg point move instruction translation.
>>
>> This includes:
>> - FMOV.{S/D}
>> - FSEL
>> - MOVGR2FR.{W/D}, MOVGR2FRH.W
>> - MOVFR2GR.{S/D}, MOVFRH2GR.S
>> - MOVGR2FCS
Hi, Richard.
On 07/23/2021 02:38 PM, Richard Henderson wrote:
> On 7/20/21 11:53 PM, Song Gao wrote:
>> +/* Branch Instructions translation */
>> +static bool trans_beqz(DisasContext *ctx, arg_beqz *a)
>> +{
>> + TCGv t0, t1;
>> + int bcond_flag = 0;
>> +
>> + t0 = tcg_temp_new();
>> +
On 27/07/2021 09.55, Philippe Mathieu-Daudé wrote:
On 7/27/21 7:59 AM, Thomas Huth wrote:
On 26/07/2021 17.04, Philippe Mathieu-Daudé wrote:
We introduced the QEMU_CI_AVOCADO_TESTING variable in commit f56bf4caf
("gitlab: Run Avocado tests manually (except mainstream CI)"), but
forgot to docume
On Mon, Jul 26, 2021 at 03:25:49PM -0700, Dongwon Kim wrote:
> With a display option, "show-fps=on", qemu adds a status bar and print
> following performance numbers on the bar,
>
> ups = update per seconds - the rate the guest scanout is updated.
> fps = frame per seconds - the frame rate of VC's
We might not start at the beginning of the memory region. Let's
calculate the offset into the memory region via the difference in the
host addresses.
Acked-by: Stefan Berger
Fixes: ffab1be70692 ("tpm: clear RAM when "memory overwrite" requested")
Cc: Marc-André Lureau
Cc: Paolo Bonzini
Cc: "Mic
Let's make sure to not merge when different memory regions are involved.
Unlikely, but theoretically possible.
Acked-by: Stefan Berger
Reviewed-by: Peter Xu
Cc: Marc-André Lureau
Cc: Paolo Bonzini
Cc: "Michael S. Tsirkin"
Cc: Eduardo Habkost
Cc: Alex Williamson
Cc: Dr. David Alan Gilbert
C
virtio-mem logically plugs/unplugs memory within a sparse memory region
and notifies via the RamDiscardManager interface when parts become
plugged (populated) or unplugged (discarded).
Currently, we end up (via the two users)
1) zeroing all logically unplugged/discarded memory during TPM resets.
2
Let's factor out adding a MemoryRegionSection to the list, to be reused in
RamDiscardManager context next.
Reviewed-by: Stefan Berger
Reviewed-by: Peter Xu
Cc: Marc-André Lureau
Cc: Paolo Bonzini
Cc: "Michael S. Tsirkin"
Cc: Eduardo Habkost
Cc: Alex Williamson
Cc: Dr. David Alan Gilbert
Cc
Minor fixes and cleanups, followed by an optimization for virtio-mem
regarding guest dumps and tpm.
virtio-mem logically plugs/unplugs memory within a sparse memory region
and notifies via the RamDiscardMgr interface when parts become
plugged (populated) or unplugged (discarded).
Currently, guest
* Chenyi Qiang (chenyi.qi...@intel.com) wrote:
> A bus lock is acquired through either split locked access to writeback
> (WB) memory or any locked access to non-WB memory. It is typically >1000
> cycles slower than an atomic operation within a cache and can also
> disrupts performance on other cor
Per the "MIPS Architecture Extension: nanoMIPS32 DSP TRM" rev 0.04,
MULT and MULTU opcodes:
The value of ac selects an accumulator numbered from 0 to 3.
When ac=0, this refers to the original HI/LO register pair of the
MIPS32 architecture.
In Release 6 of the MIPS Architecture, accumulato
On 7/27/21 10:09 AM, Thomas Huth wrote:
> On 27/07/2021 09.55, Philippe Mathieu-Daudé wrote:
>> On 7/27/21 7:59 AM, Thomas Huth wrote:
>>> On 26/07/2021 17.04, Philippe Mathieu-Daudé wrote:
We introduced the QEMU_CI_AVOCADO_TESTING variable in commit f56bf4caf
("gitlab: Run Avocado tests
This patch adds record/replay test which boots Linux
kernel on s390x platform. The test uses kernel binaries
taken from boot_linux_console test.
Signed-off-by: Pavel Dovgalyuk
Reviewed-by: Willian Rampazzo
---
tests/acceptance/replay_kernel.py | 16
1 file changed, 16 inserti
This patch adds record/replay test which boots Linux
kernel on openrisc platform. The test uses kernel binaries
taken from boot_linux_console test.
Signed-off-by: Pavel Dovgalyuk
Reviewed-by: Willian Rampazzo
---
tests/acceptance/replay_kernel.py | 11 +++
1 file changed, 11 insertion
This patch adds record/replay test which boots Linux
kernel on nios2 platform. The test uses kernel binaries
taken from boot_linux_console test.
Signed-off-by: Pavel Dovgalyuk
Reviewed-by: Willian Rampazzo
---
tests/acceptance/replay_kernel.py | 11 +++
1 file changed, 11 insertions(+
This patch adds record/replay test which boots Linux
kernel on alpha platform. The test uses kernel binaries
taken from boot_linux_console test.
Signed-off-by: Pavel Dovgalyuk
Reviewed-by: Willian Rampazzo
---
tests/acceptance/replay_kernel.py | 17 +
1 file changed, 17 insert
From: Pavel Dovgalyuk
This patch adds a test for record/replay, which boots Linux
image from the disk and interacts with the network.
The idea and code of this test is borrowed from boot_linux.py
This test includes only x86_64 platform. Other platforms and
machines will be added later after testi
The following series adds new record/replay tests to the acceptance group.
The provided tests perform kernel boot and disk image boot scenarios.
For all of them recording and replaying phases are executed.
Tests were borrowed from existing boot_linux*.py tests.
New tests include kernel boot for s
On Mon, Jul 26, 2021 at 10:12:38PM -0700, Guenter Roeck wrote:
> On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
> > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> > > (cc Bjorn)
> > >
> > > On Mon, 26 Jul 2021 at 11:08, Philippe Mathieu-Daudé
> > > wrote:
> > > >
> > > > On 7/
On Tue, Jul 27, 2021 at 09:04:20AM +0200, Ard Biesheuvel wrote:
> On Tue, 27 Jul 2021 at 07:12, Guenter Roeck wrote:
> >
> > On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
> > > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> > >> (cc Bjorn)
> > >>
> > >> On Mon, 26 Jul 2021 at 11
On Tue, 27 Jul 2021 at 01:39, Cleber Rosa wrote:
> tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt
> is currently failing consistently (first found that in [1]).
FWIW I find that on my local machine this test is consistently flaky
and always has been, so I just ignore any f
On Mon, 26 Jul 2021 at 16:09, Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/arm/nseries.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
> index 906c915df78..af3164c5519 100644
> --- a/hw/arm/nseri
On Wed, 21 Jul 2021 at 22:06, Shengtan Mao wrote:
>
> Hi everyone,
> we are hoping to upstream a MAX I2C device to QEMU. The device's datasheet is
> not public, and we are contacting the Maxim company to get their permission.
> If Maxim is okay with upstreaming the device with an unpublished dat
On 24.07.21 00:19, Peter Xu wrote:
On Fri, Jul 23, 2021 at 08:41:40PM +0200, David Hildenbrand wrote:
On 23.07.21 18:12, Peter Xu wrote:
On Thu, Jul 22, 2021 at 01:43:41PM +0200, David Hildenbrand wrote:
a) In precopy code, always clearing all dirty bits from the bitmap that
correspond t
On Tue, Jul 27, 2021 at 09:04:20AM +0200, Ard Biesheuvel wrote:
> On Tue, 27 Jul 2021 at 07:12, Guenter Roeck wrote:
> >
> > On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
> > > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> > >> (cc Bjorn)
> > >>
> > >> On Mon, 26 Jul 2021 at 11
On Tue, 27 Jul 2021 at 11:30, Michael S. Tsirkin wrote:
>
> On Tue, Jul 27, 2021 at 09:04:20AM +0200, Ard Biesheuvel wrote:
> > On Tue, 27 Jul 2021 at 07:12, Guenter Roeck wrote:
> > >
> > > On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
> > > > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Bieshe
On Mon, 26 Jul 2021 at 22:47, Richard Henderson
wrote:
>
> The following changes since commit 34fd92ab4142bde5b54adacd16e6682f4ea83da1:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-for-6.1-rc1-230721-1' into staging (2021-07-26
> 11:00:15 +0100)
>
> are available in the Git re
On Tue, 27 Jul 2021 at 09:02, Joel Stanley wrote:
>
> On Mon, 19 Jul 2021 at 16:02, Cédric Le Goater wrote:
> >
> > On 7/13/21 8:58 AM, Joel Stanley wrote:
> > > The macro used to calculate the maximum memory size of the MMIO region
> > > had a mistake, causing all GPIO models to create a mapping
On Tue, Jul 27, 2021 at 11:50:23AM +0200, Ard Biesheuvel wrote:
> On Tue, 27 Jul 2021 at 11:30, Michael S. Tsirkin wrote:
> >
> > On Tue, Jul 27, 2021 at 09:04:20AM +0200, Ard Biesheuvel wrote:
> > > On Tue, 27 Jul 2021 at 07:12, Guenter Roeck wrote:
> > > >
> > > > On 7/26/21 9:45 PM, Michael S.
(+ Lorenzo)
On Tue, 27 Jul 2021 at 12:07, Michael S. Tsirkin wrote:
>
> On Tue, Jul 27, 2021 at 11:50:23AM +0200, Ard Biesheuvel wrote:
> > On Tue, 27 Jul 2021 at 11:30, Michael S. Tsirkin wrote:
> > >
> > > On Tue, Jul 27, 2021 at 09:04:20AM +0200, Ard Biesheuvel wrote:
> > > > On Tue, 27 Jul 2
On Tue, 27 Jul 2021 05:01:23 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Jul 26, 2021 at 10:12:38PM -0700, Guenter Roeck wrote:
> > On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
> > > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> > > > (cc Bjorn)
> > > >
> > > > On Mon, 2
From: Joe Komlodi
The bit to see if a CD is valid is the last bit of the first word of the CD.
Signed-off-by: Joe Komlodi
Message-id: 1626728232-134665-2-git-send-email-joe.koml...@xilinx.com
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
hw/arm/smmuv3-internal.h | 2 +-
1 file
In do_v7m_exception_exit(), we perform various checks as part of
performing the exception return. If one of these checks fails, the
architecture requires that we take an appropriate exception on the
existing stackframe. We implement this by calling
v7m_exception_taken() to set up to take the new
From: Richard Henderson
Rename from sve_zcr_get_valid_len and make accessible
from outside of helper.c.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20210723203344.968563-3-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/internals.h | 10 ++
/tags/pull-tcg-20210726' into
staging (2021-07-27 08:35:01 +0100)
are available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20210727
for you to fetch changes up to e229a179a503f2aee43a76888cf12fbdfe8a3749:
hw: aspeed_gpio: Fix m
For M-profile, we weren't reporting alignment faults triggered by the
generic TCG code correctly to the guest. These get passed into
arm_v7m_cpu_do_interrupt() as an EXCP_DATA_ABORT with an A-profile
style exception.fsr value of 1. We didn't check for this, and so
they fell through into the defau
For M-profile, unlike A-profile, the low 2 bits of SP are defined to be
RES0H, which is to say that they must be hardwired to zero so that
guest attempts to write non-zero values to them are ignored.
Implement this behaviour by masking out the low bits:
* for writes to r13 by the gdbstub
* for w
From: Mao Zhongyi
Missed in commit f3478392 "docs: Move deprecation, build
and license info out of system/"
Signed-off-by: Mao Zhongyi
Reviewed-by: Peter Maydell
Message-id: 20210723065828.1336760-1-maozhon...@cmss.chinamobile.com
Signed-off-by: Peter Maydell
---
configure | 2 +-
ta
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-id: 20210726150953.1218690-1-f4...@amsat.org
Signed-off-by: Peter Maydell
---
hw/arm/nseries.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/nseries.c b/hw/ar
The documentation of the -machine memory-backend has some minor
formatting errors:
* Misindentation of the initial line meant that the whole option
section is incorrectly indented in the HTML output compared to
the other -machine options
* The examples weren't indented, which meant that the
The ISCR.ISRPENDING bit is set when an external interrupt is pending.
This is true whether that external interrupt is enabled or not.
This means that we can't use 's->vectpending == 0' as a shortcut to
"ISRPENDING is zero", because s->vectpending indicates only the
highest priority pending enabled
The VECTPENDING field in the ICSR is 9 bits wide, in bits [20:12] of
the register. We were incorrectly masking it to 8 bits, so it would
report the wrong value if the pending exception was greater than 256.
Fix the bug.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 202
In Arm v8.1M the VECTPENDING field in the ICSR has new behaviour: if
the register is accessed NonSecure and the highest priority pending
enabled exception (that would be returned in the VECTPENDING field)
targets Secure, then the VECTPENDING field must read 1 rather than
the exception number of the
From: Joel Stanley
The macro used to calculate the maximum memory size of the MMIO region
had a mistake, causing all GPIO models to create a mapping of 0x9D8.
The intent was to have it be 0x9D8 - 0x800.
This extra size doesn't matter on ast2400 and ast2500, which have a 4KB
region set aside for
From: Richard Henderson
Currently, our only caller is sve_zcr_len_for_el, which has
already masked the length extracted from ZCR_ELx, so the
masking done here is a nop. But we will shortly have uses
from other locations, where the length will be unmasked.
Saturate the length to ARM_MAX_VQ inste
From: Richard Henderson
Mirror the behavour of /proc/sys/abi/sve_default_vector_length
under the real linux kernel. We have no way of passing along
a real default across exec like the kernel can, but this is a
decent way of adjusting the startup vector length of a process.
Resolves: https://git
On 7/27/21 2:30 AM, Michael S. Tsirkin wrote:
On Tue, Jul 27, 2021 at 09:04:20AM +0200, Ard Biesheuvel wrote:
On Tue, 27 Jul 2021 at 07:12, Guenter Roeck wrote:
On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
(cc Bjorn)
On Mon,
On Tue, Jul 27, 2021 at 10:23:26AM +0100, Peter Maydell wrote:
> On Wed, 21 Jul 2021 at 22:06, Shengtan Mao wrote:
> >
> > Hi everyone,
> > we are hoping to upstream a MAX I2C device to QEMU. The device's datasheet
> > is not public, and we are contacting the Maxim company to get their
> > permi
On 7/27/21 3:36 AM, Igor Mammedov wrote:
On Tue, 27 Jul 2021 05:01:23 -0400
"Michael S. Tsirkin" wrote:
On Mon, Jul 26, 2021 at 10:12:38PM -0700, Guenter Roeck wrote:
On 7/26/21 9:45 PM, Michael S. Tsirkin wrote:
On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
(cc Bjorn)
On
26.07.2021 17:46, Max Reitz wrote:
As of HEAD^, there is no meaning to s->synced other than whether the job
is READY or not. job_is_ready() gives us that information, too.
Suggested-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best r
On Mon, 26 Jul 2021 14:52:15 -0500
Eric DeVolder wrote:
> On 7/26/21 5:06 AM, Igor Mammedov wrote:
> > On Wed, 21 Jul 2021 10:42:33 -0500
> > Eric DeVolder wrote:
> >
> >> On 7/19/21 10:02 AM, Igor Mammedov wrote:
> >>> On Wed, 30 Jun 2021 19:26:39 +
> >>> Eric DeVolder wrote:
> >>>
On Mon, 26 Jul 2021 15:02:55 -0500
Eric DeVolder wrote:
[...]
> +build_serialization_instruction_entry(table_data, action,
> +ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
> +s->bar0 + ERST_CSR_ACTION, action, MASK8);
> +br
Hi all,
Any comments for this patch?
On Fri, Jul 9, 2021 at 6:11 PM Li Zhang wrote:
>
> For some scenarios, we'd like to hot-add a monitor device. But QEMU
> doesn't support that, yet. It does support hot-swapping character
> backends with QMP command chardev-change. This lets us pre-add a
>
Hi all,
Any comments for this patch?
On Fri, Jul 9, 2021 at 6:11 PM Li Zhang wrote:
>
> To improve the problematic source code in qmp_chardev_change
> and some redundant source code, the functions qmp_chardev_add
> and qmp_chardev_change are refactored. It is mentioned in thread:
> https://lists
On Mon, 26 Jul 2021 at 13:47, Dr. David Alan Gilbert (git)
wrote:
>
> From: "Dr. David Alan Gilbert"
>
> The following changes since commit a2376507f615495b1d16685449ce0ea78c2caf9d:
>
> Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream'
> into staging (2021-07-24 11:04:57
On 23.07.21 21:34, Peter Xu wrote:
This is v2 of the series. It was actually got forgotten for months until it
was used to identify another potential issue of bql usage here (besides it
could still be helpful when debugging a previous kvm dirty ring issue in that
series):
https://lore.kernel.or
26.07.2021 17:46, Max Reitz wrote:
We largely have two cancel modes for jobs:
First, there is actual cancelling. The job is terminated as soon as
possible, without trying to reach a consistent result.
Second, we have mirror in the READY state. Technically, the job is not
really cancelled, but
On 23.07.21 21:34, Peter Xu wrote:
The helper is introduced but we've still got plenty of places that are directly
referencing the qemu_global_mutex itself. Spread the usage.
Signed-off-by: Peter Xu
---
softmmu/cpus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
On Wed, 21 Jul 2021 at 00:58, John Snow wrote:
>
> Patch 1 does (roughly) the bare minimum, patch 2 adds some formatting,
> and patch 3 adds cross-references.
>
> John Snow (3):
> docs: convert qapi-code-gen.txt to ReST
> docs/qapi-code-gen: Beautify formatting
> docs/qapi-code-gen: add cros
On 23.07.21 21:34, Peter Xu wrote:
We must use the BQL for do_run_on_cpu() without much choice, it means the
parameter is helpless. Remove it. Meanwhile use the newly introduced
s/helpless/useless/ ?
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On Mon, 26 Jul 2021 15:01:05 -0500
Eric DeVolder wrote:
> On 7/26/21 5:42 AM, Igor Mammedov wrote:
> > On Wed, 21 Jul 2021 11:07:40 -0500
> > Eric DeVolder wrote:
> >
> >> On 7/20/21 7:17 AM, Igor Mammedov wrote:
> >>> On Wed, 30 Jun 2021 15:07:16 -0400
> >>> Eric DeVolder wrote:
> >>>
PS:
If I haven't said it already, use checkpatch script before posting patches.
On 23.07.21 21:34, Peter Xu wrote:
The prepare function before unlocking BQL. There're only three places that can
release the BQL: unlock(), cond_wait() or cond_timedwait().
Signed-off-by: Peter Xu
---
softmmu/cpus.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/softmmu/cpus.c
On 23.07.21 21:34, Peter Xu wrote:
Make sure we don't have any more ongoing memory transaction when releasing the
BQL. This will trigger an abort if we misuse the QEMU memory model, e.g., when
calling run_on_cpu() during a memory commit.
... or pause_all_vcpus() during a memory transaction :)
On 23.07.21 21:34, Peter Xu wrote:
This should be functionally the same as before, but this allows the
memory_region_transaction_depth to be non-zero during commit, which can help us
to do sanity check on misuses.
Since at it, fix an indentation issue on the bracket.
Signed-off-by: Peter Xu
--
On 23.07.21 21:34, Peter Xu wrote:
This patch has no functional change, but prepares for moving the function
do_run_on_cpu() into softmmu/cpus.c. It does:
1. Move qemu_work_item into hw/core/cpu.h.
2. Export queue_work_on_cpu()/qemu_work_cond.
All of them will be used by softmmu/cpus.c l
On 23.07.21 21:34, Peter Xu wrote:
It's only used by softmmu binaries not linux-user ones. Make it static and
drop the definition in the header too.
Signed-off-by: Peter Xu
---
cpus-common.c | 25 -
include/hw/core/cpu.h | 12
softmmu/cpus.c
26.07.2021 17:46, Max Reitz wrote:
Most callers of job_is_cancelled() actually want to know whether the job
is on its way to immediate termination. For example, we refuse to pause
jobs that are cancelled; but this only makes sense for jobs that are
really actually cancelled.
A mirror job that i
On 23.07.21 21:34, Peter Xu wrote:
memory_region_transaction_{begin|commit}() could be too big when finalizing a
memory region. E.g., we should never attempt to update address space topology
during the finalize() of a memory region. Provide helpers for further use.
Signed-off-by: Peter Xu
---
26.07.2021 17:46, Max Reitz wrote:
We must check whether the job is force-cancelled early in our main loop,
most importantly before any `continue` statement. For example, we used
to have `continue`s before our current checking location that are
triggered by `mirror_flush()` failing. So, if `mir
On Tue, Jul 27, 2021 at 3:37 AM Peter Maydell wrote:
>
> On Tue, 27 Jul 2021 at 01:39, Cleber Rosa wrote:
> >
> >
> > Hi everyone,
> >
> > tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt
> > is currently failing consistently (first found that in [1]).
> >
> > I've bisected
On 23.07.21 21:34, Peter Xu wrote:
Topology update could be wrongly triggered in memory region finalize() if
there's bug somewhere else. It'll be a very confusing stack when it
happens (e.g., sending KVM ioctl within the RCU thread, and we'll observe it
only until it fails!).
Instead of that, w
On Tue, Jul 27, 2021 at 5:17 AM Peter Maydell wrote:
>
> On Tue, 27 Jul 2021 at 01:39, Cleber Rosa wrote:
> > tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt
> > is currently failing consistently (first found that in [1]).
>
> FWIW I find that on my local machine this test
26.07.2021 17:46, Max Reitz wrote:
Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
On Tue, 27 Jul 2021 at 14:18, Cleber Rosa wrote:
>
> On Tue, Jul 27, 2021 at 3:37 AM Peter Maydell
> wrote:
> > This is probably fixed by
> > https://patchew.org/QEMU/20210725174405.24568-1-peter.mayd...@linaro.org/
> > (which is in RTH's pullreq currently on list).
> Actually, it is already fi
On Tue, 27 Jul 2021 at 14:24, Cleber Rosa wrote:
> Yes, I've spent quite some time with some flaky behavior while running
> the replay tests as well. But in the end, the test remained unchanged
> because we found the issues in the actual code under test (one time
> the recording of the replay file
On Tue, Jul 27, 2021 at 9:48 AM Peter Maydell wrote:
>
> On Tue, 27 Jul 2021 at 14:24, Cleber Rosa wrote:
> > Yes, I've spent quite some time with some flaky behavior while running
> > the replay tests as well. But in the end, the test remained unchanged
> > because we found the issues in the act
On Thu, 4 Feb 2021 at 22:38, Hao Wu wrote:
>
> I don't see this error. It could be some error in the clock that the timer
> module does not get a correct clock input.
> How do you reproduce this?
>
> On Thu, Feb 4, 2021 at 1:39 AM Philippe Mathieu-Daudé wrote:
>>
>> Hi,
>>
>> On Tue, Jan 12, 202
On 21/07/2021 19.22, Daniel P. Berrangé wrote:
Peter caught the following transient fail on the staging tree:
https://gitlab.com/qemu-project/qemu/-/jobs/1438817749
--- /builds/qemu-project/qemu/tests/qemu-iotests/197.out
+++ 197.out.bad
@@ -12,13 +12,12 @@
128 KiB, X ops; XX:XX:XX.X (XXX
Since v4:
- Fixed typo, update link (thuth)
Since v3:
- Unfortunately patch 4 v2 got merged as 0a9487d80af so
rebase & reword.
Philippe Mathieu-Daudé (4):
docs: Document GitLab custom CI/CD variables
gitlab-ci: Fix 'when:' condition in acceptance_test_job_template
gitlab-ci: Fix 'when:' c
Jobs depending on another should not use the 'when: always'
condition, because if a dependency failed we should not keep
running jobs depending on it. The correct condition is
'when: on_success'.
Fixes: f56bf4caf71 ("gitlab: Run Avocado tests manually (except mainstream CI)")
Reported-by: Daniel P
We introduced the QEMU_CI_AVOCADO_TESTING variable in commit f56bf4caf
("gitlab: Run Avocado tests manually (except mainstream CI)"), but
forgot to document it properly. Do it now.
Suggested-by: Thomas Huth
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Willian Rampazzo
Reviewed-by: Thomas Huth
Jobs depending on another should not use the 'when: always'
condition, because if a dependency failed we should not keep
running jobs depending on it. The correct condition is
'when: on_success'.
Fixes: 71920809cea ("gitlab-ci.yml: Add jobs to build EDK2 firmware binaries")
Reported-by: Daniel P.
Jobs depending on another should not use the 'when: always'
condition, because if a dependency failed we should not keep
running jobs depending on it. The correct condition is
'when: on_success'.
Fixes: c6fc0fc1a71 ("gitlab-ci.yml: Add jobs to build OpenSBI firmware
binaries")
Reported-by: Daniel
On Mon, Jul 26, 2021 at 09:22:19PM -0700, Guenter Roeck wrote:
> On 7/26/21 2:31 PM, Bjorn Helgaas wrote:
> > [+cc linux-pci]
> >
> > On Mon, Jul 26, 2021 at 04:16:29PM -0500, Bjorn Helgaas wrote:
> > > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> > > > On Mon, 26 Jul 2021 at
On Mon, 26 Jul 2021 at 20:19, Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> Hi Peter,
>
> The following changes since commit 1d6f147f043bece029a795c6eb9d43c1abd909b6:
>
> Merge remote-tracking branch 'remotes/quic/tags/pull-hex-20210725' into
> staging (2021-07-26 13:36:51 +0100)
>
> are avai
On Fri, Jul 23, 2021 at 8:31 AM Daniel P. Berrangé wrote:
>
> GitLab will happily publish pages generated by the latest CI pipeline
> from any branch:
>
> https://docs.gitlab.com/ee/user/project/pages/introduction.html
>
> "Remember that GitLab Pages are by default branch/tag agnostic
>and t
26.07.2021 10:09, Max Reitz wrote:
job->ret = -ECANCELED;
}
if (job->ret) {
@@ -704,7 +709,7 @@ static int job_finalize_single(Job *job)
/* Emit events only if we actually started */
if (job_started(job)) {
- if (job_is_cancelled(job)) {
+ if (j
Commit 1793ad0247 ("iothread: add aio-max-batch parameter") added
a new parameter (aio-max-batch) to IOThread and used PollParamInfo
structure to handle it.
Since it is not a parameter of the polling mechanism, we rename the
structure to a more generic IOThreadParamInfo.
Suggested-by: Kevin Wolf
Commit 0445409d74 ("iothread: generalize
iothread_set_param/iothread_get_param") moved common code to set and
get IOThread parameters in two new functions.
These functions are called inside callbacks, so we don't need to use an
opaque pointer. Let's replace `void *opaque` parameter with
`IOThreadP
1 - 100 of 178 matches
Mail list logo
