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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 1AC1EC433FE for ; Thu, 29 Sep 2022 16:41:35 +0000 (UTC) Received: from localhost ([::1]:59484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odwbO-0005Fq-1Q for qemu-devel@archiver.kernel.org; Thu, 29 Sep 2022 12:41:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odvsR-0004eU-3b for qemu-devel@nongnu.org; Thu, 29 Sep 2022 11:55:08 -0400 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:34324) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odvsP-0004Ao-4L for qemu-devel@nongnu.org; Thu, 29 Sep 2022 11:55:06 -0400 Received: by mail-ej1-x62f.google.com with SMTP id rk17so3730626ejb.1 for ; Thu, 29 Sep 2022 08:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=1ZX8EvEFOBPZ8Nn8dtI/ON1GrCSiq6zEKTfRiGuMpPQ=; b=oBLteebaGEh642DLK7mUSkKnfO4NSEIIDfTt2QkNAKzPfywTphEVxxMeEflXOQNUpj +O36JpLejvTsEZeesVkyipAT4677EXMf8qTf/+dUtQ0XGYtmUA3vtTMOA0HvFBo4q5W+ pTIp0cTFfdQ6LhxxHkV0lmv/3z2vFekY97ZsT2QcdbIdhvgXZTrr4BYs2aWCq2sljxwu Ig7j3xKvUY+qkUyS2GET9f0mo/gmJiPv9N7HgBg28XmhAoo6gzvd1HuFsOVH9doAURZA mTDsgpWEwrDnPyzgmumE7G0PG3QHJKTCF36gurPl0oMD4v8DTLO3cUiV5hgmsS9Px0fA yO6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=1ZX8EvEFOBPZ8Nn8dtI/ON1GrCSiq6zEKTfRiGuMpPQ=; b=Ijlf9ydz5661O4jPRvFckYBhi6zoOZ6YY6pGtbHmvLTp3b/OMD52xHNoz05zf7VQc1 WuA4QgUWzpG03DlVbkCLkqYizCEMit+Njhtb3Aaze0SBpaDkJSojK5QnI2t0d/RnYKj/ n/Prbcavxfz9/ppTGwCbWZqsCrybkNR3zQiKuRxcu/MX8EEizI6iiKzowr4lcEC+RHc4 mGu6OFyrOtZYYcImdJvMLvhsIxV8EiuTtXmNvOyldkBxsX3VgAgkYqwRoHhZk+2nzGnN fFjgDNHxwhHERU0FmoqwF007HtRJwPiwr7yGRqVqCQtGJG0HwLiJpz5b1/7UYDy4Q5oz Qnvw== X-Gm-Message-State: ACrzQf0kb8GXLkqhzDk8ItUYBwi7J8GNDWZCDUKUXDf/fMyvGENc+Q7v Ij2GubCxZ4k9zz7vOa3Mvxvq/yimKgh1EDO8nc9OFg== X-Google-Smtp-Source: AMsMyM7ic5DaDUPWaf4EXJwCV2DItK005Y7orlO2jy5AF11ZSf+99o9E/fbaJhNHtBNBmucY80z/tm1CGGtk+EPHto4= X-Received: by 2002:a17:907:728e:b0:782:8e91:64c8 with SMTP id dt14-20020a170907728e00b007828e9164c8mr3420250ejc.36.1664466895915; Thu, 29 Sep 2022 08:54:55 -0700 (PDT) MIME-Version: 1.0 References: <20220921234646.949273-1-venture@google.com> In-Reply-To: From: Peter Maydell Date: Thu, 29 Sep 2022 16:54:44 +0100 Message-ID: Subject: Re: [PATCH] hw/net: npcm7xx_emc: set MAC in register space To: Patrick Venture Cc: Jason Wang , Havard Skinnemoen , CS20 KFTing , qemu-arm , qemu-devel , Hao Wu Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=peter.maydell@linaro.org; helo=mail-ej1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 29 Sept 2022 at 16:28, Patrick Venture wrote: > On Mon, Sep 26, 2022 at 8:45 AM Patrick Venture wrote: >>> I think what Jason is suggesting is that that should depend on what >>> the real hardware does. On a physical board, if the guest sets the >>> MAC address, and then you power-cycle the hardware, does the MAC >>> that it set still persist after powercycle ? Does the guest writing >>> to these MAC registers correspond to writing to an EEPROM ? >> >> >> Thanks, Peter - we've reached out to the vendor off-list to seek out some details, I'll update this with a v2 when I get an answer. > "No, The EMC driver reset the MAC address registers during boot cycle/reset." OK, I guess that's clear enough. In a real full-software-stack setup is the MAC address setup usually done by a BIOS/firmware, or is it done by Linux ? > So in that case, we should disregard the value the user sets in > reset and use the value provided through Qemu. Or, should we just > not allow Qemu to set the MAC address at all? I think that the behaviour for QEMU's model should be that on reset we should reset the MAC address registers to the user-provided value. That is, if the guest writes to the MAC address registers then that does have an effect, but only until the next reset. That gives you reasonably plausible behaviour for both: (1) you're emulating some guest that always sets up its own MAC address when it starts up (eg if it's done by some BIOS-level code that you're running in the guest) (2) you're booting a guest kernel directly that expects that the firmware/BIOS/whatever has already set up a MAC address -- then the MAC address provided by QEMU/the user fills that role More concretely: * on reset, set the emc->regs[] fields from emc->conf.macaddr * when using the MAC address, always use emc->regs[], never emc->conf.macaddr * to handle the guest writes to the MAC registers, set emc->regs[], but not emc->conf.macaddr Assuming that doesn't break your existing booting workloads, of course :-) thanks -- PMM