From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3750CC433E0 for ; Sat, 2 Jan 2021 14:13:40 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 73EE422482 for ; Sat, 2 Jan 2021 14:13:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 73EE422482 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=nongnu.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:60234 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvhf0-0004Om-28 for qemu-devel@archiver.kernel.org; Sat, 02 Jan 2021 09:13:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvhdl-0003cO-E1; Sat, 02 Jan 2021 09:12:21 -0500 Received: from zero.eik.bme.hu ([152.66.115.2]:13745) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvhdi-0002Lp-F3; Sat, 02 Jan 2021 09:12:20 -0500 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id 6DAAA7470FD; Sat, 2 Jan 2021 15:12:14 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 359247470DD; Sat, 2 Jan 2021 15:12:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 3396574645F; Sat, 2 Jan 2021 15:12:14 +0100 (CET) Date: Sat, 2 Jan 2021 15:12:14 +0100 (CET) To: Peter Maydell Subject: Re: [RFC PATCH 3/5] hw/pci-host/bonito: Remap PCI "lo" regions when PCIMAP reg is modified In-Reply-To: Message-ID: <8e9f16e-2f17-4f99-d0ee-96df2ad76d3e@eik.bme.hu> References: <20210101231215.1870611-1-f4bug@amsat.org> <20210101231215.1870611-4-f4bug@amsat.org> <2da14074-a4ef-e90c-ea42-74d48ca06afd@amsat.org> <293aa484-89c8-acc2-b9a3-37f17a506a2d@eik.bme.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: pass client-ip=152.66.115.2; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aleksandar Rikalo , Qemu-block , Huacai Chen , Mark Cave-Ayland , =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , Wainer dos Santos Moschetta , QEMU Developers , Artyom Tarasenko , Cleber Rosa , John Snow , Aurelien Jarno Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Reply-to: BALATON Zoltan From: BALATON Zoltan via On Sat, 2 Jan 2021, Peter Maydell wrote: > On Sat, 2 Jan 2021 at 11:22, BALATON Zoltan wrote: >> I have similar code in the series I've just posted where I'm mapping >> regions of serial devices. I did consider using set_enabled and >> set_address but ended up with removing and adding regions because I'm not >> sure what happens if guest tries to move one region over another like >> having one region at a default location while guest tries to map the other >> one there (the pegasos2 maps serial at 0x2f8 which is normally COM2 on a >> PC). This should not happen in theory but when removing disabled regions >> it cannot happen so that looks safer therefore I chose to do that. Not >> sure if this could be a problem here just shared my thughts about this. > > I'm not sure what you have in mind -- could you explain further? > There should be no difference as far as the MemoryRegion handling > code is concerned between "this memory region is marked disabled" and > "the memory region was deleted and will be created from fresh and added > back later" -- an MR that's in the hierarchy but not enabled is > entirely ignored, as if it wasn't there at all, when creating the > flat-view. The device I was implementing has two registers one to set base address of io region and another with bits to enable/disable the regions so I could do set_address for base regs and set_enabled for control reg bits but I've seen guests first flipping the enable bits on then setting the base address so I thought it might cause problems with regions added to their parent but thinking about it more it's probably the same if we remove regions and add them instead of just set_enabled because they should be readded when control reg bits are set so they'll end up at the same default address. > That said, doing memory_region_del_subregion()/memory_region_add_subregion() > I think is also OK -- what's definitely not required is actually > deleting and recreating the MRs the way this code is doing. Anyway that's what I ended up doing and did not notice that this patch was also deleting and recreating the memory regions which I did not do just removing from parent when they are disabled but using set_address if they are enabled and new base is set. Removing inactive regions maybe better for debugging because they show up in info mtree so one can see which one is enabled/disabled not sure how disabled regions show up though. All in all I probably have nothing to add to this so just disregard my comment. Regards, BALATON Zoltan