qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> > 
> 
> 

  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).