Hi,
I am using qemu to boot minix 3.1.2a.
I am using following versions,
qemu -> qemu-0.8.1-i386 (pre compiled)
kqemu -> kqemu-1.3.0pre9 (compiled using gcc version 4.1.0 SUSE Linux )
linux-kernel -> 2.6.16.13-4-bigsmp
Messages after inserting kqemu module,
--
On Tue, 11 Jul 2006, Fabrice Bellard wrote:
Hi malc,
In fact I am already working on the issue. My solution is different and it
seems to work too.
Great news, i don't particulary like mine (mainly because of requiring
CAP_SYS_RAWIO and ioperm working only on <0x3ff ports), but i had an
idle
Hi malc,
In fact I am already working on the issue. My solution is different and
it seems to work too.
Fabrice.
malc wrote:
Hello,
Attached is a patch that implements non-rdtsc based[1] clock source.
Gotchas:
1. Only works on Linux
2. Only works on i386 Linux
3. Only works on i386 Linux wi
Hello,
Attached is a patch that implements non-rdtsc based[1] clock source.
Gotchas:
1. Only works on Linux
2. Only works on i386 Linux
3. Only works on i386 Linux with ACPI enabled
4. Requires root privileges (though they will be dropped)
Perhaps this will be useful to someone.
--
mailto:[EMA
I'm fairly surprised user emulation works at all for 64-bit targets. I'm
fairly sure that code isn't even remotely 64-bit safe.
On a 32-bit host, a write() from 64-bit program succeeds because the data
happens to lie below 4G. I don't know if this can be guaranteed in every
case, but then syst
On Tuesday 11 July 2006 20:46, Blue Swirl wrote:
> I got a statically linked trivial program (hello, world) execute on a x86
> host. More complex programs expose bugs in the Sparc64 emulation, even the
> dynamic linker uses currently unimplemented VIS instructions.
I'm fairly surprised user emulat
I got a statically linked trivial program (hello, world) execute on a x86
host. More complex programs expose bugs in the Sparc64 emulation, even the
dynamic linker uses currently unimplemented VIS instructions.
_
Express yourself i
I'm not sure about LZMA, but I'd really like to see this experiment
done with LZO. The compression/decompression speeds of LZO are
fantastic, and I really don't care to shave off every bit of
compressible information as long as it doesn't impact performance as
hard as cqcow does.
There will natur
Oliver Gerlich wrote:
> Personally, I'd be interested to have a GUI for controlling a running
> Qemu instance: change CD-ROM, add/remove USB devices, save/restore VM
> snapshots (though this would also require to save/restore disk
> snapshots), and eg. provide buttons to switch between guest Virtu
Linas Žvirblis wrote:
Jason Gress wrote:
I know this is a lot different than the discussion so far, but has anyone
considered keeping SDL and using an SDL GUI similar to ZSNES?
I did not check the source code, but it looks just like any other
self-made bitmap-based SDL menu I have seen. It
Jason Gress wrote:
> I know this is a lot different than the discussion so far, but has anyone
> considered keeping SDL and using an SDL GUI similar to ZSNES?
I did not check the source code, but it looks just like any other
self-made bitmap-based SDL menu I have seen. It is like inventing yet
a
I know this is a lot different than the discussion so far, but has anyone
considered keeping SDL and using an SDL GUI similar to ZSNES? Take a look
(for those not familiar) at http://www.zsnes.com and grab a download. Many
Linux distro package managers have it also. You don't need a SNES ROM
ok, I did this experiment (long and painful).
a XP2003/SP1 qemu guest required 964,231,168 bytes qcow image.
zlib qcow image became 459,686,368 bytes.
lzma estimation (4k clusters) is 437,038,838 bytes.
Yes, 5% are still gained, but the time to get the lzma'ed qcow is
disastrous (especially on s
John R. wrote:
> On 7/8/06, Oliver Gerlich <[EMAIL PROTECTED]> wrote:
>
>> Is wxC still under active development? The CVS version seems to be quite
>> old, and I also couldn't find any documentation.
>>
>
> Well it wouldn't be the first unmaintained batch of code added to
> QEMU... Slirp is the exa
Fabrice Bellard wrote:
It seems to be a host kernel problem.
It is a host kernel problem. The kernel does not save/restore the config of the periodic interrupt
timer over a suspend/resume cycle. I'm having a cursory look into it.
Brad
--
"Human beings, who are almost unique in having the ab
15 matches
Mail list logo
