Re: [Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary

Eduardo Habkost writes: > On Fri, Aug 16, 2019 at 02:22:58PM +0200, Markus Armbruster wrote: >> Erik Skultety writes: >> >> > On Fri, Aug 16, 2019 at 08:10:20AM +0200, Markus Armbruster wrote: >> >> Eduardo Habkost writes: >> >> >> >> > We have this issue reported when using libvirt to

Re: [Qemu-devel] [PATCH qemu] target/ppc: Add Directed Privileged Door-bell Exception State (DPDES) SPR

On Fri, Aug 16, 2019 at 04:17:33PM +1000, Alexey Kardashevskiy wrote: > DPDES stores a status of a doorbell message and if it is lost in > migration, the destination CPU won't receive it. This does not hit us > much as IPIs complete too quick to catch a pending one and even if > we missed one,

Re: [Qemu-devel] [PATCH] job: drop job_drain

Patchew URL: https://patchew.org/QEMU/20190816170457.522990-1-vsement...@virtuozzo.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN ===

Re: [Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF

Patchew URL: https://patchew.org/QEMU/20190816233422.16715-1-...@google.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF Message-id:

Re: [Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF

+cc: riku.voi...@iki.fi, I typoed the email on the first go. On Fri, Aug 16, 2019 at 4:34 PM Josh Kunz wrote: > This is needed to support debugging PIE ELF binaries running under QEMU > user mode. Currently, `code_offset` and `data_offset` remain unset for > all ELF binaries, so GDB is unable

Re: [Qemu-devel] [PATCH] Add support for ethtool via TARGET_SIOCETHTOOL ioctls.

Hi Shu-Chun Weng via Qemu-devel! We received your email, but were unable to deliver it because it contains content which has been blacklisted by the list admin. Please remove your application/pkcs7-signature attachments and send again. You are also advised to configure your email client to send

[Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF

This is needed to support debugging PIE ELF binaries running under QEMU user mode. Currently, `code_offset` and `data_offset` remain unset for all ELF binaries, so GDB is unable to correctly locate the position of the binary's text and data. The fields `code_offset`, and `data_offset` were

Re: [Qemu-devel] [PATCH v2] linux-user: Add support for SIOCETHTOOL ioctl

Patchew URL: https://patchew.org/QEMU/20190817000714.142802-1-...@google.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH v2] linux-user: Add support for SIOCETHTOOL ioctl Message-id:

Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, August 17, 2019 6:20 AM > To: Laszlo Ersek > Cc: Yao, Jiewen ; Paolo Bonzini > ; de...@edk2.groups.io; edk2-rfc-groups-io > ; qemu devel list ; Igor > Mammedov ; Chen, Yingwen > ;

[Qemu-devel] [PATCH v2] linux-user: Add support for SIOCETHTOOL ioctl

The ioctl numeric values are platform-independent and determined by the file include/uapi/linux/sockios.h in Linux kernel source code: #define SIOCETHTOOL 0x8946 These ioctls get (or set) the field ifr_data of type char* in the structure ifreq. Such functionality is achieved in QEMU by using

Re: [Qemu-devel] [PATCH] Add support for ethtool via TARGET_SIOCETHTOOL ioctls.

Thank you Aleksandar, I've updated the patch description and will send out v2 soon. As for the length of the line: all lines in file syscall_defs.h are of length 81 with a fixed width comment at the end. I'm not sure if making the one line I add 80-character-wide is the right choice. Shu-Chun

[Qemu-devel] [PULL 3/3] hw/ide/atapi: Use the ldst API

From: Philippe Mathieu-Daudé The big-endian load/store functions are already provided by "qemu/bswap.h". Avoid code duplication, use the generic API. Signed-off-by: Philippe Mathieu-Daudé Message-id: 20190808130454.9930-1-phi...@redhat.com Signed-off-by: John Snow --- hw/ide/atapi.c | 80

[Qemu-devel] [PULL 0/3] Ide patches

The following changes since commit afd760539308a5524accf964107cdb1d54a059e3: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190816' into staging (2019-08-16 17:21:40 +0100) are available in the Git repository at: https://github.com/jnsnow/qemu.git tags/ide-pull

[Qemu-devel] [PULL 32/36] iotests/257: test traditional sync modes

Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-12-js...@redhat.com [Edit 'Bitmap' --> 'bitmap' in 257.out --js] Signed-off-by: John Snow --- tests/qemu-iotests/257 | 41 +- tests/qemu-iotests/257.out | 3089 2 files

[Qemu-devel] [PULL 17/36] iotests: add test 257 for bitmap-mode backups

Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-18-js...@redhat.com [Removed 'auto' group, as per new testing config guidelines --js] Signed-off-by: John Snow --- tests/qemu-iotests/257 | 416 +++ tests/qemu-iotests/257.out | 2247

[Qemu-devel] [PULL 2/3] Revert "ide/ahci: Check for -ECANCELED in aio callbacks"

This reverts commit 0d910cfeaf2076b116b4517166d5deb0fea76394. It's not correct to just ignore an error code in a callback; we need to handle that error and possible report failure to the guest so that they don't wait indefinitely for an operation that will now never finish. This ought to help

[Qemu-devel] [PULL 24/36] iotests/257: Refactor backup helpers

This test needs support for non-bitmap backups and missing or unspecified bitmap sync modes, so rewrite the helpers to be a little more generic. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-4-js...@redhat.com Signed-off-by: John Snow ---

[Qemu-devel] [PULL 31/36] block/backup: support bitmap sync modes for non-bitmap backups

Accept bitmaps and sync policies for the other backup modes. This allows us to do things like create a bitmap synced to a full backup without a transaction, or start a resumable backup process. Some combinations don't make sense, though: - NEVER policy combined with any non-BITMAP mode doesn't

[Qemu-devel] [PULL 36/36] tests/test-hbitmap: test next_zero and _next_dirty_area after truncate

From: Vladimir Sementsov-Ogievskiy Test that hbitmap_next_zero and hbitmap_next_dirty_area can find things after old bitmap end. Signed-off-by: Vladimir Sementsov-Ogievskiy Message-id: 20190805164652.42409-1-vsement...@virtuozzo.com Tested-by: John Snow Reviewed-by: John Snow Signed-off-by:

[Qemu-devel] [PULL 35/36] block/backup: refactor write_flags

From: Vladimir Sementsov-Ogievskiy write flags are constant, let's store it in BackupBlockJob instead of recalculating. It also makes two boolean fields to be unused, so, drop them. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: John Snow Reviewed-by: Max Reitz Message-id:

[Qemu-devel] [PULL 1/3] dma-helpers: ensure AIO callback is invoked after cancellation

From: Paolo Bonzini dma_aio_cancel unschedules the BH if there is one, which corresponds to the reschedule_dma case of dma_blk_cb. This can stall the DMA permanently, because dma_complete will never get invoked and therefore nobody will ever invoke the original AIO callback in dbs->common.cb.

[Qemu-devel] [PULL 34/36] block/backup: deal with zero detection

From: Vladimir Sementsov-Ogievskiy We have detect_zeroes option, so at least for blockdev-backup user should define it if zero-detection is needed. For drive-backup leave detection enabled by default but do it through existing option instead of open-coding. Signed-off-by: Vladimir

[Qemu-devel] [PULL 28/36] block/backup: centralize copy_bitmap initialization

Just a few housekeeping changes that keeps the following commit easier to read; perform the initial copy_bitmap initialization in one place. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-8-js...@redhat.com Signed-off-by: John Snow --- block/backup.c | 29

[Qemu-devel] [PULL 29/36] block/backup: add backup_is_cluster_allocated

Modify bdrv_is_unallocated_range to utilize the pnum return from bdrv_is_allocated, and in the process change the semantics from "is unallocated" to "is allocated." Optionally returns a full number of clusters that share the same allocation status. This will be used to carefully toggle bits in

[Qemu-devel] [PULL 27/36] block/backup: improve sync=bitmap work estimates

When making backups based on bitmaps, the work estimate can be more accurate. Update iotests to reflect the new strategy. TOP work estimates are broken, but do not get worse with this commit. That issue is addressed in the following commits instead. Signed-off-by: John Snow Reviewed-by: Max

[Qemu-devel] [PULL 33/36] qapi: add dirty-bitmaps to query-named-block-nodes result

From: Vladimir Sementsov-Ogievskiy Let's add a possibility to query dirty-bitmaps not only on root nodes. It is useful when dealing both with snapshots and incremental backups. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: John Snow Message-id:

[Qemu-devel] [PULL 23/36] iotests/257: add EmulatedBitmap class

Represent a bitmap with an object that we can mark and clear bits in. This makes it easier to manage partial writes when we don't write a full group's worth of patterns before an error. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-3-js...@redhat.com

[Qemu-devel] [PULL 22/36] iotests/257: add Pattern class

Just kidding, this is easier to manage with a full class instead of a namedtuple. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-2-js...@redhat.com Signed-off-by: John Snow --- tests/qemu-iotests/257 | 58 +++--- 1 file

[Qemu-devel] [PULL 26/36] iotests/257: test API failures

Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-6-js...@redhat.com Signed-off-by: John Snow --- tests/qemu-iotests/257 | 67 ++ tests/qemu-iotests/257.out | 85 ++ 2 files changed, 152

[Qemu-devel] [PULL 30/36] block/backup: teach TOP to never copy unallocated regions

Presently, If sync=TOP is selected, we mark the entire bitmap as dirty. In the write notifier handler, we dutifully copy out such regions. Fix this in three parts: 1. Mark the bitmap as being initialized before the first yield. 2. After the first yield but before the backup loop, interrogate the

[Qemu-devel] [PULL 19/36] blockdev: reduce aio_context locked sections in bitmap add/remove

From: Vladimir Sementsov-Ogievskiy Commit 0a6c86d024c52 returned these locks back to add/remove functionality, to protect from intersection of persistent bitmap related IO with other IO. But other bitmap-related functions called here are unrelated to the problem, and there are no needs to keep

[Qemu-devel] [PULL 16/36] iotests: Add virtio-scsi device helper

Seems that it comes up enough. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-17-js...@redhat.com Signed-off-by: John Snow --- tests/qemu-iotests/040| 6 +- tests/qemu-iotests/093| 6 ++ tests/qemu-iotests/139| 7 ++-

[Qemu-devel] [PULL 25/36] block/backup: hoist bitmap check into QMP interface

This is nicer to do in the unified QMP interface that we have now, because it lets us use the right terminology back at the user. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190716000117.25219-5-js...@redhat.com Signed-off-by: John Snow --- block/backup.c | 13 -

[Qemu-devel] [PULL 20/36] qapi: implement block-dirty-bitmap-remove transaction action

It is used to do transactional movement of the bitmap (which is possible in conjunction with merge command). Transactional bitmap movement is needed in scenarios with external snapshot, when we don't want to leave copy of the bitmap in the base image. Signed-off-by: Vladimir Sementsov-Ogievskiy

[Qemu-devel] [PULL 13/36] iotests: add testing shim for script-style python tests

Because the new-style python tests don't use the iotests.main() test launcher, we don't turn on the debugger logging for these scripts when invoked via ./check -d. Refactor the launcher shim into new and old style shims so that they share environmental configuration. Two cleanup notes: debug was

[Qemu-devel] [PULL 21/36] iotests: test bitmap moving inside 254

From: Vladimir Sementsov-Ogievskiy Test persistent bitmap copying with and without removal of original bitmap. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190708220502.12977-4-js...@redhat.com [Edited comment "bitmap1" -->

[Qemu-devel] [PULL 15/36] iotests: teach FilePath to produce multiple paths

Use "FilePaths" instead of "FilePath" to request multiple files be cleaned up after we leave that object's scope. This is not crucial; but it saves a little typing. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-16-js...@redhat.com Signed-off-by: John Snow

[Qemu-devel] [PULL 11/36] block/backup: upgrade copy_bitmap to BdrvDirtyBitmap

This simplifies some interface matters; namely the initialization and (later) merging the manifest back into the sync_bitmap if it was provided. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-12-js...@redhat.com Signed-off-by: John Snow --- block/backup.c |

[Qemu-devel] [PULL 18/36] block/backup: loosen restriction on readonly bitmaps

With the "never" sync policy, we actually can utilize readonly bitmaps now. Loosen the check at the QMP level, and tighten it based on provided arguments down at the job creation level instead. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-19-js...@redhat.com

[Qemu-devel] [PULL 10/36] block/dirty-bitmap: add bdrv_dirty_bitmap_get

Add a public interface for get. While we're at it, rename "bdrv_get_dirty_bitmap_locked" to "bdrv_dirty_bitmap_get_locked". (There are more functions to rename to the bdrv_dirty_bitmap_VERB form, but they will wait until the conclusion of this series.) Signed-off-by: John Snow Reviewed-by: Max

[Qemu-devel] [PULL 14/36] iotests: teach run_job to cancel pending jobs

run_job can cancel pending jobs to simulate failure. This lets us use the pending callback to issue test commands while the job is open, but then still have the job fail in the end. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-15-js...@redhat.com [Maintainer

[Qemu-devel] [PULL 05/36] block/backup: Add mirror sync mode 'bitmap'

We don't need or want a new sync mode for simple differences in semantics. Create a new mode simply named "BITMAP" that is designed to make use of the new Bitmap Sync Mode field. Because the only bitmap sync mode is 'on-success', this adds no new functionality to the backup job (yet). The old

[Qemu-devel] [PULL 02/36] drive-backup: create do_backup_common

Create a common core that comprises the actual meat of what the backup API boundary needs to do, and then switch drive-backup to use it. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-3-js...@redhat.com Signed-off-by: John Snow --- blockdev.c | 122

[Qemu-devel] [PULL 12/36] block/backup: add 'always' bitmap sync policy

This adds an "always" policy for bitmap synchronization. Regardless of if the job succeeds or fails, the bitmap is *always* synchronized. This means that for backups that fail part-way through, the bitmap retains a record of which sectors need to be copied out to accomplish a new backup using the

[Qemu-devel] [PULL 09/36] block/dirty-bitmap: add bdrv_dirty_bitmap_merge_internal

I'm surprised it didn't come up sooner, but sometimes we have a +busy bitmap as a source. This is dangerous from the QMP API, but if we are the owner that marked the bitmap busy, it's safe to merge it using it as a read only source. It is not safe in the general case to allow users to read from

[Qemu-devel] [PULL 01/36] qapi/block-core: Introduce BackupCommon

drive-backup and blockdev-backup have an awful lot of things in common that are the same. Let's fix that. I don't deduplicate 'target', because the semantics actually did change between each structure. Leave that one alone so it can be documented separately. Where documentation was not

[Qemu-devel] [PULL 04/36] qapi: add BitmapSyncMode enum

Depending on what a user is trying to accomplish, there might be a few bitmap cleanup actions that occur when an operation is finished that could be useful. I am proposing three: - NEVER: The bitmap is never synchronized against what was copied. - ALWAYS: The bitmap is always synchronized, even

[Qemu-devel] [PULL 07/36] hbitmap: Fix merge when b is empty, and result is not an alias of a

Nobody calls the function like this currently, but we neither prohibit or cope with this behavior. I decided to make the function cope with it. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-8-js...@redhat.com Signed-off-by: John Snow --- util/hbitmap.c | 13

[Qemu-devel] [PULL 08/36] hbitmap: enable merging across granularities

Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-9-js...@redhat.com Signed-off-by: John Snow --- util/hbitmap.c | 36 +++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/util/hbitmap.c b/util/hbitmap.c index

[Qemu-devel] [PULL 03/36] blockdev-backup: utilize do_backup_common

Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id: 20190709232550.10724-4-js...@redhat.com Signed-off-by: John Snow --- blockdev.c | 65 +- 1 file changed, 6 insertions(+), 59 deletions(-) diff --git a/blockdev.c b/blockdev.c index

[Qemu-devel] [PULL 00/36] Bitmaps patches

The following changes since commit afd760539308a5524accf964107cdb1d54a059e3: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190816' into staging (2019-08-16 17:21:40 +0100) are available in the Git repository at: https://github.com/jnsnow/qemu.git tags/bitmaps-pull

[Qemu-devel] [PULL 06/36] block/backup: add 'never' policy to bitmap sync mode

This adds a "never" policy for bitmap synchronization. Regardless of if the job succeeds or fails, we never update the bitmap. This can be used to perform differential backups, or simply to avoid the job modifying a bitmap. Signed-off-by: John Snow Reviewed-by: Max Reitz Message-id:

Re: [Qemu-devel] [Qemu-block] [PATCH] block: posix: Always allocate the first block

On 8/16/19 6:45 PM, Nir Soffer wrote: > On Sat, Aug 17, 2019 at 12:57 AM John Snow > wrote: > > On 8/16/19 5:21 PM, Nir Soffer wrote: > > When creating an image with preallocation "off" or "falloc", the first > > block of the image is typically not

Re: [Qemu-devel] [PATCH] ppc: Three floating point fixes

16.08.2019. 21.28, "Paul A. Clarke" је написао/ла: > > From: "Paul A. Clarke" > > - target/ppc/fpu_helper.c: > - helper_todouble() was not properly converting INFINITY from 32 bit > float to 64 bit double. > - helper_todouble() was not properly converting any denormalized > 32 bit float

[Qemu-devel] [Bug 1810400] Re: Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted

Acknowledged; target is 4.2. Vladimir Sementsov-Ogievskiy has some patches in-flight that seek to correct block commit behavior with bitmaps: https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg01160.html ** Changed in: qemu Status: New => Confirmed ** Changed in: qemu

Re: [Qemu-devel] [Qemu-block] [PATCH] block: posix: Always allocate the first block

On Sat, Aug 17, 2019 at 12:57 AM John Snow wrote: > On 8/16/19 5:21 PM, Nir Soffer wrote: > > When creating an image with preallocation "off" or "falloc", the first > > block of the image is typically not allocated. When using Gluster > > storage backed by XFS filesystem, reading this block

Re: [Qemu-devel] [POC Seabios PATCH] seabios: use isolated SMM address space for relocation

On 8/16/19 7:24 AM, Igor Mammedov wrote: > for purpose of demo SMRAM (at 0x3) is aliased at a in system address > space > for easy initialization of SMI entry point. > Here is resulting debug output showing that RAM at 0x3 is not affected > by SMM and only RAM in SMM adderss space is

Re: [Qemu-devel] [PATCH] Add support for ethtool via TARGET_SIOCETHTOOL ioctls.

16.08.2019. 23.28, "Shu-Chun Weng via Qemu-devel" је написао/ла: > > The ioctl numeric values are platform-independent and determined by > the file include/uapi/linux/sockios.h in Linux kernel source code: > > #define SIOCETHTOOL 0x8946 > > These ioctls get (or set) the field ifr_data of type

Re: [Qemu-devel] bitmaps branch conflict resolution

On 17.08.19 00:07, John Snow wrote: > Hi Max, I took your patch and adjusted it slightly: I don't like > "skip_bytes" anymore because it's clear now that we don't only read that > value when we're skipping bytes, so now it's just status_bytes. Yep, sure. > Since this is based on your fixup,

Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On Fri, 16 Aug 2019 22:15:15 +0200 Laszlo Ersek wrote: > +Alex (direct question at the bottom) > > On 08/16/19 09:49, Yao, Jiewen wrote: > > below > > > >> -Original Message- > >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >> Sent: Friday, August 16, 2019 3:20 PM > >> To:

Re: [Qemu-devel] [Qemu-block] [PATCH] block: posix: Always allocate the first block

On 8/16/19 5:21 PM, Nir Soffer wrote: > When creating an image with preallocation "off" or "falloc", the first > block of the image is typically not allocated. When using Gluster > storage backed by XFS filesystem, reading this block using direct I/O > succeeds regardless of request length,

Re: [Qemu-devel] [PATCH] Add support for ethtool via TARGET_SIOCETHTOOL ioctls.

Patchew URL: https://patchew.org/QEMU/20190816211356.59244-1-...@google.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH] Add support for ethtool via TARGET_SIOCETHTOOL ioctls. Message-id:

[Qemu-devel] [PATCH] linux-user: add memfd_create

Add support for the memfd_create syscall. If the host does not have the libc wrapper, translate to a direct syscall with NC-macro. Buglink: https://bugs.launchpad.net/qemu/+bug/1734792 Signed-off-by: Shu-Chun Weng --- include/qemu/memfd.h | 4 linux-user/syscall.c | 11 +++

[Qemu-devel] [PATCH] Add support for ethtool via TARGET_SIOCETHTOOL ioctls.

The ioctl numeric values are platform-independent and determined by the file include/uapi/linux/sockios.h in Linux kernel source code: #define SIOCETHTOOL 0x8946 These ioctls get (or set) the field ifr_data of type char* in the structure ifreq. Such functionality is achieved in QEMU by using

[Qemu-devel] [PATCH] block: posix: Always allocate the first block

When creating an image with preallocation "off" or "falloc", the first block of the image is typically not allocated. When using Gluster storage backed by XFS filesystem, reading this block using direct I/O succeeds regardless of request length, fooling alignment detection. In this case we

Re: [Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary

On 8/16/19 1:42 PM, Eduardo Habkost wrote: > On Fri, Aug 16, 2019 at 02:22:58PM +0200, Markus Armbruster wrote: >> Erik Skultety writes: >> >>> On Fri, Aug 16, 2019 at 08:10:20AM +0200, Markus Armbruster wrote: Eduardo Habkost writes: > We have this issue reported when using

Re: [Qemu-devel] Translation of qemu to Swedish...

16.08.2019. 22.20, "Sebastian Rasmussen" је написао/ла: > > Hi! > > I noticed that a translation to Swedish was missing, > so I'd like to contribute that. Let me know if there is > some issue and I'll do my best to fix it. :) > > / Sebastian > > From 9d8525b987e0db8309b6221a7e2a292fa5db9eec Mon

Re: [Qemu-devel] [Qemu-block] [PATCH v5 3/6] iotests: Add casenotrun report to bash tests

On Thu, Aug 15, 2019 at 08:44:11PM -0400, John Snow wrote: > > > On 7/19/19 12:30 PM, Andrey Shinkevich wrote: > > The new function _casenotrun() is to be invoked if a test case cannot > > be run for some reason. The user will be notified by a message passed > > to the function. > > > > Oh, I

[Qemu-devel] Translation of qemu to Swedish...

Hi! I noticed that a translation to Swedish was missing, so I'd like to contribute that. Let me know if there is some issue and I'll do my best to fix it. :) / Sebastian >From 9d8525b987e0db8309b6221a7e2a292fa5db9eec Mon Sep 17 00:00:00 2001 From: Sebastian Rasmussen Date: Fri, 16 Aug 2019

Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

+Alex (direct question at the bottom) On 08/16/19 09:49, Yao, Jiewen wrote: > below > >> -Original Message- >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> Sent: Friday, August 16, 2019 3:20 PM >> To: Yao, Jiewen ; Laszlo Ersek >> ; de...@edk2.groups.io >> Cc: edk2-rfc-groups-io ;

Re: [Qemu-devel] [PATCH v5 0/6] Allow Valgrind checking all QEMU processes

On Fri, Jul 19, 2019 at 07:30:10PM +0300, Andrey Shinkevich wrote: > In the current implementation of the QEMU bash iotests, only qemu-io > processes may be run under the Valgrind, which is a useful tool for > finding memory usage issues. Let's allow the common.rc bash script > runing all the QEMU

Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 08/15/19 18:21, Paolo Bonzini wrote: > On 15/08/19 17:00, Laszlo Ersek wrote: >> On 08/14/19 16:04, Paolo Bonzini wrote: >>> On 14/08/19 15:20, Yao, Jiewen wrote: > - Does this part require a new branch somewhere in the OVMF SEC code? > How do we determine whether the CPU executing

[Qemu-devel] [PATCH] monitor/qmp: Update comment for commit 4eaca8de268

Commit 4eaca8de268 dropped monitor_qmp_respond()'s parameter @id without updating its function comment. Fix that. Signed-off-by: Markus Armbruster --- monitor/qmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/monitor/qmp.c b/monitor/qmp.c index e1b196217d..9d9e5d8b27

[Qemu-devel] [PATCH] ppc: Three floating point fixes

From: "Paul A. Clarke" - target/ppc/fpu_helper.c: - helper_todouble() was not properly converting INFINITY from 32 bit float to 64 bit double. - helper_todouble() was not properly converting any denormalized 32 bit float to 64 bit double. - GCC, as of version 8 or so, takes advantage of

Re: [Qemu-devel] [PATCH v4] ppc: Add support for 'mffsl' instruction

Patchew URL: https://patchew.org/QEMU/1565982203-11048-1-git-send-email...@us.ibm.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH v4] ppc: Add support for 'mffsl' instruction Message-id:

Re: [Qemu-devel] [PATCH 0/4] backup: fix skipping unallocated clusters

On 8/14/19 12:54 PM, Vladimir Sementsov-Ogievskiy wrote: > > > 14 авг. 2019 г. 17:43 пользователь Vladimir Sementsov-Ogievskiy > написал: > > Hi all! > > There is a bug in not yet merged patch > "block/backup: teach TOP to never copy unallocated regions" > in

[Qemu-devel] [PATCH v4] ppc: Add support for 'mffsl' instruction

From: "Paul A. Clarke" ISA 3.0B added a set of Floating-Point Status and Control Register (FPSCR) instructions: mffsce, mffscdrn, mffscdrni, mffscrn, mffscrni, mffsl. This patch adds support for 'mffsl'. 'mffsl' is identical to 'mffs', except it only returns mode, status, and enable bits from

Re: [Qemu-devel] [PATCH 0/2] Add virtio-fs (experimental)

Patchew URL: https://patchew.org/QEMU/20190816143321.20903-1-dgilb...@redhat.com/ Hi, This series failed build test on s390x host. Please find the details below. === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a commit

Re: [Qemu-devel] [Qemu-block] [PATCH] virtio-blk: Cancel the pending BH when the dataplane is reset

On 8/16/19 1:15 PM, Philippe Mathieu-Daudé wrote: > When 'system_reset' is called, the main loop clear the memory > region cache before the BH has a chance to execute. Later when > the deferred function is called, some assumptions that were > made when scheduling them are no longer true when

Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious replication

On Fri, 16 Aug 2019 01:51:20 + "Zhang, Chen" wrote: > > -Original Message- > > From: Lukas Straub [mailto:lukasstra...@web.de] > > Sent: Friday, August 16, 2019 3:48 AM > > To: Dr. David Alan Gilbert > > Cc: qemu-devel ; Zhang, Chen > > ; Jason Wang ; Xie > > Changlong ; Wen

[Qemu-devel] more automated/public CI for QEMU pullreqs

We had a conversation some months back about ways we might switch away from the current handling of pull requests which I do via some hand-curated scripts and personal access to machines, to a more automated system that could be operated by a wider range of people. Unfortunately that conversation

Re: [Qemu-devel] [PATCH 0/2] target/arm: Take exceptions on ATS instructions

Patchew URL: https://patchew.org/QEMU/20190816125802.25877-1-peter.mayd...@linaro.org/ Hi, This series failed build test on s390x host. Please find the details below. === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a

Re: [Qemu-devel] [PATCH for-4.2 09/13] qcow2: Fix overly long snapshot tables

On 31.07.19 11:22, Max Reitz wrote: > On 30.07.19 21:08, Eric Blake wrote: >> On 7/30/19 12:25 PM, Max Reitz wrote: >>> We currently refuse to open qcow2 images with overly long snapshot >>> tables. This patch makes qemu-img check -r all drop all offending >>> entries past what we deem

Re: [Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary

On Fri, Aug 16, 2019 at 02:22:58PM +0200, Markus Armbruster wrote: > Erik Skultety writes: > > > On Fri, Aug 16, 2019 at 08:10:20AM +0200, Markus Armbruster wrote: > >> Eduardo Habkost writes: > >> > >> > We have this issue reported when using libvirt to hotplug CPUs: > >> >

Re: [Qemu-devel] RISCV: when will the CLIC be ready?

On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei wrote: > > Hi, Palmer > > When Michael Clark still was the maintainer of RISCV QEMU, he wrote in the > mail list, "the CLIC interrupt controller is under testing, > and will be included in QEMU 3.1 or 3.2". It is pity that the CLIC is not in > included

[Qemu-devel] [PATCH] virtio-blk: Cancel the pending BH when the dataplane is reset

When 'system_reset' is called, the main loop clear the memory region cache before the BH has a chance to execute. Later when the deferred function is called, some assumptions that were made when scheduling them are no longer true when they actually execute. This is what happens using a virtio-blk

Re: [Qemu-devel] [PATCH] job: drop job_drain

16.08.2019 20:10, Vladimir Sementsov-Ogievskiy wrote: > 16.08.2019 20:04, Vladimir Sementsov-Ogievskiy wrote: >> In job_finish_sync job_enter should be enough for a job to make some >> progress and draining is a wrong tool for it. So use job_enter directly >> here and drop job_drain with all

Re: [Qemu-devel] [PATCH] job: drop job_drain

16.08.2019 20:04, Vladimir Sementsov-Ogievskiy wrote: > In job_finish_sync job_enter should be enough for a job to make some > progress and draining is a wrong tool for it. So use job_enter directly > here and drop job_drain with all related staff not used more. > > Suggested-by: Kevin Wolf >

[Qemu-devel] [PATCH v2] pc: Don't make die-id mandatory unless necessary

We have this issue reported when using libvirt to hotplug CPUs: https://bugzilla.redhat.com/show_bug.cgi?id=1741451 Basically, libvirt is not copying die-id from query-hotpluggable-cpus, but die-id is now mandatory. We could blame libvirt and say it is not following the documented interface,

[Qemu-devel] [PATCH] job: drop job_drain

In job_finish_sync job_enter should be enough for a job to make some progress and draining is a wrong tool for it. So use job_enter directly here and drop job_drain with all related staff not used more. Suggested-by: Kevin Wolf Signed-off-by: Vladimir Sementsov-Ogievskiy --- It's a

Re: [Qemu-devel] [PULL 00/29] target-arm queue

814a' into staging (2019-08-16 > 12:00:18 +0100) > > are available in the Git repository at: > > https://git.linaro.org/people/pmaydell/qemu-arm.git > tags/pull-target-arm-20190816 > > for you to fetch changes up to 664b7e3b97d6376f3329986c465b3782458b0f8b: > > ta

Re: [Qemu-devel] [Bug 645662] Re: QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit

Fine by me. I suggest to keep tracking this though, if necessary in another bug item. Regards, Arno On Fri, Aug 16, 2019 at 16:06:29 CEST, Peter Maydell wrote: > Looking at our code we're still implementing the x87 insns FSIN, FCOS, > FSINCOS, FPTAN, FPATAN, F2XM1, FYL2X, FYL2XP1 by "convert

Re: [Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary

On Fri, Aug 16, 2019 at 03:20:11PM +0200, Igor Mammedov wrote: > On Thu, 15 Aug 2019 15:38:03 -0300 > Eduardo Habkost wrote: > > > We have this issue reported when using libvirt to hotplug CPUs: > > https://bugzilla.redhat.com/show_bug.cgi?id=1741451 > > > > Basically, libvirt is not copying

Re: [Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary

On Fri, Aug 16, 2019 at 08:10:20AM +0200, Markus Armbruster wrote: > Eduardo Habkost writes: > > > We have this issue reported when using libvirt to hotplug CPUs: > > https://bugzilla.redhat.com/show_bug.cgi?id=1741451 > > > > Basically, libvirt is not copying die-id from > >

Re: [Qemu-devel] [PATCH v3 0/4] qcow2: async handling of fragmented io

15.08.2019 18:39, Vladimir Sementsov-Ogievskiy wrote: > 15.08.2019 17:09, Max Reitz wrote: >> On 15.08.19 14:10, Vladimir Sementsov-Ogievskiy wrote: >>> Hi all! >>> >>> Here is an asynchronous scheme for handling fragmented qcow2 >>> reads and writes. Both qcow2 read and write functions loops

Re: [Qemu-devel] [PULL 00/16] Block layer patches

On Fri, 16 Aug 2019 at 10:36, Kevin Wolf wrote: > > The following changes since commit 9e06029aea3b2eca1d5261352e695edc1e7d7b8b: > > Update version for v4.1.0 release (2019-08-15 13:03:37 +0100) > > are available in the Git repository at: > > git://repo.or.cz/qemu/kevin.git tags/for-upstream

Re: [Qemu-devel] [PATCH v4 0/3] Add Aspeed GPIO controller model

On 16/08/2019 09:32, Rashmica Gupta wrote: > v5: > - integrated AspeedGPIOController fields into AspeedGPIOClass > - separated ast2600_3_6v and ast2600_1_8v into two classes Rashmica, This looks much nicer ! Please take a look at branch aspeed-4.2 in which I have merged your v5 and modified

Re: [Qemu-devel] [PATCH v6 37/42] block: Leave BDS.backing_file constant

09.08.2019 19:14, Max Reitz wrote: > Parts of the block layer treat BDS.backing_file as if it were whatever > the image header says (i.e., if it is a relative path, it is relative to > the overlay), other parts treat it like a cache for > bs->backing->bs->filename (relative paths are relative to

Re: [Qemu-devel] [PATCH v5 2/3] aspeed: add a GPIO controller to the SoC

On 16/08/2019 09:40, Rashmica Gupta wrote: > Cédric, this is how I thought changes to the SOC for your aspeed-4.1 > branch would look Some comments, > From 13a07834476fa266c352d9a075b341c483b2edf9 Mon Sep 17 00:00:00 2001 > From: Rashmica Gupta > Date: Fri, 16 Aug 2019 15:18:22 +1000 >

Re: [Qemu-devel] [PATCH v5 2/3] aspeed: add a GPIO controller to the SoC

On 16/08/2019 09:32, Rashmica Gupta wrote: > Signed-off-by: Rashmica Gupta Reviewed-by: Cédric Le Goater Thanks, C. > --- > include/hw/arm/aspeed_soc.h | 3 +++ > hw/arm/aspeed_soc.c | 17 + > 2 files changed, 20 insertions(+) > > diff --git

  1   2   3   >