[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] A different serial port question

From: Nile Geisinger
Subject: [Qemu-devel] A different serial port question
Date: Sun, 15 Aug 2004 19:52:43 +0000
User-agent: KMail/1.6

Hi everyone,

I asked the following question earlier on the list, but was Warnocked :]. The 
question was a little detailed, but that was to make it simple to answer. 
It's probably an obvious solution to a reader here, so thanks in advance for 
any help.




I want to send data from the host qemu program to a guest kernel and
back. This has a number of benefits for everyone. One of the most obvious is 
users can output to a log on the host system easily (guest to host). Another
benefit is that the host can inform the guest if its shutting down so it
can shut down as well (host to guest). 

To accomplish this, I've created by own serial device and am trying to send 
data back and forth between guest and host operating systems. At the moment, 
I have it working sending data from  Linux to my serial device in qemu, but 
am only intermittently successful going the other way -- i.e., I'm having 
difficulty getting all of the data I think I'm putting in the serial device
read by the Linux OS. 

I've tried very hard to simplify my approach. Although I could use one 
dual-channel serial port, I'm intentionally using two (one for reading, one 
for writing) to narrow down on the problem. 

I start by adding both serial devices as follows in pc.c:

// Initialize serial port (ttyS1)
serial_init(0x2f8, 3, 0);

// Initialize serial port (ttyS2)
serial_init(0x3e8, 11, 0);

I also added code in serial_init to initialize the devices (Here's the code 
for ttyS1, though I don't think this is where the problem is):

if  (irq == 3)
          /* Create the communication file. */
          input_writeptr = fopen("mycom.txt", "w");

          /* Open up our communication file for non-blocking reading */
          input_readfd = open("mycom.txt", O_RDONLY | O_NONBLOCK);
          input_layer = s;
          qemu_add_fd_read_handler(input_readfd, serial_can_receive1, 
serial_receive1, s);

          /* Open up our communication file for writing. */
          input_writefd = open("mycom.txt", O_WRONLY);
          s->out_fd = input_writefd ;

Linux correctly recognizes both of the serial ports on booting. 

On the client side, the C code that sends information from the linux os 
through port (ttyS2) to the qemu program works correctly and I've written 
code in qemu that prints it out. 

However, the code that sends information from the qemu program through ttyS1 
to the Linux operating system has some bug I'm missing. Data gets dropped
intermittently. I think I am making either one of two problems: sending 
information in qemu wrong to that serial device or reading it wrong in the C 
code on the linux side. This may be based on the fact that I'm new to serial 
port programming and qemu. 

Here are the two places I've tried sending information from qemu:

-> in the inner loop of vl.c as it cycles through devices and performs its 
read and then calls fd_read I pass it the info I want to send. For example:

        // Don't touch regular devices
        if (ioh->opaque != my_output_device)
                n = read(ioh->fd, buf, ioh->max_size);
        // This is our device: Directly set n and the input buffer so that 
        // be passed them.
        else {
                n = strlen(myinfo);
                strcpy(buf, myinfo, n);
-> Alternatively, in serial_ioport_read when that specific device is called 
with case 0, I change the variable 'ret' to the character I want to send. For 

        if (s != my_output_device)
                ret = s->rbr; // Original code
                ret = get_character_to_send();  // Directly set the variable 
                s->rbr = ret;
Either way, the result is that data is dropped somewhere from where qemu
is sending it here to the program on the linux client trying to read it. The 
linux C code will read a few continuous bytes of information, then skip 10 
bytes, read a few more and skip another random set of bytes. My code on the 
linux side also seems fairly standard:

        fd = open(argv[1], O_RDONLY);
        tcgetattr(fd, tp);

        tp.c_cflag = CS8|CLOCAL|baud|CREAD;
        tp.c_oflag = 0;
        tp.c_iflag = IGNCR|IGNPAR;
        tp.c_lflag = 0;

        cfsetospeed(&tp, baud);
        cfsetispeed(&tp, baud);
        if (tcsetattr(fd, TCSANOW, &tp) < 0) {
                perror("Couldn't set term attributes");

        n = read(fd, readBuffer, 6);

I've also tried this with O_NONBLOCK (i.e., non-blocking read), but it has the 
same problem of reading a few continuous bytes, then skipping a segment. 

Can anyone see my mistake or have any ideas to make it possible for the Linux
side to continually read all the data?

thanks again,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]