qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug


From: li guang
Subject: Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Date: Tue, 19 Mar 2013 15:28:38 +0800

在 2013-02-28四的 11:18 +0100,Vasilis Liaskovitis写道:
> Hi,
> 
> sorry for the delay.
> On Tue, Feb 19, 2013 at 07:39:40PM -0300, Erlon Cruz wrote:
> > On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis <
> > address@hidden> wrote:
> > 
> > > This is v4 of the ACPI memory hotplug functionality. Only x86_64 target is
> > > supported (both i440fx and q35). There are still several issues, but it's
> > > been a while since v3 and I wanted to get some more feedback on the 
> > > current
> > > state of the patchseries.
> > >
> > >
> > We are working in memory hotplug functionality on pSeries machine. I'm
> > wondering whether and how we can better integrate things. Do you think the
> > DIMM abstraction is generic enough to be used in other machine types?
> 
> I think the DimmDevice is generic enough but I am open to other suggestions. 
> 
> A related issue is that the patchseries uses a DimmBus to hot-add and 
> hot-remove
> DimmDevice. Another approach that has been suggested is to use links<> between
> DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc
> machines respectively). This would be more similar to the CPUState/qom
> patches - see Andreas Färber's earlier reply to this thread.
> 
> I think we should get some consensus from the community/maintainers before we
> continue to integrate. 
> 
> I haven't updated the series for a while, but I can rework if there is a more
> clear direction for the community.
> 
> Another open issue is reference counting of memoryregions in qemu memory
> model. In order to make memory hot-remove operations safe, we need to remove
> a memoryregion after all users (e.g. both guest and block layer) have stopped
> using it,

it seems it mostly up to the user who want to hot-(un)plug,
if user want to un-plug a memory which is kernel's main memory, kernel
will always run on it(never stop) unless power off.
and if guest stops, all DIMMs should be safe to hot-remove,
or else we should do something to let user can unlock all reference.

>  see discussion at
> http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. There was 
> a
> relevant ibm patchset
> https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html
> but it was not merged.
> 
> > 
> > 
> > > Overview:
> > >
> > > Dimm device layout is modeled with a normal qemu device:
> > >
> > > "-device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0"
> > >
> > >
> >  How does this will handle the no-hotplugable memory for example the memory
> > passed in '-m' parameter?
> 
> The non-hotpluggable initial memory (-m) is currently not modelled at all as a
> DimmDevice. We may want to model it though.
> 
> thanks,
> - Vasilis
> 





reply via email to

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