From: Vlad Yasevich <vyasevic@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: jasowang@redhat.com, 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: Wed, 13 Nov 2013 11:21:18 -0500 [thread overview]
Message-ID: <5283A6FE.60205@redhat.com> (raw)
In-Reply-To: <20131110121151.GA5908@redhat.com>
On 11/10/2013 07:11 AM, Michael S. Tsirkin wrote:
> On Fri, Nov 08, 2013 at 02:42:27PM -0500, Vlad Yasevich wrote:
>> What about this approach? This only updates the monitory when all the
>> bits have been written to.
>>
>> -vlad
>
>
> Thanks!
> Some comments below.
>
>> -- >8 --
>> Subject: [PATCH] e1000/rtl8139: update HMP NIC when every bit is written
>>
>> 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.
>
> I would rather say "it seems better not to make this assumption".
> This does look somewhat safer than what Amos proposed.
>
>>
>> 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 has been changed. It will be same as virtio-net.
>>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>> ---
>> hw/net/e1000.c | 17 ++++++++++++++++-
>> hw/net/rtl8139.c | 14 +++++++++-----
>> 2 files changed, 25 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>> index 8387443..a5967ed 100644
>> --- a/hw/net/e1000.c
>> +++ b/hw/net/e1000.c
>> @@ -149,6 +149,10 @@ typedef struct E1000State_st {
>> #define E1000_FLAG_AUTONEG (1 << E1000_FLAG_AUTONEG_BIT)
>> #define E1000_FLAG_MIT (1 << E1000_FLAG_MIT_BIT)
>> uint32_t compat_flags;
>> + uint32_t mac_changed;
>
> Hmm why uint32_t? uint8_t is enough here isn't?
>
> This new state has to be migrated then, and
> we need to fallback to old behaviour if migrating to/from
> an old version (see compat_flags for one way to
> detect this compatibility mode).
>
Hi Michael
I started looking at migrating this thing and I now starting to question
the whole approach.
The only reason to migrate this is if we can migrate between writes to
the mac address registers. We can fairly easily solve the issue of
migrating from net to old versions. The more interesting question
is migrating from old to new versions.
If someone is migrating from an older version (without this feature)
to a newer version and doing so between writes, the bitmap state will
have no idea that a partial write has already happened. The completing
write will just set one of the bits and notifications that we are
looking for do not happen.
-vlad
next prev parent reply other threads:[~2013-11-13 16:21 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
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 [this message]
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=5283A6FE.60205@redhat.com \
--to=vyasevic@redhat.com \
--cc=akong@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@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).