Hi,
On Mon, 4 Feb 2008, Asheesh Laroia wrote:
> Booting that resulted in a virtual machine that, as I had hoped, used
> 10.0.3.15 and could therefore successfully talk to my 10.0.2.x IPs on
> the LAN. I've attached a 'cvs diff' against HEAD that results from the
> above command.
And the next
Mmm, actually, shouldn't qemu use a more "private" network like a
RFC1918 172.16.0.0/12 network?
(see http://www.ucam.org/cam-grin/)
Samuel
You can always do what I do --- run openvpn between my QEMU sessions and set
up private networks that way ;)
On Feb 4, 2008 4:24 PM, Asheesh Laroia <[EMAIL PROTECTED]> wrote:
> I'm running qemu (really, KVM) in a LAN that uses 10.0.2.x as the IP
> address block for workstations. So naturally whe
I'm running qemu (really, KVM) in a LAN that uses 10.0.2.x as the IP
address block for workstations. So naturally when I booted a guest, it
couldn't access machines inside the LAN.
I tried the simplest thing that could possibly work:
[EMAIL PROTECTED]:~/dnlds/qemu/qemu $ replace 10.0.
Am 04.02.2008 um 00:41 schrieb Dean Payne:
Andreas Färber wrote:
Hello,
When running `qemu-img convert haikuware.vmdk -O qcow2
haikuware.qcow2` on OSX, it complains it cannot open '-O'.
According to `qemu-img convert --help` my syntax is correct.
Andreas
I had similar problems and n
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 22:26:57
Modified files:
linux-user : syscall.c
Log message:
lock_iovec() fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.161&r
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 22:03:16
Modified files:
tcg: tcg.c
Log message:
win32: suppress alloca() warning
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1=1.3&r2
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 22:00:42
Modified files:
. : dyngen.c
Log message:
win32 fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemu&r1=1.60&r2=1.61
On [Mon, 04.02.2008 20:03], Richard Purdie wrote:
> Hi,
>
> OpenEmbedded/Poky use qemu for locale generation when cross compiling.
> When we upgraded to qemu 0.9.1 it started giving locale generation
> errors on all 64 bit machines and some 32 bit ones.
>
> I've traced it to the writev syscall fa
Hi,
OpenEmbedded/Poky use qemu for locale generation when cross compiling.
When we upgraded to qemu 0.9.1 it started giving locale generation
errors on all 64 bit machines and some 32 bit ones.
I've traced it to the writev syscall failing. localedef passes several
{ NULL, 0 } iovec entries which
Solaris has boolean_t defined, so this #ifndef allows hw/e1000.c
to compile on Solaris.
Ben
--- qemu.ORIG/hw/e1000.c2008-02-02 21:20:18.0 -0500
+++ qemu/hw/e1000.c 2008-02-04 10:39:33.097052000 -0500
@@ -28,7 +28,9 @@
#include "net.h"
#define __iomem
+#ifndef __sun__
type
On Mon, 2008-02-04 at 09:33 -0600, Anthony Liguori wrote:
> Izik Eidus wrote:
> > On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
> >
> >> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
> >> fixes a number of type related issues where int's were being used
Izik Eidus wrote:
On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS
Izik Eidus wrote:
Do you recall what this change fixed? As Paul pointed out in IRC, using
the host type here doesn't really fix the problem (target_ulong would be
more appropriate). However, we're both curious what problem it's
actually fixing since sign extending the int should just work.
Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this p
On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been. It also introduces CMOS support so the BIOS can build
> the
Hi Soren,
Soren Hansen wrote:
These need to move into VGA_STATE_COMMON instead. Otherwise vmware_vga
will get confoozled becuase it relies on vga.c for its vesa
implementation. The patch is at:
http://people.ubuntu.com/~soren/0001-Move-common-VGAState-attributes-to-VGA_STATE_COMMON.pat
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
This patch hasn't chan
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be
very unreliably because of startup timing issues. By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.
Since v1, I've incorporated Fabrice's feedback so this is now a 1-lin
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this patch, I've moved ram_addr
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
This patch hasn't changed since v1.
diff --git a/hw/acpi.c b/hw/acpi.c
index 2669e4e..e21ded0 100644
--- a/hw/acpi.c
+++ b/h
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has been included since 2.6.20 and supports Intel VT and
AMD-V. Ports are under way for ia64, embedded PowerPC, and s390.
This set of patches provide basic support for KVM in QEMU. It does not include
Stuart Brady wrote:
> Hi,
>
> I've noticed that "@ref{...}" commands aren't handled properly in the
> qemu man page -- you can see @ref{pcsys_monitor}, @ref{vnc_security} and
> @ref{pcsys_keys} in the output. I'm not sure what the correct fix for
> this is -- any thoughts?
texi2pod.pl fails to
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 08/02/04 14:47:50
Modified files:
. : texi2pod.pl
Log message:
Update texi2pod.pl.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/texi2pod.pl?cvsroot=qemu&r1=1.2&r2=1.3
On Fri, Feb 01, 2008 at 04:12:01PM -0600, Anthony Liguori wrote:
> Index: qemu/hw/vga_int.h
> ===
> --- qemu.orig/hw/vga_int.h2008-02-01 15:23:45.0 -0600
> +++ qemu/hw/vga_int.h 2008-02-01 15:29:04.0 -0600
> @@ -145
Hi,
I've noticed that "@ref{...}" commands aren't handled properly in the
qemu man page -- you can see @ref{pcsys_monitor}, @ref{vnc_security} and
@ref{pcsys_keys} in the output. I'm not sure what the correct fix for
this is -- any thoughts?
Cheers,
--
Stuart Brady
The following patch fixes a typo in drive_init().
Cheers,
--
Stuart Brady
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.403
diff -u -r1.403 vl.c
--- vl.c3 Feb 2008 03:45:47 - 1.403
+++ v
Hello,
Any DOS game that I've tried eventually hangs the QEMU. GDB shows that QEMU is
running in infinite loop in translated basic block and does not respond to any
keyboard or mouse events. It looks like all events got lost and guest is
waiting for timer update, while SDL is not getting its ke
On Sun, 2008-02-03 at 19:56 -0600, Anthony Liguori wrote:
> Hi Izik,
Hi
>
> Anthony Liguori wrote:
> > Index: qemu/cpu-all.h
> > ===
> > --- qemu.orig/cpu-all.h 2008-02-01 15:24:45.0 -0600
> > +++ qemu/cpu-all.h 2008-0
29 matches
Mail list logo
