On Tue, 4 Jul 2017 14:41:33 +0530 Bharata B Rao <bhar...@linux.vnet.ibm.com> wrote:
> On Tue, Jul 04, 2017 at 10:02:46AM +0200, Greg Kurz wrote: > > > > There is some history to this. I was doing error recovery and > > > > propagation > > > > here similarly during memory hotplug development phase until Igor > > > > suggested that we shoudn't try to recover after we have done guest > > > > visible changes. > > > > > > > > Refer to "changes in v6" section in this post: > > > > https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00296.html > > > > > > > > However at that time we were doing memory add by DRC index method > > > > and hence would attach and online one LMB at a time. > > > > In that method, if an intermediate attach fails we would end up with a > > > > few > > > > LMBs being onlined by the guest already. However subsequently > > > > we have switched (optionally, based on dedicated_hp_event_source) to > > > > count-indexed method of hotplug where we do attach of all LMBs one by > > > > one > > > > and then request the guest to hotplug all of them at once using > > > > count-indexed > > > > method. > > > > > > > > So it will be a bit tricky to abort for index based case and recover > > > > correctly for count-indexed case. > > > > > > Looked at the code again and realized that though we started with > > > index based LMB addition, we later switched to count based addition. Then > > > we added support for count-indexed type subject to the presence > > > of dedidated hotplug event source while still retaining the support > > > for count based addition. > > > > > > So presently we do attach of all LMBs one by one and then do onlining > > > (count based or count-indexed based) once. Hence error recovery > > > for both cases would be similar now. So I guess you should take care of > > > undoing pc_dimm_memory_plug() like Igor mentioned and also undo the > > > effects of partial successful attaches. > > > > > > > I've sent a v2 that adds rollback. > > oh ok, somehow v2 didn't reach me at all and I saw the v2 in archives only > now. So just noting that my above replies were sent w/o being aware of v2 :) > No problem at all. It confirms that v2 was indeed needed. Also, it exposes some details I wasn't aware of. Thanks for the explanation! :) Cheers, -- Greg > > > > > > > > Regards, > > > > Bharata. >
pgpK0Z0iIojdZ.pgp
Description: OpenPGP digital signature
