Re: [Qemu-devel] [PATCH v3 0/2] block: Quiesce old aio context during bdrv_set_aio_context

On 11/04/2017 00:04, Stefan Hajnoczi wrote: > On Mon, Apr 10, 2017 at 10:26:34AM +0800, Fam Zheng wrote: >> v3: Use bdrv_parent_drained_begin/end. [Kevin] >> Do it before releasing new_context. [Stefan] >> >> Fam Zheng (2): >> block: Make bdrv_parent_drained_begin/end public >> block: Qui

Re: [Qemu-devel] [PATCH 0/5] mc146818rtc: fix Windows VM clock faster

On 12/04/2017 17:51, guangrong.x...@gmail.com wrote: > The root cause is that the clock will be lost if the periodic period is > changed as currently code counts the next periodic time like this: > next_irq_clock = (cur_clock & ~(period - 1)) + period; > > consider the case if cur_clock =

Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN

On 07/04/2017 05:09, Eric Blake wrote: > ## > +# @ShutdownSignal: > +# > +# The list of host signal types known to cause qemu to shut down a guest. > +# > +# @int: SIGINT > +# @hup: SIGHUP > +# @term: SIGTERM > +# > +# Since: 2.10 > +## > +{ 'enum': 'ShutdownSignal', 'data': [ 'int', 'hup', 'ter

Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN

On 12/04/2017 19:02, Markus Armbruster wrote: >> Note that mingw lacks decent signal >> support, and will never report a signal because it never calls >> qemu_system_killed(). > > Awkward. ISO C trivia of the day: "kill" is only a POSIX function. > os-posix.c arranges

Re: [Qemu-devel] [PATCH] event: Add signal information to SHUTDOWN

On 07/04/2017 17:35, Daniel P. Berrange wrote: > Is it conceivable that we find a non-signal based way to distinguish > guest initiated shutdown, from host OS initiated kill when on Win32 ? As far as I know there's no such thing as a "soft kill" (SIGTERM) on Win32, since there is no kill functio

Re: [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

On 2017/4/13 7:51, Stefano Stabellini wrote: On Wed, 12 Apr 2017, Herongguang (Stephen) wrote: On 2017/4/12 6:32, Stefano Stabellini wrote: On Tue, 11 Apr 2017, hrg wrote: On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini wrote: On Mon, 10 Apr 2017, Stefano Stabellini wrote: On Mon, 10

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On 13/04/2017 09:11, Jeff Cody wrote: >> It didn't make it into 2.9-rc4 because of limited time. :( >> >> Looks like there is no -rc5, we'll have to document this as a known issue. >> Users should "block-job-complete/cancel" as soon as possible to avoid such a >> hang. > > I'd argue for including

Re: [Qemu-devel] [PATCH 05/10] tcg: add jr opcode

On 12/04/2017 09:17, Emilio G. Cota wrote: > This will be used by TCG targets to implement a fast path > for indirect branches. > > I only have implemented and tested this on an i386 host, so > make this opcode optional and mark it as not implemented by > other TCG backends. Please don't forget

Re: [Qemu-devel] [PATCH] spapr-cpu-core: Release ICPState object during CPU unrealization

On Wed, Apr 12, 2017 at 01:45:07PM +0530, Bharata B Rao wrote: > Recent commits that re-organized ICPState object missed to destroy > the object when CPU is unrealized. Fix this so that CPU unplug > doesn't abort QEMU. > > Signed-off-by: Bharata B Rao Applied to ppc-for-2.10, thanks. > --- > h

Re: [Qemu-devel] [Qemu-devel RFC v2 0/4] Add support for Smartfusion2 SoC

Hi Qemu-devel, This is my first attempt in Qemu. Please let me know am doing correct or not. SoC is cortex M3 based so no bootrom stuff and unlike other SoCs Qemu need not load dtb and kernel in DDR. Hence am using u-boot (supplied with -kernel) as bootloader in eNVM and it loads kernel from SPI f

Re: [Qemu-devel] WinDbg module

On Wed, Apr 12, 2017 at 05:05:45PM +0300, Mihail Abakumov wrote: > Hello. > > We made the debugger module WinDbg (like GDB) for QEMU. This is the > replacement of the remote stub in Windows kernel. Used for remote Windows > kernel debugging without debugging mode. > > The latest build and instruc

[Qemu-devel] [PATCH v6] migration/block: use blk_pwrite_zeroes for each zero cluster

From: Lidong Chen BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default, this may cause the qcow2 file size to be bigger after migration. This patch checks each cluster, using blk_pwrite_zeroes for each zero cluster. Reviewed-by: Stefan Hajnoczi Signed-off-by: Lidong Chen --- v6 chan

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On Wed, Apr 12, 2017 at 09:11:09PM -0400, Jeff Cody wrote: > On Thu, Apr 13, 2017 at 07:54:20AM +0800, Fam Zheng wrote: > > On Wed, 04/12 18:22, Jeff Cody wrote: > > > On Wed, Apr 12, 2017 at 05:38:17PM -0400, John Snow wrote: > > > > > > > > > > > > On 04/12/2017 04:46 PM, Jeff Cody wrote: > > >

Re: [Qemu-devel] [PATCH 09/10] target/i386: optimize indirect branches with TCG's jr op

On Wed, Apr 12, 2017 at 11:43:45 +0800, Paolo Bonzini wrote: > > > On 12/04/2017 09:17, Emilio G. Cota wrote: > > > > The fact that NBench is not very sensitive to changes here is a > > little surprising, especially given the significant improvements for > > ARM shown in the previous commit. I w

Re: [Qemu-devel] [PATCH 12/12] dirty-bitmap: Convert internal hbitmap size/granularity

On 04/12/2017 01:49 PM, Eric Blake wrote: > Now that all callers are using byte-based interfaces, there's no > reason for our internal hbitmap to remain with sector-based > granularity. It also simplifies our internal scaling, since we > already know that hbitmap widens requests out to granulari

Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/12/2017 09:20 PM, Eric Blake wrote: > On 04/12/2017 12:55 PM, Denis V. Lunev wrote: >> Let me rephrase a bit. >> >> The proposal is looking very close to the following case: >> - raw sparse file >> >> In this case all writes are very-very-very fast and from the >> guest point of view all is O

Re: [Qemu-devel] [PATCH 11/12] dirty-bitmap: Switch bdrv_set_dirty() to bytes

On 04/12/2017 01:49 PM, Eric Blake wrote: > Both callers already had bytes available, but were scaling to > sectors. Move the scaling to internal code. In the case of > bdrv_aligned_pwritev(), we are now passing the exact offset > rather than a rounded sector-aligned value, but that's okay > as

Re: [Qemu-devel] [PATCH 10/12] mirror: Switch mirror_dirty_init() to byte-based iteration

On 04/12/2017 01:49 PM, Eric Blake wrote: > Now that we have adjusted the majority of the calls this function > makes to be byte-based, it is easier to read the code if it makes > passes over the image using bytes rather than sectors. > > Signed-off-by: Eric Blake > --- > block/mirror.c | 35 +

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On Thu, Apr 13, 2017 at 07:54:20AM +0800, Fam Zheng wrote: > On Wed, 04/12 18:22, Jeff Cody wrote: > > On Wed, Apr 12, 2017 at 05:38:17PM -0400, John Snow wrote: > > > > > > > > > On 04/12/2017 04:46 PM, Jeff Cody wrote: > > > > > > > > This occurs on v2.9.0-rc4, but not on v2.8.0. > > > > > >

Re: [Qemu-devel] [PATCH 08/12] dirty-bitmap: Change bdrv_get_dirty() to take bytes

On 04/12/2017 07:25 PM, John Snow wrote: >> +++ b/migration/block.c >> @@ -537,8 +537,7 @@ static int mig_save_device_dirty(QEMUFile *f, >> BlkMigDevState *bmds, >> } else { >> blk_mig_unlock(); >> } >> -if (bdrv_get_dirty(bs, bmds->dirty_bitmap, sector)) {

Re: [Qemu-devel] Fw: First contribution - Interested in Outreachy

On Tue, 04/11 16:44, Prerna Garg wrote: > > > > > From: Prerna Garg > Sent: Tuesday, April 11, 2017 9:57 PM > To: Kevin Wolf > Subject: Re: First contribution - Interested in Outreachy > > > Hello, > > > I am having difficulties sending the email through comm

Re: [Qemu-devel] [PATCH 09/12] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

On 04/12/2017 01:49 PM, Eric Blake wrote: > Some of the callers were already scaling bytes to sectors; others > can be easily converted to pass byte offsets, all in our shift > towards a consistent byte interface everywhere. Making the change > will also make it easier to write the hold-out call

Re: [Qemu-devel] [PATCH 08/12] dirty-bitmap: Change bdrv_get_dirty() to take bytes

On 04/12/2017 01:49 PM, Eric Blake wrote: > Half the callers were already scaling bytes to sectors; the other > half can eventually be simplified to use byte iteration. Both > callers were already using the result as a bool, so make that > explicit. Making the change also makes it easier for a

Re: [Qemu-devel] [PATCH 07/12] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

On 04/12/2017 01:49 PM, Eric Blake wrote: > Thanks to recent cleanups, all callers were scaling a return value > of sectors into bytes; do the scaling internally instead. > > Signed-off-by: Eric Blake > --- > block/dirty-bitmap.c | 4 ++-- > block/mirror.c | 13 + > migratio

Re: [Qemu-devel] [PATCH 07/12] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

On 04/12/2017 01:49 PM, Eric Blake wrote: > Thanks to recent cleanups, all callers were scaling a return value > of sectors into bytes; do the scaling internally instead. > > Signed-off-by: Eric Blake > --- > block/dirty-bitmap.c | 4 ++-- > block/mirror.c | 13 + > migratio

Re: [Qemu-devel] [PATCH 06/12] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

On 04/12/2017 01:49 PM, Eric Blake wrote: > Thanks to recent cleanups, all callers were scaling a return value > of sectors into bytes; do the scaling internally instead. > > Signed-off-by: Eric Blake > --- > block/backup.c | 2 +- > block/dirty-bitmap.c | 2 +- > block/mirror.c |

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

On 04/12/2017 06:57 PM, no-re...@patchew.org wrote: > Hi, > > This series seems to have some coding style problems. See output below for > more information: > === OUTPUT BEGIN === > Checking PATCH 1/1: raspi: Add Raspberry Pi 1 support... > ERROR: line over 90 characters > #189: FILE: hw/arm/rasp

Re: [Qemu-devel] [PULL 00/10] Block layer fixes for 2.9.0-rc4

On Wed, 04/12 16:51, no-re...@patchew.org wrote: > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Message-id: 1491572865-8549-1-git-send-email-kw...@redhat.com > Subject: [Qemu-devel] [PULL 00/10] Block layer fixes for 2.9.0-rc4 > Type:

Re: [Qemu-devel] [PATCH 05/12] dirty-bitmap: Set iterator start by offset, not sector

On 04/12/2017 01:49 PM, Eric Blake wrote: > All callers to bdrv_dirty_iter_new() passed 0 for their initial > starting point, drop that parameter. > > All callers to bdrv_set_dirty_iter() were scaling an offset to > a sector number; move the scaling to occur internally to dirty > bitmap code ins

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 20170408054318.19830-1-omar.riz...@gmail.com Subject: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On Wed, 04/12 18:22, Jeff Cody wrote: > On Wed, Apr 12, 2017 at 05:38:17PM -0400, John Snow wrote: > > > > > > On 04/12/2017 04:46 PM, Jeff Cody wrote: > > > > > > This occurs on v2.9.0-rc4, but not on v2.8.0. > > > > > > When running QEMU with an iothread, and then performing a block-mirror, i

Re: [Qemu-devel] Hacks for building on gcc 7 / Fedora 26

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 20170407143847.GM2138@work-vm Subject: [Qemu-devel] Hacks for building on gcc 7 / Fedora 26 Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log --oneline $BA

Re: [Qemu-devel] [PULL 00/10] Block layer fixes for 2.9.0-rc4

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 1491572865-8549-1-git-send-email-kw...@redhat.com Subject: [Qemu-devel] [PULL 00/10] Block layer fixes for 2.9.0-rc4 Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 tota

Re: [Qemu-devel] [PATCH v2] hw/arm/virt: generate 64-bit addressable ACPI objects

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 20170407144138.12871-1-ard.biesheu...@linaro.org Subject: [Qemu-devel] [PATCH v2] hw/arm/virt: generate 64-bit addressable ACPI objects Type: series === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

On Wed, 12 Apr 2017, Herongguang (Stephen) wrote: > On 2017/4/12 6:32, Stefano Stabellini wrote: > > On Tue, 11 Apr 2017, hrg wrote: > > > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini > > > wrote: > > > > On Mon, 10 Apr 2017, Stefano Stabellini wrote: > > > > > On Mon, 10 Apr 2017, hrg wrot

Re: [Qemu-devel] [PATCH v2 0/9] Provide support for the software TPM

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 1491575431-32170-1-git-send-email-amarnath.vall...@intel.com Subject: [Qemu-devel] [PATCH v2 0/9] Provide support for the software TPM Type: series === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] [Xen-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

On Wed, 12 Apr 2017, Alexey G wrote: > On Tue, 11 Apr 2017 15:32:09 -0700 (PDT) > Stefano Stabellini wrote: > > > On Tue, 11 Apr 2017, hrg wrote: > > > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini > > > wrote: > > > > On Mon, 10 Apr 2017, Stefano Stabellini wrote: > > > >> On Mon, 10

Re: [Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

On 04/12/2017 07:36 PM, Eric Blake wrote: > On 04/12/2017 05:47 PM, John Snow wrote: >> >> >> On 04/12/2017 01:49 PM, Eric Blake wrote: >>> We had several functions that no one was using, and which used >>> sector-based interfaces. I'm trying to convert towards byte-based >>> interfaces, so it's

Re: [Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

On 04/12/2017 05:47 PM, John Snow wrote: > > > On 04/12/2017 01:49 PM, Eric Blake wrote: >> We had several functions that no one was using, and which used >> sector-based interfaces. I'm trying to convert towards byte-based >> interfaces, so it's easier to just drop the unused functions: >> >> b

Re: [Qemu-devel] [PATCH 04/12] dirty-bitmap: Track size in bytes

On 04/12/2017 01:49 PM, Eric Blake wrote: > We are still using an internal hbitmap that tracks a size in sectors, > with the granularity scaled down accordingly, because it lets us > use a shortcut for our iterators which are currently sector-based. > But there's no reason we can't track the dirt

Re: [Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

On 04/12/2017 01:49 PM, Eric Blake wrote: > We had several functions that no one was using, and which used > sector-based interfaces. I'm trying to convert towards byte-based > interfaces, so it's easier to just drop the unused functions: > > bdrv_dirty_bitmap_size > bdrv_dirty_bitmap_get_meta

Re: [Qemu-devel] [PATCH 02/12] migration: Don't lose errno across aio context changes

On 04/12/2017 01:49 PM, Eric Blake wrote: > set_drity_tracking() was assuming that the errno value set by *cough* > bdrv_create_dirty_bitmap() would not be corrupted by either > blk_get_aio_context() or aio_context_release(). Rather than > audit whether this assumption is safe, rewrite the cod

Re: [Qemu-devel] [PATCH 01/12] dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented

On 04/12/2017 01:49 PM, Eric Blake wrote: > We've been documenting the value in bytes since its introduction > in commit b9a9b3a4 (v1.3), where it was actually reported in bytes. > > Commit e4654d2 (v2.0) then removed things from block/qapi.c, in > preparation for a rewrite to a list of dirty se

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On Wed, Apr 12, 2017 at 05:38:17PM -0400, John Snow wrote: > > > On 04/12/2017 04:46 PM, Jeff Cody wrote: > > > > This occurs on v2.9.0-rc4, but not on v2.8.0. > > > > When running QEMU with an iothread, and then performing a block-mirror, if > > we do a system-reset after the BLOCK_JOB_READY e

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On 04/12/2017 04:46 PM, Jeff Cody wrote: > > This occurs on v2.9.0-rc4, but not on v2.8.0. > > When running QEMU with an iothread, and then performing a block-mirror, if > we do a system-reset after the BLOCK_JOB_READY event has emitted, qemu > becomes deadlocked. > > The block job is not paus

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

On Wed, Apr 12, 2017 at 09:17:12PM +, Marc-André Lureau wrote: > Hi > > On Thu, Apr 13, 2017 at 1:03 AM Ben Warren wrote: > > On Apr 12, 2017, at 1:47 PM, Marc-André Lureau < > marcandre.lur...@gmail.com> wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:25 AM Be

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

Hi On Thu, Apr 13, 2017 at 1:03 AM Ben Warren wrote: > On Apr 12, 2017, at 1:47 PM, Marc-André Lureau > wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:25 AM Ben Warren > wrote: > > On Apr 12, 2017, at 1:22 PM, Marc-André Lureau > wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:17 AM Ben Warren >

Re: [Qemu-devel] [PATCH for-2.10 10/23] numa: mirror cpu to node mapping in MachineState::possible_cpus

On Wed, Mar 22, 2017 at 02:32:35PM +0100, Igor Mammedov wrote: > Introduce machine_set_cpu_numa_node() helper that stores > node mapping for CPU in MachineState::possible_cpus. > CPU and node it belongs to is specified by 'props' argument. > > Patch doesn't remove old way of storing mapping in > n

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

> On Apr 12, 2017, at 1:47 PM, Marc-André Lureau > wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:25 AM Ben Warren > wrote: >> On Apr 12, 2017, at 1:22 PM, Marc-André Lureau > > wrote: >> >> Hi >> >> On Thu, Apr 13, 2017 at 12

Re: [Qemu-devel] [PATCH for-2.10 07/23] pc: add node-id property to CPU

On Wed, Mar 22, 2017 at 02:32:32PM +0100, Igor Mammedov wrote: > it will allow switching from cpu_index to property based > numa mapping in follow up patches. I am not sure I understand all the consequences of this, so I will give it a try: "node-id" is an existing field in CpuInstanceProperties.

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

Hi On Thu, Apr 13, 2017 at 12:25 AM Ben Warren wrote: > On Apr 12, 2017, at 1:22 PM, Marc-André Lureau > wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:17 AM Ben Warren > wrote: > > On Apr 12, 2017, at 1:06 PM, Marc-André Lureau > wrote: > > +Device Usage: > +- > + > +The device has

[Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

This occurs on v2.9.0-rc4, but not on v2.8.0. When running QEMU with an iothread, and then performing a block-mirror, if we do a system-reset after the BLOCK_JOB_READY event has emitted, qemu becomes deadlocked. The block job is not paused, nor cancelled, so we are stuck in the while loop in blo

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

> On Apr 12, 2017, at 1:22 PM, Marc-André Lureau > wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:17 AM Ben Warren > wrote: >> On Apr 12, 2017, at 1:06 PM, Marc-André Lureau > > wrote: >> >> +Device Usage: >> +- >>

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

Hi On Thu, Apr 13, 2017 at 12:17 AM Ben Warren wrote: > On Apr 12, 2017, at 1:06 PM, Marc-André Lureau > wrote: > > +Device Usage: > +- > + > +The device has one property, which may be only be set using the command > line: > + > + guid - sets the value of the GUID. A special value

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

On Wed, Apr 12, 2017 at 08:06:32PM +, Marc-André Lureau wrote: > Hi > > On Thu, Mar 2, 2017 at 10:22 AM Michael S. Tsirkin wrote: > > From: Ben Warren > > This patch is based off an earlier version by > Gal Hammer (gham...@redhat.com) > > Requirements section, ASCII diagra

Re: [Qemu-devel] [PATCH for-2.10 00/23] numa: add '-numa cpu' option

On Wed, Mar 22, 2017 at 02:32:25PM +0100, Igor Mammedov wrote: > Changes since RFC: > * convert all targets that support numa (Eduardo) > * add numa CLI tests > * support wildcard matching with "-numa cpu,..." (Paolo) > > Series introduces a new CLI option to allow mapping cpus to numa

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

> On Apr 12, 2017, at 1:06 PM, Marc-André Lureau > wrote: > > Hi > > On Thu, Mar 2, 2017 at 10:22 AM Michael S. Tsirkin > wrote: > From: Ben Warren mailto:b...@skyportsystems.com>> > > This patch is based off an earlier version by > Gal Hammer (gham...@redhat.com

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

On 04/12/17 22:06, Marc-André Lureau wrote: > On Thu, Mar 2, 2017 at 10:22 AM Michael S. Tsirkin wrote: >> +Device Usage: >> +- >> + >> +The device has one property, which may be only be set using the command >> line: >> + >> + guid - sets the value of the GUID. A special value "aut

Re: [Qemu-devel] [PATCH v3 1/1] qga: Add 'guest-get-users' command

Quoting Vinzenz 'evilissimo' Feenstra (2017-04-04 00:51:46) > From: Vinzenz Feenstra > > A command that will list all currently logged in users, and the time > since when they are logged in. > > Examples: > > virsh # qemu-agent-command F25 '{ "execute": "guest-get-users" }' > {"return":[{"login

Re: [Qemu-devel] vmbus bridge: machine property or device?

On Wed, Apr 12, 2017 at 05:18:51PM +0200, Markus Armbruster wrote: > Cc'ing a few more people who might have a reasoned opinion. > > Roman Kagan writes: > > > While hammering out the VMBus / storage series, we've been struggling to > > figure out the best practices solution to the following prob

Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

Hi On Thu, Mar 2, 2017 at 10:22 AM Michael S. Tsirkin wrote: > From: Ben Warren > > This patch is based off an earlier version by > Gal Hammer (gham...@redhat.com) > > Requirements section, ASCII diagrams and overall help > provided by Laszlo Ersek (ler...@redhat.com) > > Signed-off-by: Gal Ham

Re: [Qemu-devel] [PATCH v3] qemu-ga: add guest-get-osrelease command

On 04/03/2017 10:17 AM, Marc-André Lureau wrote: > Hi > > On Fri, Mar 31, 2017 at 3:41 PM Eric Blake wrote: > >> On 03/31/2017 05:19 AM, Vinzenz 'evilissimo' Feenstra wrote: >>> From: Vinzenz Feenstra >>> >>> Add a new 'guest-get-osrelease' command to report OS information in >>> the >>> os-rel

Re: [Qemu-devel] [PATCH] Add 'none' as type for drive's if option

Is there an action I need to take for that? From: Markus Armbruster Sent: Tuesday, April 11, 2017 6:17:10 AM To: Craig Jellick Cc: qemu-devel@nongnu.org; qemu-triv...@nongnu.org Subject: Re: [Qemu-devel] [PATCH] Add 'none' as type for drive's if option Perhaps th

[Qemu-devel] First contribution - Interested in Outreachy

Hello, This is my first patch submission. I am interested in the block filter project for this round of Outreachy. diff --git a/backends/hostmem.c b/backends/hostmem.c index 89feb9e..f056a25 100644 --- a/backends/hostmem.c +++ b/backends/hostmem.c @@ -263,7 +263,7 @@ host_memory_backend_memory

Re: [Qemu-devel] WinDbg module

On 04/12/2017 05:05 PM, Mihail Abakumov wrote: > Hello. > > We made the debugger module WinDbg (like GDB) for QEMU. This is the > replacement of the remote stub in Windows kernel. Used for remote > Windows kernel debugging without debugging mode. > > The latest build and instructions for the launch

Re: [Qemu-devel] EXT :Re: Emulating external registers

Thank you for the suggestions. I found out that the issue was with how the bare metal program configured memory. The program is now able to read and write from a pointer. I included your unimplemented device into the g3 machine (mac_oldworld.c) I am emulating using the following code. create_uni

Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/12/2017 12:55 PM, Denis V. Lunev wrote: > Let me rephrase a bit. > > The proposal is looking very close to the following case: > - raw sparse file > > In this case all writes are very-very-very fast and from the > guest point of view all is OK. Sequential data is really sequential. > Though

Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/06/2017 06:01 PM, Alberto Garcia wrote: > Hi all, > > over the past couple of months I discussed with some of you the > possibility to extend the qcow2 format in order to improve its > performance and reduce its memory requirements (particularly with very > large images). > > After some discu

Re: [Qemu-devel] [PATCH v4 4/4] qemu-img: copy *key-secret opts when opening newly created files

On 04/12/2017 11:44 AM, Daniel P. Berrange wrote: > The qemu-img dd/convert commands will create a image file and > then try to open it. Historically it has been possible to open > new files without passing any options. With encrypted files > though, the *key-secret options are mandatory, so we nee

[Qemu-devel] [PATCH 11/12] dirty-bitmap: Switch bdrv_set_dirty() to bytes

Both callers already had bytes available, but were scaling to sectors. Move the scaling to internal code. In the case of bdrv_aligned_pwritev(), we are now passing the exact offset rather than a rounded sector-aligned value, but that's okay as long as dirty bitmap widens start/bytes to granularit

[Qemu-devel] [PATCH 10/12] mirror: Switch mirror_dirty_init() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. Signed-off-by: Eric Blake --- block/mirror.c | 35 ++- 1 file changed, 14 ins

[Qemu-devel] [PATCH 08/12] dirty-bitmap: Change bdrv_get_dirty() to take bytes

Half the callers were already scaling bytes to sectors; the other half can eventually be simplified to use byte iteration. Both callers were already using the result as a bool, so make that explicit. Making the change also makes it easier for a future dirty-bitmap patch to offload scaling over to

Re: [Qemu-devel] WinDbg module

Am 12.04.2017 um 18:30 schrieb Roman Kagan: On Wed, Apr 12, 2017 at 05:05:45PM +0300, Mihail Abakumov wrote: Hello. We made the debugger module WinDbg (like GDB) for QEMU. This is the replacement of the remote stub in Windows kernel. Used for remote Windows kernel debugging without debugging mo

[Qemu-devel] [PATCH 09/12] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

Some of the callers were already scaling bytes to sectors; others can be easily converted to pass byte offsets, all in our shift towards a consistent byte interface everywhere. Making the change will also make it easier to write the hold-out callers to use byte rather than sectors for their iterat

[Qemu-devel] [PATCH 05/12] dirty-bitmap: Set iterator start by offset, not sector

All callers to bdrv_dirty_iter_new() passed 0 for their initial starting point, drop that parameter. All callers to bdrv_set_dirty_iter() were scaling an offset to a sector number; move the scaling to occur internally to dirty bitmap code instead. Signed-off-by: Eric Blake --- include/block/dir

[Qemu-devel] [PATCH 07/12] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

Thanks to recent cleanups, all callers were scaling a return value of sectors into bytes; do the scaling internally instead. Signed-off-by: Eric Blake --- block/dirty-bitmap.c | 4 ++-- block/mirror.c | 13 + migration/block.c| 2 +- 3 files changed, 8 insertions(+), 11 d

[Qemu-devel] [PATCH 12/12] dirty-bitmap: Convert internal hbitmap size/granularity

Now that all callers are using byte-based interfaces, there's no reason for our internal hbitmap to remain with sector-based granularity. It also simplifies our internal scaling, since we already know that hbitmap widens requests out to granularity boundaries. Signed-off-by: Eric Blake --- bloc

[Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

We had several functions that no one was using, and which used sector-based interfaces. I'm trying to convert towards byte-based interfaces, so it's easier to just drop the unused functions: bdrv_dirty_bitmap_size bdrv_dirty_bitmap_get_meta bdrv_dirty_bitmap_reset_meta bdrv_dirty_bitmap_meta_gran

[Qemu-devel] [PATCH 02/12] migration: Don't lose errno across aio context changes

set_drity_tracking() was assuming that the errno value set by bdrv_create_dirty_bitmap() would not be corrupted by either blk_get_aio_context() or aio_context_release(). Rather than audit whether this assumption is safe, rewrite the code to just grab the value of errno sooner. CC: qemu-sta...@non

[Qemu-devel] [PATCH 06/12] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

Thanks to recent cleanups, all callers were scaling a return value of sectors into bytes; do the scaling internally instead. Signed-off-by: Eric Blake --- block/backup.c | 2 +- block/dirty-bitmap.c | 2 +- block/mirror.c | 8 3 files changed, 6 insertions(+), 6 deletions(-)

[Qemu-devel] [PATCH 04/12] dirty-bitmap: Track size in bytes

We are still using an internal hbitmap that tracks a size in sectors, with the granularity scaled down accordingly, because it lets us use a shortcut for our iterators which are currently sector-based. But there's no reason we can't track the dirty bitmap size in bytes, since it is an internal-only

[Qemu-devel] [PATCH 01/12] dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented

We've been documenting the value in bytes since its introduction in commit b9a9b3a4 (v1.3), where it was actually reported in bytes. Commit e4654d2 (v2.0) then removed things from block/qapi.c, in preparation for a rewrite to a list of dirty sectors in the next commit 21b5683 in block.c, but the n

[Qemu-devel] [PATCH 00/12] make dirty-bitmap byte-based

There are patches floating around to add NBD_CMD_BLOCK_STATUS, but NBD wants to report status on byte granularity (even if the reporting will probably be naturally aligned to sectors or even much higher levels). I've therefore started the task of converting our block status code to report at a byt

Re: [Qemu-devel] [PATCH 1/4] net: add FTGMAC100 support

On 12 April 2017 at 18:29, Cédric Le Goater wrote: > On 04/10/2017 03:43 PM, Peter Maydell wrote: >> On 1 April 2017 at 13:57, Cédric Le Goater wrote: >>> +case FTGMAC100_MAC_LADR: >>> +return (s->conf.macaddr.a[2] << 24) | (s->conf.macaddr.a[3] << 16) >>> | >>> + (s->c

[Qemu-devel] [PATCH] arm: remove remaining cannot_destroy_with_object_finalize_yet

With commit ce5b1bbf624b ("exec: move cpu_exec_init() calls to realize functions"), we can now remove all the remaining cannot_destroy_with_object_finalize_yet as unsafe references have been moved to cpu_exec_realizefn(). (tested with QOM command provided by commit 4c315c27). Suggested-by: Markus

Re: [Qemu-devel] [PATCH 1/4] net: add FTGMAC100 support

On 04/10/2017 03:43 PM, Peter Maydell wrote: > On 1 April 2017 at 13:57, Cédric Le Goater wrote: >> The FTGMAC100 device is an Ethernet controller with DMA function that >> can be found on Aspeed SoCs (which include NCSI). >> >> It is fully compliant with IEEE 802.3 specification for 10/100 Mbps >

Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/06/2017 06:01 PM, Alberto Garcia wrote: > Hi all, > > over the past couple of months I discussed with some of you the > possibility to extend the qcow2 format in order to improve its > performance and reduce its memory requirements (particularly with very > large images). > > After some discu

[Qemu-devel] [PATCH v4 4/4] qemu-img: copy *key-secret opts when opening newly created files

The qemu-img dd/convert commands will create a image file and then try to open it. Historically it has been possible to open new files without passing any options. With encrypted files though, the *key-secret options are mandatory, so we need to provide those options when opening the newly created

[Qemu-devel] [PATCH v4 3/4] qemu-img: introduce --target-image-opts for 'convert' command

The '--image-opts' flags indicates whether the source filename includes options. The target filename has to remain in the plain filename format though, since it needs to be passed to bdrv_create(). When using --skip-create though, it would be possible to use image-opts syntax. This adds --target-i

[Qemu-devel] [PATCH v4 0/4 for-2.10] Improve convert and dd commands

Update to v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05699.html v2: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00728.html v3: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg04391.html This series is in response to Max pointing out that you cannot us

[Qemu-devel] [PATCH v4 2/4] qemu-img: fix --image-opts usage with dd command

The --image-opts flag can only be used to affect the parsing of the source image. The target image has to be specified in the traditional style regardless, since it needs to be passed to the bdrv_create() API which does not support the new style opts. Reviewed-by: Max Reitz Signed-off-by: Daniel

[Qemu-devel] [PATCH v4 1/4] qemu-img: add support for --object with 'dd' command

The qemu-img dd command added --image-opts support, but missed the corresponding --object support. This prevented passing secrets (eg auth passwords) needed by certain disk images. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrange --- qemu-img.c | 18 ++ 1 file changed,

Re: [Qemu-devel] [PATCH v6] kvm: better MWAIT emulation for guests

On Wed, Apr 12, 2017 at 04:54:10PM +0200, Alexander Graf wrote: > > > On 12.04.17 16:34, Jim Mattson wrote: > > Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate > > monitor and mwait instructions as nop"), so when we intercept > > MONITOR/MWAIT, we synthesize #UD. Perhaps it

Re: [Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash

On 12 April 2017 at 16:02, Harry Wagstaff <1682...@bugs.launchpad.net> wrote: > I've done some investigation and it appears that this bug is caused by > the following: > > 1. The flash memory of the virt platform is initialised as a > cfi.pflash01. It has a memory region with romd_mode = true and >

Re: [Qemu-devel] WinDbg module

Hi On Wed, Apr 12, 2017 at 6:44 PM Mihail Abakumov wrote: > Hello. > > We made the debugger module WinDbg (like GDB) for QEMU. This is the > replacement of the remote stub in Windows kernel. Used for remote > Windows kernel debugging without debugging mode. > > The latest build and instructions

Re: [Qemu-devel] [PATCH v6] kvm: better MWAIT emulation for guests

On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf wrote: > > > On 12.04.17 16:34, Jim Mattson wrote: >> >> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate >> monitor and mwait instructions as nop"), so when we intercept >> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this d

Re: [Qemu-devel] vmbus bridge: machine property or device?

Cc'ing a few more people who might have a reasoned opinion. Roman Kagan writes: > While hammering out the VMBus / storage series, we've been struggling to > figure out the best practices solution to the following problem: > > VMBus is provided by a vmbus bridge; it appears the most natural to ha

[Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash

I've done some investigation and it appears that this bug is caused by the following: 1. The flash memory of the virt platform is initialised as a cfi.pflash01. It has a memory region with romd_mode = true and rom_device = true 2. Some code stored in the flash memory is executed. This causes the

Re: [Qemu-devel] [PATCH v2 1/4] Throttle: Create IOThrottle structure

On Thu 30 Mar 2017 02:10:10 PM CEST, Pradeep Jagadeesh wrote: > +## > +# == QAPI IOThrottle definitions > +## > +# @IOThrottle: > +# > +# A set of parameters describing block > +# "describing block ..." ? There's missing text here. Berto

Re: [Qemu-devel] [PATCH] test-keyval: fix leaks

Marc-André Lureau writes: > Hi > > On Wed, Apr 12, 2017 at 3:19 PM Markus Armbruster wrote: > >> Marc-André Lureau writes: >> >> > Signed-off-by: Marc-André Lureau >> > --- >> > tests/test-keyval.c | 4 >> > 1 file changed, 4 insertions(+) >> > >> > diff --git a/tests/test-keyval.c b/tes

  1   2   >