[Qemu-devel] [PATCH V2 0/2] net: Fix lan9118 multi-buffer transmit

[Qemu-devel] [PATCH V2 0/2] net: Fix lan9118 multi-buffer transmit

[Roy Franz]

This patchset fixes some bugs in the lan9118 emulation that were found
while debugging UEFI network support on the emulated VExpress platform.

The 9118 ethernet controller supports transmission of multi-buffer packets 
with arbitrary byte alignment of the start and end bytes of each buffer.  
All writes to the packet fifo are 32 bits, so the controller discards 
bytes at the beginning and end of each buffer based on the 'Data start 
offset' and 'Buffer size' of the TX command 'A' word.  

The UEFI network driver uses 1 buffer for the packet header, and one for 
the payload.  The mishandling of the start offset and buffer length 
resulted in extra bytes being inserted in the packet.  

With these changes the UEFI network driver that works with the real 9118 
chip on the VExpress evaluation board works unmodified on QEMU.  The Linux 
kernel driver continues to work on QEMU as well.  Since the Linux driver 
was unaffected by these bugs I am inferring that it is using a single 
buffer for each packet.  

Changes since V1:
* use extract32() instead of shift/mask for CMD A field extraction
* compute number of valid bytes in word at beginning of block

Roy Franz (2):
  Fix lan9118 TX "CMD A" handling
  Fix lan9118 buffer length handling

 hw/net/lan9118.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.10.4

[Qemu-devel] [PATCH V2 1/2] Fix lan9118 TX "CMD A" handling

[Roy Franz]

The 9118 ethernet controller supports transmission of multi-buffer packets
with arbitrary byte alignment of the start and end bytes.  All writes to
the packet fifo are 32 bits, so the controller discards bytes at the beginning
and end of each buffer based on the 'Data start offset' and 'Buffer size'
of the TX command 'A' format.

This patch changes the buffer size and offset internal state variables to be
updated on every "TX command A" write.  Previously they were only updated for
the first segment, which resulted incorrect behavior for packets with more
than one segment. Each segment of the packet has its own CMD A command, with
its own buffer size and start offset.

Also update extraction of fields from the CMD A word to use extract32().

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
 hw/net/lan9118.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
index 2315f99..bb0c503 100644
--- a/hw/net/lan9118.c
+++ b/hw/net/lan9118.c
@@ -727,14 +727,14 @@ static void tx_fifo_push(lan9118_state *s, uint32_t val)
         s->txp->cmd_a = val & 0x831f37ff;
         s->txp->fifo_used++;
         s->txp->state = TX_B;
+        s->txp->buffer_size = extract32(s->txp->cmd_a, 0, 11);
+        s->txp->offset = extract32(s->txp->cmd_a, 16, 5);
         break;
     case TX_B:
         if (s->txp->cmd_a & 0x2000) {
             /* First segment */
             s->txp->cmd_b = val;
             s->txp->fifo_used++;
-            s->txp->buffer_size = s->txp->cmd_a & 0x7ff;
-            s->txp->offset = (s->txp->cmd_a >> 16) & 0x1f;
             /* End alignment does not include command words.  */
             n = (s->txp->buffer_size + s->txp->offset + 3) >> 2;
             switch ((n >> 24) & 3) {
-- 
1.7.10.4

[Qemu-devel] [PATCH V2 2/2] Fix lan9118 buffer length handling

[Roy Franz]

The 9118 ethernet controller supports transmission of multi-buffer packets
with arbitrary byte alignment of the start and end bytes.  All writes to
the packet fifo are 32 bits, so the controller discards bytes at the beginning
and end of each buffer based on the 'Data start offset' and 'Buffer size'
of the TX command 'A' format.

This patch uses the provided buffer length to limit the bytes transmitted.
Previously all the bytes of the last 32-bit word written to the TX fifo
were added to the internal transmit buffer structure resulting in more bytes
being transmitted than were submitted to the hardware in the command.  This
resulted in extra bytes being inserted into the middle of multi-buffer
packets when the non-final buffers had non-32bit aligned ending addresses.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
 hw/net/lan9118.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
index bb0c503..e528290 100644
--- a/hw/net/lan9118.c
+++ b/hw/net/lan9118.c
@@ -763,7 +763,7 @@ static void tx_fifo_push(lan9118_state *s, uint32_t val)
         if (s->txp->buffer_size <= 0 && s->txp->pad != 0) {
             s->txp->pad--;
         } else {
-            n = 4;
+            n = MIN(4, s->txp->buffer_size + s->txp->offset);
             while (s->txp->offset) {
                 val >>= 8;
                 n--;
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH V2 1/2] Fix lan9118 TX "CMD A" handling

[Peter Crosthwaite]

On Wed, Jan 8, 2014 at 2:19 PM, Roy Franz <roy.franz@linaro.org> wrote:
> The 9118 ethernet controller supports transmission of multi-buffer packets
> with arbitrary byte alignment of the start and end bytes.  All writes to
> the packet fifo are 32 bits, so the controller discards bytes at the beginning
> and end of each buffer based on the 'Data start offset' and 'Buffer size'
> of the TX command 'A' format.
>
> This patch changes the buffer size and offset internal state variables to be
> updated on every "TX command A" write.  Previously they were only updated for
> the first segment, which resulted incorrect behavior for packets with more
> than one segment. Each segment of the packet has its own CMD A command, with
> its own buffer size and start offset.
>
> Also update extraction of fields from the CMD A word to use extract32().
>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>

Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>

> ---
>  hw/net/lan9118.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
> index 2315f99..bb0c503 100644
> --- a/hw/net/lan9118.c
> +++ b/hw/net/lan9118.c
> @@ -727,14 +727,14 @@ static void tx_fifo_push(lan9118_state *s, uint32_t val)
>          s->txp->cmd_a = val & 0x831f37ff;
>          s->txp->fifo_used++;
>          s->txp->state = TX_B;
> +        s->txp->buffer_size = extract32(s->txp->cmd_a, 0, 11);
> +        s->txp->offset = extract32(s->txp->cmd_a, 16, 5);
>          break;
>      case TX_B:
>          if (s->txp->cmd_a & 0x2000) {
>              /* First segment */
>              s->txp->cmd_b = val;
>              s->txp->fifo_used++;
> -            s->txp->buffer_size = s->txp->cmd_a & 0x7ff;
> -            s->txp->offset = (s->txp->cmd_a >> 16) & 0x1f;
>              /* End alignment does not include command words.  */
>              n = (s->txp->buffer_size + s->txp->offset + 3) >> 2;
>              switch ((n >> 24) & 3) {
> --
> 1.7.10.4
>
>

Re: [Qemu-devel] [PATCH V2 2/2] Fix lan9118 buffer length handling

[Peter Crosthwaite]

On Wed, Jan 8, 2014 at 2:19 PM, Roy Franz <roy.franz@linaro.org> wrote:
> The 9118 ethernet controller supports transmission of multi-buffer packets
> with arbitrary byte alignment of the start and end bytes.  All writes to
> the packet fifo are 32 bits, so the controller discards bytes at the beginning
> and end of each buffer based on the 'Data start offset' and 'Buffer size'
> of the TX command 'A' format.
>
> This patch uses the provided buffer length to limit the bytes transmitted.
> Previously all the bytes of the last 32-bit word written to the TX fifo
> were added to the internal transmit buffer structure resulting in more bytes
> being transmitted than were submitted to the hardware in the command.  This
> resulted in extra bytes being inserted into the middle of multi-buffer
> packets when the non-final buffers had non-32bit aligned ending addresses.
>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>

Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>

> ---
>  hw/net/lan9118.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
> index bb0c503..e528290 100644
> --- a/hw/net/lan9118.c
> +++ b/hw/net/lan9118.c
> @@ -763,7 +763,7 @@ static void tx_fifo_push(lan9118_state *s, uint32_t val)
>          if (s->txp->buffer_size <= 0 && s->txp->pad != 0) {
>              s->txp->pad--;
>          } else {
> -            n = 4;
> +            n = MIN(4, s->txp->buffer_size + s->txp->offset);
>              while (s->txp->offset) {
>                  val >>= 8;
>                  n--;
> --
> 1.7.10.4
>
>

Re: [Qemu-devel] [PATCH V2 0/2] net: Fix lan9118 multi-buffer transmit

[Stefan Hajnoczi]

On Tue, Jan 07, 2014 at 08:19:50PM -0800, Roy Franz wrote:
> This patchset fixes some bugs in the lan9118 emulation that were found
> while debugging UEFI network support on the emulated VExpress platform.
> 
> The 9118 ethernet controller supports transmission of multi-buffer packets 
> with arbitrary byte alignment of the start and end bytes of each buffer.  
> All writes to the packet fifo are 32 bits, so the controller discards 
> bytes at the beginning and end of each buffer based on the 'Data start 
> offset' and 'Buffer size' of the TX command 'A' word.  
> 
> The UEFI network driver uses 1 buffer for the packet header, and one for 
> the payload.  The mishandling of the start offset and buffer length 
> resulted in extra bytes being inserted in the packet.  
> 
> With these changes the UEFI network driver that works with the real 9118 
> chip on the VExpress evaluation board works unmodified on QEMU.  The Linux 
> kernel driver continues to work on QEMU as well.  Since the Linux driver 
> was unaffected by these bugs I am inferring that it is using a single 
> buffer for each packet.  
> 
> Changes since V1:
> * use extract32() instead of shift/mask for CMD A field extraction
> * compute number of valid bytes in word at beginning of block
> 
> Roy Franz (2):
>   Fix lan9118 TX "CMD A" handling
>   Fix lan9118 buffer length handling
> 
>  hw/net/lan9118.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Thanks, applied to my net tree:
https://github.com/stefanha/qemu/commits/net

Stefan