On Wed, Jul 15, 2015 at 7:46 PM, Andrey Korolyov <and...@xdel.ru> wrote: > On Wed, Jul 15, 2015 at 7:08 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> On Wed, Jul 15, 2015 at 06:26:03PM +0300, Andrey Korolyov wrote: >>> On Wed, Jul 15, 2015 at 6:18 PM, Igor Mammedov <imamm...@redhat.com> wrote: >>> > On Thu, 9 Jul 2015 20:04:35 +0300 >>> > Andrey Korolyov <and...@xdel.ru> wrote: >>> > >>> >> On Wed, Jul 8, 2015 at 6:46 PM, Igor Mammedov <imamm...@redhat.com> >>> >> wrote: >>> >> > On Wed, 8 Jul 2015 13:01:05 +0300 >>> >> > "Michael S. Tsirkin" <m...@redhat.com> wrote: >>> >> > >>> >> > [...] >>> >> >> - this fixes qemu on current kernels, so it's a bugfix >>> >> >> >>> >> >> - this changes the semantics of memory hot unplug slightly >>> >> >> so I think it's important to merge in 2.4 before we >>> >> >> release qemu with memory hot unplug, this way we >>> >> >> won't have to maintain old semantics forever >>> >> > concerning semantic change, I've just chatted with Peter >>> >> > who implemented libvirt side of the memory hotplug stack. >>> >> > And it's not a problem for libvirt since it always does >>> >> > unplug dimm -> remove backend sequence. >>> >> > >>> >> > >>> >> >>> >> >>> >> Just for the record - top of the series somehow fixed mysterious guest >>> >> memory corruption issue described in >>> >> https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg03117.html >>> >> which existed right from a moment of a memory hotplug introduction, I >>> >> checked series for its disappearance only with vhost for now. Thanks >>> >> Igor! >>> > just to be sure which patch exactly fixed issue for you? >>> > >>> >>> Had not bisected this yet, 2.3 is fairly distant from mine production >>> yet... will post a result today or tomorrow. Until then, I`ll be >>> absolutely out of clues of what was behind mentioned corruption. >> >> Igor merely asked which of his 8 patches fixed it. > > I mentioned exactly the same thing - right now I`m bisecting over his > series from abovementioned branch to find out what commit fixes the > issue, it should take about a hour for completion of the test series. > The expression is about nature of the bug, as it should be ultimately > weird or well-hidded, given conditions of its exposure.
Whoops.. I`m horribly sorry for the statement above, messed up testing result in my head. So far, picture looks as following acf7b7fdf31fa76b53803790917c8acf23a2badb (pre- vhost_one_hp_range_v4 series) - good e5b3a24181ea0cebf1c5b20f44d016311b7048f0 (2.3.0 tag) - bad This means that the issue is fixed elsewhere during rc, I am not promising to find a commit quickly, but I would elaborate as fast as possible in a spare time. Apologies again for messing things up a little.