From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: jasowang@redhat.com, Amos Kong <akong@redhat.com>,
qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH] e1000/rtl8139: update HMP NIC when every bit is written
Date: Thu, 7 Nov 2013 17:27:28 +0200 [thread overview]
Message-ID: <20131107152728.GA3739@redhat.com> (raw)
In-Reply-To: <1383834837.21055.240.camel@ul30vt.home>
On Thu, Nov 07, 2013 at 07:33:57AM -0700, Alex Williamson wrote:
> On Thu, 2013-11-07 at 12:26 +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2013 at 03:32:29PM +0800, Amos Kong wrote:
> > > On Thu, Nov 07, 2013 at 08:59:22AM +0200, Michael S. Tsirkin wrote:
> > > > On Tue, Nov 05, 2013 at 07:17:18PM +0800, Amos Kong wrote:
> > > > > We currently just update the HMP NIC info when the last bit of macaddr
> > > > > is written. This assumes that guest driver will write all the macaddr
> > > > > from bit 0 to bit 5 when it changes the macaddr, this is the current
> > > > > behavior of linux driver (e1000/rtl8139cp), but we can't do this
> > > > > assumption.
> > > > >
> > > > > The macaddr that is used for rx-filter will be updated when every bit
> > > > > is changed. This patch updates the e1000/rtl8139 nic to update HMP NIC
> > > > > info when every bit is changed. It will be same as virtio-net.
> > > > >
> > > > > Signed-off-by: Amos Kong <akong@redhat.com>
> > > >
> > > > I'm not sure I buy this.
> > > >
> > > > If we actually implement e.g. mac change notifications,
> > > > sending them on writes of random bytes will confuse
> > > > the host.
> > >
> > > This patch just effects the monitor display of macaddr.
> > > During each writing, the macaddr is used for rx-filter is really
> > > changed.
> > >
> > > In the real hardware, it supports to just write part of bits,
> > > the rx-filtering is effected by every bit writing.
> >
> > Yes but again, the window can just be too small to matter
> > on real hardware.
> >
> > Our emulation is not perfect, fixing this to be just like real
> > hardware just might expose other bugs we can't fix
> > that easily.
>
> If we were to implement mac change notification, then every partial
> update would send a notify and the host. Is that a problem? It seems
> no different than if the device had an atomic mac update procedure and
> the guest admin changed the mac several times.
I think modern nics make address updates atomic.
Problem is, we are emulating an ancient one,
so to make host configuration of a modern one
reasonable we need to resort to tricks.
> The problem with assuming that a given byte is always written last is
> that unless the hardware spec identifies an order, we're just basing our
> code on examples where we know what the guest driver does, either by
> code inspection or access tracing. If there are examples of guests that
> write the last byte first, then the host will never know the correct mac
> address. Maybe there are no guests that use the wrong order, but that's
> a pretty exhaustive search.
I agree what we have is a hack. Maybe we need some better hacks.
For example, maybe we should update mac at link state change
(I think link is always down when mac is updated?).
Needs some thought.
> The patch doesn't change anything about how the NIC operates, only when
> mac changes are updated. During an update the mac is in a transitory
> state and we can't go back in time to make it atomic on this hardware
> design to avoid a window where the wrong mac may be seen. I think the
> patch is the right thing to do. Thanks,
>
> Alex
Yes but this info is propaged to host NIC by libvirt so it better
make sense.
> > > > I would say let's leave e1000/rtl8139 well alone unless
> > > > we see guests that actually write mac without touching
> > > > the last byte.
> > >
> > > At least, linux rtl8139cp/e1000 writes macaddr from bit 0 to bit 5.
> > > It works to just watch the last bit.
> > >
> > > Thanks, Amos
> > >
> > > > Then think of ways to detect when mac change is done
> > > > for these.
> > > >
> > > > > ---
> > > > > hw/net/e1000.c | 2 +-
> > > > > hw/net/rtl8139.c | 5 +----
> > > > > 2 files changed, 2 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> > > > > index ec8ecd7..2d60639 100644
> > > > > --- a/hw/net/e1000.c
> > > > > +++ b/hw/net/e1000.c
> > > > > @@ -1110,7 +1110,7 @@ mac_writereg(E1000State *s, int index, uint32_t val)
> > > > >
> > > > > s->mac_reg[index] = val;
> > > > >
> > > > > - if (index == RA + 1) {
> > > > > + if (index == RA || index == RA + 1) {
> > > > > macaddr[0] = cpu_to_le32(s->mac_reg[RA]);
> > > > > macaddr[1] = cpu_to_le32(s->mac_reg[RA + 1]);
> > > > > qemu_format_nic_info_str(qemu_get_queue(s->nic), (uint8_t *)macaddr);
> > > > > diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
> > > > > index 5329f44..7f2b4db 100644
> > > > > --- a/hw/net/rtl8139.c
> > > > > +++ b/hw/net/rtl8139.c
> > > > > @@ -2741,10 +2741,7 @@ static void rtl8139_io_writeb(void *opaque, uint8_t addr, uint32_t val)
> > > > >
> > > > > switch (addr)
> > > > > {
> > > > > - case MAC0 ... MAC0+4:
> > > > > - s->phys[addr - MAC0] = val;
> > > > > - break;
> > > > > - case MAC0+5:
> > > > > + case MAC0 ... MAC0+5:
> > > > > s->phys[addr - MAC0] = val;
> > > > > qemu_format_nic_info_str(qemu_get_queue(s->nic), s->phys);
> > > > > break;
> > > > > --
> > > > > 1.8.3.1
> >
>
>
next prev parent reply other threads:[~2013-11-07 15:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 11:17 [Qemu-devel] [PATCH] e1000/rtl8139: update HMP NIC when every bit is written Amos Kong
2013-11-07 2:59 ` Alex Williamson
2013-11-07 6:59 ` Michael S. Tsirkin
2013-11-07 7:32 ` Amos Kong
2013-11-07 10:26 ` Michael S. Tsirkin
2013-11-07 14:33 ` Alex Williamson
2013-11-07 15:27 ` Michael S. Tsirkin [this message]
2013-11-07 15:43 ` Vlad Yasevich
2013-11-07 15:49 ` Vlad Yasevich
2013-11-08 19:42 ` Vlad Yasevich
2013-11-09 3:43 ` Amos Kong
2013-11-12 19:57 ` Vlad Yasevich
2013-11-10 12:11 ` Michael S. Tsirkin
2013-11-12 15:49 ` Vlad Yasevich
2013-11-13 16:21 ` Vlad Yasevich
2013-11-13 20:00 ` Michael S. Tsirkin
2013-11-13 20:26 ` Vlad Yasevich
2013-11-13 21:55 ` Michael S. Tsirkin
2013-11-18 15:02 ` Michael S. Tsirkin
2013-11-18 17:33 ` Vlad Yasevich
2013-11-18 19:42 ` Michael S. Tsirkin
2013-11-18 19:42 ` Vlad Yasevich
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=20131107152728.GA3739@redhat.com \
--to=mst@redhat.com \
--cc=akong@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).