I am going to defend QEMU
I've run a Plan 9 auth/cpu server on there for 8 months or so with no
problems beyond those of my own construction.
I am emulating x86-32 on a pre-VT Opteron AMD-64 (though I only found
out about the difference *after* I bought it) and have kqemu.ko loaded,
I run D
> >> i find there's a certain simplicty in dealing directly
> >> with hardware, provided one has documentation.
> >
> > Provided it is complete and the h/w well designed and
> > interface regular. Unfortunately not all that common.
>
> you continue with this claim without presenting evidence.
On Sat, Jun 14, 2008 at 9:53 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> I don't know how the praise of "excellent" was bestowed on QEMU. It
>> may work well on a x86 emulating an x86 but try something else. It
>> ends in tears.
>>
>
> this isn't a defense of qemu. i don't know enough about i
>> i find there's a certain simplicty in dealing directly
>> with hardware, provided one has documentation.
>
> Provided it is complete and the h/w well designed and
> interface regular. Unfortunately not all that common.
you continue with this claim without presenting evidence.
i respond to th
> I don't know how the praise of "excellent" was bestowed on QEMU. It
> may work well on a x86 emulating an x86 but try something else. It
> ends in tears.
>
this isn't a defense of qemu. i don't know enough about it
to defend it.
however, why is it a requirement that a vm be able to emulate
ot
On Sat, Jun 14, 2008 at 1:58 AM, Bruce Ellis <[EMAIL PROTECTED]> wrote:
> I don't know how the praise of "excellent" was bestowed on QEMU. It
> may work well on a x86 emulating an x86 but try something else. It
> ends in tears.
>
just like opening up an x86 machine and trying to stick a mips
proce
I don't know how the praise of "excellent" was bestowed on QEMU. It
may work well on a x86 emulating an x86 but try something else. It
ends in tears.
brucee
On Fri, 13 Jun 2008 20:39:48 EDT erik quanstrom <[EMAIL PROTECTED]> wrote:
> > On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets
> > 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB
> > from /dev/zero to a file. Neither needs any special drivers.
> >
> > I think part of the
> On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets
> 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB
> from /dev/zero to a file. Neither needs any special drivers.
>
> I think part of the performance problem is qemu emulates an
> early Intel ATA controller chip (PIIX3) and
On Fri, 13 Jun 2008 19:52:22 EDT erik quanstrom <[EMAIL PROTECTED]> wrote:
> > You don't need this sort of code in a virtualizable processor.
> > See for example
> > http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requiremen
> ts
>
> i'm not convinced that the illusion that the v
> Any good recommended lecture to learn about good virtualization?
i think this is an interesting approach. note that some code runs faster
under the vx32 than natively, though the title seems to hint that there
are varying definitions of virtualization.
http://swtch.com/~rsc/papers/vx32-usenix2
On Sat, Jun 14, 2008 at 1:42 AM, Lorenzo Fernando Bivens de la Fuente
> FPGA's are getting cheaper. A friend of mine got a nice Spartan III
> for less than us$50
>
> Clock speeds are still behind the usual ASIC (lack of sleep might
> alter my grammar habilities), but I think they are ok for things
FPGA's are getting cheaper. A friend of mine got a nice Spartan III
for less than us$50
Clock speeds are still behind the usual ASIC (lack of sleep might
alter my grammar habilities), but I think they are ok for things like
a java vm, or a nes emulator...
Years ago I made a picoJava based process
On Fri, 13 Jun 2008 19:26:42 EDT Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
>
> > IMHO a virtualizable processor is the necessary first step as
>
>
> And don't forget the cost of a virtualizer v. the cost of actual
> hardware. Verilog is free,
On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
IMHO a virtualizable processor is the necessary first step as
And don't forget the cost of a virtualizer v. the cost of actual
hardware. Verilog is free, but the device to make it is not. Start
simple:
void
main(int, char *[
On Fri, 13 Jun 2008 21:33:15 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> >perhaps qemu-ide specific drivers need to be done.
> > Many hosted OSs need custom made drivers to
> > be used with a virtualizer.
On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets
18MB/s & plan9/qemu gets 3MB/
Any good recommended lecture to learn about good virtualization?
I imagine that the biggest issue is to avoid a racing condition
between the two(or 'n') running kernels.
Then... Would it be very hard to build an fs that allows to share real
hardware with another kernel running alongside plan 9? I
> the peculiar thing about the modern virtualisers/hypervisors etc is that
> they require specialised drivers but are no easier (often harder) to drive
> than
> actual hardware! it's all gone wrong!
but the blinding performance is ... check that.
- erik
>perhaps qemu-ide specific drivers need to be done.
> Many hosted OSs need custom made drivers to
> be used with a virtualizer.
i must say that my experience with VM/370 was otherwise,
for the standard devices. there were extensions you could access
if you liked, but the basic emulation was solid
> the peculiar thing about the modern virtualisers/hypervisors etc is that
sorry. i meant to write "one peculiar thing ...", because there are others.
In fact it is definetly not a plan9 issue...
If qemu fails hosting plan 9, it affects plan 9 but there is little to
be done unless we communicate with the qemu dev team.
Plan 9 is not the only os having problems with DMA access through
qemu. I am myself a moron... All I know is that the issue exis
> Everything, in my experience, crashes QEMU. Nice try.
> Just the opinion of me and my dog (who barks loudly when I shout
> f**king QEMU - piece of f**king sh*t!).
I have used qemu/freebsd for the past 4 years or so. On the
whole it has worked quite well. I often use plan9, Windows
2000 and fre
I am experiencing crashes here too. QEMU 0.9.1 with and without
kqemu, using qcow2, on Linux 2.6.24. I have built QEMU from source so
I can backtrace it next time it happens.
Perhaps Plan 9 under lguest is the way to go.
Stefan
On Thu, Jun 12, 2008 at 9:54 PM, Venkatesh Srinivas <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O
> demanding such as unpacking a ~100MB tarball, qemu locks up and refuses
> further connections (via vnc, or gdb for example). I am using
I have problems with Qemu too. Qemu hangs booting, hangs after booting,
hangs ramdomly, ... with or without venti.
I am using now a "new" PC for Plan9
> Everything, in my experience, crashes QEMU. Nice try.
>
> Just the opinion of me and my dog (who barks loudly when I shout
> f**king QEMU - pie
Everything, in my experience, crashes QEMU. Nice try.
Just the opinion of me and my dog (who barks loudly when I shout
f**king QEMU - piece of f**king sh*t!).
Hey, this is off topic but ... anyone had fun with a Asus EeePC? The
excess stock are being sold in Oz and I got a 4G for US$300. Tho Amz
On Fri, Jun 13, 2008 at 12:00 PM, Venkatesh Srinivas <[EMAIL PROTECTED]> wrote:
> I've tried with both qcow2 and raw; raw takes longer to get to a crash,
> but still reliably crashes. Strangely, connecting to qemu with gdb
> before Plan 9 starts reduces the crash rate a lot, but it might just be
>
I've tried with both qcow2 and raw; raw takes longer to get to a crash,
but still reliably crashes. Strangely, connecting to qemu with gdb
before Plan 9 starts reduces the crash rate a lot, but it might just be
because the world is noticeably slower...
--vs
Also... Renice if you can.
On 6/12/08, Lorenzo Fernando Bivens de la Fuente
<[EMAIL PROTECTED]> wrote:
> Thoughts:
> + Running Plan 9 on qemu is slow (when doing disk access) (the
> ethernal DMA wiwi bla bla bla)
> + qcow2 is quality challenged, but I think that the standard plan9.img
> ain't
Thoughts:
+ Running Plan 9 on qemu is slow (when doing disk access) (the
ethernal DMA wiwi bla bla bla)
+ qcow2 is quality challenged, but I think that the standard plan9.img
ain't qcow2
+kqemu has worked for me very well... but I have not benchmarked it.
+ Unpacking 100 MiB sounds like a lot of I/
On Jun 12, 2008, at 9:54 PM, Venkatesh Srinivas wrote:
Hi,
I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything
I/O
demanding such as unpacking a ~100MB tarball, qemu locks up and
refuses
further connections (via vnc, or gdb for example). I am using fossil
alone. This behavi
Hi,
I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O
demanding such as unpacking a ~100MB tarball, qemu locks up and refuses
further connections (via vnc, or gdb for example). I am using fossil
alone. This behavior occurs whether kqemu is enabled or not, though it
happens a
32 matches
Mail list logo
