qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] mem1 is in use, can not be deleted


From: Igor Mammedov
Subject: Re: [Qemu-devel] mem1 is in use, can not be deleted
Date: Fri, 10 Jul 2015 11:30:10 +0200

On Thu, 9 Jul 2015 16:22:41 +0200
Eduardo Otubo <address@hidden> wrote:

> On Tue, Jun 30, 2015 at 05=56=02PM +0200, Igor Mammedov wrote:
> > On Tue, 30 Jun 2015 15:56:13 +0200
> > Eduardo Otubo <address@hidden> wrote:
> > 
> > > On Tue, Jun 30, 2015 at 11=18=21AM +0200, Igor Mammedov wrote:
> > > > On Tue, 30 Jun 2015 10:07:52 +0200
> > > > Eduardo Otubo <address@hidden> wrote:
> > > > 
> > > > > Hello all,
> > > > > 
> > > > > I compiled the HEAD of the master branch and was testing memory
> > > > > hotunplug and got to this issue. Note: I followed exactly what's
> > > > > written on the docs/memory-hotplug.txt file.
> > > > > 
> > > > > QEMU 2.3.50 monitor - type 'help' for more information
> > > > > (qemu) object_add memory-backend-ram,id=mem1,size=1G
> > > > > object_add memory-backend-ram,id=mem1,size=1G
> > > > > (qemu) device_add pc-dimm,id=dimm1,memdev=mem1
> > > > > device_add pc-dimm,id=dimm1,memdev=mem1
> > > > > (qemu) device_del dimm1
> > > > > device_del dimm1
> > > > > (qemu) object_del mem1
> > > > > object_del mem1
> > > > > mem1 is in use, can not be deleted
> > > > 
> > > > probably because  dimm1 isn't deleted,
> > > > you can check it in monitor using command "info memory-devices"
> > > 
> > > 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

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.


> 
> >  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.

> 
>  (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.

> 
> Regards,
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]