RE: [Qemu-devel] Mac as Host
Hi, I'm new to the list, so forgive me if this has been asked before... Has anyone thought of adjusting Qemu to be a Virtualiser rather than an emulator? Or a combination of both? This would allow a Linux host to run Windows at 95% speed? Or from my point of view allow the new OS X (x86) Host to run a Windows client? Jon -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Michael FisherSent: 14 January 2006 19:16To: qemu-devel@nongnu.orgSubject: [Qemu-devel] Mac as Host I am wondering if Apple's switch over to Intel will make it easier or harder to use a Mac as host using qemu? Also, what about the Mac OS's as guest?Any thought?desNotes == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] problem with vvfat and plan9
> > cannot add sdC1!dos [63,966798) to disk [0,966735): partition boundaries > > out of range > > Note that the difference of the larger numbers is exactly 63... > > It might be fixed by replacing the line > > s->sector_count=0xec04f; > > with > > s->sector_count=0xec04f - 63; > > in block-vvfat.c, but I can't tell all the implications right now. If you > feel lucky, you can try it, but I'll have a look anyway. I have tested this little fix with plan9 and now it works. I have found no errors e.g. with Linux or so in qemu. Looks like it is working correctly. Then I have tried to test the :rw: with plan9, but nothing is written into the host filesystem. I have enabled debug in vvfat and there I see that the newly created file in plan9 mounted vvfat-drive is shown in the log. But I do not see the commit message which in the log is shown if I try with linux. Jens ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] ne2000 did not save rxcr in state file
Hi,
as I promised I will send QEMU patches even if I don't know about QEMU's patch
policy ... Here a very simple one:
Index: hw/ne2000.c
===
RCS file: /home/Cvsroot/qemu/hw/ne2000.c,v
retrieving revision 1.1.1.1
diff -B -b -U3 -r1.1.1.1 ne2000.c
--- hw/ne2000.c 14 Jan 2006 13:19:59 - 1.1.1.1
+++ hw/ne2000.c 16 Jan 2006 10:10:12 -
@@ -643,7 +643,9 @@
{
NE2000State* s=(NE2000State*)opaque;
- qemu_put_8s(f, &s->cmd);
+ qemu_put_8s(f, &s->rxcr); // version 2
+
+ qemu_put_8s(f, &s->cmd); // version 1 ...
qemu_put_be32s(f, &s->start);
qemu_put_be32s(f, &s->stop);
qemu_put_8s(f, &s->boundary);
@@ -667,7 +669,9 @@
{
NE2000State* s=(NE2000State*)opaque;
- if (version_id != 1)
+ if (version_id == 2)
+ qemu_get_8s(f, &s->rxcr);
+ else if (version_id != 1)
return -EINVAL;
qemu_get_8s(f, &s->cmd);
@@ -726,7 +730,7 @@
s->macaddr[4],
s->macaddr[5]);
-register_savevm("ne2000", 0, 1, ne2000_save, ne2000_load, s);
+register_savevm("ne2000", 0, 2, ne2000_save, ne2000_load, s);
}
This patch is not yet enough to make win2003 happy after a "loadvm" but
it fixes an existing bug.
Yours Jürgen
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [HACK] Demo for higher speed on large display (cirrus_vga)
Hello,
although I will integrate this into my patchset this not a proposed patch
for qemu. This hack just shows that the current implementation of updating
the emulated screen is inefficient and needs improvements.
(1) 1280 px width does not work well (16 bit only) - too slow to be usefull
(2) 1024 px width for 24 bit gets faster by this patch, all other modes
are not accelerated.
IMPROVEMENT:
- the original code almost always updates whole lines (e.g. the whole screen
width). This even happens if you move the mouse.
- this code monitors the min/max horizontal limits to reduce the updated
area.
- as a side-effect the code optimises the idle cpu time requirement (qemu
checks every 30ms for screen updates).
TIPS:
- You can compile cirrus_vga.c with -O3 (but not the remainder of qemu!)
- In win2003 enable full hw acceleration and disable write combining.
KNOWN PROBLEMS:
(a) for this hack: it is ugly but IT WORKS (1024 px 24 bit only).
(b) other: when you try to change the screen resolution from inside win
2003 the display might get garbeld - but you can still read it. You
must reboot windows to get a correct display. THIS IS NOT A PROBLEM
OF THIS PATCH.
I hope that some genius will do a much nicer patch that fixes also problem
(b). Would be nice if a way could be found to support 1280x1024 with 24
bits. The cirrus emulator itself is quite cool.
Yours Jürgen
Index: hw/cirrus_vga.c
===
RCS file: /home/Cvsroot/qemu/hw/cirrus_vga.c,v
retrieving revision 1.1.1.1
diff -B -b -U3 -r1.1.1.1 cirrus_vga.c
--- hw/cirrus_vga.c 14 Jan 2006 13:19:59 - 1.1.1.1
+++ hw/cirrus_vga.c 16 Jan 2006 10:10:02 -
@@ -579,6 +579,20 @@
}
}
+// VGA speed hack -
+static inline void my_physical_memory_set_dirty(uint32_t uaddr)
+{
+if(vga_dirty_left != 0x) { // only for 1024 pix width!
+int jx = uaddr % 3072; // pixel*3 - will divide later
+if(jx < vga_dirty_left)
+ vga_dirty_left = jx;
+else if(jx > vga_dirty_right)
+ vga_dirty_right = jx;
+}
+cpu_physical_memory_set_dirty(uaddr);
+}
+// -
+
static void cirrus_invalidate_region(CirrusVGAState * s, int off_begin,
int off_pitch, int bytesperline,
int lines)
@@ -587,6 +601,17 @@
int off_cur;
int off_cur_end;
+// VGA speed hack -
+if(vga_dirty_left != 0x) { // only for 1024 pix width!
+int jx = off_begin % 3072; // pixel*3 - will divide later
+if(off_pitch < 0)
+jx -= bytesperline - 3;
+if(jx < vga_dirty_left) vga_dirty_left = jx;
+jx += bytesperline - 3;
+if(jx > vga_dirty_right) vga_dirty_right = jx;
+}
+// -
+
for (y = 0; y < lines; y++) {
off_cur = off_begin;
off_cur_end = off_cur + bytesperline;
@@ -1787,8 +1812,8 @@
val <<= 1;
dst++;
}
-cpu_physical_memory_set_dirty(s->vram_offset + offset);
-cpu_physical_memory_set_dirty(s->vram_offset + offset + 7);
+my_physical_memory_set_dirty(s->vram_offset + offset);
+my_physical_memory_set_dirty(s->vram_offset + offset + 7);
}
static void cirrus_mem_writeb_mode4and5_16bpp(CirrusVGAState * s,
@@ -1812,8 +1837,8 @@
val <<= 1;
dst += 2;
}
-cpu_physical_memory_set_dirty(s->vram_offset + offset);
-cpu_physical_memory_set_dirty(s->vram_offset + offset + 15);
+my_physical_memory_set_dirty(s->vram_offset + offset);
+my_physical_memory_set_dirty(s->vram_offset + offset + 15);
}
/***
@@ -1933,7 +1958,7 @@
mode = s->gr[0x05] & 0x7;
if (mode < 4 || mode > 5 || ((s->gr[0x0B] & 0x4) == 0)) {
*(s->vram_ptr + bank_offset) = mem_value;
- cpu_physical_memory_set_dirty(s->vram_offset +
+my_physical_memory_set_dirty(s->vram_offset +
bank_offset);
} else {
if ((s->gr[0x0B] & 0x14) != 0x14) {
@@ -2262,7 +2287,7 @@
mode = s->gr[0x05] & 0x7;
if (mode < 4 || mode > 5 || ((s->gr[0x0B] & 0x4) == 0)) {
*(s->vram_ptr + addr) = (uint8_t) val;
- cpu_physical_memory_set_dirty(s->vram_offset + addr);
+my_physical_memory_set_dirty(s->vram_offset + addr);
} else {
if ((s->gr[0x0B] & 0x14) != 0x14) {
cirrus_mem_writeb_mode4and5_8bpp(s, mode, addr, val);
@@ -2321,7 +2346,7 @@
addr &= s->cirrus_addr_mask;
*(s->vram_ptr + addr) = val;
-cpu_physical_memory_set_dirty(s->vram_offset + addr);
+my_physical_memory_set_dirty(s->vram_offset + addr);
}
static void cirrus_linear_mem_writew(void *opaque, target_phys_addr_t addr,
@@ -2331,7 +2356,7 @@
addr &= s->cirrus_addr_mask;
cpu_to_le16w((uint16_t *)(s->vram_ptr + addr), val);
-cpu_physical_memory_set_dirty(s->vr
[Qemu-devel] [PATCH] ne2000 did not save rxcr in state file (2nd try)
Hi (on my 1st try some lines at the end of the patch were missing)
as I promised I will send QEMU patches even if I don't know about QEMU's patch
policy ... Here a very simple one:
Index: hw/ne2000.c
===
RCS file: /home/Cvsroot/qemu/hw/ne2000.c,v
retrieving revision 1.1.1.1
diff -B -b -U3 -r1.1.1.1 ne2000.c
--- hw/ne2000.c 14 Jan 2006 13:19:59 - 1.1.1.1
+++ hw/ne2000.c 16 Jan 2006 10:10:12 -
@@ -643,7 +643,9 @@
{
NE2000State* s=(NE2000State*)opaque;
- qemu_put_8s(f, &s->cmd);
+ qemu_put_8s(f, &s->rxcr); // version 2
+
+ qemu_put_8s(f, &s->cmd); // version 1 ...
qemu_put_be32s(f, &s->start);
qemu_put_be32s(f, &s->stop);
qemu_put_8s(f, &s->boundary);
@@ -667,7 +669,9 @@
{
NE2000State* s=(NE2000State*)opaque;
- if (version_id != 1)
+ if (version_id == 2)
+ qemu_get_8s(f, &s->rxcr);
+ else if (version_id != 1)
return -EINVAL;
qemu_get_8s(f, &s->cmd);
@@ -726,7 +730,7 @@
s->macaddr[4],
s->macaddr[5]);
- register_savevm("ne2000", 0, 1, ne2000_save, ne2000_load, s);
+ register_savevm("ne2000", 0, 2, ne2000_save, ne2000_load, s);
}
/***/
@@ -796,7 +800,7 @@
s->macaddr[5]);
/* XXX: instance number ? */
-register_savevm("ne2000", 0, 1, ne2000_save, ne2000_load, s);
+register_savevm("ne2000", 0, 2, ne2000_save, ne2000_load, s);
register_savevm("ne2000_pci", 0, 1, generic_pci_save, generic_pci_load,
&d->dev);
}
This patch is not yet enough to make win2003 happy after a "loadvm" but
it fixes an existing bug.
Yours Jürgen
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac as Host
> Has anyone thought of adjusting Qemu to be a Virtualiser rather than an > emulator? Or a combination of both? This would allow a Linux host to run > Windows at 95% speed? Or from my point of view allow the new OS X (x86) > Host to run a Windows client? http://www.qvm86.org/ Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu - where will it go?
Hi, On Sun, 15 Jan 2006, Fabrice Bellard wrote: > Using legacy apps is clearly an interesting topic for QEMU. With the > improved dynamic translator written by Paul Brook (but not merged yet), > QEMU will be far less dependent of C compiler and porting the dynamic > translator to a new host will still be simple. Just wondering: Deducing from the above, you are willing to merge it... You have any plan as to when? > - VNC server (merge the VNC patch) The big problem remains: How to keep host and guest cursor in sync. Note that I am playing around with a half-working patch to add SummaSketch (Tablet) emulation, and maybe eventually Wacom (since some Linux distros can autodetect it). Maybe even a USB emulation is needed, but I still don't know if Windows/Linux auto-select the absolute positioning. If not, all this is mute. Also, the new LibVNCServer -- due this or next week -- should solve the jinky mouse problem. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] IP mismatch in redirection using user-net dhcp
For some as-yet-unknown reason, the IP assigned by the user-net DHCP server occasionally switches to 10.0.2.16. I suspect this happens while renewing the lease while I'm away, since that would explain why the headless VM is unreachable when I come back on mondays - then when booting with SDL display, I find out the IP is 10.0.2.16. This would not be a problem at all, if the port redirections would know about that, but a tcpdump in the VM shows that my "-redir tcp:10080::10080" is indeed taken as "tcp:10080:10.0.2.15:10080", even though the attributed IP is 10.0.2.16. Not sure how qemu could be taught to do something sensible here, without breaking multi-NIC setups. But with some luck we should not have to bother with it, if only the problem is just that the lease renewal is broken. Bringing the (gentoo/dhcpcd) VM back on its feet seems to require all of the following steps, which is quite error-prone (and time-consuming when a single step is missed;): - "dhcpcd -k", which clears /var/cache/dhcpcd-eth0.cache - removing /var/lib/dhcpc/* - restarting qemu itself so that it forgets about the lease as well Would it make sense to be able to tell qemu "do not ever issue a lease on an IP different from 10.0.2.15", and possibly make that the default for single-NIC VMs ? -- Yann Dirson <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] 1st improvement of serial.c (Modemstatus etc.)
Hello,
as I promised I will send QEMU patches even if I don't know about QEMU's patch
policy ... Here a more complex one:
serial.c (and vl.h):
(1) sending break
(2) outgoing modem state
(3) incomming modem state
(4) CHECK THIS: support to disable interrupts (a PC feature)
in vl.c (and vl.h):
(1) host serial implementation extended
(2) CHECK THIS: post-processing disabled
(3) the if/else cascade for -net was cleaned-up a little
This patch is sufficent for win2003 to detect and support a smartcard reader
like towitoko chipdrive micro.
The driver has still missing features like parity error detection, modem
status change interrupts and 16650 support!
Yours Jürgen
Index: vl.c
===
RCS file: /home/Cvsroot/qemu/vl.c,v
retrieving revision 1.1.1.1
diff -B -b -U3 -r1.1.1.1 vl.c
--- vl.c 14 Jan 2006 13:19:59 - 1.1.1.1
+++ vl.c 15 Jan 2006 20:26:54 -
@@ -1468,9 +1468,11 @@
tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
|INLCR|IGNCR|ICRNL|IXON);
-tty.c_oflag |= OPOST;
+// TODO: OPOST clear or set ?
+//tty.c_oflag |= OPOST;
+tty.c_oflag = 0;
tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
-tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS);
+tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
switch(data_bits) {
default:
case 8:
@@ -1486,6 +1488,11 @@
tty.c_cflag |= CS5;
break;
}
+
+if(stop_bits > 1)
+tty.c_cflag |= CSTOPB;
+tty.c_cflag |= CREAD | CLOCAL;
+
switch(parity) {
default:
case 'N':
@@ -1516,10 +1523,57 @@
case CHR_IOCTL_SERIAL_SET_BREAK:
{
int enable = *(int *)arg;
+#if defined(TIOCSBRK) && !defined(_WIN32)
+// Linux should use TIOCSBRK and TIOCCBRK
+if(ioctl(s->fd_in, enable ? TIOCSBRK : TIOCCBRK) == 0)
+break;
+// don't care about pending interrupt ...
+if(errno == EINTR)
+break;
+perror("CHR_IOCTL_SERIAL_SET_BREAK fallback to tcsendbreak()");
+#endif
+// here arg=1 is used and in the linux tty driver the code is:
+//send_break(tty, arg ? arg*100 : 250);
if (enable)
tcsendbreak(s->fd_in, 1);
}
break;
+
+case CHR_IOCTL_SERIAL_SET_MSTAT:
+#if defined(TIOCMBIS) && !defined(_WIN32)
+{
+int tiomsk = TIOCM_DTR | TIOCM_RTS;
+int tiobit = 0;
+if((*(int *)arg) & CHR_IOCTL_SERIAL_DTR) tiobit |= TIOCM_DTR;
+if((*(int *)arg) & CHR_IOCTL_SERIAL_RTS) tiobit |= TIOCM_RTS;
+
+if(tiobit != 0)
+ioctl(s->fd_in, TIOCMBIS, &tiobit);
+if(tiobit != tiomsk) {
+tiobit = (~tiobit) & tiomsk;
+ioctl(s->fd_in, TIOCMBIC, &tiobit);
+}
+}
+#endif
+break;
+
+case CHR_IOCTL_SERIAL_GET_MSTAT:
+{
+int tiores = -1;
+#if defined(TIOCMGET) && !defined(_WIN32)
+int tiobit;
+if( ioctl(s->fd_in, TIOCMGET, &tiobit) == 0 ) {
+tiores = 0;
+if(tiobit & TIOCM_CTS) tiores |= CHR_IOCTL_SERIAL_CTS;
+if(tiobit & TIOCM_CAR) tiores |= CHR_IOCTL_SERIAL_DCD;
+if(tiobit & TIOCM_RNG) tiores |= CHR_IOCTL_SERIAL_RI;
+if(tiobit & TIOCM_DSR) tiores |= CHR_IOCTL_SERIAL_DSR;
+}
+#endif
+*(int *)arg = tiores;
+}
+break;
+
default:
return -ENOTSUP;
}
@@ -2620,19 +2674,19 @@
nd->vlan = vlan;
nb_nics++;
ret = 0;
-} else
-if (!strcmp(device, "none")) {
+}
+else if (!strcmp(device, "none")) {
/* does nothing. It is needed to signal that no network cards
are wanted */
ret = 0;
-} else
+}
#ifdef CONFIG_SLIRP
-if (!strcmp(device, "user")) {
+else if (!strcmp(device, "user")) {
ret = net_slirp_init(vlan);
-} else
+}
#endif
#ifndef _WIN32
-if (!strcmp(device, "tap")) {
+else if (!strcmp(device, "tap")) {
char ifname[64];
char setup_script[1024];
int fd;
@@ -2648,8 +2702,8 @@
}
ret = net_tap_init(vlan, ifname, setup_script);
}
-} else
-if (!strcmp(device, "socket")) {
+}
+else if (!strcmp(device, "socket")) {
if (get_param_value(buf, sizeof(buf), "fd", p) > 0) {
int fd;
fd = strtol(buf, NULL, 0);
@@ -2666,8 +2720,9 @@
fprintf(stderr, "Unknown socket options: %s\n", p);
return -1;
}
-} else
+}
#endif
+else
{
fprintf(stderr, "Unknown network device: %s\n", device);
return -1;
@@ -3655,7 +3710,7 @@
return 0;
}
-QEMUMachine *find_machine(const char *name)
+static QEMUMachine *find_machine(const char *name)
{
QEMUMachine *m;
@@ -3669,7 +
[Qemu-devel] USB Patches
(It looks like the author forgot to announce his pathces on the mailing list, and just put them on the forum). Anyway, you're invited to see this thread about some new USB patches and comments. http://qemu.dad-answers.com/viewtopic.php?t=704 Thanks, Hetz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu debian etch
Hello all, I'm new with qemu. I install qemu and kqemu by download and compile the sources qemu-0.8.0 and kqemu-0.7.2 on a debian testing I try to install windows xp pro upgrade version (official) , the boot start and after different stages windows ask me to change the cdrom and put a valid version of windows (aka xp home, winme, ect...) I upgrade from my official xp home I switch to the qemu console (ctrl-alt-shift-2) and I run these commands : eject cdrom (and I change the media xp pro by my xp home) change cdrom /dev/cdrom ctrl-alt-shift-1 enter and the install xp tools go back to the same message (the cdrom led still inactive) How can I force the change of the cdrom for xp ? I test this couple of media on a pc test and the install work. I try to copy via dd the two cdrom on my harddrive and launch qemu with the two images, but same: not working When I trie to install a full version of windows xp pro, ok work fine. Can you help me ? Thanks in advance Guy ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Mac as Host
Paul, thanks for the link. That project looks dead. Can't link to the CVS and the page hasn't been updated since March 05. Anyone know of any updated project branch or has the functionality been merged into the main project? Jon -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: 16 January 2006 15:03 To: qemu-devel@nongnu.org Cc: Farina, Jonathan Subject: Re: [Qemu-devel] Mac as Host > Has anyone thought of adjusting Qemu to be a Virtualiser rather than an > emulator? Or a combination of both? This would allow a Linux host to run > Windows at 95% speed? Or from my point of view allow the new OS X (x86) > Host to run a Windows client? http://www.qvm86.org/ Paul == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac as Host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 KQEMU and qvm86 already do that El 16/01/2006, a las 9:31, Farina, Jonathan escribió: Hi, I'm new to the list, so forgive me if this has been asked before... Has anyone thought of adjusting Qemu to be a Virtualiser rather than an emulator? Or a combination of both? This would allow a Linux host to run Windows at 95% speed? Or from my point of view allow the new OS X (x86) Host to run a Windows client? Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Fisher Sent: 14 January 2006 19:16 To: qemu-devel@nongnu.org Subject: [Qemu-devel] Mac as Host I am wondering if Apple's switch over to Intel will make it easier or harder to use a Mac as host using qemu? Also, what about the Mac OS's as guest? Any thought? desNotes == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDy7T8SOHwOb87puQRAoR8AJ9yr+ibgpbsoBFBX8zdkFqmgdHpZQCgzBlN Z64nICUZOzzbwlxU61yNU/c= =0fR6 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu - where will it go?
> Jürgen has stated his desired functionality already. What other "main > uses" are there? (Asked in the hope of further sparking the discussion ;) I use the usermode emulation fairly extensively for cross development/testing. User emulation has three main advantages for our purposes: - It's significantly faster than full system emulation, especially when the target system would be using an NFSroot. - It doesn't rely on a target kernel. These frequently have bugs, especially on the less popular architectures.. - It's much easier to integrate into test harnesses. With binfmt_misc it's mostly transparent. For full system emulation you have to mess about with telnet/rsh. The main downside is that threaded applications don't currently work properly, but that's fixable. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac as Host
On Monday 16 January 2006 15:10, Farina, Jonathan wrote: > Paul, thanks for the link. > > That project looks dead. Can't link to the CVS Huh? CVS works fine here. > and the page hasn't been > updated since March 05. Anyone know of any updated project branch or has > the functionality been merged into the main project? It's been a few months since I did anything with it, but it should still work. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu debian etch
On Mon, 16 Jan 2006, De Leeuw Guy wrote: Hello all, I'm new with qemu. I install qemu and kqemu by download and compile the sources qemu-0.8.0 and kqemu-0.7.2 on a debian testing I try to install windows xp pro upgrade version (official) , the boot start and after different stages windows ask me to change the cdrom and put a valid version of windows (aka xp home, winme, ect...) I upgrade from my official xp home I switch to the qemu console (ctrl-alt-shift-2) and I run these commands : eject cdrom (and I change the media xp pro by my xp home) change cdrom /dev/cdrom ctrl-alt-shift-1 enter and the install xp tools go back to the same message (the cdrom led still inactive) How can I force the change of the cdrom for xp ? I test this couple of media on a pc test and the install work. I try to copy via dd the two cdrom on my harddrive and launch qemu with the two images, but same: not working When I trie to install a full version of windows xp pro, ok work fine. Can you help me ? Linuxs VFS is blissfuly unaware that the physical media has changed and therefore when QEMU tries to read from the fd that corresponds to /dev/cdrom it gets old (cached) data. To workaround you can dump the contents of your physical CDs on disk and install from them. -- mailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Mac as Host
On Mon, Jan 16, 2006 at 03:10:02PM -, Farina, Jonathan wrote: > Paul, thanks for the link. > > That project looks dead. Can't link to the CVS and the page hasn't > been updated since March 05. Anyone know of any updated project > branch or has the functionality been merged into the main project? Did you even look at the same page Paul sent you to? :-) It's active, CVS works fine, and he's the author. -- Daniel Jacobowitz CodeSourcery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Set SO_REUSEADDR at the right time
It looks like qemu (at least version 0.7.2, which is what I'm running
here) doesn't set SO_REUSEADDR before calling bind(), which makes that
fairly useless. This obvious patch moves up setting SO_REUSEADDR to the
right place, just before bind().
Apologies if this is already fixed in 0.8.0.
-- kolya
--- slirp/socket.c.orig 2006-01-16 15:54:40.993024000 -0800
+++ slirp/socket.c 2006-01-16 15:55:06.049849000 -0800
@@ -573,6 +573,7 @@
addr.sin_port = port;
if (((s = socket(AF_INET,SOCK_STREAM,0)) < 0) ||
+ (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) ||
(bind(s,(struct sockaddr *)&addr, sizeof(addr)) < 0) ||
(listen(s,1) < 0)) {
int tmperrno = errno; /* Don't clobber the real reason we
failed */
@@ -587,7 +588,6 @@
#endif
return NULL;
}
- setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char *)&opt,sizeof(int));
setsockopt(s,SOL_SOCKET,SO_OOBINLINE,(char *)&opt,sizeof(int));
getsockname(s,(struct sockaddr *)&addr,&addrlen);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu debian etch
malc a écrit : > On Mon, 16 Jan 2006, De Leeuw Guy wrote: > >> Hello all, >> >> I'm new with qemu. >> I install qemu and kqemu by download and compile the sources >> qemu-0.8.0 and kqemu-0.7.2 on a debian testing >> I try to install windows xp pro upgrade version (official) , the boot >> start and after different stages >> windows ask me to change the cdrom and put a valid version of windows >> (aka xp home, winme, ect...) >> I upgrade from my official xp home >> I switch to the qemu console (ctrl-alt-shift-2) and I run these >> commands : >> eject cdrom (and I change the media xp pro by my xp home) >> change cdrom /dev/cdrom >> ctrl-alt-shift-1 >> enter >> and the install xp tools go back to the same message (the cdrom led >> still inactive) >> How can I force the change of the cdrom for xp ? >> >> I test this couple of media on a pc test and the install work. >> >> I try to copy via dd the two cdrom on my harddrive and launch qemu with >> the two images, but same: not working >> >> When I trie to install a full version of windows xp pro, ok work fine. >> >> >> Can you help me ? > > > Linuxs VFS is blissfuly unaware that the physical media has changed and > therefore when QEMU tries to read from the fd that corresponds to > /dev/cdrom it gets old (cached) data. > > To workaround you can dump the contents of your physical CDs on disk and > install from them. > Thanks, but I try that have you a particular example to process ? Guy ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
