All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Otubo <eduardo.otubo@profitbricks.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] mem1 is in use, can not be deleted
Date: Fri, 10 Jul 2015 17:35:08 +0200	[thread overview]
Message-ID: <20150710153508.GA11936@vader> (raw)
In-Reply-To: <20150710113010.1a9d405f@nial.brq.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

> > > > Yes, you're right. The reason is surely because dimm1 wasn't deleted
> > > > -- and I think I didn't make my point very clear -- my question was
> > > > more about: Is there any reason for dimm1 not being deleted? The
> > > > reason why I tested with the guest OS fully running and on GRUB is
> > > > because I guessed the guest OS was using this memory and couldn't be
> > > > deallocated. If that's the case, and qemu did a best effort to remove
> > > > and couldn't because guest was using it, then Ok, I just need to
> > > > adapt my tests. Other than that perhaps I hit a bug.
> > > Guest OS has to:
> > >  1. support memory hot remove
> > 
> > How do I know if guest OS supports memory hot remove? I'm testing on
> > Debian 8 with kernel 4.1. I start qemu with "-m 2G,slots=32,maxmem=8G".
> kernel should be compiled with memory remove options

Double checked that and yes, my guest kernel has memory hotplug support.

> 
> Also memory removal is allowed to fail if guest kernel is not able
> to offline corresponding memory sections but it probably should notify
> QEMU via ACPI about failure.

How can I check this notification?

> 
> 
> > 
> > >  2. eject memory device using ACPI _EJ0 method, once it has handled
> > >  removal request, provided it is able to free corresponding memory pages
> > > See docs they should have flows described for success and failure case.
> > 
> > When I issue the command "device_del dimm1" I see no output on dmesg on
> > the guest OS. I guess this is a sign that perhaps the guest does not
> > support it?
> > 
> > From the (very nice) diagram I found at docs/specs/acpi_mem_hotplug.txt,
> > Qemu QMP should output some sort of failure if Guest OS fails to
> > process ejection right? The only information I see is:
> you need to use query-acpi-ospm-status command to see slot status.

Yep, this command outputs that the dimm is still there, no news :/

> 
> > 
> >  (qemu) device_del dimm1
> >  device_del dimm1
> > 
> >  (qemu) info memory-devices
> >  info memory-devices
> >  Memory device [dimm]: "dimm1"
> >    addr: 0x100000000
> >    slot: 0
> >    node: 0
> >    size: 1073741824
> >    memdev: /objects/mem1
> >    hotplugged: true
> >    hotpluggable: true
> > 
> >  (qemu) info memdev
> >  info memdev
> >  memory backend: 0
> >    size:  1073741824
> >    merge: true
> >    dump: true
> >    prealloc: false
> >    policy: default
> >    host nodes: 
> > 
> > How was the environment when you tested this feature?
> Most likely I've used RHEL7.1 as guest with latest systemd
> which onlines hotplugged memory automatically on hotplug.

I tried with Ubuntu 15.04, latest kernel 4.2 and systemd, still not
working. I'm downloading CentOS-7, I'll setup with systemd and proper
kernel configuration. I'll let you know the results.

Thanks a lot for the help so far! :)

-- 
Eduardo Otubo
ProfitBricks GmbH

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-07-10 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30  8:07 [Qemu-devel] mem1 is in use, can not be deleted Eduardo Otubo
2015-06-30  9:18 ` Igor Mammedov
2015-06-30 13:56   ` Eduardo Otubo
2015-06-30 15:56     ` Igor Mammedov
2015-07-09 14:22       ` Eduardo Otubo
2015-07-10  9:30         ` Igor Mammedov
2015-07-10 15:35           ` Eduardo Otubo [this message]
2015-07-13  8:23             ` Igor Mammedov

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=20150710153508.GA11936@vader \
    --to=eduardo.otubo@profitbricks.com \
    --cc=imammedo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.