From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BqFdf-00035x-J2 for qemu-devel@nongnu.org; Thu, 29 Jul 2004 14:28:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BqFde-00035l-Rv for qemu-devel@nongnu.org; Thu, 29 Jul 2004 14:28:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BqFde-00035b-MS for qemu-devel@nongnu.org; Thu, 29 Jul 2004 14:28:22 -0400 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BqFa6-0005nO-9B for qemu-devel@nongnu.org; Thu, 29 Jul 2004 14:24:42 -0400 Received: from windmill.dloo.org (adsl-209-204-144-115.sonic.net [209.204.144.115]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i6TIOc8T014470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 29 Jul 2004 11:24:39 -0700 From: Nile Geisinger Date: Thu, 29 Jul 2004 11:19:29 +0000 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200407291119.29715.nile@dloo.com> Subject: [Qemu-devel] Ugh! Greatly appreciate help. Reply-To: nile@dloo.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Pulling my hair out a little on this one. :]. It's probably an obvious solution to a reader here, so thanks in advance for any help. My two questions are: 1. What is the easiest way to send data from qemu (the program, not the host os) to a client linux os *without* a network connection? 2. In regards to doing this with serial devices, what mistake am I in the code below? Is the qemu serial device writer still on the list or anyone familiar with serial programming? I have it working sending data from Linux to my serial device in qemu, but am only intermittently successful going the other way. My code is included below to show my approach. thanks in advance for an answer to either question, Nile *** Question number two with code *** Thanks for reading this far. In regards to question two, I'm trying to set up a two way communication channel between qemu (the program) and the client where the client os is Linux. I need to use a non-net connection if at all possible. I've added two new serial devices and it's mostly working, but I'm having one last difficulty -- getting all the data I think I'm putting in the serial device read by the Linux os. Here's what I've tried so far. 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 add 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. */ unlink("mycom.txt"); input_writeptr = fopen("mycom.txt", "w"); fclose(input_writeptr); /* 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 sent 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 fd_read can // 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 example: if (s != my_output_device) { ret = s->rbr; // Original code } else { ret = get_character_to_send(); // Directly set the variable 'ret' 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"); exit(-1); } 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?