Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

[Aleksandar Markovic <aleksandar.m.mail@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4003 bytes --]

2:54 AM Sre, 19.02.2020. Aleksandar Markovic <aleksandar.m.mail@gmail.com>
је написао/ла:
>
> 2:06 AM Sre, 19.02.2020. Finn Thain <fthain@telegraphics.com.au> је
написао/ла:
> >
> > On Tue, 18 Feb 2020, Aleksandar Markovic wrote:
> >
> > > On Wednesday, January 29, 2020, Finn Thain <fthain@telegraphics.com.au
>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > There are bugs in the emulated dp8393x device that can stop packet
> > > > reception in a Linux/m68k guest (q800 machine).
> > > >
> > > > With a Linux/m68k v5.5 guest (q800), it's possible to remotely
trigger
> > > > an Oops by sending ping floods.
> > > >
> > > > With a Linux/mips guest (magnum machine), the driver fails to probe
> > > > the dp8393x device.
> > > >
> > > > With a NetBSD/arc 5.1 guest (magnum), the bugs in the device can be
> > > > fatal to the guest kernel.
> > > >
> > > > Whilst debugging the device, I found that the receiver algorithm
> > > > differs from the one described in the National Semiconductor
> > > > datasheet.
> > > >
> > > > This patch series resolves these bugs.
> > > >
> > > > AFAIK, all bugs in the Linux sonic driver were fixed in Linux v5.5.
> > > > ---
> > >
> > >
> > > Herve,
> > >
> > > Do your Jazz tests pass with these changes?
> > >
> >
> > AFAIK those tests did not expose the NetBSD panic that is caused by
> > mainline QEMU (mentioned above).
> >
> > I have actually run the tests you requested (Hervé described them in an
> > earlier thread). There was no regression. Quite the reverse -- it's no
> > longer possible to remotely crash the NetBSD kernel.
> >
> > Apparently my testing was also the first time that the jazzsonic driver
> > (from the Linux/mips Magnum port) was tested successfully with QEMU. It
> > doesn't work in mainline QEMU.
> >
>
> Well, I appologize if I missed all these facts. I just did not notice
them, at least not in this form. And, yes, some "Tested-by:" by Herve would
be desirable and nice.
>

Or, perhaps, even "Reviewed-by:".

> Yours,
> Aleksandae
>
> > Anyway, more testing is always nice, and I'd certainly welcome an
> > 'acked-by' or 'tested-by' if Hervé would like to send one.
> >
> > Please consider backporting this series of bug fixes to QEMU stable
> > branch(es).
> >
> > Regards,
> > Finn
> >
> > > Regards,
> > > Aleksandar
> > >
> > >
> > >
> > > > Changed since v1:
> > > >  - Minor revisions as described beneath commit logs.
> > > >  - Dropped patches 4/10 and 7/10.
> > > >  - Added 5 new patches.
> > > >
> > > > Changed since v2:
> > > >  - Minor revisions as described beneath commit logs.
> > > >  - Dropped patch 13/13.
> > > >  - Added 2 new patches.
> > > >
> > > > Changed since v3:
> > > >  - Replaced patch 13/14 with patch suggested by Philippe
Mathieu-Daudé.
> > > >
> > > >
> > > > Finn Thain (14):
> > > >   dp8393x: Mask EOL bit from descriptor addresses
> > > >   dp8393x: Always use 32-bit accesses
> > > >   dp8393x: Clean up endianness hacks
> > > >   dp8393x: Have dp8393x_receive() return the packet size
> > > >   dp8393x: Update LLFA and CRDA registers from rx descriptor
> > > >   dp8393x: Clear RRRA command register bit only when appropriate
> > > >   dp8393x: Implement packet size limit and RBAE interrupt
> > > >   dp8393x: Don't clobber packet checksum
> > > >   dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
> > > >   dp8393x: Pad frames to word or long word boundary
> > > >   dp8393x: Clear descriptor in_use field to release packet
> > > >   dp8393x: Always update RRA pointers and sequence numbers
> > > >   dp8393x: Don't reset Silicon Revision register
> > > >   dp8393x: Don't stop reception upon RBE interrupt assertion
> > > >
> > > >  hw/net/dp8393x.c | 202
+++++++++++++++++++++++++++++++----------------
> > > >  1 file changed, 134 insertions(+), 68 deletions(-)
> > > >
> > > > --
> > > > 2.24.1
> > > >
> > > >
> > > >
> > >

[-- Attachment #2: Type: text/html, Size: 5786 bytes --]