Re: [9fans] I/O load crashes Qemu
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 Debian. My Qemu is 0.9.1 though I used 0.9.0 for a while - I upgraded to take advantage of PXE booting in 0.9.1 and compiled it from the tar.gz I've not done much heavy I/O though I have made numerous pdf's with it with CGI on httpd. I've also produced my own installer isos with it which included plan9.iso plan9.iso.bz2 in the iso. I've used it for fancy networking tricks with vde_switch and tap0. I use qcow images and I think they are sparse files. I have borked the file system with it, though it was my own fault. matt
Re: [9fans] I/O load crashes Qemu
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 this because i think there is a prevalent attitude, not well-informed by experience, that hardware is bad and impossible to program. my opinion, based on experience, is this is not true. and restating the untruth has the consequence of discouraging folk from working on drivers, thus reenforcing the myth. were it true, it would not be an attitude condusive to getting things done. hardware, unlike linux, is unavoidable. to your claim: in my experience, the complexity of the hardware has very little to do with the complexity of the driver. for example, the intel 82598 10gbe is a beast of a part. 341 pages of documentation. 200 registers. yet it's a simple driver because 1. of experience with other ethernet drivers; 2. everything the driver needs from the kernel already exists; 3. most complicated functionality was ignored; 4. the spec has not changed; and 5. only one part implements the register set. - erik
Re: [9fans] I/O load crashes Qemu
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. ... for example, the intel 82598 10gbe is a beast of a part. 341 pages of documentation. 200 registers. yet it's a simple driver because ... 3. most complicated functionality was ignored; I rest my case :-) How much simpler it would've been if instead of 200 registers there was just a cmd,arg-block-ptr fifo in each direction. You can do everything you want with a small set of commands. An open ended interface that can be efficiently virtualized. Or why not just implement something like 9p? i respond to this because i think there is a prevalent attitude, not well-informed by experience, that hardware is bad and impossible to program. my opinion, based on experience, is this is not true. and restating the untruth has the consequence of discouraging folk from working on drivers, thus reenforcing the myth. Sorry, my experience does not match yours. May be things have improved since I used to write drivers but controllers like NEC765 were pretty bad (I can cite a lot of other examples but I won't, not here!). As a driver writer one should go in with eyes open so nothing grosses you out, read specs thoroughly but when in doubt experiment and so on. were it true, it would not be an attitude condusive to getting things done. If only. Unfortunately too much bad hardware gets drivers written for them. This is so far from qemu or plan9 that I will stop now.
Re: [9fans] I/O load crashes Qemu
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 because the world is noticeably slower... Does it actually crash or just hang? Maybe you just need to wait for the I/O to drop before it will accept connections again? -sqweek
Re: [9fans] I/O load crashes Qemu
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 Amzon were down to 4. Let me know off-list. Regards, The Dude With The Little Dog.
Re: [9fans] I/O load crashes Qemu
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 - 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 Amzon were down to 4. Let me know off-list. Regards, The Dude With The Little Dog. -- Rodolfo García AKA kix http://www.kix.es/ EA4ERH (@IN80ER)
Re: [9fans] I/O load crashes Qemu
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 fossil alone. This behavior occurs whether kqemu is enabled or not, though it happens a lot faster w/o kqemu. Has anyone else noticed anything like this? Any thoughts about running Plan 9 in qemu? Yes, I had this problem several times while doing replica/pull yesterday. Qemu uses up all cpu load, and does not respond. Sometimes it comes back on from the lock up, while other times I lose my patience and kill it. I went back to 0.9.0. Lets see if I have the same problem. fhs
Re: [9fans] I/O load crashes Qemu
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 freebsd under qemu for hours on end. Juergen Lock has done an excellent job on making sure qemu+kqemu continue to work on freebsd but he has needed feedback from qemu/freebsd users. If you plan on continuing with qemu it might be worth asking on the qemu-devel mailing list or #qemu on freenode as I don't think any qemu dveloper follows 9fans. But they will need details like the host OS and version, qemu version, command line used, exact symptoms, steps to repeat the problem etc.
Re: [9fans] I/O load crashes Qemu
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 exists, I don't know why... (But it would be very appreciated if an explanation is given) One thing I've thought several times is that perhaps qemu-ide specific drivers need to be done. Many hosted OSs need custom made drivers to be used with a virtualizer. I am sure a lot has been discused about this on the list. I'll try to do a quick scan about it later. On 6/13/08, Bakul Shah [EMAIL PROTECTED] wrote: 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 freebsd under qemu for hours on end. Juergen Lock has done an excellent job on making sure qemu+kqemu continue to work on freebsd but he has needed feedback from qemu/freebsd users. If you plan on continuing with qemu it might be worth asking on the qemu-devel mailing list or #qemu on freenode as I don't think any qemu dveloper follows 9fans. But they will need details like the host OS and version, qemu version, command line used, exact symptoms, steps to repeat the problem etc.
Re: [9fans] I/O load crashes Qemu
the peculiar thing about the modern virtualisers/hypervisors etc is that sorry. i meant to write one peculiar thing ..., because there are others.
Re: [9fans] I/O load crashes Qemu
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 only restriction i remember was that you couldn't any longer dynamically modify channel programs (by having a channel program read some blocks into memory that would later be executed in the same channel program), but other systems imposed a similar restriction on that hardware. 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!
Re: [9fans] I/O load crashes Qemu
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
Re: [9fans] I/O load crashes Qemu
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 processor and it was really fun...
All we need is to put that into a PCI thing and enjoy (And it would
even be better if you can program the thing dynamically from your pc
as needed)
I also believe I've seen some SUN workstations that do have a pci
processor to emulate an x86 machine...
Blah... I really need to sleeep.
I hate PHP.
On 6/13/08, 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, but the device to make it is not. Start simple:
void
main(int, char *[])
{
while(readbyte()){
parseinst();
doinst();
}
exits(nerrs ? error : 0);
}
Re: [9fans] I/O load crashes Qemu
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 like a java vm, or a nes emulator... Ever heard of 'Dis on a Chip'? http://groups.google.com/group/dis-on-a-chip uriel
Re: [9fans] I/O load crashes Qemu
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 virtualized environment is in every way equivalent to the bare iron is always useful or worth the effort. why should a virtualized operating system need to worry about what nic the machine has? Well the URL was more to get the point across. Whether your virtual OS uses simplified virtual devices or emulated real devices, you shouldn't have to emulate each instruction in software! I won't argue with worth the effort but it can be useful (e.g. running dusty decks, debugging etc). My argument is more that real device intefaces should be designed to make virtualization efficient. for example vmware doesn't provide this sort of virtualized environment. it provides the same virtual network card interface regardless of what hardware the machine has. It is doable but it took them years to get there and provide good efficiency. May be even more years that VM/370?!
Re: [9fans] I/O load crashes Qemu
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 performance problem is qemu emulates an early Intel ATA controller chip (PIIX3) and perhaps plan9 does not do certain optimizations. It would not be too hard to emulate a more modern controller. try turning dma on. it is very unlikely that plan 9 is missing some important ata optimization. Already tried. echo 'dma on' /dev/sdC0/ctl doesn't make any difference in performance. IMHO a virtualizable processor is the necessary first step as it clears one's mind about what not to do in an efficient virtualizable IO architecture! unless you are contemplating a processor with i/o instructions, what does the processor have to do with i/o architecture? Just that if you have no incentive to virtualize IO, you are unlikely to think about making it efficient. 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. but just wait, there will come a day when people complain about the nasty registers in vm and how it would be good to abstract that stuff out. Ha! First we have to get there.
Re: [9fans] I/O load crashes Qemu
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
Re: [9fans] I/O load crashes Qemu
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 processor inside. at the end of the day you get qemu-mips. iru
Re: [9fans] I/O load crashes Qemu
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/O... Ergo a lot of disk ergo a lot of no-dma bottleneck Good luck On 6/12/08, Pietro Gagliardi [EMAIL PROTECTED] wrote: 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 behavior occurs whether kqemu is enabled or not, though it happens a lot faster w/o kqemu. Has anyone else noticed anything like this? Any thoughts about running Plan 9 in qemu? Thanks, --vs Compressed disc image (qcow2)? That's what screwed up my fossil+venti.
Re: [9fans] I/O load crashes Qemu
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 qcow2 +kqemu has worked for me very well... but I have not benchmarked it. + Unpacking 100 MiB sounds like a lot of I/O... Ergo a lot of disk ergo a lot of no-dma bottleneck Good luck On 6/12/08, Pietro Gagliardi [EMAIL PROTECTED] wrote: 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 behavior occurs whether kqemu is enabled or not, though it happens a lot faster w/o kqemu. Has anyone else noticed anything like this? Any thoughts about running Plan 9 in qemu? Thanks, --vs Compressed disc image (qcow2)? That's what screwed up my fossil+venti.
Re: [9fans] I/O load crashes Qemu
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
