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

[...]

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