[Qemu-devel] Serial port hacking

[Qemu-devel] Serial port hacking

[Darryl Dixon]

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

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>

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

Re: [Qemu-devel] Serial port hacking

[Nile Geisinger]

Hi Darryl,

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

I'm reading this question two different ways and I'm not sure which question 
you're asking, but here's my best shot at both of them.

1) How stdin/stdout are remapped so that linux kernels can run without a gui:
	
	-------------------------------  PICTURE -----------------------------------

	STDIN/STDOUT	-> 		QEMU		-> LINUX KERNEL console

	This is done in both vl.c and serial.c. In vl.c, there is a function 	
	called serial_open_device that returns 0 if the no_graphic option
	is set. This is called in pc.c when it sets up the first serial port by
	calling serial_init and passing in 0 (STDOUT). In serial_init,
	the variable out_fd of the serial console is also set to STDIN 
	(i.e., 1). This serial device is then *seen* by the operating system
	as the first serial device when it boots. In this way, when 
	we pass the options:

	-nographic -append "console=ttyS0"

	we tell the guest kernel to use ttyS0, our serial device, which is 
	connected to the host's STDOUT and STDIN as the console. 
	All of this is fairly opaque and uncommented [ : but if you look at those 
	functions I think it'll make sense.

2) How to connect a host pseudo-tty to a guest-tty:

	-------------------------------  PICTURE -----------------------------------

	MY PSEUDO	-> 		QEMU		-> LINUX KERNEL console -> TTYS1
		TTY

 I believe that this can also be found in serial_open_device. If you look 
there, you'll see the following code commented out in 0.60:

#if 0
        char slave_name[1024];
        int master_fd, slave_fd;
        
        /* Not satisfying */
        if (openpty(&master_fd, &slave_fd, slave_name, NULL, NULL) < 0) {
            fprintf(stderr, "warning: could not create pseudo terminal for 
serial port\n");
            return -1;
        }
        fprintf(stderr, "Serial port redirected to %s\n", slave_name);
        return master_fd;
#else
	
	Here's one way to do this. Uncomment this code and create a separate if block 
	for it that tests for a flag like INITIALIZE_MY_SERIAL_PORT_NOW (too long, I 
	know) as follows:

	if (INITIALIZE_MY_SERIAL_PORT_NOW)
	{
	        char slave_name[1024];
	        int master_fd, slave_fd;
        
 	       /* Not satisfying */
 	       if (openpty(&master_fd, &slave_fd, slave_name, NULL, NULL) < 0) {
 	           fprintf(stderr, "warning: could not create pseudo terminal for 
serial port\n");
  	          return -1;
  	      }
  	      fprintf(stderr, "Serial port redirected to %s\n", slave_name);
  	      return master_fd;
	}

	Now, after initializing the first serial device in pc.c, add the following
	lines of code.

	INITIALIZE_MY_SERIAL_PORT_NOW = 1;
	my_serial_fd = serial_open_device()
	serial_init(0x2f8, 3, my_serial_fd);

 	This will alias a new serial port to the first available pseudo-tty on the 	
	host system which in turn will be available as /dev/ttyS1 (possible S2) on
	the guest linux kernel.

Does this help? Out of curiousity, what are you trying to accomplish? I've 
also been hacking  on serial ports and its possible we're tackling a similar 
problem,

cheers,

Nile

On Monday 16 August 2004 12:13 am, 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,

Re: [Qemu-devel] Serial port hacking -- BUG?

[Darryl Dixon]

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

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 #2: Type: text/html, Size: 3087 bytes --]

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

[Nile Geisinger]

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

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

[Darryl Dixon]

[-- 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 */
 

Re: [Qemu-devel] Serial port hacking -- BUG?

[Hampa Hug]

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

Darryl Dixon wrote:

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

You might want to try the attached patch, it solved this problem
for me.

cheers,
Hampa

[-- Attachment #2: qemu-serial.diff --]
[-- Type: text/plain, Size: 732 bytes --]

diff -ur qemu-cvs/hw/serial.c qemu-serial/hw/serial.c
--- qemu-cvs/hw/serial.c	2004-07-14 19:28:13.000000000 +0200
+++ qemu-serial/hw/serial.c	2004-08-19 22:42:49.000000000 +0200
@@ -133,7 +133,10 @@
         if (s->lcr & UART_LCR_DLAB) {
             s->divider = (s->divider & 0x00ff) | (val << 8);
         } else {
-            s->ier = val;
+            s->ier = val & 0x0f;
+            if (s->lsr & UART_LSR_THRE) {
+                s->thr_ipending = 1;
+            }
             serial_update_irq(s);
         }
         break;
@@ -143,7 +146,7 @@
         s->lcr = val;
         break;
     case 4:
-        s->mcr = val;
+        s->mcr = val & 0x1f;
         break;
     case 5:
         break;

Re: [Qemu-devel] Serial port hacking -- Fix verified on Linux

[Nile Geisinger]

Thanks Hampa!

I tested the patch with Darryl's patch, a Linux host and Linux guest, and the 
test programs that were posted earlier (with some slight modifications to 
poll for file events to prevent data loss). All tests passed perfectly.

great work,

Nile

Re: [Qemu-devel] Serial port hacking -- Fix verified for Windows Guest (kindof ;)

[Darryl Dixon]

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

Hi All,

    I concur with Nile and Hampa (thanks Hampa!) that Hampa's patch
works successfully for a Windows guest, however I will add the rider
that whatever the guest OS is expecting in the form of Hardware Flow
Control from the UART still does not work, but No Flow Control and
Software Flow Control (Xon/Xoff) DO both work now with this patch. 
Hurray! :)   Unfortunately this means that the guest OS still can't
quite drive the Host's modem ;)  Ahh well :)

    I have rewritten my *original* patch to make it fit more nicely with
the other command line options that qemu provides and attach it below. 
It adds the ability to add up to a possible 4 guest com ports at the
normal memory addresses and fairly standard IRQs (I have integrated the
changes with the ppc stuff for the first, builtin, com port, but because
I am unfamiliar with ppc hardware I didn't want to add the other three
extra ports until someone had verified that they'll be OK; if someone
can confirm that the three extra ports as defined for the pc will be OK
in the ppc machine I'll add them there, too.).  This patch cleans up the
command line options for serial devices also:
-serial1 'dev'   <------ serial1 is always connected regardless, so this
option is only to redirect it if you want it to go somewhere other than
the vc
-serial2 'dev' -serial3 'dev' -serial4 'dev'   <--- these options will
turn on the designated guest com port and connect it to char device
'dev'


Enjoy,
D





On Fri, 2004-08-20 at 05:15, Nile Geisinger wrote:

> Thanks Hampa!
> 
> I tested the patch with Darryl's patch, a Linux host and Linux guest, and the 
> test programs that were posted earlier (with some slight modifications to 
> poll for file events to prevent data loss). All tests passed perfectly.
> 
> great work,
> 
> Nile
> 
> 
> 
> 
> _______________________________________________
> 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: 2698 bytes --]

[-- Attachment #2: extra_serialports.patch --]
[-- Type: text/x-patch, Size: 9035 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-20 14:19:50.830140666 +1200
@@ -471,7 +471,21 @@
     pic_init();
     pit = pit_init(0x40, 0);
 
-    serial_init(0x3f8, 4, serial_hd);
+    /* register each com port:
+     * the memory address are Well Defined but
+     * the IRQs are a matter of preference and
+     * general consensus
+     */
+    serial_init(0x3f8, 4, serial1_hd); /* serial1 is always on */
+    if (init_serial2_device) {
+        serial_init(0x2f8, 3, serial2_hd);
+    }
+    if (init_serial3_device) {
+        serial_init(0x3e8, 5, serial3_hd);
+    }
+    if (init_serial4_device) {
+        serial_init(0x2e8, 9, serial4_hd);
+    }
 
     if (pci_enabled) {
         for(i = 0; i < nb_nics; i++) {
diff -ru qemu-snapshot-2004-08-16_23/hw/ppc_chrp.c qemu-snapshot-2004-08-16_23-testserial/hw/ppc_chrp.c
--- qemu-snapshot-2004-08-16_23/hw/ppc_chrp.c	2004-07-15 05:28:13.000000000 +1200
+++ qemu-snapshot-2004-08-16_23-testserial/hw/ppc_chrp.c	2004-08-20 14:50:41.827364816 +1200
@@ -200,7 +200,7 @@
     pic_init();
 
     /* XXX: use Mac Serial port */
-    serial_init(0x3f8, 4, serial_hd);
+    serial_init(0x3f8, 4, serial1_hd);
 
     for(i = 0; i < nb_nics; i++) {
         pci_ne2000_init(pci_bus, &nd_table[i]);
diff -ru qemu-snapshot-2004-08-16_23/hw/ppc_prep.c qemu-snapshot-2004-08-16_23-testserial/hw/ppc_prep.c
--- qemu-snapshot-2004-08-16_23/hw/ppc_prep.c	2004-07-15 05:28:13.000000000 +1200
+++ qemu-snapshot-2004-08-16_23-testserial/hw/ppc_prep.c	2004-08-20 14:49:47.155402748 +1200
@@ -492,7 +492,7 @@
     pic_init();
     //    pit = pit_init(0x40, 0);
 
-    serial_init(0x3f8, 4, serial_hd);
+    serial_init(0x3f8, 4, serial1_hd);
     nb_nics1 = nb_nics;
     if (nb_nics1 > NE2000_NB_MAX)
         nb_nics1 = NE2000_NB_MAX;
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-20 14:56:17.390009809 +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;
+        }
     }
 }
 
@@ -2352,7 +2361,10 @@
            "\n"
            "Debug/Expert options:\n"
            "-monitor dev    redirect the monitor to char device 'dev'\n"
-           "-serial dev     redirect the serial port to char device 'dev'\n"
+           "-serial1 dev     redirect the guest com1 port to char device 'dev'\n"
+           "-serial2 dev     initialise and redirect the guest com2 port to char device 'dev'\n"
+           "-serial3 dev     initialise and redirect the guest com3 port to char device 'dev'\n"
+           "-serial4 dev     initialise and redirect the guest com4 port to char device 'dev'\n"
            "-S              freeze CPU at startup (use 'c' to start execution)\n"
            "-s              wait gdb connection to port %d\n"
            "-p port         change gdb connection port\n"
@@ -2437,7 +2449,10 @@
     QEMU_OPTION_g,
     QEMU_OPTION_std_vga,
     QEMU_OPTION_monitor,
-    QEMU_OPTION_serial,
+    QEMU_OPTION_serial1,
+    QEMU_OPTION_serial2,
+    QEMU_OPTION_serial3,
+    QEMU_OPTION_serial4,
 };
 
 typedef struct QEMUOption {
@@ -2490,7 +2505,10 @@
     { "isa", 0, QEMU_OPTION_isa },
     { "std-vga", 0, QEMU_OPTION_std_vga },
     { "monitor", 1, QEMU_OPTION_monitor },
-    { "serial", 1, QEMU_OPTION_serial },
+    { "serial1", HAS_ARG, QEMU_OPTION_serial1 },
+    { "serial2", HAS_ARG, QEMU_OPTION_serial2 },
+    { "serial3", HAS_ARG, QEMU_OPTION_serial3 },
+    { "serial4", HAS_ARG, QEMU_OPTION_serial4 },
     
     /* temporary options */
     { "pci", 0, QEMU_OPTION_pci },
@@ -2568,8 +2586,11 @@
     const char *r, *optarg;
     CharDriverState *monitor_hd;
     char monitor_device[128];
-    char serial_device[128];
-
+    char serial1_device[128];
+    char serial2_device[128];
+    char serial3_device[128];
+    char serial4_device[128];
+ 
 #if !defined(CONFIG_SOFTMMU)
     /* we never want that malloc() uses mmap() */
     mallopt(M_MMAP_THRESHOLD, 4096 * 1024);
@@ -2594,7 +2615,14 @@
     has_cdrom = 1;
     cyls = heads = secs = 0;
     pstrcpy(monitor_device, sizeof(monitor_device), "vc");
-    pstrcpy(serial_device, sizeof(serial_device), "vc");
+    /* Because serial1 is on by default we initialise it to the vc */
+    pstrcpy(serial1_device, sizeof(serial1_device), "vc");
+    pstrcpy(serial2_device, sizeof(serial2_device), "NULL");
+    pstrcpy(serial3_device, sizeof(serial3_device), "NULL");
+    pstrcpy(serial4_device, sizeof(serial4_device), "NULL");
+    init_serial2_device = 0;
+    init_serial3_device = 0;
+    init_serial4_device = 0;
 
     nb_tun_fds = 0;
     net_if_type = -1;
@@ -2674,7 +2702,7 @@
                 break;
             case QEMU_OPTION_nographic:
                 pstrcpy(monitor_device, sizeof(monitor_device), "stdio");
-                pstrcpy(serial_device, sizeof(serial_device), "stdio");
+                pstrcpy(serial1_device, sizeof(serial1_device), "stdio");
                 nographic = 1;
                 break;
             case QEMU_OPTION_kernel:
@@ -2864,8 +2892,20 @@
             case QEMU_OPTION_monitor:
                 pstrcpy(monitor_device, sizeof(monitor_device), optarg);
                 break;
-            case QEMU_OPTION_serial:
-                pstrcpy(serial_device, sizeof(serial_device), optarg);
+            case QEMU_OPTION_serial1:
+                pstrcpy(serial1_device, sizeof(serial1_device), optarg);
+                break;
+            case QEMU_OPTION_serial2:
+                pstrcpy(serial2_device, sizeof(serial2_device), optarg);
+                init_serial2_device = 1;
+                break;
+            case QEMU_OPTION_serial3:
+                pstrcpy(serial3_device, sizeof(serial3_device), optarg);
+                init_serial3_device = 1;
+                break;
+            case QEMU_OPTION_serial4:
+                pstrcpy(serial4_device, sizeof(serial4_device), optarg);
+                init_serial4_device = 1;
                 break;
             }
         }
@@ -3065,15 +3105,41 @@
         exit(1);
     }
     monitor_init(monitor_hd, !nographic);
-
-    serial_hd = qemu_chr_open(serial_device);
-    if (!serial_hd) {
-        fprintf(stderr, "qemu: could not open serial device '%s'\n", serial_device);
+   
+    /* Initialise all relevant serial ports */
+    /* serial1 is always connected by default */
+    serial1_hd = qemu_chr_open(serial1_device);
+    if (!serial1_hd) {
+        fprintf(stderr, "qemu: could not open serial1 device '%s'\n", serial1_device);
         exit(1);
     }
-    if (!strcmp(serial_device, "vc"))
-        qemu_chr_printf(serial_hd, "serial0 console\n");
+    if (!strcmp(serial1_device, "vc"))
+        qemu_chr_printf(serial1_hd, "serial1 console\n");
     
+    if (init_serial2_device) {
+        serial2_hd = qemu_chr_open(serial2_device);
+        if (!serial2_hd) {
+            fprintf(stderr, "qemu: could not open serial2 device '%s'\n", serial2_device);
+            exit(1);
+        }
+    }
+
+    if (init_serial3_device) {
+        serial3_hd = qemu_chr_open(serial3_device);
+        if (!serial3_hd) {
+            fprintf(stderr, "qemu: could not open serial3 device '%s'\n", serial3_device);
+            exit(1);
+        }
+    }
+
+    if (init_serial4_device) {
+        serial4_hd = qemu_chr_open(serial4_device);
+        if (!serial4_hd) {
+            fprintf(stderr, "qemu: could not open serial4 device '%s'\n", serial4_device);
+            exit(1);
+        }
+    }
+
 
     /* setup cpu signal handlers for MMU / self modifying code handling */
 #if !defined(CONFIG_SOFTMMU)
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-20 13:59:59.110132869 +1200
@@ -200,7 +200,14 @@
                                IOReadHandler *fd_read, void *opaque);
 void qemu_chr_add_event_handler(CharDriverState *s, IOEventHandler *chr_event);
                                
-CharDriverState *serial_hd;
+CharDriverState *serial1_hd;
+CharDriverState *serial2_hd;
+CharDriverState *serial3_hd;
+CharDriverState *serial4_hd;
+int init_serial2_device;
+int init_serial3_device;
+int init_serial4_device;
+
 
 /* consoles */
 

Re: [Qemu-devel] Serial port hacking -- Fix verified for Windows Guest (kindof ;)

[Fabrice Bellard]

OK for the idea of several serial ports, but for consistency I prefer to 
add several '-serial' options. I'll make an implementation soon.

Fabrice.

Darryl Dixon wrote:
>   Hi All,
> 
>     I concur with Nile and Hampa (thanks Hampa!) that Hampa's patch 
> works successfully for a Windows guest, however I will add the rider 
> that whatever the guest OS is expecting in the form of Hardware Flow 
> Control from the UART still does not work, but No Flow Control and 
> Software Flow Control (Xon/Xoff) DO both work now with this patch.  
> Hurray! :)   Unfortunately this means that the guest OS still can't 
> quite drive the Host's modem ;)  Ahh well :)
> 
>     I have rewritten my *original* patch to make it fit more nicely with 
> the other command line options that qemu provides and attach it below.  
> It adds the ability to add up to a possible 4 guest com ports at the 
> normal memory addresses and fairly standard IRQs (I have integrated the 
> changes with the ppc stuff for the first, builtin, com port, but because 
> I am unfamiliar with ppc hardware I didn't want to add the other three 
> extra ports until someone had verified that they'll be OK; if someone 
> can confirm that the three extra ports as defined for the pc will be OK 
> in the ppc machine I'll add them there, too.).  This patch cleans up the 
> command line options for serial devices also:
> -serial1 'dev'   <------ serial1 is always connected regardless, so this 
> option is only to redirect it if you want it to go somewhere other than 
> the vc
> -serial2 'dev' -serial3 'dev' -serial4 'dev'   <--- these options will 
> turn on the designated guest com port and connect it to char device 'dev'
> 
> 
> Enjoy,
> D
> 
> 
> 
> 
> 
> On Fri, 2004-08-20 at 05:15, Nile Geisinger wrote:
> 
>> /Thanks Hampa!
>>
>>I tested the patch with Darryl's patch, a Linux host and Linux guest, and the 
>>test programs that were posted earlier (with some slight modifications to 
>>poll for file events to prevent data loss). All tests passed perfectly.
>>
>>great work,
>>
>>Nile
>>
>>
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org/ 
>>/ http://lists.nongnu.org/mailman/listinfo/qemu-devel  <http://lists.nongnu.org/mailman/listinfo/qemu-devel>/
>>
> -- 
> Darryl Dixon < esrever_otua@pythonhacker.is-a-geek.net 
> <mailto:esrever_otua@pythonhacker.is-a-geek.net>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 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-20 14:19:50.830140666 +1200
> @@ -471,7 +471,21 @@
>      pic_init();
>      pit = pit_init(0x40, 0);
>  
> -    serial_init(0x3f8, 4, serial_hd);
> +    /* register each com port:
> +     * the memory address are Well Defined but
> +     * the IRQs are a matter of preference and
> +     * general consensus
> +     */
> +    serial_init(0x3f8, 4, serial1_hd); /* serial1 is always on */
> +    if (init_serial2_device) {
> +        serial_init(0x2f8, 3, serial2_hd);
> +    }
> +    if (init_serial3_device) {
> +        serial_init(0x3e8, 5, serial3_hd);
> +    }
> +    if (init_serial4_device) {
> +        serial_init(0x2e8, 9, serial4_hd);
> +    }
>  
>      if (pci_enabled) {
>          for(i = 0; i < nb_nics; i++) {
> diff -ru qemu-snapshot-2004-08-16_23/hw/ppc_chrp.c qemu-snapshot-2004-08-16_23-testserial/hw/ppc_chrp.c
> --- qemu-snapshot-2004-08-16_23/hw/ppc_chrp.c	2004-07-15 05:28:13.000000000 +1200
> +++ qemu-snapshot-2004-08-16_23-testserial/hw/ppc_chrp.c	2004-08-20 14:50:41.827364816 +1200
> @@ -200,7 +200,7 @@
>      pic_init();
>  
>      /* XXX: use Mac Serial port */
> -    serial_init(0x3f8, 4, serial_hd);
> +    serial_init(0x3f8, 4, serial1_hd);
>  
>      for(i = 0; i < nb_nics; i++) {
>          pci_ne2000_init(pci_bus, &nd_table[i]);
> diff -ru qemu-snapshot-2004-08-16_23/hw/ppc_prep.c qemu-snapshot-2004-08-16_23-testserial/hw/ppc_prep.c
> --- qemu-snapshot-2004-08-16_23/hw/ppc_prep.c	2004-07-15 05:28:13.000000000 +1200
> +++ qemu-snapshot-2004-08-16_23-testserial/hw/ppc_prep.c	2004-08-20 14:49:47.155402748 +1200
> @@ -492,7 +492,7 @@
>      pic_init();
>      //    pit = pit_init(0x40, 0);
>  
> -    serial_init(0x3f8, 4, serial_hd);
> +    serial_init(0x3f8, 4, serial1_hd);
>      nb_nics1 = nb_nics;
>      if (nb_nics1 > NE2000_NB_MAX)
>          nb_nics1 = NE2000_NB_MAX;
> 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-20 14:56:17.390009809 +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;
> +        }
>      }
>  }
>  
> @@ -2352,7 +2361,10 @@
>             "\n"
>             "Debug/Expert options:\n"
>             "-monitor dev    redirect the monitor to char device 'dev'\n"
> -           "-serial dev     redirect the serial port to char device 'dev'\n"
> +           "-serial1 dev     redirect the guest com1 port to char device 'dev'\n"
> +           "-serial2 dev     initialise and redirect the guest com2 port to char device 'dev'\n"
> +           "-serial3 dev     initialise and redirect the guest com3 port to char device 'dev'\n"
> +           "-serial4 dev     initialise and redirect the guest com4 port to char device 'dev'\n"
>             "-S              freeze CPU at startup (use 'c' to start execution)\n"
>             "-s              wait gdb connection to port %d\n"
>             "-p port         change gdb connection port\n"
> @@ -2437,7 +2449,10 @@
>      QEMU_OPTION_g,
>      QEMU_OPTION_std_vga,
>      QEMU_OPTION_monitor,
> -    QEMU_OPTION_serial,
> +    QEMU_OPTION_serial1,
> +    QEMU_OPTION_serial2,
> +    QEMU_OPTION_serial3,
> +    QEMU_OPTION_serial4,
>  };
>  
>  typedef struct QEMUOption {
> @@ -2490,7 +2505,10 @@
>      { "isa", 0, QEMU_OPTION_isa },
>      { "std-vga", 0, QEMU_OPTION_std_vga },
>      { "monitor", 1, QEMU_OPTION_monitor },
> -    { "serial", 1, QEMU_OPTION_serial },
> +    { "serial1", HAS_ARG, QEMU_OPTION_serial1 },
> +    { "serial2", HAS_ARG, QEMU_OPTION_serial2 },
> +    { "serial3", HAS_ARG, QEMU_OPTION_serial3 },
> +    { "serial4", HAS_ARG, QEMU_OPTION_serial4 },
>      
>      /* temporary options */
>      { "pci", 0, QEMU_OPTION_pci },
> @@ -2568,8 +2586,11 @@
>      const char *r, *optarg;
>      CharDriverState *monitor_hd;
>      char monitor_device[128];
> -    char serial_device[128];
> -
> +    char serial1_device[128];
> +    char serial2_device[128];
> +    char serial3_device[128];
> +    char serial4_device[128];
> + 
>  #if !defined(CONFIG_SOFTMMU)
>      /* we never want that malloc() uses mmap() */
>      mallopt(M_MMAP_THRESHOLD, 4096 * 1024);
> @@ -2594,7 +2615,14 @@
>      has_cdrom = 1;
>      cyls = heads = secs = 0;
>      pstrcpy(monitor_device, sizeof(monitor_device), "vc");
> -    pstrcpy(serial_device, sizeof(serial_device), "vc");
> +    /* Because serial1 is on by default we initialise it to the vc */
> +    pstrcpy(serial1_device, sizeof(serial1_device), "vc");
> +    pstrcpy(serial2_device, sizeof(serial2_device), "NULL");
> +    pstrcpy(serial3_device, sizeof(serial3_device), "NULL");
> +    pstrcpy(serial4_device, sizeof(serial4_device), "NULL");
> +    init_serial2_device = 0;
> +    init_serial3_device = 0;
> +    init_serial4_device = 0;
>  
>      nb_tun_fds = 0;
>      net_if_type = -1;
> @@ -2674,7 +2702,7 @@
>                  break;
>              case QEMU_OPTION_nographic:
>                  pstrcpy(monitor_device, sizeof(monitor_device), "stdio");
> -                pstrcpy(serial_device, sizeof(serial_device), "stdio");
> +                pstrcpy(serial1_device, sizeof(serial1_device), "stdio");
>                  nographic = 1;
>                  break;
>              case QEMU_OPTION_kernel:
> @@ -2864,8 +2892,20 @@
>              case QEMU_OPTION_monitor:
>                  pstrcpy(monitor_device, sizeof(monitor_device), optarg);
>                  break;
> -            case QEMU_OPTION_serial:
> -                pstrcpy(serial_device, sizeof(serial_device), optarg);
> +            case QEMU_OPTION_serial1:
> +                pstrcpy(serial1_device, sizeof(serial1_device), optarg);
> +                break;
> +            case QEMU_OPTION_serial2:
> +                pstrcpy(serial2_device, sizeof(serial2_device), optarg);
> +                init_serial2_device = 1;
> +                break;
> +            case QEMU_OPTION_serial3:
> +                pstrcpy(serial3_device, sizeof(serial3_device), optarg);
> +                init_serial3_device = 1;
> +                break;
> +            case QEMU_OPTION_serial4:
> +                pstrcpy(serial4_device, sizeof(serial4_device), optarg);
> +                init_serial4_device = 1;
>                  break;
>              }
>          }
> @@ -3065,15 +3105,41 @@
>          exit(1);
>      }
>      monitor_init(monitor_hd, !nographic);
> -
> -    serial_hd = qemu_chr_open(serial_device);
> -    if (!serial_hd) {
> -        fprintf(stderr, "qemu: could not open serial device '%s'\n", serial_device);
> +   
> +    /* Initialise all relevant serial ports */
> +    /* serial1 is always connected by default */
> +    serial1_hd = qemu_chr_open(serial1_device);
> +    if (!serial1_hd) {
> +        fprintf(stderr, "qemu: could not open serial1 device '%s'\n", serial1_device);
>          exit(1);
>      }
> -    if (!strcmp(serial_device, "vc"))
> -        qemu_chr_printf(serial_hd, "serial0 console\n");
> +    if (!strcmp(serial1_device, "vc"))
> +        qemu_chr_printf(serial1_hd, "serial1 console\n");
>      
> +    if (init_serial2_device) {
> +        serial2_hd = qemu_chr_open(serial2_device);
> +        if (!serial2_hd) {
> +            fprintf(stderr, "qemu: could not open serial2 device '%s'\n", serial2_device);
> +            exit(1);
> +        }
> +    }
> +
> +    if (init_serial3_device) {
> +        serial3_hd = qemu_chr_open(serial3_device);
> +        if (!serial3_hd) {
> +            fprintf(stderr, "qemu: could not open serial3 device '%s'\n", serial3_device);
> +            exit(1);
> +        }
> +    }
> +
> +    if (init_serial4_device) {
> +        serial4_hd = qemu_chr_open(serial4_device);
> +        if (!serial4_hd) {
> +            fprintf(stderr, "qemu: could not open serial4 device '%s'\n", serial4_device);
> +            exit(1);
> +        }
> +    }
> +
>  
>      /* setup cpu signal handlers for MMU / self modifying code handling */
>  #if !defined(CONFIG_SOFTMMU)
> 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-20 13:59:59.110132869 +1200
> @@ -200,7 +200,14 @@
>                                 IOReadHandler *fd_read, void *opaque);
>  void qemu_chr_add_event_handler(CharDriverState *s, IOEventHandler *chr_event);
>                                 
> -CharDriverState *serial_hd;
> +CharDriverState *serial1_hd;
> +CharDriverState *serial2_hd;
> +CharDriverState *serial3_hd;
> +CharDriverState *serial4_hd;
> +int init_serial2_device;
> +int init_serial3_device;
> +int init_serial4_device;
> +
>  
>  /* consoles */
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel