Re: [PATCH v4] i386: Add ratelimit for bus locks acquired in guest

On 7/27/2021 4:28 PM, Dr. David Alan Gilbert wrote: * 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

Re: [PATCH V5 17/25] vfio-pci: cpr part 2

Hi On 2021/7/20 2:38, Steven Sistare wrote: > On 7/19/2021 2:10 PM, Alex Williamson wrote: >> On Mon, 19 Jul 2021 13:44:08 -0400 >> Steven Sistare wrote: >> >>> On 7/16/2021 4:51 PM, Alex Williamson wrote: On Wed, 7 Jul 2021 10:20:26 -0700 Steve Sistare wrote: > Finish

Re: [PATCH V5 16/25] vfio-pci: cpr part 1

Hi On 2021/7/8 1:20, Steve Sistare wrote: > Enable vfio-pci devices to be saved and restored across an exec restart > of qemu. > > At vfio creation time, save the value of vfio container, group, and device > descriptors in the environment. > > In cprsave and cprexec, suspend the use of virtual

Re: [PATCH V5 13/25] cpr: HMP interfaces for restart

Hi On 2021/7/8 1:20, Steve Sistare wrote: > cprsave > mode may be "restart" > > cprexec > Call cprexec(). > Arguments: > command : command line to execute, with space-separated arguments > > Signed-off-by: Steve Sistare > --- > hmp-commands.hx | 20 +++- >

Re: [PATCH V5 04/25] cpr: HMP interfaces for reboot

Hi On 2021/7/8 1:20, Steve Sistare wrote: > cprsave > Call cprsave(). > Arguments: > file : save vmstate to this file name > mode: must be "reboot" > > cprload > Call cprload(). > Arguments: > file : load vmstate from this file name > > cprinfo > Print to stdout a

Re: [PATCH for-6.2 v3 07/11] machine: Use ms instead of global current_machine in sanity-check

> In the sanity-check of smp_cpus and max_cpus against mc in function > machine_set_smp(), we are now using ms->smp.max_cpus for the check > but using current_machine->smp.max_cpus in the error message. > Tweak this by uniformly using the local ms. > > Reviewed-by: Andrew Jones > Signed-off-by:

[PATCH for-6.2 v3 09/11] machine: Make smp_parse generic enough for all arches

Currently the only difference between smp_parse and pc_smp_parse is the support of dies parameter and the related error reporting. With some arch compat variables like "bool dies_supported", we can make smp_parse generic enough for all arches and the PC specific one can be removed. Making

[PATCH for-6.2 v3 11/11] machine: Move smp_prefer_sockets to struct SMPCompatProps

Now we have a common structure SMPCompatProps used to store information about SMP compatibility stuff, so we can also move smp_prefer_sockets there for cleaner code. No functional change intended. Signed-off-by: Yanan Wang --- hw/arm/virt.c | 2 +- hw/core/machine.c | 2

[PATCH for-6.2 v3 06/11] machine: Prefer cores over sockets in smp parsing since 6.2

In the real SMP hardware topology world, it's much more likely that we have high cores-per-socket counts and few sockets totally. While the current preference of sockets over cores in smp parsing results in a virtual cpu topology with low cores-per-sockets counts and a large number of sockets,

[PATCH for-6.2 v3 04/11] machine: Improve the error reporting of smp parsing

We have two requirements for a valid SMP configuration: the product of "sockets * cores * threads" must represent all the possible cpus, i.e., max_cpus, and then must include the initially present cpus, i.e., smp_cpus. So we only need to ensure 1) "sockets * cores * threads == maxcpus" at first

[PATCH for-6.2 v3 10/11] machine: Remove smp_parse callback from MachineClass

Now we have a generic smp parser for all arches, and there will not be any other arch specific ones, so let's remove the callback from MachineClass and call the parser directly. Signed-off-by: Yanan Wang --- hw/core/machine.c | 3 +-- include/hw/boards.h | 5 - 2 files changed, 1

[PATCH for-6.2 v3 03/11] machine: Set the value of cpus to match maxcpus if it's omitted

Currently we directly calculate the omitted cpus based on the given incomplete collection of parameters. This makes some cmdlines like: -smp maxcpus=16 -smp sockets=2,maxcpus=16 -smp sockets=2,dies=2,maxcpus=16 -smp sockets=2,cores=4,maxcpus=16 not work. We should probably set the value of

[PATCH for-6.2 v3 00/11] machine: smp parsing fixes and improvement

Hi, This is new version of the series [1] that I have posted to introduce some fixes and improvement for SMP parsing. [1] https://lore.kernel.org/qemu-devel/20210719032043.25416-1-wangyana...@huawei.com/ Most of this series is about the SMP parsers: maxcpus is now uniformly used to calculate

[PATCH for-6.2 v3 01/11] machine: Minor refactor/cleanup for the smp parsers

To pave the way for the functional improvement in later patches, make some refactor/cleanup for the smp parsers, including using local maxcpus instead of ms->smp.max_cpus in the calculation, defaulting dies to 0 initially like other members, cleanup the sanity check for dies. No functional change

[PATCH for-6.2 v3 07/11] machine: Use ms instead of global current_machine in sanity-check

In the sanity-check of smp_cpus and max_cpus against mc in function machine_set_smp(), we are now using ms->smp.max_cpus for the check but using current_machine->smp.max_cpus in the error message. Tweak this by uniformly using the local ms. Reviewed-by: Andrew Jones Signed-off-by: Yanan Wang

[PATCH for-6.2 v3 05/11] hw: Add compat machines for 6.2

Add 6.2 machine types for arm/i440fx/q35/s390x/spapr. Reviewed-by: Pankaj Gupta Reviewed-by: Cornelia Huck Reviewed-by: Andrew Jones Acked-by: David Gibson Signed-off-by: Yanan Wang --- hw/arm/virt.c | 9 - hw/core/machine.c | 3 +++ hw/i386/pc.c

[PATCH for-6.2 v3 02/11] machine: Uniformly use maxcpus to calculate the omitted parameters

We are currently using maxcpus to calculate the omitted sockets but using cpus to calculate the omitted cores/threads. This makes cmdlines like: -smp cpus=8,maxcpus=16 -smp cpus=8,cores=4,maxcpus=16 -smp cpus=8,threads=2,maxcpus=16 work fine but the ones like: -smp

[PATCH for-6.2 v3 08/11] machine: Tweak the order of topology members in struct CpuTopology

Now that all the possible topology parameters are integrated in struct CpuTopology, tweak the order of topology members to be "cpus/sockets/ dies/cores/threads/maxcpus" for readability and consistency. We also tweak the comment by adding explanation of dies parameter. Reviewed-by: Pankaj Gupta

RE: [PATCH v5] ui/gtk: New -display gtk option 'full-screen-on-monitor'.

Hi Gerd, Could you add comment or review on this patch? Thank You. Best Regards, Khairul > -Original Message- > From: Markus Armbruster > Sent: Thursday, July 8, 2021 11:49 PM > To: Khor, Swee Aun > Cc: qemu-devel@nongnu.org; Romli, Khairul Anuar > ; Mazlan, Hazwan Arif > ;

[PATCH] ui/cocoa: Use qemu_input_map_osx_to_qcode

ui/cocoa used to have a conversion table from macOS keycode to QKeyCode. It is an unnecessary redundancy as ui/input-keymap.c already has such a table. Worse, I added an incorrect mapping of kVK_JIS_Eisu and kVK_JIS_Kana with commit 708b72557ff510493ab3653c7a1ebfe983009469. According to the

Re: [PATCH v2 13/22] target/loongarch: Add floating point arithmetic instruction translation

Hi, Richard. On 07/28/2021 12:12 AM, Richard Henderson wrote: > On 7/26/21 9:17 PM, Song Gao wrote: >>> I think this should be as simple as >>> >>>    gen_helper_fp_add_s(cpu_fpu[a->fd], cpu_env, >>>    cpu_fpu[a->fj], cpu_fpu[a->fk]); >>> >>> I also think that loongarch

[PATCH] target/arm: kvm: use RCU_READ_LOCK_GUARD() in kvm_arch_fixup_msi_route()

As per commit 5626f8c6d468 ("rcu: Add automatically released rcu_read_lock variants"), RCU_READ_LOCK_GUARD() should be used instead of rcu_read_{un}lock(). Signed-off-by: Hamza Mahfooz --- target/arm/kvm.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git

[ANNOUNCE] QEMU 6.1.0-rc1 is now available

Hello, On behalf of the QEMU Team, I'd like to announce the availability of the second release candidate for the QEMU 6.1 release. This release is meant for testing purposes and should not be used in a production environment. http://download.qemu-project.org/qemu-6.1.0-rc1.tar.xz

[PATCH 1/3] docs: Move the protocol part of barrier.txt into interop

Most of docs/barrier.txt is describing the protocol implemented by the input-barrier device. Move this into the interop section of the manual, and rstify it. Signed-off-by: Peter Maydell --- docs/barrier.txt | 318 - docs/interop/barrier.rst | 426

[PATCH 3/3] docs: Move user-facing barrier docs into system manual

The remaining text in docs/barrier.txt is user-facing description of what the device is and how to use it. Move this into the system manual and rstify it. Signed-off-by: Peter Maydell --- docs/barrier.txt| 48 - docs/system/barrier.rst | 44

[PATCH 2/3] ui/input-barrier: Move TODOs from barrier.txt to a comment

docs/barrier.txt has a couple of TODO notes about things to be implemented in this device; move them into a comment in the source code. Signed-off-by: Peter Maydell --- docs/barrier.txt | 4 ui/input-barrier.c | 5 + 2 files changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH 0/3] docs: Convert barrier.txt to rST

This patchset converts docs/barrier.txt to rST, putting it in the appropriate places: * the protocol info lives in interop/ * the "how to use this" info lives in system/ * TODO remarks live in the .c file :-) thanks -- PMM Peter Maydell (3): docs: Move the protocol part of barrier.txt into

Re: [PULL 1/2] Update libslirp to v4.5.0

Hi all. Just checking in to see where we are. I just checked and master is still using the older libslirp. On Fri, Jun 18, 2021 at 11:14 AM Marc-André Lureau < marcandre.lur...@gmail.com> wrote: > Hi > > On Fri, Jun 18, 2021 at 8:05 PM Doug Evans wrote: > >> Hi. Does anything more need to be

[PATCH] docs: Move bootindex.txt into system section and rstify

Move bootindex.txt into the system section of the manual and turn it into rST format. To make the document make more sense in the context of the system manual, expand the title and introductory paragraphs to give more context. Signed-off-by: Peter Maydell --- docs/bootindex.txt| 52

Re: [PATCH v2 4/6] util/oslib-posix: Avoid creating a single thread with MADV_POPULATE_WRITE

* David Hildenbrand (da...@redhat.com) wrote: > Let's simplify the case when we only want a single thread and don't have > to mess with signal handlers. > > Signed-off-by: David Hildenbrand > --- > util/oslib-posix.c | 8 > 1 file changed, 8 insertions(+) > > diff --git

Re: [PATCH v2 3/6] util/oslib-posix: Don't create too many threads with small memory or little pages

* David Hildenbrand (da...@redhat.com) wrote: > Let's limit the number of threads to something sane, especially that > - We don't have more threads than the number of pages we have > - We don't have threads that initialize small (< 64 MiB) memory > > Signed-off-by: David Hildenbrand

Re: [PATCH 1/3] ui/gtk: adds status bar for expressing ups and fps

I found there are no such performance indicators available in Qemu/GTK. I thought this was the gap as in many fields, users want to check fps or ups to evaluate graphic or display performance in their use-cases. Thanks for your feedback!. On Tue, Jul 27, 2021 at 09:24:44AM +0100, Daniel P.

Re: [PULL 16/21] hw/timer: Refactor NPCM7XX Timer to use CLK clock

On Tue, Jul 27, 2021 at 7:19 AM Peter Maydell wrote: > > 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

RE: [PATCH 02/20] Hexagon HVX (target/hexagon) add Hexagon Vector eXtensions (HVX) to core

> -Original Message- > From: Taylor Simpson > Sent: Sunday, July 25, 2021 10:02 PM > To: Richard Henderson ; qemu- > de...@nongnu.org > Cc: phi...@redhat.com; a...@rev.ng; Brian Cain ; > peter.mayd...@linaro.org > Subject: RE: [PATCH 02/20] Hexagon HVX (target/hexagon) add Hexagon >

Re: [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager

On Tue, Jul 27, 2021 at 11:25:09AM +0200, David Hildenbrand wrote: > For 2) I see 3 options: > > a) Sync everything, fixup the dirty bitmap, never clear the dirty log of > discarded parts. It's fairly simple and straight forward, as I can simply > reuse the existing helper. Something that's

[PATCH 6/7] virtio-gpu: Initialize Venus

Enable VirGL unstable APIs and request Venus when initializing VirGL. Signed-off-by: Antonio Caggiano --- hw/display/virtio-gpu-virgl.c | 2 +- meson.build | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/display/virtio-gpu-virgl.c

[PATCH 2/7] virtio-gpu: hostmem [wip]

From: Gerd Hoffmann --- hw/display/virtio-gpu-base.c| 4 +++ hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu.c | 1 + hw/display/virtio-vga.c | 32 +++-- include/hw/virtio/virtio-gpu.h

[PATCH 7/7] virtio-gpu: Handle resource blob commands

Support BLOB resources creation by calling virgl_renderer_resource_create_blob. Signed-off-by: Antonio Caggiano --- hw/display/virtio-gpu-virgl.c| 148 +++ hw/display/virtio-gpu.c | 9 +- include/hw/virtio/virtio-gpu-bswap.h | 18

[PATCH 3/7] virtio: Add shared memory capability

From: "Dr. David Alan Gilbert" Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG'. They allow defining shared memory regions with sizes and offsets of 2^32 and more. Multiple instances of the capability are allowed and distinguished by a device-specific 'id'. Use

Re: [PULL 0/1] Miscellaneous patches for 2021-07-27

On Tue, 27 Jul 2021 at 16:22, Markus Armbruster wrote: > > The following changes since commit ca4b5ef371d6602b73bc5eec08e3199b05caf146: > > Merge remote-tracking branch > 'remotes/dgilbert-gitlab/tags/pull-migration-20210726a' into staging > (2021-07-27 10:55:50 +0100) > > are available in

Re: [PULL 00/14] target-arm queue

lowing changes since commit c08ccd1b53f488ac86c1f65cf7623dc91acc249a: > > Merge remote-tracking branch 'remotes/rth-gitlab/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-

[PATCH 0/7] virtio-gpu: Support Venus Vulkan driver

This series of patches enables support for the Venus VirtIO-GPU Vulkan driver by adding some features required by the driver: - CONTEXT_INIT - HOSTMEM - RESOURCE_UUID - BLOB_RESOURCES In addition to these features, Venus capset support was required together with the implementation for Virgl blob

[PATCH 5/5] MAINTAINERS: Add ACPI specs documents to ACPI and NVDIMM sections

Add entries for the ACPI specs documents in docs/specs to appropriate sections of MAINTAINERS. Signed-off-by: Peter Maydell --- This is an educated guess; feel free to suggest that these files should go in other sections. --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 5/7] virtio-gpu: Support Venus capset

Signed-off-by: Antonio Caggiano --- hw/display/virtio-gpu-virgl.c | 21 + include/standard-headers/linux/virtio_gpu.h | 2 ++ 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c index

[PATCH 1/7] virtio-gpu: CONTEXT_INIT feature

Create virgl renderer context with flags using context_id when valid. Signed-off-by: Antonio Caggiano --- hw/display/virtio-gpu-base.c| 2 ++ hw/display/virtio-gpu-virgl.c | 10 -- include/hw/virtio/virtio-gpu-bswap.h| 2 +-

[PATCH 1/5] docs/specs/acpu_cpu_hotplug: Convert to rST

Do a basic conversion of the acpi_cpu_hotplug spec document to rST. Signed-off-by: Peter Maydell --- docs/specs/acpi_cpu_hotplug.rst | 235 docs/specs/acpi_cpu_hotplug.txt | 160 -- docs/specs/index.rst| 1 + 3 files changed,

[PATCH 4/5] docs/specs/acpi_nvdimm: Convert to rST

Convert the ACPI NVDIMM spec document to rST. Signed-off-by: Peter Maydell --- docs/specs/acpi_nvdimm.rst | 228 + docs/specs/acpi_nvdimm.txt | 188 -- docs/specs/index.rst | 1 + 3 files changed, 229 insertions(+), 188

[PATCH 4/7] virtio-gpu: Resource UUID

Enable resource UUID feature and implement command resource assign UUID. For the moment, use the resource ID as UUID. Signed-off-by: Antonio Caggiano --- hw/display/trace-events| 1 + hw/display/virtio-gpu-base.c | 2 ++ hw/display/virtio-gpu-virgl.c | 3 +++

[PATCH 3/5] docs/specs/acpi_pci_hotplug: Convert to rST

Convert the PCI hotplug spec document to rST. --- ...i_pci_hotplug.txt => acpi_pci_hotplug.rst} | 37 ++- docs/specs/index.rst | 1 + 2 files changed, 21 insertions(+), 17 deletions(-) rename docs/specs/{acpi_pci_hotplug.txt => acpi_pci_hotplug.rst}

[PATCH 0/5] docs/specs: Convert various ACPI docs to rST

This patchset does a basic conversion of four ACPI related files in docs/specs from plain text to rST format. The aim of the conversion is not to produce a maximally pretty result, but simply to do a low-effort conversion that at least results in this documentation appearing in our manuals rather

[PATCH 2/5] docs/specs/acpi_mem_hotplug: Convert to rST

Convert the acpi memory hotplug spec to rST. Note that this includes converting a lot of weird whitespace characters to plain old spaces (the rST parser does not like whatever the old ones were). Signed-off-by: Peter Maydell --- docs/specs/acpi_mem_hotplug.rst | 128

Re: [PATCH RFC 0/3] mirror: rework soft-cancelling READY mirror

27.07.2021 19:47, Vladimir Sementsov-Ogievskiy wrote: Hi all! That's an alternative to (part of) Max's "[PATCH for-6.1? v2 0/7] mirror: Handle errors after READY cancel" and shows' my idea of handling soft-cancelling READY mirror case directly in qmp_block_job_cancel. And cleanup all other job

[PATCH 3/3] job: drop force argument of *job*cancel

Now, when soft-cancelling READY mirror handled in qmp_block_job_cancel(), no other functions need to care of it: cancel is always force. So drop unused code paths. Signed-off-by: Vladimir Sementsov-Ogievskiy --- include/qemu/job.h | 14 -- block/backup.c

[PATCH 2/3] job: use complete(do_graph_change=false) to handle soft cancel

Soft cancel of READY mirror is more like completion than cancelling. We have bugs and misunderstanding because of this feature. Now, let's handle it the other way to drop force cancelling at all in the following commit. This makes internal implementation cleaner. Still, we should deprecate and

[PATCH 1/3] job: add job_complete_ex with do_graph_change argument

It's an alternative for soft-cancelling mirror job after READY: mirror should finish all in-flight requests, but don't change block graph in any way. To be used in the next commit. Signed-off-by: Vladimir Sementsov-Ogievskiy --- include/qemu/job.h | 5 - block/mirror.c

[PATCH RFC 0/3] mirror: rework soft-cancelling READY mirror

Hi all! That's an alternative to (part of) Max's "[PATCH for-6.1? v2 0/7] mirror: Handle errors after READY cancel" and shows' my idea of handling soft-cancelling READY mirror case directly in qmp_block_job_cancel. And cleanup all other job cancelling functions. That's untested draft, don't take

Re: [PATCH] gitlab-ci.d/buildtest: Disable iotests 197 and 215

On Tue, Jul 27, 2021 at 1:26 PM Thomas Huth wrote: > > The iotests 197 and 215 are occasionally failing in the gitlab-CI now. > According to the log, the failure is "./common.rc: Killed" which might > be an indication that the process has been killed due to out-of-memory > reasons. Both tests are

Re: [PATCH-for-6.1] target/mips: Check nanoMIPS DSP MULT[U] accumulator with Release 6

On 7/26/21 10:30 PM, Philippe Mathieu-Daudé wrote: 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

Re: [PATCH] gitlab-ci.d/buildtest: Disable iotests 197 and 215

On 7/27/21 6:25 PM, Thomas Huth wrote: > The iotests 197 and 215 are occasionally failing in the gitlab-CI now. > According to the log, the failure is "./common.rc: Killed" which might > be an indication that the process has been killed due to out-of-memory > reasons. Both tests are doing a big

Re: [PATCH v2 0/9] memory: Sanity checks memory transaction when releasing BQL

On Tue, Jul 27, 2021 at 02:41:17PM +0200, David Hildenbrand wrote: > Functions that silently drop the BQL are really nasty. I once fall into a > similar trap calling pause_all_vcpus() from within > memory_region_transaction_begin(), while resizing RAM blocks. Yes, hopefull the series can help all

Re: [PATCH RFC 03/19] vfio-user: define VFIO Proxy and communication functions

On Sun, Jul 18, 2021 at 11:27:42PM -0700, Elena Ufimtseva wrote: > From: John G Johnson > > Add user.c and user.h files for vfio-user with the basic > send and receive functions. > > Signed-off-by: John G Johnson > Signed-off-by: Elena Ufimtseva > Signed-off-by: Jagannathan Raman > --- >

Re: [PATCH] gitlab-ci.d/buildtest: Disable iotests 197 and 215

On Tue, Jul 27, 2021 at 06:25:42PM +0200, Thomas Huth wrote: > The iotests 197 and 215 are occasionally failing in the gitlab-CI now. > According to the log, the failure is "./common.rc: Killed" which might > be an indication that the process has been killed due to out-of-memory > reasons. Both

[PATCH] gitlab-ci.d/buildtest: Disable iotests 197 and 215

The iotests 197 and 215 are occasionally failing in the gitlab-CI now. According to the log, the failure is "./common.rc: Killed" which might be an indication that the process has been killed due to out-of-memory reasons. Both tests are doing a big read with 2G that likely causes this issue. It

Re: [PATCH v2 13/22] target/loongarch: Add floating point arithmetic instruction translation

On 7/26/21 9:17 PM, Song Gao wrote: I think this should be as simple as   gen_helper_fp_add_s(cpu_fpu[a->fd], cpu_env,   cpu_fpu[a->fj], cpu_fpu[a->fk]); I also think that loongarch should learn from risc-v and change the architecture to "nan-box" single-precision

Re: [PATCH v2 7/9] cpus: Introduce qemu_mutex_unlock_iothread_prepare()

On Tue, Jul 27, 2021 at 02:59:26PM +0200, David Hildenbrand wrote: > 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 > > ---

Re: [PATCH v2 4/9] memory: Don't do topology update in memory finalize()

On Tue, Jul 27, 2021 at 03:21:31PM +0200, David Hildenbrand wrote: > 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

Re: [PATCH-for-6.1 v5 0/4] gitlab-ci: Document custom CI/CD variables, fix 'when:' conditions

On 27/07/2021 16.24, Philippe Mathieu-Daudé wrote: 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

Re: [PATCH 1/2 v5] Configure script for Haiku

On 21/07/2021 03.40, Richard Zak wrote: Signed-off-by: Richard Zak > ---  configure | 3 ++-  1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 232c54dcc1..163af793e9 100755 --- a/configure +++ b/configure @@ -768,7 +768,8

Re: [PATCH for-6.1? v2 5/7] job: Add job_cancel_requested()

27.07.2021 18:39, Max Reitz wrote: On 27.07.21 15:04, Vladimir Sementsov-Ogievskiy wrote: 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

Re: [PATCH v4 1/4] tpm: mark correct memory region range dirty when clearing RAM

On Tue, Jul 27, 2021 at 10:25:42AM +0200, David Hildenbrand wrote: > 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

Re: [PATCH for-6.1? v2 6/7] mirror: Check job_is_cancelled() earlier

On 27.07.21 15:13, Vladimir Sementsov-Ogievskiy wrote: 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

Re: [PATCH for-6.1? v2 5/7] job: Add job_cancel_requested()

On 27.07.21 15:04, Vladimir Sementsov-Ogievskiy wrote: 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

Re: [PATCH for-6.1? 4/6] job: Add job_cancel_requested()

On 27.07.21 16:47, Vladimir Sementsov-Ogievskiy wrote: 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

[PULL 1/1] vl: Don't continue after -smp help.

We continue after -smp help: $ qemu-system-x86_64 -smp help -display none -monitor stdio smp-opts options: cores= cpus= dies= maxcpus= sockets= threads= QEMU 6.0.50 monitor - type 'help' for more information (qemu) Other options, such as

[PULL 0/1] Miscellaneous patches for 2021-07-27

The following changes since commit ca4b5ef371d6602b73bc5eec08e3199b05caf146: Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-migration-20210726a' into staging (2021-07-27 10:55:50 +0100) are available in the Git repository at: git://repo.or.cz/qemu/armbru.git

Re: [PATCH-for-6.1 v5 4/4] gitlab-ci: Fix 'when:' condition in OpenSBI jobs

On Tue, Jul 27, 2021 at 11:27 AM Philippe Mathieu-Daudé wrote: > > 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

[PATCH 0/2] iothread: cleanup after adding a new parameter to IOThread

We recently added a new parameter (aio-max-batch) to IOThread. This series cleans up the code a bit, no functional changes. Stefano Garzarella (2): iothread: rename PollParamInfo to IOThreadParamInfo iothread: use IOThreadParamInfo in iothread_[set|get]_param() iothread.c | 28

[PATCH 2/2] iothread: use IOThreadParamInfo in iothread_[set|get]_param()

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

[PATCH 1/2] iothread: rename PollParamInfo to IOThreadParamInfo

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

Re: [PATCH for-6.1? 4/6] job: Add job_cancel_requested()

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

Re: [PATCH v2] gitlab: only let pages be published from default branch

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

Re: [PULL for-6.1 00/11] hw/nvme fixes

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

Re: aarch64 efi boot failures with qemu 6.0+

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

[PATCH-for-6.1 v5 4/4] gitlab-ci: Fix 'when:' condition in OpenSBI jobs

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:

[PATCH-for-6.1 v5 3/4] gitlab-ci: Fix 'when:' condition in EDK2 jobs

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.

[PATCH-for-6.1 v5 1/4] docs: Document GitLab custom CI/CD variables

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

[PATCH-for-6.1 v5 2/4] gitlab-ci: Fix 'when:' condition in acceptance_test_job_template

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

[PATCH-for-6.1 v5 0/4] gitlab-ci: Document custom CI/CD variables, fix 'when:' conditions

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:'

Re: Transient fail of iotests 215 and 197

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

Re: [PULL 16/21] hw/timer: Refactor NPCM7XX Timer to use CLK clock

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,

Re: Regression caught by replay_kernel.py:ReplayKernelNormal.test_aarch64_virt

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

Re: Regression caught by replay_kernel.py:ReplayKernelNormal.test_aarch64_virt

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

Re: Regression caught by replay_kernel.py:ReplayKernelNormal.test_aarch64_virt

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

Re: [PATCH for-6.1? v2 7/7] iotests: Add mirror-ready-cancel-error 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

Re: Regression caught by replay_kernel.py:ReplayKernelNormal.test_aarch64_virt

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

Re: [PATCH v2 4/9] memory: Don't do topology update in memory finalize()

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,

Re: Regression caught by replay_kernel.py:ReplayKernelNormal.test_aarch64_virt

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

Re: [PATCH for-6.1? v2 6/7] mirror: Check job_is_cancelled() earlier

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

Re: [PATCH v2 3/9] memory: Introduce memory_region_transaction_{push|pop}()

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

Re: [PATCH for-6.1? v2 5/7] job: Add job_cancel_requested()

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

  1   2   >