On Mon, 19 Aug 2024 at 13:59, Salil Mehta <salil.me...@huawei.com> wrote: > > > From: Peter Maydell <peter.mayd...@linaro.org> > > Sent: Friday, August 16, 2024 6:00 PM > > To: Alex Bennée <alex.ben...@linaro.org> > > > > On Fri, 16 Aug 2024 at 16:50, Peter Maydell <peter.mayd...@linaro.org> > > wrote: > > > We shouldn't need to explicitly call cpu_address_space_destroy() from > > > a target-specific unrealize anyway: we can do it all from the base > > > class (and I think this would fix some leaks in current code for > > > targets that hot-unplug, though I should check that). Otherwise you > > > need to duplicate all the logic for figuring out which address spaces > > > we created in realize, which is fragile and not necessary when all we > > > want to do is "delete every address space the CPU object has" > > > and we want to do that for every target architecture always. > > > > I have a patch to do this now, but I need to test it a bit more and > > confirm (or > > disprove) my hypothesis that we're currently leaking memory on existing > > architectures with vCPU hot-unplug before I send it out. > > I think you are referring to this patch? > > https://lore.kernel.org/qemu-devel/20230918160257.30127-9-phi...@linaro.org/
I'd forgotten that Phil had sent that patch out. My patch is a bit different because it refactors cpu_address_space_destroy() into a single function that destroys all the ASes (and so we don't for instance need cpu->cpu_ases_count any more). -- PMM
