Any confirmations from OS X users that this patch works OK with CVS
version of QEMU?
Thanks,
Hetz
On 5/10/05, Jason Brittain <[EMAIL PROTECTED]> wrote:
> On December 14th, 2004 Hans Fuchs wrote:
> > Hello
> >
> > Here is a patch
> >
> > http://www-user.rhrk.uni-kl.de/~nissler/tuntap/qemu_tap_os_
On December 14th, 2004 Hans Fuchs wrote:
Hello
Here is a patch
http://www-user.rhrk.uni-kl.de/~nissler/tuntap/qemu_tap_os_x.patch
it adds tun/tap support to osx.
Best,
Hans
I don't own a macosx machine, but others around me do, and they want to run
qemu. The above patch comes from this page:
h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I guess
> the question is whether it's possible for the hardware to tell Windows
> 2000 to shut down?
The answer is YES FOR SURE.
If you press the power button the system cleanly shut down.
The question is: which is the event generated by the power
You're welcome Ryan. Glad you like it.
As to your other option, it is already the case that the APM bios sends
the shutdown command to Qemu by out'ing bytes to a special port, so I
imagine it would be possible for Qemu to send commands to the APM bios
in a similar fashion. But, can the APM bios
On Monday 09 May 2005 01:26 pm, Juergen Lock wrote:
> On Mon, May 09, 2005 at 10:37:04AM -0400, Leonardo E. Reiter wrote:
> > We have seen problems on the AMD64 with -user-net as well. While
> > we have not been able to debug further yet, I suspect what is
> > happening is that some 32-bit values
This looks great -- thanks!
I suppose one other option that would be kind of neat is if closing
Qemu could somehow signal the Windows 2000 guest to shut down. Someone
had suggested that earlier in the thread, but it sounded like that
would require ACPI support in Qemu? Or is it something that cou
On Mon, 9 May 2005 19:26:33 +0200, Juergen Lock wrote
> There are a few cases of `long' being used when apparently (u)
> int32_t was meant. Not sure i catched them all, but try this patch:
> (Unfortunately I don't have an amd64 box here so I cant test it
> myself...)
I can try it later (4 to 5
On Mon, May 09, 2005 at 10:37:04AM -0400, Leonardo E. Reiter wrote:
> We have seen problems on the AMD64 with -user-net as well. While we
> have not been able to debug further yet, I suspect what is happening is
> that some 32-bit values in packet headers that SLIRP is decoding are
> actually r
On Mon, 09 May 2005 11:50:09 -0400, Leonardo E. Reiter wrote
> correctly and detects it as a DHCP/BOOTP request. You might want to
> also study slirp/ip.h and slirp/udp.h to make sure all the values
> are represented in the correct bit length.
If you have this problem too I will try to fix 64-b
On Mon, 9 May 2005 17:19:57 +0200, Adrian Smarzewski wrote
> If you need some help... I'm a programmer and I have amd64 machine.
> I don't know anything about user-network code and don't have a lot
> of time but It's important for me to have a qemu networking. Just write
> me what to do.
I will lo
Adrian,
we will be working on this shortly. In the meantime, where I would
start is by putting a breakpoint in udp_input() in the file slirp/udp.c,
and following the flow until it calls bootp_input(). If it gets that
far, it means it's probably decoding the UDP packet correctly and
detects it
On Mon, 09 May 2005 10:37:04 -0400, Leonardo E. Reiter wrote
> We have seen problems on the AMD64 with -user-net as well. While we
> have not been able to debug further yet, I suspect what is happening
> is that some 32-bit values in packet headers that SLIRP is decoding
> are actually represen
@Nicholas
Just to make sure, I'll be sending you off-list a "tiny" 2.6.10 kernel with
a minimalistic embedded initramfs. It's quite small (<600k),
just to check qemu is working fine.
To use it, just do (tested with mingw/qemu-0.7.0):
qemu-img create -f qcow hda.img 32M
qemu -L . -hda hda.img -ker
We have seen problems on the AMD64 with -user-net as well. While we
have not been able to debug further yet, I suspect what is happening is
that some 32-bit values in packet headers that SLIRP is decoding are
actually represented as 64-bit types on 64-bit processors. Again, this
is just a gue
On Monday 09 May 2005 10:09, Ian Rogers wrote:
> Hi,
>
> I recently spent some effort working out what Separate Kernel Address
> Space (SKAS) did for user-mode-linux (UML). The results of this keen be
> seen here:
>
> http://news.gmane.org/group/gmane.linux.uml.devel/last=/force_load=t
> on the thr
Paul Brook wrote:
For user-mode emulation the largest chunk of address space is the translated
code buffer. This needs to be able to directly address the guest memory
space, so sharing a VM with the host qemu process isn't really a problem. We
just map the host qemu out of the way somewhere. Thi
> On Sun, 8 May 2005, Der Herr Hofrat wrote:
>
> >> it's ok with me on a XP host and running linux 2.6.10 with either
> >> -kernel option (remember you need an -hda too) and inside an iso.
> >>
> >> It also works inside a -fda too.
> >>
> >> What is your exact cmd line ?
> >>
> >
> > qemu -nograph
Hi,
I recently spent some effort working out what Separate Kernel Address
Space (SKAS) did for user-mode-linux (UML). The results of this keen be
seen here:
http://news.gmane.org/group/gmane.linux.uml.devel/last=/force_load=t
on the thread "Using SKAS, any examples?"
the conclusion to this is th
Hi,
On Monday 09 May 2005 07:04, Filip Navara wrote:
>
> Let me guess ... you're using GCC 3.4.x, right? To compile QEMU with
> MinGW you need to use GCC 3.3.x, otherwise op.c will get overoptimized
> and QEMU can't handle that...
Oh, yes, I check and find my cross-tools i386-mingw32msvc is gcc
Cai Qiang wrote:
[snip]
I has also worked on serial port support for windows host, but my build of
qemu always crash, althrough I have tried different method: cross-compile
using i386-mingw32msvc; mingw/msys. If anyone who has build qemu windows
port can teach me about it, I will try to finish
20 matches
Mail list logo
