[9fans] I/O load crashes Qemu

[9fans] I/O load crashes Qemu

[Venkatesh Srinivas]

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

Re: [9fans] I/O load crashes Qemu

[Pietro Gagliardi]

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

[Lorenzo Fernando Bivens de la Fuente]

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 <pietro10@mac.com> 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

[Lorenzo Fernando Bivens de la Fuente]

Also... Renice if you can.

On 6/12/08, Lorenzo Fernando Bivens de la Fuente
<lorenzobivens@gmail.com> 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 <pietro10@mac.com> 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

[Venkatesh Srinivas]

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

Re: [9fans] I/O load crashes Qemu

[sqweek]

On Fri, Jun 13, 2008 at 12:00 PM, Venkatesh Srinivas <me@acm.jhu.edu> 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

[Bruce Ellis]

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

[Rodolfo kix García]

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

[Fazlul Shahriar]

On Thu, Jun 12, 2008 at 9:54 PM, Venkatesh Srinivas <me@acm.jhu.edu> 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

[stefanha]

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

Re: [9fans] I/O load crashes Qemu

[Bakul Shah]

> 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

[Lorenzo Fernando Bivens de la Fuente]

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 <bakul+plan9@bitblocks.com> 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

[erik quanstrom]

> 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

[Charles Forsyth]

>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

[Charles Forsyth]

> 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

[Lorenzo Fernando Bivens de la Fuente]

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 imagine that
the so called hypervisors are kind of a "(exo-)scheduler"

A not very educated guess...

On 6/13/08, erik quanstrom <quanstro@quanstro.net> wrote:
> > 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

[Bakul Shah]

On Fri, 13 Jun 2008 21:33:15 BST Charles Forsyth <forsyth@terzarima.net>  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/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.

> 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 reme
> mber
> 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 th
> an
> actual hardware!  it's all gone wrong!

I don't think you can escape writing device emulation code
for the virtualization layer (when the guest os diddles a
device register, someone has to implement its semantics).
If the emulated device is not the same as some real device,
the guest os has to have a special drivers for it.

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!  Emulating grotty device
registers with horrible side-effects is just too painful and
one would be forced to abstract that out.  Probably too late
for that!

Re: [9fans] I/O load crashes Qemu

[Pietro Gagliardi]

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

[Bakul Shah]

On Fri, 13 Jun 2008 19:26:42 EDT Pietro Gagliardi <pietro10@mac.com>  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);
> 	}

?

You don't need this sort of code in a virtualizable processor.
See for example
  http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements

Re: [9fans] I/O load crashes Qemu

[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...

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 <pietro10@mac.com> 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

[erik quanstrom]

> 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-usenix2008.pdf

> I imagine that the biggest issue is to avoid a racing condition
> between the two(or 'n') running kernels.

two different kernels can't race as they share no resources.
in the hypervisor, races can be taken care of with the same techniques
that work on any other multithreaded program.

so, if performance is not an issue, a single threaded hypervisor could
schedule any number of guests.  then there are no locking problems at all.

> Then... Would it be very hard to build an fs that allows to share real
> hardware with another kernel running alongside plan 9? I imagine that
> the so called hypervisors are kind of a "(exo-)scheduler"

this is already possible.  any number of plan 9 cpu servers may share
a single fileserver.  no virtualization needed.

> You don't need this sort of code in a virtualizable processor.
> See for example
>   http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements

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?

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.

- erik

Re: [9fans] I/O load crashes Qemu

[Uriel]

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

[Bakul Shah]

On Fri, 13 Jun 2008 19:52:22 EDT erik quanstrom <quanstro@quanstro.net>  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

[matt]

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

[Bakul Shah]

> >> 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

[Iruata Souza]

On Sat, Jun 14, 2008 at 9:53 AM, erik quanstrom <quanstro@coraid.com> 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 it
> to defend it.
>
> however, why is it a requirement that a vm be able to emulate
> other machines?
>

because it claims to do so?

iru

Re: [9fans] I/O load crashes Qemu

[erik quanstrom]

>> 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

[erik quanstrom]

> 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
other machines?

- erik

Re: [9fans] I/O load crashes Qemu

[Iruata Souza]

On Sat, Jun 14, 2008 at 1:58 AM, Bruce Ellis <bruce.ellis@gmail.com> 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

[Bruce Ellis]

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

[Bakul Shah]

On Fri, 13 Jun 2008 20:39:48 EDT erik quanstrom <quanstro@quanstro.net>  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

[erik quanstrom]

> 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.

> 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?

> Emulating grotty device
> registers with horrible side-effects is just too painful and
> one would be forced to abstract that out.  Probably too late
> for that!

i find there's a certain simplicty in dealing directly
with hardware, provided one has documentation.

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.

i think that may have been yesterday.

- erik