RE: [Qemu-devel] win64
I tried with - Fedora Core 5 x86-64 in rescue mode - Ubuntu 6.06 live DVD x86 they works, I can use a ssh session without problems. I tried scp with Ubuntu, speed was about 530KB/s. In both cases I used user mode (-net nic,model=rtl8139 -net user). Perhaps it would fine to add a rtl8139too like Linux... freddy77 > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > .org] On Behalf Of Fabrice Bellard > Sent: lunedì 26 giugno 2006 21.58 > To: qemu-devel@nongnu.org > Subject: Re: [Qemu-devel] win64 > > If it works with Linux too then I can change it without > leaving the old > value... > > Fabrice. > > ZIGLIO, Frediano, VF-IT wrote: > > I got windows xp 64 working using current CVS. > > I still have problems with network, I had to use this patch > > > > Index: hw/rtl8139.c > > === > > RCS file: /sources/qemu/qemu/hw/rtl8139.c,v > > retrieving revision 1.1 > > diff -u -1 -0 -r1.1 rtl8139.c > > --- hw/rtl8139.c5 Feb 2006 04:14:41 - 1.1 > > +++ hw/rtl8139.c26 Jun 2006 08:44:49 - > > @@ -2826,21 +2826,21 @@ > > d = (PCIRTL8139State *)pci_register_device(bus, > >"RTL8139", > > sizeof(PCIRTL8139State), > >-1, > >NULL, NULL); > > pci_conf = d->dev.config; > > pci_conf[0x00] = 0xec; /* Realtek 8139 */ > > pci_conf[0x01] = 0x10; > > pci_conf[0x02] = 0x39; > > pci_conf[0x03] = 0x81; > > pci_conf[0x04] = 0x05; /* command = I/O space, Bus Master */ > > -pci_conf[0x08] = 0x20; /* 0x10 */ /* PCI revision ID; > >=0x20 is for > > 8139C+ */ > > +pci_conf[0x08] = 0x10; /* 0x10 */ /* PCI revision ID; > >=0x20 is for > > 8139C+ */ > > pci_conf[0x0a] = 0x00; /* ethernet network controller */ > > pci_conf[0x0b] = 0x02; > > pci_conf[0x0e] = 0x00; /* header_type */ > > pci_conf[0x3d] = 1;/* interrupt pin 0 */ > > pci_conf[0x34] = 0xdc; > > > > s = &d->rtl8139; > > > > /* I/O handler for memory-mapped I/O */ > > s->rtl8139_mmio_io_addr = > > > > without it using rtl3139 card windows hangs (it don't have > driver for > > ne2000). Perhaps it would be helpful to add a rtl8139old card. > > With patch all is working however saving state and restoring (after > > quitting qemu) cause machine to hangs (mouse do not move, > cursors do not > > blink, remote desktop give timeout but I can see cpu > activity with info > > registers). > > > > bye > > Frediano Ziglio > > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PIT clock count
Hi, we are developing an x86 application that we are testing using qemu and are having some issues with the PIT clock count. We are using PIT clock count as a reference to measure cpu frequency: wait_wrap() a=read_current_cycles() wait_wrap() b=read_current_cycles() calculate_freq(a,b)... The problem is that when running in qemu it sometimes "loops twice" in the wrap wait, thus reporting twice the cycles. The same problem occurs whether I am running 100Hz or 1000Hz. Is this a known bug? And is there any solution? I recall I have seen similar problems with VMWare and Linux. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm: Make commandline args available to semihosting
Hello list, ARM ADS/RVCT compiler generated executables by default use "semihosting" to communicate with the host, including retrieval of a commandline. The semihosting implementation up to now did not implement this functionality; this patch adds the SYS_GET_CMDLINE semihosting call, such that semihosting executables get a command line when executed through qemu-arm. This is a reworked patch an earlier version of which can be found at http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00323.html . The old version contained a bug which effectively limited the commandline to 128 bytes. (quoted from that earlier mail:) The patch below implements the SYS_GET_CMDLINE semihosting call, by keeping a global pointer to the user space commandline arguments, and by re-building a space-separated command line in the guest side supplied buffer. This patch has two shortcomings, which I would love to see feedback on: - I am keeping a global pointer in order to have a handle on the command line arguments inside do_arm_semihosting. Is there a better place to keep this? - The ARM (guest) side supplied buffer is only 256 bytes long; if the user supplied command line is larger, the semihosting call will fail (gracefully). A better strategy may be to build the string on the initial guest stack (similar to loader_build_argptgr()) and then hand that pointer to the guest. I am not quite sure whether the ARGS[] array should be locked before access (then again, none of the functions in do_arm_semihosting() do this). This is tested with both big- and littleendian emulation (i.e. qemu-arm and qemu-armeb). All comments welcome. -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH arm_semihosting_commandline.diff Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] telnet IAC options and simplified tcp & udp options
This patch simplifies the syntax of the tcp and udp options, as well as
adding the telnet protocol.
signed-off-by: [EMAIL PROTECTED]
Jason.
Index: qemu/vl.c
===
--- qemu.orig/vl.c
+++ qemu/vl.c
@@ -2203,16 +2203,16 @@ static void udp_chr_add_read_handler(Cha
}
int parse_host_port(struct sockaddr_in *saddr, const char *str);
+int parse_host_src_port(struct sockaddr_in *haddr,
+struct sockaddr_in *saddr,
+const char *str);
CharDriverState *qemu_chr_open_udp(const char *def)
{
CharDriverState *chr = NULL;
NetCharDriver *s = NULL;
int fd = -1;
-int con_type;
-struct sockaddr_in addr;
-const char *p, *r;
-int port;
+struct sockaddr_in saddr;
chr = qemu_mallocz(sizeof(CharDriverState));
if (!chr)
@@ -2227,58 +2227,12 @@ CharDriverState *qemu_chr_open_udp(const
goto return_err;
}
-/* There are three types of port definitions
- * 1) udp:remote_port
- *Juse use 0.0.0.0 for the IP and send to remote
- * 2) udp:remote_host:port
- *Use a IP and send traffic to remote
- * 3) udp:local_port:remote_host:remote_port
- *Use local_port as the originator + #2
- */
-con_type = 0;
-p = def;
-while ((p = strchr(p, ':'))) {
-p++;
-con_type++;
-}
-
-p = def;
-memset(&addr,0,sizeof(addr));
-addr.sin_family = AF_INET;
-addr.sin_addr.s_addr = htonl(INADDR_ANY);
-s->daddr.sin_family = AF_INET;
-s->daddr.sin_addr.s_addr = htonl(INADDR_ANY);
-
-switch (con_type) {
-case 0:
-port = strtol(p, (char **)&r, 0);
-if (r == p) {
-fprintf(stderr, "Error parsing port number\n");
-goto return_err;
-}
-s->daddr.sin_port = htons((short)port);
-break;
-case 2:
-port = strtol(p, (char **)&r, 0);
-if (r == p) {
-fprintf(stderr, "Error parsing port number\n");
-goto return_err;
-}
-addr.sin_port = htons((short)port);
-p = r + 1;
-/* Fall through to case 1 now that we have the local port */
-case 1:
-if (parse_host_port(&s->daddr, p) < 0) {
-fprintf(stderr, "Error parsing host name and port\n");
-goto return_err;
-}
-break;
-default:
-fprintf(stderr, "Too many ':' characters\n");
-goto return_err;
+if (parse_host_src_port(&s->daddr, &saddr, def) < 0) {
+printf("Could not parse: %s\n", def);
+goto return_err;
}
-if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0)
+if (bind(fd, (struct sockaddr *)&saddr, sizeof(saddr)) < 0)
{
perror("bind");
goto return_err;
@@ -2312,6 +2266,7 @@ typedef struct {
int fd, listen_fd;
int connected;
int max_size;
+int do_telnetopt;
} TCPCharDriver;
static void tcp_chr_accept(void *opaque);
@@ -2337,6 +2292,56 @@ static int tcp_chr_read_poll(void *opaqu
return s->max_size;
}
+#define IAC 255
+#define IAC_BREAK 243
+static void tcp_chr_process_IAC_bytes(CharDriverState *chr,
+ TCPCharDriver *s,
+ char *buf, int *size)
+{
+/* Handle any telnet client's basic IAC options to satisfy char by
+ * char mode with no echo. All IAC options will be removed from
+ * the buf and the do_telnetopt variable will be used to track the
+ * state of the width of the IAC information.
+ *
+ * IAC commands come in sets of 3 bytes with the exception of the
+ * "IAC BREAK" command and the double IAC.
+ */
+
+int i;
+int j = 0;
+
+for (i = 0; i < *size; i++) {
+if (s->do_telnetopt > 1) {
+if ((unsigned char)buf[i] == IAC && s->do_telnetopt == 2) {
+/* Double IAC means send an IAC */
+if (j != i)
+buf[j] = buf[i];
+j++;
+s->do_telnetopt = 1;
+} else {
+if ((unsigned char)buf[i] == IAC_BREAK && s->do_telnetopt ==
2) {
+/* Handle IAC break commands by sending a serial break */
+chr->chr_event(s->fd_opaque, CHR_EVENT_BREAK);
+s->do_telnetopt++;
+}
+s->do_telnetopt++;
+}
+if (s->do_telnetopt >= 4) {
+s->do_telnetopt = 1;
+}
+} else {
+if ((unsigned char)buf[i] == IAC) {
+s->do_telnetopt = 2;
+} else {
+if (j != i)
+buf[j] = buf[i];
+j++;
+}
+}
+}
+*size = j;
+}
+
static void tcp_chr_read(void *opaque)
{
CharDriverState *chr = opaque;
@@ -2360
MIPS instruction set configuration, was: Re: [Qemu-devel] Pending MIPS patches
Fabrice Bellard wrote: 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html Same remark. These are NEC VR54xx specific extensions to the MIPS instruction set. They are used if you use GCC's -march=vr5400 option. See www.necelam.com/docs/files/1375_V2.pdf as well. Can you add some kind of define or dynamic processor definnition in your patch so that we can keep track of the exact instruction set ? Yes, I will update the patch. Any ideas or proposals from anybody how to do this the best way? Are there already examples from other architectures? I think a define to be able to completely select/unselect it at compile time combined with possibility for dynamic runtime selection would be the best? Regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: MIPS instruction set configuration
On Tue, 27 Jun 2006, Dirk Behme wrote: Fabrice Bellard wrote: 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html Same remark. These are NEC VR54xx specific extensions to the MIPS instruction set. They are used if you use GCC's -march=vr5400 option. See www.necelam.com/docs/files/1375_V2.pdf as well. Can you add some kind of define or dynamic processor definnition in your patch so that we can keep track of the exact instruction set ? Yes, I will update the patch. Any ideas or proposals from anybody how to do this the best way? Are there already examples from other architectures? I think a define to be able to completely select/unselect it at compile time combined with possibility for dynamic runtime selection would be the best? I'm trying to make sense of a compile-time switch -- for the use to select you vr5400 based platform, I can't think of anything else than a new -M option (ie. a new machine definition). So the full set of possible insns must be present and be available depending on the machine (-M ...) at runtime. Or is it possible to compile qemu for a specific "-M machine"? Regards, Marius -- Marius Groeger <[EMAIL PROTECTED]> SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Windows Vista D0000144
Numerous people successfully installed vista on qemu. I'm able to bootstrap (pass the ACPI test),and do most of the installation, but I still get the d144 error message.1) Someone had reported that they where able to pass this point, could you share your configuration? 2) What is the error d144 exactly, is an ide.c problem?My configuration:virtual machine:memory 512hda 20GB rawcdrom isooptions -win2k-hack and without-- Marco ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/06/27 21:02:43 Modified files: . : vl.c qemu-doc.texi Log message: telnet protocol and more consistent syntax (Jason Wessel) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.196&r2=1.197 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.97&r2=1.98 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/linux-user main.c signal.c syscall.c sysca...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/06/27 21:08:10 Modified files: linux-user : main.c signal.c syscall.c syscall_defs.h Log message: initial MIPS signal handling (initial patch by Raphael Rigo) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.89&r2=1.90 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.31&r2=1.32 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.74&r2=1.75 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemu&r1=1.27&r2=1.28 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: MIPS instruction set configuration
Marius Groeger wrote: On Tue, 27 Jun 2006, Dirk Behme wrote: Fabrice Bellard wrote: 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html Same remark. These are NEC VR54xx specific extensions to the MIPS instruction set. They are used if you use GCC's -march=vr5400 option. See www.necelam.com/docs/files/1375_V2.pdf as well. Can you add some kind of define or dynamic processor definnition in your patch so that we can keep track of the exact instruction set ? Yes, I will update the patch. Any ideas or proposals from anybody how to do this the best way? Are there already examples from other architectures? I think a define to be able to completely select/unselect it at compile time combined with possibility for dynamic runtime selection would be the best? I'm trying to make sense of a compile-time switch -- for the use to select you vr5400 based platform, I can't think of anything else than a new -M option (ie. a new machine definition). So the full set of possible insns must be present and be available depending on the machine (-M ...) at runtime. Or is it possible to compile qemu for a specific "-M machine"? You should add a runtime selection system : see the ARM and PowerPC targets (I would prefer a parameter to cpu_init(). It was not done that way on PowerPC for legacy reasons). Each machine should be able to select the processor it needs (and allow the user to change it if needed, but it is not the main point). There is no good reason to make the selection at compile time because the translator can efficiently handle any CPU differences at runtime. Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pending MIPS patches
Hi, Another task to improve mips-user and the other QEMU user targets would be to properly define the errno values (use the TARGET_ prefix) and to use them at the appropriate places. A header "errno-generic.h" could be used for most targets and specific targets (such as mips) could add a errno.h in their directory. Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pending MIPS patches
Raphaël Rigo wrote: Dirk Behme wrote: Hi Raphaël, maybe you find some time and like to answer to Fabrice's remark regarding patch 8 below? http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00419.html Would be nice to get as many of the pending MIPS patches applied as possible. Many thanks Dirk Fabrice Bellard wrote: Pending MIPS patches (bugs & improvements): === 8. [PATCH] Add mips-user signal handling http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00319.html OK. Need to check the handling of "env->PC += 4" in linux-user/main.c. I want to be sure there is not a better solution. Adding setup_rt_frame would be good too. Hello, there are 2 possibilities to handle this env->PC += 4: -do a special case wrapper here to avoid increasing PC when it's a sigreturn. -in do_sigreturn set PC with a -4 offset. I chose the first way because I thought it would be cleaner, if anyone was to change this part of the code, then it would be clear that sigreturn directly sets PC. Using the 2nd possibility, one could change this += 4 without knowing do_sigreturn would be affected. I also checked if we could get rid of this weird piece of code, but could not find a clear way to do so. So i preferred maintainability over efficiency, but if you think setting PC with an offset of -4 in signal.c is better, tell me and i will update the patch. There is another simpler solution and I applied it. BTW, the Linux kernel uses the same solution :-) Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Make -std-vga the default?
I've been using -std-vga for a couple of weeks now, and it works well at least for the guests I've been using (Win2K/XP, Red Hat 9, SuSE 10.1). Overall it seems to work much better than the default 5446 simulation and it seems to me that non-developer users, who are presumably the larger fraction of the user base, would benefit from having -std-vga as the default. The "it just works" property is important for new users, and -std-vga has more of that than the 5446 just at the moment. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Make -std-vga the default?
On Wednesday 28 June 2006 02:21, Julian Seward wrote: > I've been using -std-vga for a couple of weeks now, and it works well > at least for the guests I've been using (Win2K/XP, Red Hat 9, SuSE 10.1). Really? My win2k install couldn't do anything useful with -std-vga. It would only do the very basic 640x480x4 mode. I'm fairly sure win9x can't do anything useful with straight VGA either. > Overall it seems to work much better than the default 5446 simulation > and it seems to me that non-developer users, who are presumably the larger > fraction of the user base, would benefit from having -std-vga as the > default. The "it just works" property is important for new users, and > -std-vga has more of that than the 5446 just at the moment. In my experience the Cirrus emulation "just works", and is supported by pretty much every OS out the box. AFAIK Windows earlier than XP doesn't needs additional 3rd party drivers to support anonymous VESA hardware. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
