[Qemu-devel] Re: eepro100.c

[Qemu-devel] Re: eepro100.c

[Stefan Weil]

Brandon Bennett schrieb:
> I noticed you started submitting patches to the main qemu branch to
> match what you have in your arm
ar7, not arm
> repository.   Are you going to submit a patch for working multicast on
> the eepro100 nics?   I have used qemu and your eepro100.c patch to
> emulate Juniper routers and multicast is required for low level
> routing protocols (OSPF, PIM, etc) and it would be extremely nice to
> have this without patching and compiling.
>
> If you are going to submit a patch do you know when it may be ready?
>
> Thanks,
>
> Brandon Bennett

Hi,

there are a lot of people waiting for this because they emulate
Juniper routers.

I already sent a patch (eepro100: Fix multicast support)
to the QEMU developer mailing list.

The patch is based on another patch (eepro100: Restructure code)
which I have already sent two times.

It seems to be extremely difficult to get these patches
integrated. Maybe your mail helps to speed up the process.
Therefore I send my reply to the list and to the responsible, too.

Regards,

Stefan Weil

[Qemu-devel] Re: eepro100.c

[Jan Kiszka]

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

Michal Filka wrote:
> Hi,
> 
> I have question on i82557b emulation in kvm.
> 
> I have run a proprietary operating system (Pharlap OS) in kvm. Part
> of the job has been porting driver for i8255x. During the job I
> discovered that kvm's emulation doesn't support a RNR interrupt (it
> is disabled in the code).
> 
> Why is it disabled? I'm running heavily loaded application and I have
> to poll descriptor list instead of waiting for RNR interrupt.

Best asked on qemu-devel, CC'ing the developer of this device model.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: eepro100.c

[Stefan Weil]

Jan Kiszka schrieb:
> Michal Filka wrote:
>> Hi,
>>
>> I have question on i82557b emulation in kvm.
>>
>> I have run a proprietary operating system (Pharlap OS) in kvm. Part
>> of the job has been porting driver for i8255x. During the job I
>> discovered that kvm's emulation doesn't support a RNR interrupt (it
>> is disabled in the code).
>>
>> Why is it disabled? I'm running heavily loaded application and I have
>> to poll descriptor list instead of waiting for RNR interrupt.
>
> Best asked on qemu-devel, CC'ing the developer of this device model.
>
> Jan
>

Hi,

up to now, nobody complained about the missing RNR interrupts.
Linux obviously works without them, so I had no reason to
implement them.

The disabled code parts (function eepro100_rnr_interrupt)
can be enabled, but you still need code which calls them
at the right places.

This should not be very difficult if there is some test case
which proves the working RNR interrupt.

Regards
Stefan

[Qemu-devel] Re: eepro100.c

[Stefan Weil]

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

Stefan Weil schrieb:
> Jan Kiszka schrieb:
>> Michal Filka wrote:
>>> Hi,
>>>
>>> I have question on i82557b emulation in kvm.
>>>
>>> I have run a proprietary operating system (Pharlap OS) in kvm. Part
>>> of the job has been porting driver for i8255x. During the job I
>>> discovered that kvm's emulation doesn't support a RNR interrupt (it
>>> is disabled in the code).
>>>
>>> Why is it disabled? I'm running heavily loaded application and I have
>>> to poll descriptor list instead of waiting for RNR interrupt.
>> Best asked on qemu-devel, CC'ing the developer of this device model.
>>
>> Jan
>>
>
> Hi,
>
> up to now, nobody complained about the missing RNR interrupts.
> Linux obviously works without them, so I had no reason to
> implement them.
>
> The disabled code parts (function eepro100_rnr_interrupt)
> can be enabled, but you still need code which calls them
> at the right places.
>
> This should not be very difficult if there is some test case
> which proves the working RNR interrupt.
>
> Regards
> Stefan
>

Hi Michal,

could you please try the appended patch and tell me whether it works?

Regards
Stefan



[-- Attachment #2: 0001-eepro100-Add-RNR-interrupt.patch --]
[-- Type: text/x-diff, Size: 2300 bytes --]

>From cb12daa2f7ecbf041655825054a1661668ab7274 Mon Sep 17 00:00:00 2001
From: Stefan Weil <weil@mail.berlios.de>
Date: Sat, 19 Sep 2009 19:05:07 +0200
Subject: [PATCH] eepro100: Add RNR interrupt

Set RNR (receive unit not ready) interrupt for RU abort command.

Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
 hw/eepro100.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/hw/eepro100.c b/hw/eepro100.c
index a8f6b3f..6d49bb8 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -114,7 +114,7 @@
 #define  RU_NOP         0x0000
 #define  RX_START       0x0001
 #define  RX_RESUME      0x0002
-#define  RX_ABORT       0x0004
+#define  RU_ABORT       0x0004
 #define  RX_ADDR_LOAD   0x0006
 #define  RX_RESUMENR    0x0007
 #define INT_MASK        0x0100
@@ -363,13 +363,11 @@ static void eepro100_fr_interrupt(EEPRO100State * s)
     eepro100_interrupt(s, 0x40);
 }
 
-#if 0
 static void eepro100_rnr_interrupt(EEPRO100State * s)
 {
     /* RU is not ready. */
     eepro100_interrupt(s, 0x10);
 }
-#endif
 
 static void eepro100_mdi_interrupt(EEPRO100State * s)
 {
@@ -865,6 +863,13 @@ static void eepro100_ru_command(EEPRO100State * s, uint8_t val)
         }
         set_ru_state(s, ru_ready);
         break;
+    case RU_ABORT:
+        /* RU abort. */
+        if (get_ru_state(s) == ru_ready) {
+            eepro100_rnr_interrupt(s);
+        }
+        set_ru_state(s, ru_idle);
+        break;
     case RX_ADDR_LOAD:
         /* Load RU base. */
         TRACE(OTHER, logout("val=0x%02x (RU base address)\n", val));
@@ -872,7 +877,7 @@ static void eepro100_ru_command(EEPRO100State * s, uint8_t val)
         break;
     default:
         logout("val=0x%02x (undefined RU command)\n", val);
-        missing("Undefined SU command");
+        missing("Undefined RU command");
     }
 }
 
@@ -1531,6 +1536,8 @@ static ssize_t nic_receive(VLANClientState *vc, const uint8_t * buf, size_t size
     if (get_ru_state(s) != ru_ready) {
         /* No resources available. */
         logout("no resources, state=%u\n", get_ru_state(s));
+        /* TODO: RNR interrupt only at first failed frame? */
+        eepro100_rnr_interrupt(s);
         s->statistics.rx_resource_errors++;
         //~ assert(!"no resources");
         return -1;
-- 
1.5.6.5

[Qemu-devel] RE: eepro100.c

[Michal Filka]

Hi
> >
> > up to now, nobody complained about the missing RNR interrupts.
> > Linux obviously works without them, so I had no reason to
> > implement them.
... I'm not complaining, I'm asking for help ;-) Virtualization is working - no problem. However, it turns emulated driver into suspended state under heavy load (8 cores, 16 GB RAM, gigabit Ethernet - all cpu's at 100% due to network traffic processing by application in virtualizations) - my driver doesn't get any FR interrupts, when I issue a "ru resume" command (a timer) rx works again. 
> >
> > The disabled code parts (function eepro100_rnr_interrupt)
> > can be enabled, but you still need code which calls them
> > at the right places.
... sure
> >
> could you please try the appended patch and tell me whether it works?
... thank you. I'm going to try it today. I'll give you know then.
> 
Michal Filka

[Qemu-devel] RE: eepro100.c

[Michal Filka]

Hi,

I'm unable to build kvm from source on machine, where I run kvm virtualization.

I've applied your patch to kvm-88 source.

./configure
Error: libpci check failed
Disable KVM Device Assignment capability.

rm: cannot remove `include/asm': Is a directory
rm: cannot remove `include-compat/asm': Is a directory
Install prefix    /usr/local
BIOS directory    /usr/local/share/qemu
binary directory  /usr/local/bin
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /root/kvm-88
C compiler        gcc
Host C compiler   gcc
ARCH_CFLAGS       -m64
make              make
install           install
host CPU          x86_64
host big endian   no
target list       x86_64-softmmu
tcg debug enabled no
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
-Werror enabled   no
SDL support       yes
SDL static link   yes
curses support    yes
curl support      no
mingw32 support   no
Audio drivers     oss
Extra audio cards ac97 es1370 sb16
Mixer emulation   no
VNC TLS support   yes
    TLS CFLAGS
    TLS LIBS      -lgnutls
VNC SASL support  no
kqemu support     no
xen support       no
CPU emulation     yes
brlapi support    yes
Documentation     yes
NPTL support      yes
vde support       no
AIO support       yes
IO thread         no
Install blobs     yes
KVM support       yes
KVM trace support no
fdt support       no
preadv support    no

make
  LINK  qemu-nbd
/usr/bin/ld: i386 architecture of input file `cache-utils.o' is incompatible with i386:x86-64 output
collect2: ld returned 1 exit status
make: *** [qemu-nbd] Error 1

I'm going to try it somewhere else ...

Michal Filka

[Qemu-devel] RE: eepro100.c

[Michal Filka]

Hi

Earlier post was one big mistake. Everything is compiled now (from kvm-88 sources).

I don't want to corrupt present kvm installation, or better to say, I want to modify it as small as possible. Could you suggest me what should I replace or how to run new compilation instead of old one without installing?

Thanks
Michal Filka

> -----Original Message-----
> From: Stefan Weil [mailto:weil@mail.berlios.de]
> Sent: 19. září 2009 19:11
> To: Filka Michal
> Cc: qemu-devel; kvm@vger.kernel.org
> Subject: Re: eepro100.c
> 
> Stefan Weil schrieb:
> > Jan Kiszka schrieb:
> >> Michal Filka wrote:
> >>> Hi,
> >>>
> >>> I have question on i82557b emulation in kvm.
> >>>
> >>> I have run a proprietary operating system (Pharlap OS) in kvm. Part
> >>> of the job has been porting driver for i8255x. During the job I
> >>> discovered that kvm's emulation doesn't support a RNR interrupt (it
> >>> is disabled in the code).
> >>>
> >>> Why is it disabled? I'm running heavily loaded application and I have
> >>> to poll descriptor list instead of waiting for RNR interrupt.
> >> Best asked on qemu-devel, CC'ing the developer of this device model.
> >>
> >> Jan
> >>
> >
> > Hi,
> >
> > up to now, nobody complained about the missing RNR interrupts.
> > Linux obviously works without them, so I had no reason to
> > implement them.
> >
> > The disabled code parts (function eepro100_rnr_interrupt)
> > can be enabled, but you still need code which calls them
> > at the right places.
> >
> > This should not be very difficult if there is some test case
> > which proves the working RNR interrupt.
> >
> > Regards
> > Stefan
> >
> 
> Hi Michal,
> 
> could you please try the appended patch and tell me whether it works?
> 
> Regards
> Stefan
> 

[Qemu-devel] Re: eepro100.c

[Amit Shah]

On (Tue) Sep 22 2009 [13:31:11], Michal Filka wrote:
> 
> I don't want to corrupt present kvm installation, or better to say, I want to modify it as small as possible. Could you suggest me what should I replace or how to run new compilation instead of old one without installing?

You can configure with a different prefix, eg:

./configure --prefix=/home/foo/tmp/qemu-kvm/ ...
make
make install

and then run the qemu-system-x86_64 from /home/foo/tmp/qemu-kvm/bin

		Amit

[Qemu-devel] Re: eepro100.c

[Stefan Weil]

Amit Shah schrieb:
> On (Tue) Sep 22 2009 [13:31:11], Michal Filka wrote:
>   
>> I don't want to corrupt present kvm installation, or better to say, I want to modify it as small as possible. Could you suggest me what should I replace or how to run new compilation instead of old one without installing?
>>     
>
> You can configure with a different prefix, eg:
>
> ./configure --prefix=/home/foo/tmp/qemu-kvm/ ...
> make
> make install
>
> and then run the qemu-system-x86_64 from /home/foo/tmp/qemu-kvm/bin
>
> 		Amit

... or run it without installation from the source directory
(the directory containing subdirectory pc-bios):

BUILDPATH/x86_64-softmmu/qemu-system-x86_64 -L pc-bios ...

Stefan

[Qemu-devel] RE: eepro100.c

[Michal Filka]

Hi,

I did a couple of tests.

1. test
Kernel modules from distribution (kvm-72) & new user space application (qemu-system-x86_64 - patched kvm-88)

It seems that it is not working
Possibilities:
1) ru is not ready because of other reason than switching to suspended state
2) patch is not working well
3) anything else ;-)

Conclusion: net card emulation is placed in kernel module, so the test was good for nothing ;-)

2. test
Kernel modules and user space application from patched kvm-88
It seems, it works well, but 
1) RNR interrupt is not generated
2) processing is significantly slower (with kvm from my distro I had a speed (till suspending and restarting ru unit) round 6000 kB/s now it is round 1000 kB/s

My conclusion is that there is another change in i82577b emulation which solved the problem for me - probably some race condition in rx descriptor processing disappeared. Or, due to lower transfer speed (see above), processing of rx descripors is done in time, so a descriptor with "S bit" is never processed. Do you have another idea?

I'll do other stress tests during the night and send you the results. I'll try kvm-88 without the patch too.

Thank you for your time.

Michal Filka

> 
> Stefan Weil schrieb:
> > Jan Kiszka schrieb:
> >> Michal Filka wrote:
> >>> Hi,
> >>>
> >>> I have question on i82557b emulation in kvm.
> >>>
> >>> I have run a proprietary operating system (Pharlap OS) in kvm. Part
> >>> of the job has been porting driver for i8255x. During the job I
> >>> discovered that kvm's emulation doesn't support a RNR interrupt (it
> >>> is disabled in the code).
> >>>
> >>> Why is it disabled? I'm running heavily loaded application and I have
> >>> to poll descriptor list instead of waiting for RNR interrupt.
> >> Best asked on qemu-devel, CC'ing the developer of this device model.
> >>
> >> Jan
> >>
> >
> > Hi,
> >
> > up to now, nobody complained about the missing RNR interrupts.
> > Linux obviously works without them, so I had no reason to
> > implement them.
> >
> > The disabled code parts (function eepro100_rnr_interrupt)
> > can be enabled, but you still need code which calls them
> > at the right places.
> >
> > This should not be very difficult if there is some test case
> > which proves the working RNR interrupt.
> >
> > Regards
> > Stefan
> >
> 
> Hi Michal,
> 
> could you please try the appended patch and tell me whether it works?
> 
> Regards
> Stefan
>