Re: [Qemu-devel] Serial port -- OPPOSITE BUG == COMPLETE SOLUTION?

[Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>]

[-- Attachment #1.1: Type: text/plain, Size: 4680 bytes --]

Hi All,

    Please see the attached patch.  It is diff'ed against a clean
qemu-snapshot-2004-08-16_23.  What does it give me, you ask?  Well:
* Optional guest COM2 (with '-com2-serial /some/file' on the command
line)
* Ability to send either the existing builtin COM1 ('-serial') or the
optional COM2 to any arbitrary file, pipe, pty, or whatever that
supports open() style file access semantics (although do note that it
doesn't actually behave well with normal files at this point ;)

So basically if you use '-com2-serial /dev/ttyS0' on the qemu command
line, any data that you send to COM2 inside the guest will automagically
appear on /dev/ttyS0 on the host, and vice-versa.  One caveat; as noted
earlier in this thread, there appears to be a bug in the current qemu
code that uses serial_ioport_read() that is causing data sent from the
guest to not get transmitted out to the host.  Data sent from the host
works OK, but the reverse appears to be broken at the moment (at least
in my snapshot).  Once the bug is fixed in the guts of the serial
emulation this patch should work 100% with no further modification.

This is really quite a trivial, non-intrusive patch, so any recent
snapshot should work, but not qemu-0.6.0 as there seems to have been
some significant improvements in the serial code since then (thanks
guys! :).

Cheers,
D

On Tue, 2004-08-17 at 12:23, Nile Geisinger wrote:

> Hi Darryl.
> 
> How funny! We not only appear to be working on the same problem, we also 
> appear to each have solved the half of the problem the other person is 
> struggling with. 
> 
> At the moment, I can successfully send data without any difficulty from the 
> GUEST to the HOST, but am only able to read it from host to guest 
> intermittently. I've been tearing my hair out trying to figure this out. From
> your emails, it appears that you can successfully send from HOST to
> GUEST without any troubles, but cannot get any data from the
> guest to the host.
> 
> It's late here, but I'll put together a patch first thing tommorow
> and send it to you. If you do the same with your work, I suspect we'll
> put together a complete solution in short order.
> 
> cheers,
> 
> Nile
> 
> On Tuesday 17 August 2004 6:26 am, Darryl Dixon wrote:
> > Hi All,
> >
> >     I've been working on the latest snapshot's serial code and it
> > appears that there is some sort of bug that is preventing data sent by a
> > guest from making out to the host.  For example, if one connects the
> > builtin serial port (com1 or /dev/ttyS0) to stdio with '-serial stdio'
> > then if you connect something like minicom or hyperterm to the
> > appropriate port in the guest, you can see anything you type into the
> > console (STDIN) of the host appearing correctly in the guest.  However,
> > if you send some data down the line from inside the guest, nothing
> > 'comes out' at the host end (on STDOUT, in this example).  I have also
> > connected the host end of the pipe to a psuedo-terminal slave and the
> > same behaviour is present; anything cat-ed (or whatever) to the pty on
> > the Host appears on the serial port of the guest, but the reverse is not
> > true...
> >
> >     I have verified that the data sent from the guest is indeed being
> > read and it appears inside the serial_ioport_read() function
> > successfully, but tracing it onwards from there appears to take me deep
> > into the guts of qemu's machine emulation model and I'm not really
> > enough of an uber-hacker to follow it from there without spending
> > serious amounts of time...
> >
> >     Can anyone shed some light on this apparent bug, or perhaps point me
> > in the right direction to trace it further than serial_ioport_read() and
> > its entry into the ioport_table ?
> >
> > Cheers,
> > D
> >
> > On Mon, 2004-08-16 at 12:13, Darryl Dixon wrote:
> > > Hi,
> > >
> > >     Whereabouts would I start looking to find the 'glue' code that
> > > connects the emulation of the guest's serial port with the 'real'
> > > world?  I've looked briefly at serial.c but it only seemed to deal
> > > with the guts of the emulation, rather that directing its output...
> > > (maybe I'm just being thick and missing the obvious?)  Any pointers
> > > and help to send me in the right direction appreciated.
> > >
> > > Cheers,
> > > --
> > > Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>
> > >
> > > ______________________________________________________________________
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>

[-- Attachment #1.2: Type: text/html, Size: 5404 bytes --]

[-- Attachment #2: com2_serial.patch --]
[-- Type: text/x-patch, Size: 3675 bytes --]

diff -ru qemu-snapshot-2004-08-16_23/hw/pc.c qemu-snapshot-2004-08-16_23-testserial/hw/pc.c
--- qemu-snapshot-2004-08-16_23/hw/pc.c	2004-07-15 05:28:12.000000000 +1200
+++ qemu-snapshot-2004-08-16_23-testserial/hw/pc.c	2004-08-18 01:27:58.832976507 +1200
@@ -471,6 +471,9 @@
     pic_init();
     pit = pit_init(0x40, 0);
 
+    if (init_com2_serial_device) {
+        serial_init(0x2f8, 3, com2_serial_hd);
+    }
     serial_init(0x3f8, 4, serial_hd);
 
     if (pci_enabled) {
Only in qemu-snapshot-2004-08-16_23-testserial: qemu.1
Only in qemu-snapshot-2004-08-16_23-testserial: qemu-doc.html
Only in qemu-snapshot-2004-08-16_23-testserial: qemu-tech.html
diff -ru qemu-snapshot-2004-08-16_23/vl.c qemu-snapshot-2004-08-16_23-testserial/vl.c
--- qemu-snapshot-2004-08-16_23/vl.c	2004-08-04 10:09:30.000000000 +1200
+++ qemu-snapshot-2004-08-16_23-testserial/vl.c	2004-08-18 01:32:40.551758716 +1200
@@ -1222,8 +1222,17 @@
         return qemu_chr_open_stdio();
     } else 
 #endif
-    {
+    if (!strcmp(filename, "NULL")) {
+        /* Shouldn't ever end up in here */
         return NULL;
+    } else {
+        int fdesc;
+        fdesc = open(filename, O_RDWR);
+        if (fdesc >= 0) {
+            return qemu_chr_open_fd(fdesc, fdesc);
+        } else {
+            return NULL;
+        }
     }
 }
 
@@ -2438,6 +2447,7 @@
     QEMU_OPTION_std_vga,
     QEMU_OPTION_monitor,
     QEMU_OPTION_serial,
+    QEMU_OPTION_com2_serial,
 };
 
 typedef struct QEMUOption {
@@ -2491,6 +2501,7 @@
     { "std-vga", 0, QEMU_OPTION_std_vga },
     { "monitor", 1, QEMU_OPTION_monitor },
     { "serial", 1, QEMU_OPTION_serial },
+    { "com2-serial", 1, QEMU_OPTION_com2_serial },
     
     /* temporary options */
     { "pci", 0, QEMU_OPTION_pci },
@@ -2569,7 +2580,8 @@
     CharDriverState *monitor_hd;
     char monitor_device[128];
     char serial_device[128];
-
+    char com2_serial_device[128];
+ 
 #if !defined(CONFIG_SOFTMMU)
     /* we never want that malloc() uses mmap() */
     mallopt(M_MMAP_THRESHOLD, 4096 * 1024);
@@ -2595,6 +2607,8 @@
     cyls = heads = secs = 0;
     pstrcpy(monitor_device, sizeof(monitor_device), "vc");
     pstrcpy(serial_device, sizeof(serial_device), "vc");
+    pstrcpy(com2_serial_device, sizeof(com2_serial_device), "NULL");
+    init_com2_serial_device = 0;
 
     nb_tun_fds = 0;
     net_if_type = -1;
@@ -2867,6 +2881,10 @@
             case QEMU_OPTION_serial:
                 pstrcpy(serial_device, sizeof(serial_device), optarg);
                 break;
+            case QEMU_OPTION_com2_serial:
+                pstrcpy(com2_serial_device, sizeof(com2_serial_device), optarg);
+                init_com2_serial_device = 1;
+                break;
             }
         }
     }
@@ -3065,6 +3083,15 @@
         exit(1);
     }
     monitor_init(monitor_hd, !nographic);
+   
+    if (init_com2_serial_device)
+    {
+        com2_serial_hd = qemu_chr_open(com2_serial_device);
+        if (!com2_serial_hd) {
+            fprintf(stderr, "qemu: could not open serial device '%s'\n", com2_serial_device);
+            exit(1);
+        }
+    }
 
     serial_hd = qemu_chr_open(serial_device);
     if (!serial_hd) {
diff -ru qemu-snapshot-2004-08-16_23/vl.h qemu-snapshot-2004-08-16_23-testserial/vl.h
--- qemu-snapshot-2004-08-16_23/vl.h	2004-08-04 09:15:11.000000000 +1200
+++ qemu-snapshot-2004-08-16_23-testserial/vl.h	2004-08-18 01:31:55.037425215 +1200
@@ -201,6 +201,9 @@
 void qemu_chr_add_event_handler(CharDriverState *s, IOEventHandler *chr_event);
                                
 CharDriverState *serial_hd;
+CharDriverState *com2_serial_hd;
+int init_com2_serial_device;
+
 
 /* consoles */