Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

On 03/27/2015 05:21 PM, Nikunj A Dadhania wrote: Alexey Kardashevskiy writes: diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 95d666e..dd97258 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -3319,6 +3319,24 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice *vdev) vdev->req_

Re: [Qemu-devel] [PATCH 17/22] bitmap: add atomic test and clear

On Thu, 03/26 18:38, Paolo Bonzini wrote: > From: Stefan Hajnoczi > > The new bitmap_test_and_clear_atomic() function clears a range and > returns whether or not the bits were set. > > Signed-off-by: Stefan Hajnoczi > Message-Id: <1417519399-3166-3-git-send-email-stefa...@redhat.com> > [Test be

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

David Gibson writes: > On Fri, Mar 27, 2015 at 10:04:27AM +0530, Nikunj A Dadhania wrote: >> David Gibson writes: >> >> > On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote: >> >> Each hardware instance has a platform unique location code. The OF >> >> device tree that describes

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

Alexey Kardashevskiy writes: >> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c >> index 95d666e..dd97258 100644 >> --- a/hw/vfio/pci.c >> +++ b/hw/vfio/pci.c >> @@ -3319,6 +3319,24 @@ static void >> vfio_unregister_req_notifier(VFIOPCIDevice *vdev) >> vdev->req_enabled = false; >> } >> >> +b

Re: [Qemu-devel] [PATCH 14/22] exec: only check relevant bitmaps for cleanliness

On Thu, 03/26 18:38, Paolo Bonzini wrote: > Most of the time, not all bitmaps have to be marked as dirty; > do not do anything if the interesting ones are already dirty. > Previously, any clean bitmap would have cause all the bitmaps to be > marked dirty. > > In fact, unless running TCG most of th

Re: [Qemu-devel] [PATCH 2/2] sPAPR: Reenable EEH functionality on reboot

On Thu, Mar 26, 2015 at 04:35:02PM +1100, Gavin Shan wrote: > When rebooting the guest, some PEs might be in frozen state. The > contained PCI devices won't work properly if their frozen states > aren't cleared in time. One case running into this situation would > be maximal EEH error times encount

Re: [Qemu-devel] [PATCH v3 1/2] VFIO: Clear stale MSIx table during EEH reset

On Thu, Mar 26, 2015 at 04:35:01PM +1100, Gavin Shan wrote: > The PCI device MSIx table is cleaned out in hardware after EEH PE > reset. However, we still hold the stale MSIx entries in QEMU, which > should be cleared accordingly. Otherwise, we will run into another > (recursive) EEH error and the

Re: [Qemu-devel] [PATCH 05/22] memory: return bitmap from memory_region_is_logging

On 27/03/2015 06:44, Fam Zheng wrote: > Based on the commit log that said memory_region_is_logging() only returns 0 or > (1 << DIRTY_MEMORY_VGA), the new code keeps the truth table. But I don't > understand why is DIRTY_MEMORY_MIGRATION excluded here and below? Because DIRTY_MEMORY_MIGRATION is

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

On Fri, Mar 27, 2015 at 10:04:27AM +0530, Nikunj A Dadhania wrote: > David Gibson writes: > > > On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote: > >> Each hardware instance has a platform unique location code. The OF > >> device tree that describes a part of a hardware entity m

Re: [Qemu-devel] [PATCH 05/22] memory: return bitmap from memory_region_is_logging

On Thu, 03/26 18:38, Paolo Bonzini wrote: > For now it only returns (1 << DIRTY_MEMORY_VGA) or 0, but this > will change soon so adjust the callers. > > Listeners check for "any bit except migration", which is handled > via the global start/stop listener callbacks. This in practice > means VGA be

[Qemu-devel] [PATCH v4 1/2] qom: Add can_be_deleted callback to UserCreatableClass

If backends implement the can_be_deleted and it returns false, Then the qmp_object_del won't delete the given backends. Signed-off-by: Lin Ma --- include/qom/object_interfaces.h | 14 ++ qmp.c | 5 + qom/object_interfaces.c | 15 +++

[Qemu-devel] [PATCH v4 0/2] Add generic can_be_deleted to UserCreatableClass.

The patchset adds a generic can_be_deleted callback to UserCreatableClass. It prevents removing a usercreatable object if the callback returns false. Backends could implement the callback if it shoudn't be removed while it's in use. Thank Peter Crosthwaite, Paolo Bonzini, Andreas Färber and Igor

[Qemu-devel] [PATCH v4 2/2] hostmem: Prevent removing an in-use memory backend object

showing a memory device whose memdev is removed leads an assert: (qemu) object_add memory-backend-ram,id=ram0,size=128M (qemu) device_add pc-dimm,id=d0,memdev=ram0 (qemu) object_del ram0 (qemu) info memory-devices ** ERROR:qom/object.c:1274:object_get_canonical_path_component:\

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

David Gibson writes: > On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote: >> Each hardware instance has a platform unique location code. The OF >> device tree that describes a part of a hardware entity must include >> the “ibm,loc-code” property with a value that represents the l

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

Alexey Kardashevskiy writes: > On 03/26/2015 05:42 PM, Nikunj A Dadhania wrote: >> Each hardware instance has a platform unique location code. The OF >> device tree that describes a part of a hardware entity must include >> the “ibm,loc-code” property with a value that represents the location >>

Re: [Qemu-devel] [PATCH v5 17/45] Add wrappers and handlers for sending/receiving the postcopy-ram migration messages.

On Thu, Mar 26, 2015 at 04:33:28PM +, Dr. David Alan Gilbert wrote: > (Only replying to some of the items in this mail - the others I'll get > to another time). > > * David Gibson (da...@gibson.dropbear.id.au) wrote: > > On Wed, Feb 25, 2015 at 04:51:40PM +, Dr. David Alan Gilbert (git) >

Re: [Qemu-devel] [PATCH v5 20/45] Modify savevm handlers for postcopy

On Thu, Mar 26, 2015 at 11:44:36AM +, Dr. David Alan Gilbert wrote: > * David Gibson (da...@gibson.dropbear.id.au) wrote: > > On Wed, Mar 25, 2015 at 04:40:11PM +, Dr. David Alan Gilbert wrote: > > > * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: > > > > * David Gibson (da...@gibson.

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

On 03/27/2015 02:28 PM, David Gibson wrote: On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote: Each hardware instance has a platform unique location code. The OF device tree that describes a part of a hardware entity must include the “ibm,loc-code” property with a value that rep

[Qemu-devel] [Bug 1392504] Re: USB Passthrough is not working anymore

Has anyone tested whether this is still broken in 15.04? ** Also affects: libvirt (Ubuntu) Importance: Undecided Status: New ** No longer affects: libvirt (Ubuntu) ** Also affects: libvirt (Ubuntu) Importance: Undecided Status: New ** Changed in: libvirt (Ubuntu) Importan

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote: > Each hardware instance has a platform unique location code. The OF > device tree that describes a part of a hardware entity must include > the “ibm,loc-code” property with a value that represents the location > code for that hard

Re: [Qemu-devel] [PATCH 2/2] spapr: populate ibm,loc-code

On 03/26/2015 05:42 PM, Nikunj A Dadhania wrote: Each hardware instance has a platform unique location code. The OF device tree that describes a part of a hardware entity must include the “ibm,loc-code” property with a value that represents the location code for that hardware entity. Introduce

Re: [Qemu-devel] [PATCH 1/2] vfio-pci: add flag to identify vfio pci device

On 03/26/2015 05:42 PM, Nikunj A Dadhania wrote: From PCIDevice there is no way to know if the device has a backing vfio device. sPAPR guests inherits the "ibm,loc-code" from the pci pass through device in hypervisor. This helps in identifying the device if there is any failures using this "ibm

Re: [Qemu-devel] [v6 08/14] migration: Add the core code of multi-thread compression

> >> > --- a/arch_init.c > >> > +++ b/arch_init.c > >> > @@ -355,12 +355,33 @@ static DecompressParam *decomp_param; > static > >> > QemuThread *decompress_threads; static uint8_t > >> *compressed_data_buf; > >> > > >> > +static int do_compress_ram_page(CompressParam *param); > >> > + > >> > stat

Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind

On 2015/3/26 18:06, Ian Campbell wrote: On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote: Hrm, OK. I suppose we can live with autodetect and igd both meaning igd and whoever adds a new type will have to remember to add a check for qemu-trad then. When we really have to introduce a new ty

Re: [Qemu-devel] [RFC PATCH COLO v2 06/13] NBD client: implement block driver interfaces for block replication

On 03/27/2015 09:06 AM, Fam Zheng wrote: > On Thu, 03/26 15:32, Wen Congyang wrote: >> On 03/26/2015 03:21 PM, Fam Zheng wrote: >>> On Wed, 03/25 17:36, Wen Congyang wrote: Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei --- block/nbd.c |

Re: [Qemu-devel] [PATCH v4 0/7] Block Throttle Group Support

On Thu, 03/26 19:52, Alberto Garcia wrote: > On Thu, Mar 26, 2015 at 07:24:54PM +0200, Alberto Garcia wrote: > > > - The creation/destruction of ThrottleTimers is now handled internally > > when a BlockDriverState is added/removed from a group, since > > there's not much point on keeping them

Re: [Qemu-devel] [RFC PATCH COLO v2 06/13] NBD client: implement block driver interfaces for block replication

On Thu, 03/26 15:32, Wen Congyang wrote: > On 03/26/2015 03:21 PM, Fam Zheng wrote: > > On Wed, 03/25 17:36, Wen Congyang wrote: > >> Signed-off-by: Wen Congyang > >> Signed-off-by: zhanghailiang > >> Signed-off-by: Gonglei > >> --- > >> block/nbd.c | 49

[Qemu-devel] [PATCH] scripts: add 'qemu coroutine' command to qemu-gdb.py

The 'qemu coroutine ' GDB command prints the backtrace for a CoroutineUContext. This is useful for peeking inside yielded coroutines that are waiting for file descriptor events, timers, etc. For example: $ gdb tests/test-coroutine (gdb) b test_yield (gdb) r (gdb) b qemu_coroutine_enter

Re: [Qemu-devel] [Bug 1245703] Re: LD_PREFIX option reads directories recursively in an endless loop

On 26 March 2015 at 21:37, Ross Burton wrote: > We're (Yocto Project) hit this often. We're building a root file system > and then using userspace qemu to run binaries inside it (such as fc- > cache). If a cyclic symlink appears in the rootfs, it blows up. If you're actually building a rootfs t

[Qemu-devel] [Bug 1245703] Re: LD_PREFIX option reads directories recursively in an endless loop

We're (Yocto Project) hit this often. We're building a root file system and then using userspace qemu to run binaries inside it (such as fc- cache). If a cyclic symlink appears in the rootfs, it blows up. -- You received this bug notification because you are a member of qemu- devel-ml, which is

Re: [Qemu-devel] Bouncing maintainers

On 03/26/2015 09:19 AM, Kevin Wolf wrote: Am 25.03.2015 um 16:45 hat John Snow geschrieben: On 03/25/2015 10:48 AM, Markus Armbruster wrote: I just had another cc: to an address gotten from MAINTAINERS bounce with "user unknown". How do we weed out dead MAINTAINERS entries? Automated sp

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Radim Krčmář writes: > 2015-03-26 21:24+0300, Andrey Korolyov: >> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote: >> > 2015-03-26 20:08+0300, Andrey Korolyov: >> >> KVM internal error. Suberror: 2 >> >> extra data[0]: 80ef >> >> extra data[1]: 8b0d >> > >> > Btw. does this part ever

Re: [Qemu-devel] [Qemu-discuss] error - Guest has not initialized the display yet.

On 26/03/2015 21:55, Peter Maydell wrote: > I feel like we're recapitulating history here -- is > c3c1bb99d undoing the fix that a87f39543a made for when we > tried this a year ago in 360e607, or is there something > more subtle going on ? It's more subtle. The patch should only make a differen

Re: [Qemu-devel] [Qemu-discuss] error - Guest has not initialized the display yet.

On 26 March 2015 at 20:31, Mark Cave-Ayland wrote: > I've just done some testing here and I see exactly the same issue - > something is preventing OpenBIOS from executing. A quick session with > git bisect points to the following: > > > c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 is the first bad com

Re: [Qemu-devel] E5-2620v2 - emulation stop error

2015-03-26 21:24+0300, Andrey Korolyov: > On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote: > > 2015-03-26 20:08+0300, Andrey Korolyov: > >> KVM internal error. Suberror: 2 > >> extra data[0]: 80ef > >> extra data[1]: 8b0d > > > > Btw. does this part ever change? > > > > I see that firs

Re: [Qemu-devel] [PATCH v3 1/2] qom: Add can_be_deleted callback to UserCreatableClass

On 26/03/2015 18:07, Lin Ma wrote: > If backends implement the can_be_deleted and it returns false, > Then the qmp_object_del won't delete the given backends. > > Signed-off-by: Lin Ma > --- > include/qom/object_interfaces.h | 3 +++ > qmp.c | 13 + > 2 f

Re: [Qemu-devel] [PATCH] fix assertion in "info memory-devices" if memdev isn't accessible

On 26/03/2015 17:42, Igor Mammedov wrote: > +mdevid = object_property_get_str(OBJECT(dimm->hostmem), "id", > + &error_abort); > +mdevpath = g_strdup_printf("/objects/%s", mdevid); > +g_free(mdevid); > +mde

Re: [Qemu-devel] [Qemu-discuss] error - Guest has not initialized the display yet.

On 25/03/15 23:52, Programmingkid wrote: (Added Peter C as CC) > On Mar 25, 2015, at 6:20 PM, qemu-discuss-requ...@nongnu.org > wrote: > >>> QEMU window opens up, but I am getting this error "Guest has not >>> initialized >>> the display yet" >>> I had en

Re: [Qemu-devel] [PATCH] fix assertion in "info memory-devices" if memdev isn't accessible

On Thu, 26 Mar 2015 15:59:25 -0400 Luiz Capitulino wrote: > On Thu, 26 Mar 2015 16:42:54 + > Igor Mammedov wrote: > > > showing a memory device whose memdev is removed leads to an assert: > > > > (qemu) object_add memory-backend-ram,id=ram0,size=128M > > (qemu) device_add pc-dimm,id=d0,mem

Re: [Qemu-devel] [PATCH] fix assertion in "info memory-devices" if memdev isn't accessible

On Thu, 26 Mar 2015 16:42:54 + Igor Mammedov wrote: > showing a memory device whose memdev is removed leads to an assert: > > (qemu) object_add memory-backend-ram,id=ram0,size=128M > (qemu) device_add pc-dimm,id=d0,memdev=ram0 > (qemu) object_del ram0 > (qemu) info memory-devices > ** > ERRO

Re: [Qemu-devel] [PULL for-2.3 0/1] gtk: do not call gtk_widget_get_window if drawing area is not initialized

16 +) > > are available in the git repository at: > > git://git.kraxel.org/qemu tags/pull-gtk-20150326-1 > > for you to fetch changes up to 4cdfc93526364bc9b20a21c9edd802d737cec85f: > > gtk: do not call gtk_widget_get_window if drawing

Re: [Qemu-devel] [PATCH 3/3] qga support process list, netstat and file stat/delete

On 03/25/2015 06:25 AM, itamar.t...@gmail.com wrote: > From: Itamar Tal This patch says 3/3, but I see no 1/3 or 2/3 (let alone a 0/3 cover letter) in the mail archives. > > this patch add support for some more functionality in the qemu-guest-agent, > both for windows and linux. Main added feat

Re: [Qemu-devel] [PATCH v5 19/28] qapi: Add some type check tests

On 03/26/2015 11:58 AM, Markus Armbruster wrote: > Eric Blake writes: > >> Demonstrate that the qapi generator silently parses confusing >> types, which may cause other errors later on. Later patches >> will update the expected results as the generator is made stricter. >> >> Signed-off-by: Eric

Re: [Qemu-devel] [PATCH v5 18/28] qapi: Unify type bypass and add tests

On 03/26/2015 11:38 AM, Markus Armbruster wrote: > Eric Blake writes: > >> For a few QMP commands, we are forced to pass an arbitrary type >> without tracking it properly in QAPI. Among the existing clients, >> this unnamed type was spelled 'dict', 'visitor', and '**'; this >> patch standardizes

Re: [Qemu-devel] [PATCH v5 13/28] qapi: Add some expr tests

On 03/26/2015 09:55 AM, Markus Armbruster wrote: > Eric Blake writes: > >> Demonstrate that the qapi generator doesn't deal well with >> expressions that aren't up to par. Later patches will improve >> the expected results as the generator is made stricter. Only >> one of the added tests actuall

Re: [Qemu-devel] [PATCH v4 0/7] Block Throttle Group Support

On Thu, Mar 26, 2015 at 07:24:54PM +0200, Alberto Garcia wrote: > - The creation/destruction of ThrottleTimers is now handled internally > when a BlockDriverState is added/removed from a group, since > there's not much point on keeping them separate. This also hides > the timer callbacks fro

Re: [Qemu-devel] [PULL 00/14] Misc bugfixes for 2.3.0-rc2

On 26 March 2015 at 16:02, Paolo Bonzini wrote: > The following changes since commit 549c4e49788bbb16bdac3fb5480a2177019899e2: > > Merge remote-tracking branch > 'remotes/bkoppelmann/tags/pull-tricore-20150324' into staging (2015-03-24 > 09:52:19 +) > > are available in the git repository

Re: [Qemu-devel] E5-2620v2 - emulation stop error

On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote: > 2015-03-26 20:08+0300, Andrey Korolyov: >> KVM internal error. Suberror: 2 >> extra data[0]: 80ef >> extra data[1]: 8b0d > > Btw. does this part ever change? > > I see that first report had: > > KVM internal error. Suberror: 2 > ex

Re: [Qemu-devel] [PATCH v5 19/28] qapi: Add some type check tests

Eric Blake writes: > Demonstrate that the qapi generator silently parses confusing > types, which may cause other errors later on. Later patches > will update the expected results as the generator is made stricter. > > Signed-off-by: Eric Blake > --- [...] > diff --git a/tests/qapi-schema/data-a

[Qemu-devel] [PATCH 22/22] migration: run bitmap sync outside iothread lock

Synchronization of the dirty bitmap can now run concurrently with modifications of it. Note that the change in migration_bitmap_sync is not needed and is only for improved clarity. Signed-off-by: Paolo Bonzini --- arch_init.c | 10 +- include/exec/memory.h | 8 2 fil

Re: [Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1

On Mon, 23 Mar 2015 18:31:59 +0100 Andreas Färber wrote: > Hello, > > This long-postponed series proposes a hierarchical QOM model of socket > and core objects for the x86 PC machines. > > Background is that due to qdev limitations we had to introduce an ICC bus > to be able to hot-add CPUs and

[Qemu-devel] [PATCH 21/22] memory: make cpu_physical_memory_sync_dirty_bitmap() fully atomic

From: Stefan Hajnoczi The fast path of cpu_physical_memory_sync_dirty_bitmap() directly manipulates the dirty bitmap. Use atomic_xchg() to make the test-and-clear atomic. Signed-off-by: Stefan Hajnoczi Message-Id: <1417519399-3166-7-git-send-email-stefa...@redhat.com> [Only do xchg on nonzero

[Qemu-devel] [PATCH 16/22] bitmap: add atomic set functions

From: Stefan Hajnoczi Use atomic_or() for atomic bitmaps where several threads may set bits at the same time. This avoids the race condition between threads loading an element, bitwise ORing, and then storing the element. When setting all bits in a word we can avoid atomic ops and instead just

[Qemu-devel] [PATCH 18/22] memory: use atomic ops for setting dirty memory bits

From: Stefan Hajnoczi Use set_bit_atomic() and bitmap_set_atomic() so that multiple threads can dirty memory without race conditions. Signed-off-by: Stefan Hajnoczi Message-Id: <1417519399-3166-4-git-send-email-stefa...@redhat.com> Signed-off-by: Paolo Bonzini --- include/exec/ram_addr.h | 16

[Qemu-devel] [PATCH 17/22] bitmap: add atomic test and clear

From: Stefan Hajnoczi The new bitmap_test_and_clear_atomic() function clears a range and returns whether or not the bits were set. Signed-off-by: Stefan Hajnoczi Message-Id: <1417519399-3166-3-git-send-email-stefa...@redhat.com> [Test before xchg; then a full barrier is needed at the end just l

[Qemu-devel] [PATCH 10/22] ram_addr: tweaks to xen_modified_memory

Invoke xen_modified_memory from cpu_physical_memory_set_dirty_range_nocode; it is akin to DIRTY_MEMORY_MIGRATION, so set it together with that bitmap. The remaining call from invalidate_and_set_dirty's "else" branch will go away soon. Second, fix the second argument to the function in the cpu_phys

Re: [Qemu-devel] E5-2620v2 - emulation stop error

2015-03-26 20:08+0300, Andrey Korolyov: > KVM internal error. Suberror: 2 > extra data[0]: 80ef > extra data[1]: 8b0d Btw. does this part ever change? I see that first report had: KVM internal error. Suberror: 2 extra data[0]: 80d1 extra data[1]: 8b0d Was that a Windows gu

[Qemu-devel] [PATCH 19/22] migration: move dirty bitmap sync to ram_addr.h

From: Stefan Hajnoczi The dirty memory bitmap is managed by ram_addr.h and copied to migration_bitmap[] periodically during live migration. Move the code to sync the bitmap to ram_addr.h where related code lives. Signed-off-by: Stefan Hajnoczi Message-Id: <1417519399-3166-5-git-send-email-stef

[Qemu-devel] [PATCH 06/22] framebuffer: check memory_region_is_logging

framebuffer.c expects DIRTY_MEMORY_VGA logging to be always on, but that will not be the case soon. Because framebuffer.c computes the memory region on the fly for every update (with memory_region_find), it cannot enable/disable logging by itself. Instead, always treat updates as invalidations if

[Qemu-devel] [PATCH 12/22] exec: use memory_region_is_logging to optimize dirty tracking

memory_region_is_logging now returns the exact set of bitmaps that have to be tracked. Use it instead of the in_migration variable. In the next patch, we will also use it to set only DIRTY_MEMORY_VGA or DIRTY_MEMORY_MIGRATION if necessary. As a result, fewer expensive atomic operations will be r

[Qemu-devel] [PATCH 20/22] memory: replace cpu_physical_memory_reset_dirty() with test-and-clear

From: Stefan Hajnoczi The cpu_physical_memory_reset_dirty() function is sometimes used together with cpu_physical_memory_get_dirty(). This is not atomic since two separate accesses to the dirty memory bitmap are made. Turn cpu_physical_memory_reset_dirty() and cpu_physical_memory_clear_dirty_ra

[Qemu-devel] [PATCH 11/22] exec: simplify notdirty_mem_write

The function has just set two dirty bits and invalidated code, thus cpu_physical_memory_is_clean cannot return true here. Signed-off-by: Paolo Bonzini --- exec.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/exec.c b/exec.c index ffa57dd..56fd0f5 100644 --- a/exec.c

[Qemu-devel] [PATCH 14/22] exec: only check relevant bitmaps for cleanliness

Most of the time, not all bitmaps have to be marked as dirty; do not do anything if the interesting ones are already dirty. Previously, any clean bitmap would have cause all the bitmaps to be marked dirty. In fact, unless running TCG most of the time bitmap operations are not done at all because m

[Qemu-devel] [PATCH 09/22] memory: return DIRTY_MEMORY_MIGRATION from memory_region_is_logging

This will be used to make the setting of bitmaps conditional. Signed-off-by: Paolo Bonzini --- memory.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/memory.c b/memory.c index 3864667..76da05b 100644 --- a/memory.c +++ b/memory.c @@ -1324,7 +1324,11 @@ bool memory_regi

[Qemu-devel] [PATCH 15/22] memory: do not touch code dirty bitmap unless TCG is enabled

cpu_physical_memory_set_dirty_lebitmap unconditionally syncs the DIRTY_MEMORY_CODE bitmap. This however is unused unless TCG is enabled. Signed-off-by: Paolo Bonzini --- include/exec/ram_addr.h | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/include/exec/ram_addr.h b

[Qemu-devel] [PATCH 05/22] memory: return bitmap from memory_region_is_logging

For now it only returns (1 << DIRTY_MEMORY_VGA) or 0, but this will change soon so adjust the callers. Listeners check for "any bit except migration", which is handled via the global start/stop listener callbacks. This in practice means VGA because the code bitmap is TCG-specific; however, be exp

[Qemu-devel] [PATCH 13/22] exec: pass client mask to cpu_physical_memory_set_dirty_range

This cuts in half the cost of bitmap operations (which will become more expensive when made atomic) during migration on non-VRAM regions. Signed-off-by: Paolo Bonzini --- exec.c | 23 +-- include/exec/ram_addr.h | 33 - memory.

[Qemu-devel] [PATCH 07/22] ui/console: check memory_region_is_logging

dpy_gfx_update_dirty expects DIRTY_MEMORY_VGA logging to be always on, but that will not be the case soon. Because it computes the memory region on the fly for every update (with memory_region_find), it cannot enable/disable logging by itself. Instead, always treat updates as invalidations if dir

[Qemu-devel] [PATCH 08/22] memory: track DIRTY_MEMORY_CODE in mr->dirty_log_mask

DIRTY_MEMORY_CODE is only needed for TCG. Signed-off-by: Paolo Bonzini --- include/exec/memory.h | 1 - memory.c | 4 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/include/exec/memory.h b/include/exec/memory.h index 8d5feb2..aa46a52 100644 --- a/include/exec/mem

Re: [Qemu-devel] [PATCH v5 18/28] qapi: Unify type bypass and add tests

Eric Blake writes: > For a few QMP commands, we are forced to pass an arbitrary type > without tracking it properly in QAPI. Among the existing clients, > this unnamed type was spelled 'dict', 'visitor', and '**'; this > patch standardizes on '**'. > > Meanwhile, for both 'gen' and 'success-resp

[Qemu-devel] [PATCH 03/22] memory: the only dirty memory flag for users is DIRTY_MEMORY_VGA

DIRTY_MEMORY_MIGRATION is triggered by memory_global_dirty_log_start and memory_global_dirty_log_stop, so it cannot be used with memory_region_set_log. Specify this in the documentation and assert it. Signed-off-by: Paolo Bonzini --- include/exec/memory.h | 3 +-- memory.c | 1 + 2

[Qemu-devel] [PATCH 01/22] memory: add memory_region_ram_resize

This is a simple MemoryRegion wrapper for qemu_ram_resize. Cc: Michael S. Tsirkin Signed-off-by: Paolo Bonzini --- include/exec/memory.h | 12 memory.c | 7 +++ 2 files changed, 19 insertions(+) diff --git a/include/exec/memory.h b/include/exec/memory.h index 06f

[Qemu-devel] [PATCH 04/22] display: enable DIRTY_MEMORY_VGA tracking explicitly

This will be required soon by the memory core. Signed-off-by: Paolo Bonzini --- hw/display/cg3.c | 1 + hw/display/exynos4210_fimd.c | 7 ++- hw/display/g364fb.c | 2 +- hw/display/sm501.c | 1 + hw/display/tcx.c | 1 + 5 files changed, 10 insertion

[Qemu-devel] [PATCH 02/22] acpi-build: remove dependency from ram_addr.h

ram_addr_t is an internal interface, everyone should go through MemoryRegion. Clean it up by making rom_add_blob return a MemoryRegion* and using the new qemu_ram_resize infrastructure. Cc: Michael S. Tsirkin Signed-off-by: Paolo Bonzini --- hw/core/loader.c | 8 hw/i386/acpi-bui

[Qemu-devel] [PATCH 00/22] Dirty bitmap atomic access and optimizations

QEMU is currently accessing the dirty bitmaps very liberally, which is understandable since the accesses are cheap. This is however not good for squeezing maximum performance out of dataplane, and is also not good if the accesses become more expensive---as is the case when they use atomic primitiv

Re: [Qemu-devel] E5-2620v2 - emulation stop error

2015-03-26 12:36-0400, Kevin O'Connor: > On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote: > > Notice the 0xef. My best hypothesis so far is that we fail at resetting > > devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted. > > (The bug happens at the first place that

Re: [Qemu-devel] E5-2620v2 - emulation stop error

2015-03-26 19:48+0300, Andrey Korolyov: > I`ll post a sample event > capture with and without Radim`s proposed patch maybe today or > tomorrow. Thanks. The patch doesn't change runtime behavior, it just adds another data field to the error report, so t

Re: [Qemu-devel] [PATCH] seccomp: libseccomp version varying according to arch

On 26 March 2015 at 16:21, Juan Quintela wrote: > Eduardo Otubo wrote: >> Libseccomp dependency was mandating version 2.2.0 on all architectures >> and this was causing configure and virt-test to break on non-updates >> distros. This patch works-around it and give a more flexible way to >> check

Re: [Qemu-devel] E5-2620v2 - emulation stop error

On Thu, Mar 26, 2015 at 8:18 PM, Kevin O'Connor wrote: > On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote: >> On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor wrote: >> > On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote: >> >> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'

Re: [Qemu-devel] [PATCH v5 17/28] qapi: Allow true, false and null in schema json

Eric Blake writes: > From: Fam Zheng > > In the near term, we will use it for a sensible-looking > 'gen':false inside command declarations, instead of the > current ugly 'gen':'no'. > > In the long term, it will allow conversion from shorthand > with defaults mentioned only in side-band document

[Qemu-devel] [PATCH 1/7] throttle: Extract timers from ThrottleState into a separate structure

From: Benoît Canet Group throttling will share ThrottleState between multiple bs. As a consequence the ThrottleState will be accessed by multiple aio context. Timers are tied to their aio context so they must go out of the ThrottleState structure. This commit paves the way for each bs of a comm

[Qemu-devel] [PATCH 5/7] throttle: acquire the ThrottleGroup lock in bdrv_swap()

bdrv_swap() touches the fields of a BlockDriverState that are protected by the ThrottleGroup lock. Although those fields end up in their original place, they are temporarily swapped in the process, so there's a chance that an operation on a member of the same group happening on a different thread c

[Qemu-devel] [PATCH 2/7] throttle: Add throttle group infrastructure

Signed-off-by: Alberto Garcia --- block/Makefile.objs | 1 + block/throttle-groups.c | 254 include/block/block_int.h | 1 + include/block/throttle-groups.h | 39 ++ 4 files changed, 295 insertions(+) create mode 100644

[Qemu-devel] [PATCH 3/7] throttle: Add throttle group infrastructure tests

Signed-off-by: Alberto Garcia --- tests/test-throttle.c | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-) diff --git a/tests/test-throttle.c b/tests/test-throttle.c index 458f577..4f151ec 100644 --- a/tests/test-throttle.c +++ b/tests/test-throttle.c @@

Re: [Qemu-devel] [PATCH v5 6/6] target-arm: cpu.h document why env->spsr exists

On 23 March 2015 at 17:05, Alex Bennée wrote: > I was getting very confused about the duplication of state so wanted to > make it explicit. > > Signed-off-by: Alex Bennée > > diff --git a/target-arm/cpu.h b/target-arm/cpu.h > index 083211c..6dc1799 100644 > --- a/target-arm/cpu.h > +++ b/target-a

[Qemu-devel] [PATCH v4 0/7] Block Throttle Group Support

A new version of the patchset. Here was the previous one: https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg01990.html I checked all the things pointed out by Stefan in his comments and I think all of them are fixed now. In addition to that I detected and fixed some additional problem

[Qemu-devel] [PATCH 6/7] throttle: add the name of the ThrottleGroup to BlockDeviceInfo

Signed-off-by: Alberto Garcia --- block/qapi.c | 3 +++ hmp.c| 6 -- qapi/block-core.json | 4 +++- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/block/qapi.c b/block/qapi.c index 65af057..ee823d1 100644 --- a/block/qapi.c +++ b/block/qapi.c @@ -91,6

[Qemu-devel] [PATCH 7/7] throttle: Update throttle infrastructure copyright

Signed-off-by: Alberto Garcia --- include/qemu/throttle.h | 8 +--- util/throttle.c | 8 +--- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/include/qemu/throttle.h b/include/qemu/throttle.h index 2c560db..5af76f0 100644 --- a/include/qemu/throttle.h +++ b/include

[Qemu-devel] [PATCH 4/7] throttle: Add throttle group support

The throttle group support use a cooperative round robin scheduling algorithm. The principles of the algorithm are simple: - Each BDS of the group is used as a token in a circular way. - The active BDS computes if a wait must be done and arms the right timer. - If a wait must be done the token t

Re: [Qemu-devel] [PATCH v5 5/6] target-arm: kvm64 fix save/restore of SPSR regs

On 23 March 2015 at 17:05, Alex Bennée wrote: > The current code was negatively indexing the cpu state array and not > synchronizing banked spsr register state with the current mode's spsr > state, causing occasional failures with migration. > > Some munging is done to take care of the aarch64 map

Re: [Qemu-devel] [PATCH v5 16/28] qapi: Better error messages for duplicated expressions

Eric Blake writes: > The previous commit demonstrated that the generator overlooked > duplicate expressions: > - a complex type or command reusing a built-in type name > - redeclaration of a type name, whether by the same or different > metatype > - redeclaration of a command or event > - collisi

Re: [Qemu-devel] [PATCH v5 4/6] target-arm: kvm64 sync FP register state

On 23 March 2015 at 17:05, Alex Bennée wrote: > +/* Advanced SIMD and FP registers > + * We map Qn = regs[2n+1]:regs[2n] > + */ > +for (i = 0; i < 32; i++) { > +int rd = i << 1; > +float128 fp_val = make_float128(env->vfp.regs[rd + 1], > +

Re: [Qemu-devel] E5-2620v2 - emulation stop error

On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote: > On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor wrote: > > On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote: > >> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote: > >> > I'm not sure if the crash always happen

Re: [Qemu-devel] [PATCH v5 3/6] hw/intc: arm_gic_kvm.c restore config first

On 23 March 2015 at 17:05, Alex Bennée wrote: > As there is logic to deal with the difference between edge and level > triggered interrupts in the kernel we must ensure it knows the > configuration of the IRQs before we restore the pending state. > > Signed-off-by: Alex Bennée > Acked-by: Christo

Re: [Qemu-devel] [PATCH v5 2/6] target-arm: kvm: save/restore mp state

On 23 March 2015 at 17:05, Alex Bennée wrote: > This adds the saving and restore of the current Multi-Processing state > of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of > potential states for x86 we only use two for ARM. Either the process is > running or not. We then save t

[Qemu-devel] [PATCH v3 2/2] hostmem: Prevent removing an in-use memory backend object

showing a memory device whose memdev is removed leads an assert: (qemu) object_add memory-backend-ram,id=ram0,size=128M (qemu) device_add pc-dimm,id=d0,memdev=ram0 (qemu) object_del ram0 (qemu) info memory-devices ** ERROR:qom/object.c:1274:object_get_canonical_path_component:\

Re: [Qemu-devel] E5-2620v2 - emulation stop error

On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor wrote: > On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote: >> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote: >> > I'm not sure if the crash always happens at the "int $0x19" location >> > though. Andrey, does the crash always

[Qemu-devel] [PATCH v3 1/2] qom: Add can_be_deleted callback to UserCreatableClass

If backends implement the can_be_deleted and it returns false, Then the qmp_object_del won't delete the given backends. Signed-off-by: Lin Ma --- include/qom/object_interfaces.h | 3 +++ qmp.c | 13 + 2 files changed, 16 insertions(+) diff --git a/include/

Re: [Qemu-devel] E5-2620v2 - emulation stop error

On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote: > On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote: > > I'm not sure if the crash always happens at the "int $0x19" location > > though. Andrey, does the crash always happen with "EIP=d331" and/or > > with "Code=... 19"? > >

[Qemu-devel] [PATCH v3 0/2] Add generic can_be_deleted to UserCreatableClass.

The patchset adds a generic can_be_deleted callback to UserCreatableClass. It prevents removing a usercreatable object if the callback returns false. Backends could implement the callback if it shoudn't be removed while it's in use. Thank Peter Crosthwaite, Paolo Bonzini, Andreas Färber and Igor

  1   2   3   >