Re: [Qemu-devel] [RFC v3 0/8] Fix QEMU crash during memory hotplug with vhost=on

[Andrey Korolyov]

On Wed, Jul 15, 2015 at 7:46 PM, Andrey Korolyov <address@hidden> wrote:
> On Wed, Jul 15, 2015 at 7:08 PM, Michael S. Tsirkin <address@hidden> 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 <address@hidden> wrote:
>>> > On Thu, 9 Jul 2015 20:04:35 +0300
>>> > Andrey Korolyov <address@hidden> wrote:
>>> >
>>> >> On Wed, Jul 8, 2015 at 6:46 PM, Igor Mammedov <address@hidden> wrote:
>>> >> > On Wed, 8 Jul 2015 13:01:05 +0300
>>> >> > "Michael S. Tsirkin" <address@hidden> 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.