From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com, groug@kaod.org,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] QEMU terminates during reboot after memory unplug with vhost=on
Date: Thu, 14 Sep 2017 13:48:26 +0530 [thread overview]
Message-ID: <20170914081826.GA23373@in.ibm.com> (raw)
In-Reply-To: <20170914100011.296185d2@nial.brq.redhat.com>
On Thu, Sep 14, 2017 at 10:00:11AM +0200, Igor Mammedov wrote:
> On Thu, 14 Sep 2017 12:31:18 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
>
> > Hi,
> >
> > QEMU hits the below assert
> >
> > qemu-system-ppc64: used ring relocated for ring 2
> > qemu-system-ppc64: qemu/hw/virtio/vhost.c:649: vhost_commit: Assertion `r >= 0' failed.
> >
> > in the following scenario:
> >
> > 1. Boot guest with vhost=on
> > -netdev tap,id=mynet0,script=qemu-ifup,downscript=qemu-ifdown,vhost=on -device virtio-net-pci,netdev=mynet0
> > 2. Hot add a DIMM device
> > 3. Reboot
> > When the guest reboots, we can see
> > vhost_virtqueue_start:vq->used_phys getting assigned an address that
> > falls in the hotplugged memory range.
> > 4. Remove the DIMM device
> > Guest refuses the removal as the hotplugged memory is under use.
> > 5. Reboot
>
> > QEMU forces the removal of the DIMM device during reset and that's
> > when we hit the above assert.
> I don't recall implementing forced removal om DIMM,
> could you point out to the related code, pls?
This is ppc specific. We have DR Connector objects for each LMB (multiple
LMBs make up one DIMM device) and during reset we invoke the
release routine for these LMBs which will further invoke
pc_dimm_memory_unplug().
See hw/ppc/spapr_drc.c: spapr_drc_reset()
hw/ppc/spapr.c: spapr_lmb_release()
>
> > Any pointers on why we are hitting this assert ? Shouldn't vhost be
> > done with using the hotplugged memory when we hit reset ?
>
> >From another point of view,
> DIMM shouldn't be removed unless guest explicitly ejects it
> (at least that should be so in x86 case).
While that is true for ppc also, shouldn't we start fresh from reset ?
Related comment from hw/ppc/spapr_drc.c: spapr_drc_reset()
/* immediately upon reset we can safely assume DRCs whose devices
* are pending removal can be safely removed.
*/
if (drc->unplug_requested) {
spapr_drc_release(drc);
}
So essentially in the scenario I listed, the unplug request is rejected
by the guest, but during next reboot, QEMU excersies the above code
and removes any devices (memory, CPU etc) that are marked for removal.
Regards,
Bharata.
next prev parent reply other threads:[~2017-09-14 8:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 7:01 [Qemu-devel] QEMU terminates during reboot after memory unplug with vhost=on Bharata B Rao
2017-09-14 8:00 ` Igor Mammedov
2017-09-14 8:18 ` Bharata B Rao [this message]
2017-09-14 8:59 ` Igor Mammedov
2017-09-14 10:20 ` Bharata B Rao
2017-10-16 10:08 ` Bharata B Rao
-- strict thread matches above, loose matches on Subject: below --
2017-11-16 12:23 Greg Kurz
2017-11-16 15:28 ` Michael S. Tsirkin
2017-11-16 15:34 ` Greg Kurz
2017-11-16 15:53 ` Alex Williamson
2017-11-16 15:59 ` Michael S. Tsirkin
2017-11-16 16:04 ` Alex Williamson
2017-11-16 16:17 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170914081826.GA23373@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).