From: Jason Wang <jasowang@redhat.com>
To: Leonid Bloch <leonid.bloch@ravellosystems.com>
Cc: Dmitry Fleytman <dmitry@daynix.com>,
Leonid Bloch <leonid@daynix.com>,
qemu-devel@nongnu.org,
Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Subject: Re: [Qemu-devel] [PATCH 2/6] e1000: Trivial implementation of various MAC registers
Date: Thu, 22 Oct 2015 15:19:45 +0800 [thread overview]
Message-ID: <56288E11.6020102@redhat.com> (raw)
In-Reply-To: <CAOuJ279mueZKLLqMsoZjB9E8Tg2xv3cXaaOT8nVVCGpKwGyDkA@mail.gmail.com>
On 10/21/2015 05:13 PM, Leonid Bloch wrote:
> Hi Jason, thanks for the review!
>
> On Tue, Oct 20, 2015 at 8:40 AM, Jason Wang <jasowang@redhat.com> wrote:
>>
>>
>> On 10/18/2015 03:53 PM, Leonid Bloch wrote:
>>> These registers appear in Intel's specs, but were not implemented.
>>> These registers are now implemented trivially, i.e. they are initiated
>>> with zero values, and if they are RW, they can be written or read by the
>>> driver, or read only if they are R (essentially retaining their zero
>>> values). For these registers no other procedures are performed.
>>>
>>> The registers implemented here are:
>>>
>>> Transmit:
>>> RW: AIT
>>>
>>> Management:
>>> RW: WUC WUS IPAV* IP6AT* IP4AT* FFLT* WUPM* FFMT* FFVT*
>> My version of DSM (Revision) said WUS is read only.
> This seems to be a typo in the specs. We also have the specs where it
> is said that WUS's read only, but exactly two lines below it - writing
> to it is mentioned. Additionally, in the specs for newer Intel's
> devices, where the offset and the functionality of WUS are exactly the
> same, it is written that WUS is RW.
Ok.
>>> Diagnostic:
>>> RW: RDFH RDFT RDFHS RDFTS RDFPC PBM*
>> For those diagnostic register, isn't it better to warn the incomplete
>> emulation instead of trying to give all zero values silently? I suspect
>> this can make diagnostic software think the device is malfunction?
> That's a good point. What do you think about keeping the zero values,
> but printing out a warning (via DBGOUT) on each read/write attempt?
This is fine for me.
>>> Statistic:
>>> RW: FCRUC TDFH TDFT TDFHS TDFTS TDFPC
>> TDFH TDFT TDFHS TDFTS TDFPC should be Diagnostic?
> Yes, they are. Thanks, I'll reword.
>>> R: RNBC TSCTFC MGTPRC MGTPDC MGTPTC RFC RJC SCC ECOL
>>> LATECOL MCC COLC DC TNCRS SEC CEXTERR RLEC XONRXC
>>> XONTXC XOFFRXC XOFFTXC
>>>
>>> Signed-off-by: Leonid Bloch <leonid.bloch@ravellosystems.com>
>>> Signed-off-by: Dmitry Fleytman <dmitry.fleytman@ravellosystems.com>
>>> ---
>>> hw/net/e1000.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++++---
>>> hw/net/e1000_regs.h | 6 ++++++
>>> 2 files changed, 55 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>> index 6d57663..6f754ac 100644
>>> --- a/hw/net/e1000.c
>>> +++ b/hw/net/e1000.c
>>> @@ -168,7 +168,17 @@ enum {
>>> defreg(TPR), defreg(TPT), defreg(TXDCTL), defreg(WUFC),
>>> defreg(RA), defreg(MTA), defreg(CRCERRS), defreg(VFTA),
>>> defreg(VET), defreg(RDTR), defreg(RADV), defreg(TADV),
>>> - defreg(ITR),
>>> + defreg(ITR), defreg(FCRUC), defreg(TDFH), defreg(TDFT),
>>> + defreg(TDFHS), defreg(TDFTS), defreg(TDFPC), defreg(RDFH),
>>> + defreg(RDFT), defreg(RDFHS), defreg(RDFTS), defreg(RDFPC),
>>> + defreg(IPAV), defreg(WUC), defreg(WUS), defreg(AIT),
>>> + defreg(IP6AT), defreg(IP4AT), defreg(FFLT), defreg(FFMT),
>>> + defreg(FFVT), defreg(WUPM), defreg(PBM), defreg(SCC),
>>> + defreg(ECOL), defreg(MCC), defreg(LATECOL), defreg(COLC),
>>> + defreg(DC), defreg(TNCRS), defreg(SEC), defreg(CEXTERR),
>>> + defreg(RLEC), defreg(XONRXC), defreg(XONTXC), defreg(XOFFRXC),
>>> + defreg(XOFFTXC), defreg(RFC), defreg(RJC), defreg(RNBC),
>>> + defreg(TSCTFC), defreg(MGTPRC), defreg(MGTPDC), defreg(MGTPTC)
>>> };
>>>
>>> static void
>>> @@ -1114,6 +1124,18 @@ mac_readreg(E1000State *s, int index)
>>> }
>>>
>>> static uint32_t
>>> +mac_low11_read(E1000State *s, int index)
>>> +{
>>> + return s->mac_reg[index] & 0x7ff;
>>> +}
>>> +
>>> +static uint32_t
>>> +mac_low13_read(E1000State *s, int index)
>>> +{
>>> + return s->mac_reg[index] & 0x1fff;
>>> +}
>>> +
>>> +static uint32_t
>>> mac_icr_read(E1000State *s, int index)
>>> {
>>> uint32_t ret = s->mac_reg[ICR];
>>> @@ -1215,16 +1237,31 @@ static uint32_t (*macreg_readops[])(E1000State *, int) = {
>>> getreg(RDH), getreg(RDT), getreg(VET), getreg(ICS),
>>> getreg(TDBAL), getreg(TDBAH), getreg(RDBAH), getreg(RDBAL),
>>> getreg(TDLEN), getreg(RDLEN), getreg(RDTR), getreg(RADV),
>>> - getreg(TADV), getreg(ITR),
>>> + getreg(TADV), getreg(ITR), getreg(FCRUC), getreg(IPAV),
>>> + getreg(WUC), getreg(WUS), getreg(AIT), getreg(SCC),
>> For AIT should we use low16_read() ?
> Contrary to registers where lowXX_read() is used, for AIT the specs
> say that the higher bits should be written with 0b, and not "read as
> 0b". That's my reasoning for that. What do you think?
I think it's better to test this behavior on real card.
>> And low4_read() for FFMT?
> Why? The specs say nothing about the reserved bits there...
If I read the spec (Revision 3.7 13.6.10) correctly, only low 4 bits
were used for byte mask.
[...]
next prev parent reply other threads:[~2015-10-22 7:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-18 7:53 [Qemu-devel] [PATCH 0/6] e1000: Various fixes and registers' implementation Leonid Bloch
2015-10-18 7:53 ` [Qemu-devel] [PATCH 1/6] e1000: Cosmetic and alignment fixes Leonid Bloch
2015-10-18 7:53 ` [Qemu-devel] [PATCH 2/6] e1000: Trivial implementation of various MAC registers Leonid Bloch
2015-10-20 5:40 ` Jason Wang
2015-10-21 9:13 ` Leonid Bloch
2015-10-22 7:19 ` Jason Wang [this message]
2015-10-22 14:05 ` Leonid Bloch
2015-10-23 3:10 ` Jason Wang
2015-10-25 19:39 ` Leonid Bloch
2015-10-18 7:53 ` [Qemu-devel] [PATCH 3/6] e1000: Fixing the received/transmitted packets' counters Leonid Bloch
2015-10-18 7:53 ` [Qemu-devel] [PATCH 4/6] e1000: Fixing the received/transmitted octets' counters Leonid Bloch
2015-10-20 6:16 ` Jason Wang
2015-10-21 12:20 ` Leonid Bloch
2015-10-22 7:20 ` Jason Wang
2015-10-18 7:53 ` [Qemu-devel] [PATCH 5/6] e1000: Fixing the packet address filtering procedure Leonid Bloch
2015-10-18 7:53 ` [Qemu-devel] [PATCH 6/6] e1000: Implementing various counters Leonid Bloch
2015-10-20 6:34 ` Jason Wang
2015-10-21 9:20 ` Leonid Bloch
2015-10-20 6:37 ` [Qemu-devel] [PATCH 0/6] e1000: Various fixes and registers' implementation Jason Wang
2015-10-21 13:32 ` Leonid Bloch
2015-10-22 7:22 ` Jason Wang
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=56288E11.6020102@redhat.com \
--to=jasowang@redhat.com \
--cc=dmitry@daynix.com \
--cc=leonid.bloch@ravellosystems.com \
--cc=leonid@daynix.com \
--cc=qemu-devel@nongnu.org \
--cc=shmulik.ladkani@ravellosystems.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).