qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Venture <venture@google.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Jason Wang <jasowang@redhat.com>,
	Havard Skinnemoen <hskinnemoen@google.com>,
	 CS20 KFTing <kfting@nuvoton.com>, qemu-arm <qemu-arm@nongnu.org>,
	 qemu-devel <qemu-devel@nongnu.org>, Hao Wu <wuhaotsh@google.com>
Subject: Re: [PATCH] hw/net: npcm7xx_emc: set MAC in register space
Date: Thu, 29 Sep 2022 08:28:23 -0700	[thread overview]
Message-ID: <CAO=notzN3E_OA-_jBvXsB8_LGbTXpE=G50RX8APbHHFN6eHE3A@mail.gmail.com> (raw)
In-Reply-To: <CAO=notwsgvtZBLyWGu+PSnmHTrm6anakwFwoq3oBEJ-8nqPFaQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

On Mon, Sep 26, 2022 at 8:45 AM Patrick Venture <venture@google.com> wrote:

>
>
> On Sat, Sep 24, 2022 at 2:10 AM Peter Maydell <peter.maydell@linaro.org>
> wrote:
>
>> On Sat, 24 Sept 2022 at 00:42, Patrick Venture <venture@google.com>
>> wrote:
>> > On Thu, Sep 22, 2022 at 8:21 PM Jason Wang <jasowang@redhat.com> wrote:
>> >>
>> >> On Thu, Sep 22, 2022 at 8:35 PM Peter Maydell <
>> peter.maydell@linaro.org> wrote:
>> >> > A question to which I don't know the answer: if the guest writes to
>> >> > the device to change the MAC address, should that persist across
>> >> > reset, or should reset revert the device to the original MAC address
>> >> > as specified by the user on the command line or whatever ? At the
>> >> > moment you have the former behaviour (and end up storing the MAC
>> >> > address in two places as a result -- it would be neater to either
>> >> > keep it in only one place, or else have emc->regs[] be the current
>> >> > programmed MAC address and emc->conf.macaddr the value to reset to).
>> >> >
>> >> > I'm not sure we're consistent between device models about that,
>> >> > eg the e1000 seems to reset to the initial MAC addr, but the
>> >> > imx_fec keeps the guest-set value over resets. Jason, is there
>> >> > a recommended "right way" to handle guest-programmable MAC addresses
>> >> > over device reset ?
>> >>
>> >> I think it depends on the NIC.
>> >>
>> >> E1000 has a EEPROM interface for providing the MAC address for the
>> >> ethernet controller before it can be accessed by the driver during
>> >> reset. For modern Intel NICs like E810, it has similar semantics but
>> >> using NVM instead of EEPROM. So the current e1000 behaviour seems to
>> >> be correct (treat the initiali MAC as the one stored in the EEPROM).
>> >>
>> >> I guess most NIC should behave the same as having a persistent storage
>> >> for MAC for the controller during reset, but I'm not sure this is the
>> >> case for imx_fec.
>>
>> > So the first time the NIC is realized, it should take the value from
>> > the command line.  Then later if the guest OS updates it, it should
>> > always on reset use that provided value?
>>
>> 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."

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?


>
>>
>> thanks
>> -- PMM
>>
>

[-- Attachment #2: Type: text/html, Size: 4488 bytes --]

  reply	other threads:[~2022-09-29 16:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 23:46 [PATCH] hw/net: npcm7xx_emc: set MAC in register space Patrick Venture
2022-09-22 12:35 ` Peter Maydell
2022-09-23  3:21   ` Jason Wang
2022-09-23 23:42     ` Patrick Venture
2022-09-24  9:10       ` Peter Maydell
2022-09-26 15:45         ` Patrick Venture
2022-09-29 15:28           ` Patrick Venture [this message]
2022-09-29 15:54             ` Peter Maydell
2022-09-30  2:05               ` Patrick Venture

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO=notzN3E_OA-_jBvXsB8_LGbTXpE=G50RX8APbHHFN6eHE3A@mail.gmail.com' \
    --to=venture@google.com \
    --cc=hskinnemoen@google.com \
    --cc=jasowang@redhat.com \
    --cc=kfting@nuvoton.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wuhaotsh@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).