[Qemu-devel] vhost acceleration broken?

[Qemu-devel] vhost acceleration broken?

[Rusty Russell]

Hi all,

        Using latest kernel and master qemu, the following doesn't use
vhost acceleration:

sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virtio -kernel arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"

Culprit is here:

hw/net/virtio-net.c:virtio_net_vhost_status():
    if (nc->peer->info->type != NET_CLIENT_OPTIONS_KIND_TAP) {
        return;
    }

info->type is NET_CLIENT_OPTIONS_KIND_HUBPORT.

At a glance, it seems like vlan is always enabled, and that means a hub,
so that change silently disabled vhost acceleration.

It's quite possible that I've screwed up qemu's impenetrable command
line (-net or -netdev, who knows what's better?).

Frustrated,
Rusty.

Re: [Qemu-devel] vhost acceleration broken?

[Anthony Liguori]

On Wed, Jul 24, 2013 at 8:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> Hi all,
>
>         Using latest kernel and master qemu, the following doesn't use
> vhost acceleration:
>
> sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virtio -kernel arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"

sudo qemu-system-x86_64 -enable-kvm $ARGS -m 1G -netdev
tap,script=/home/rusty/bin/kvm-ifup,vhost=on,id=net0 -device
virtio-net-pci,netdev=net0 -drive file=$QEMUIMAGE,if=virtio -kernel
arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"

We really ought to strongly deprecate -net because it's misleading.  I
suspect we can reasonably add a warning for model=virtio saying
"please don't use this" and eventually remove it entirely.

> Culprit is here:
>
> hw/net/virtio-net.c:virtio_net_vhost_status():
>     if (nc->peer->info->type != NET_CLIENT_OPTIONS_KIND_TAP) {
>         return;
>     }
>
> info->type is NET_CLIENT_OPTIONS_KIND_HUBPORT.
>
> At a glance, it seems like vlan is always enabled, and that means a hub,
> so that change silently disabled vhost acceleration.
>
> It's quite possible that I've screwed up qemu's impenetrable command
> line (-net or -netdev, who knows what's better?).

It is for -net.  The whole vlan concept sucks and makes it too hard to
do offload or vhost.  It's still around for compatibility.

Regards,

Anthony Liguori

> Frustrated,
> Rusty.
>

Re: [Qemu-devel] vhost acceleration broken?

[Rusty Russell]

Anthony Liguori <anthony@codemonkey.ws> writes:
> On Wed, Jul 24, 2013 at 8:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Hi all,
>>
>>         Using latest kernel and master qemu, the following doesn't use
>> vhost acceleration:
>>
>> sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virtio -kernel arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
>
> sudo qemu-system-x86_64 -enable-kvm $ARGS -m 1G -netdev
> tap,script=/home/rusty/bin/kvm-ifup,vhost=on,id=net0 -device
> virtio-net-pci,netdev=net0 -drive file=$QEMUIMAGE,if=virtio -kernel
> arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
>
> We really ought to strongly deprecate -net because it's misleading.  I
> suspect we can reasonably add a warning for model=virtio saying
> "please don't use this" and eventually remove it entirely.

Thankyou, that works.

I'm sure you've thought more deeply about the qemu cmdline than I have,
so I won't comment.

Cheers,
Rusty.

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Thu, Jul 25, 2013 at 11:25:20AM +0930, Rusty Russell wrote:
> Hi all,
> 
>         Using latest kernel and master qemu, the following doesn't use
> vhost acceleration:
> 
> sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virtio -kernel arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
> 
> Culprit is here:
> 
> hw/net/virtio-net.c:virtio_net_vhost_status():
>     if (nc->peer->info->type != NET_CLIENT_OPTIONS_KIND_TAP) {
>         return;
>     }
> 
> info->type is NET_CLIENT_OPTIONS_KIND_HUBPORT.
> 
> At a glance, it seems like vlan is always enabled, and that means a hub,
> so that change silently disabled vhost acceleration.
> 
> It's quite possible that I've screwed up qemu's impenetrable command
> line (-net or -netdev, who knows what's better?).
> 
> Frustrated,
> Rusty.

That's just it.
Replace -net with -netdev, and things will work.

Re: [Qemu-devel] vhost acceleration broken?

[Anthony Liguori]

Rusty Russell <rusty@rustcorp.com.au> writes:

> Anthony Liguori <anthony@codemonkey.ws> writes:
>> On Wed, Jul 24, 2013 at 8:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>> Hi all,
>>>
>>>         Using latest kernel and master qemu, the following doesn't use
>>> vhost acceleration:
>>>
>>> sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virtio -kernel arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
>>
>> sudo qemu-system-x86_64 -enable-kvm $ARGS -m 1G -netdev
>> tap,script=/home/rusty/bin/kvm-ifup,vhost=on,id=net0 -device
>> virtio-net-pci,netdev=net0 -drive file=$QEMUIMAGE,if=virtio -kernel
>> arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
>>
>> We really ought to strongly deprecate -net because it's misleading.  I
>> suspect we can reasonably add a warning for model=virtio saying
>> "please don't use this" and eventually remove it entirely.
>
> Thankyou, that works.
>
> I'm sure you've thought more deeply about the qemu cmdline than I have,
> so I won't comment.

Any comment you would make is certainly fair.

We have a pretty awful legacy command line set that comes from years of
half-baked concepts and the years when too many people just committed
random shit to the tree.

I think we probably need to start planning for a clean break.  Maybe
that's a good target for a 2.0 version...

Regards,

Anthony Liguori

>
> Cheers,
> Rusty.

Re: [Qemu-devel] vhost acceleration broken?

[Peter Maydell]

On 25 July 2013 03:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> We really ought to strongly deprecate -net because it's misleading.

...we still need to figure out how -netdev is supposed to
work for embedded (created-by-default) network devices first.

-- PMM

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> 
> > Anthony Liguori <anthony@codemonkey.ws> writes:
> >> On Wed, Jul 24, 2013 at 8:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> >>> Hi all,
> >>>
> >>>         Using latest kernel and master qemu, the following doesn't use
> >>> vhost acceleration:
> >>>
> >>> sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virtio -kernel arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
> >>
> >> sudo qemu-system-x86_64 -enable-kvm $ARGS -m 1G -netdev
> >> tap,script=/home/rusty/bin/kvm-ifup,vhost=on,id=net0 -device
> >> virtio-net-pci,netdev=net0 -drive file=$QEMUIMAGE,if=virtio -kernel
> >> arch/x86/boot/bzImage -append "root=/dev/vda1 $KARGS $*"
> >>
> >> We really ought to strongly deprecate -net because it's misleading.  I
> >> suspect we can reasonably add a warning for model=virtio saying
> >> "please don't use this" and eventually remove it entirely.
> >
> > Thankyou, that works.
> >
> > I'm sure you've thought more deeply about the qemu cmdline than I have,
> > so I won't comment.
> 
> Any comment you would make is certainly fair.
> 
> We have a pretty awful legacy command line set that comes from years of
> half-baked concepts and the years when too many people just committed
> random shit to the tree.
> 
> I think we probably need to start planning for a clean break.  Maybe
> that's a good target for a 2.0 version...
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > Cheers,
> > Rusty.

Assuming -netdev supports all required configurations, we should
remove -net from the -help output.

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Thu, Jul 25, 2013 at 03:12:31PM +0100, Peter Maydell wrote:
> On 25 July 2013 03:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > We really ought to strongly deprecate -net because it's misleading.
> 
> ...we still need to figure out how -netdev is supposed to
> work for embedded (created-by-default) network devices first.
> 
> -- PMM

I guess it could work just like -net does: assume a default netdev name?

Re: [Qemu-devel] vhost acceleration broken?

[Andreas Färber]

Am 25.07.2013 16:52, schrieb Michael S. Tsirkin:
> On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
>> We have a pretty awful legacy command line set that comes from years of
>> half-baked concepts and the years when too many people just committed
>> random shit to the tree.
>>
>> I think we probably need to start planning for a clean break.  Maybe
>> that's a good target for a 2.0 version...
> 
> Assuming -netdev supports all required configurations, we should
> remove -net from the -help output.

Peter had raised the issue of -netdev not working well with boards that
already supply a default NIC - was there a solution yet?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Thu, Jul 25, 2013 at 04:56:05PM +0200, Andreas Färber wrote:
> Am 25.07.2013 16:52, schrieb Michael S. Tsirkin:
> > On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
> >> We have a pretty awful legacy command line set that comes from years of
> >> half-baked concepts and the years when too many people just committed
> >> random shit to the tree.
> >>
> >> I think we probably need to start planning for a clean break.  Maybe
> >> that's a good target for a 2.0 version...
> > 
> > Assuming -netdev supports all required configurations, we should
> > remove -net from the -help output.
> 
> Peter had raised the issue of -netdev not working well with boards that
> already supply a default NIC - was there a solution yet?
> 
> Andreas

Whoever is removing -net will have to code that up. Want to do this?

> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] vhost acceleration broken?

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Thu, Jul 25, 2013 at 04:56:05PM +0200, Andreas Färber wrote:
>> Am 25.07.2013 16:52, schrieb Michael S. Tsirkin:
>> > On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
>> >> We have a pretty awful legacy command line set that comes from years of
>> >> half-baked concepts and the years when too many people just committed
>> >> random shit to the tree.
>> >>
>> >> I think we probably need to start planning for a clean break.  Maybe
>> >> that's a good target for a 2.0 version...
>> > 
>> > Assuming -netdev supports all required configurations, we should
>> > remove -net from the -help output.
>> 
>> Peter had raised the issue of -netdev not working well with boards that
>> already supply a default NIC - was there a solution yet?
>> 
>> Andreas
>
> Whoever is removing -net will have to code that up. Want to do this?

I would not rush to remove things.  If we're going to go through a
deprecation process, we should start with a proposal on what things
should be removed and go from there.

I still don't even think -netdev is the right answer here either.
Wouldn't it make more sense to have something like:

qemu -vnic tap,script=/foo/myscript

Or something vaguely understandable by a human?

Regards,

Anthony Liguori

>
>> -- 
>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] vhost acceleration broken?

[Peter Maydell]

On 25 July 2013 17:16, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Or something vaguely understandable by a human?

I think this is actually one of the main issues with trying
to get rid of the 'legacy' command line options. They
may be a random mishmash of things, but they're also
often much easier to understand, remember and type than
the new-style options that are supposed to replace them :-(

-- PMM

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Thu, Jul 25, 2013 at 05:20:44PM +0100, Peter Maydell wrote:
> On 25 July 2013 17:16, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > Or something vaguely understandable by a human?
> 
> I think this is actually one of the main issues with trying
> to get rid of the 'legacy' command line options. They
> may be a random mishmash of things, but they're also
> often much easier to understand, remember and type than
> the new-style options that are supposed to replace them :-(
> 
> -- PMM

The new-style ones are not really harder to understand,
but they are mostly undocumented.
I think that's the real issue.

I think recent patchset to at least classify -device help
output by Marcel is a step in the right direction here.

-- 
MST

Re: [Qemu-devel] vhost acceleration broken?

[Stefan Hajnoczi]

On Thu, Jul 25, 2013 at 05:53:06PM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2013 at 03:12:31PM +0100, Peter Maydell wrote:
> > On 25 July 2013 03:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > We really ought to strongly deprecate -net because it's misleading.
> > 
> > ...we still need to figure out how -netdev is supposed to
> > work for embedded (created-by-default) network devices first.
> > 
> > -- PMM
> 
> I guess it could work just like -net does: assume a default netdev name?

Sounds like a simple way to solve it, as long as machines use the
standard name(s) for build-in NICs.

Stefan

Re: [Qemu-devel] vhost acceleration broken?

[Peter Maydell]

On 26 July 2013 10:25, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Thu, Jul 25, 2013 at 05:53:06PM +0300, Michael S. Tsirkin wrote:
>> On Thu, Jul 25, 2013 at 03:12:31PM +0100, Peter Maydell wrote:
>> > On 25 July 2013 03:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> > > We really ought to strongly deprecate -net because it's misleading.
>> >
>> > ...we still need to figure out how -netdev is supposed to
>> > work for embedded (created-by-default) network devices first.

>> I guess it could work just like -net does: assume a default netdev name?

(for clarity, rather than as an argument against this idea)
This isn't how -net works : "-net nic,options" sets up an
entry in the nd_table[], and the board will then pick up those
entries based on some ad-hoc combination of order and whether
a model= was specified for that nic.

> Sounds like a simple way to solve it, as long as machines use the
> standard name(s) for build-in NICs.

How would this work for (for example) specifying a macaddr
for the built-in NIC? At the moment you can do that with
-net nic,macaddr=<whatever>.

-- PMM

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Fri, Jul 26, 2013 at 10:43:44AM +0100, Peter Maydell wrote:
> On 26 July 2013 10:25, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > On Thu, Jul 25, 2013 at 05:53:06PM +0300, Michael S. Tsirkin wrote:
> >> On Thu, Jul 25, 2013 at 03:12:31PM +0100, Peter Maydell wrote:
> >> > On 25 July 2013 03:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >> > > We really ought to strongly deprecate -net because it's misleading.
> >> >
> >> > ...we still need to figure out how -netdev is supposed to
> >> > work for embedded (created-by-default) network devices first.
> 
> >> I guess it could work just like -net does: assume a default netdev name?
> 
> (for clarity, rather than as an argument against this idea)
> This isn't how -net works : "-net nic,options" sets up an
> entry in the nd_table[], and the board will then pick up those
> entries based on some ad-hoc combination of order and whether
> a model= was specified for that nic.
> 
> > Sounds like a simple way to solve it, as long as machines use the
> > standard name(s) for build-in NICs.
> 
> How would this work for (for example) specifying a macaddr
> for the built-in NIC? At the moment you can do that with
> -net nic,macaddr=<whatever>.
> 
> -- PMM

ATM you can use -global for that.

We generally need a way to specify properties for
built-in devices by path.

-- 
MST

Re: [Qemu-devel] vhost acceleration broken?

[Rusty Russell]

Anthony Liguori <anthony@codemonkey.ws> writes:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
>> On Thu, Jul 25, 2013 at 04:56:05PM +0200, Andreas Färber wrote:
>>> Am 25.07.2013 16:52, schrieb Michael S. Tsirkin:
>>> > On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
>>> >> We have a pretty awful legacy command line set that comes from years of
>>> >> half-baked concepts and the years when too many people just committed
>>> >> random shit to the tree.
>>> >>
>>> >> I think we probably need to start planning for a clean break.  Maybe
>>> >> that's a good target for a 2.0 version...
>>> > 
>>> > Assuming -netdev supports all required configurations, we should
>>> > remove -net from the -help output.
>>> 
>>> Peter had raised the issue of -netdev not working well with boards that
>>> already supply a default NIC - was there a solution yet?
>>> 
>>> Andreas
>>
>> Whoever is removing -net will have to code that up. Want to do this?
>
> I would not rush to remove things.  If we're going to go through a
> deprecation process, we should start with a proposal on what things
> should be removed and go from there.
>
> I still don't even think -netdev is the right answer here either.
> Wouldn't it make more sense to have something like:
>
> qemu -vnic tap,script=/foo/myscript
>
> Or something vaguely understandable by a human?

OK.  It seems to me that each net device has a host side and a guest
side, which you can mix and match.  So the commandline should reflect
that explicitly:

        qemu -hostdev net,[tap|user|bridge|socket|vde],....  -guestdev net,....

If you have a built-in net device on your emulated board, you've got one
implied -guestdev net.  And similar principles apply to other things
like consoles and disks.

Now, guest and host terms may suck.  But please pick one terminology and
use it *everywhere*.  Documentation, code and cmdline.

Thanks,
Rusty.

Re: [Qemu-devel] vhost acceleration broken?

[Anthony Liguori]

On Sun, Jul 28, 2013 at 6:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Or something vaguely understandable by a human?
>
> OK.  It seems to me that each net device has a host side and a guest
> side, which you can mix and match.  So the commandline should reflect
> that explicitly:
>
>         qemu -hostdev net,[tap|user|bridge|socket|vde],....  -guestdev net,....
>
> If you have a built-in net device on your emulated board, you've got one
> implied -guestdev net.  And similar principles apply to other things
> like consoles and disks.

See, we have this:

qemu -netdev tap,...  -device virtio-net-pci,...

> Now, guest and host terms may suck.  But please pick one terminology and
> use it *everywhere*.  Documentation, code and cmdline.

But *this* is the problem.  Our documentation (man page, --help,
qemu-doc.texi) hasn't been touched since the beginning.  I get the
feedback, will take a look at it for 1.7.

Regards,

Anthony Liguori

> Thanks,
> Rusty.

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Mon, Jul 29, 2013 at 09:25:20AM +0930, Rusty Russell wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> >
> >> On Thu, Jul 25, 2013 at 04:56:05PM +0200, Andreas Färber wrote:
> >>> Am 25.07.2013 16:52, schrieb Michael S. Tsirkin:
> >>> > On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
> >>> >> We have a pretty awful legacy command line set that comes from years of
> >>> >> half-baked concepts and the years when too many people just committed
> >>> >> random shit to the tree.
> >>> >>
> >>> >> I think we probably need to start planning for a clean break.  Maybe
> >>> >> that's a good target for a 2.0 version...
> >>> > 
> >>> > Assuming -netdev supports all required configurations, we should
> >>> > remove -net from the -help output.
> >>> 
> >>> Peter had raised the issue of -netdev not working well with boards that
> >>> already supply a default NIC - was there a solution yet?
> >>> 
> >>> Andreas
> >>
> >> Whoever is removing -net will have to code that up. Want to do this?
> >
> > I would not rush to remove things.  If we're going to go through a
> > deprecation process, we should start with a proposal on what things
> > should be removed and go from there.
> >
> > I still don't even think -netdev is the right answer here either.
> > Wouldn't it make more sense to have something like:
> >
> > qemu -vnic tap,script=/foo/myscript
> >
> > Or something vaguely understandable by a human?
> 
> OK.  It seems to me that each net device has a host side and a guest
> side, which you can mix and match.  So the commandline should reflect
> that explicitly:
> 
>         qemu -hostdev net,[tap|user|bridge|socket|vde],....  -guestdev net,....
> 
> If you have a built-in net device on your emulated board, you've got one
> implied -guestdev net.  And similar principles apply to other things
> like consoles and disks.

I think what Peter was asking for is a way to set parameters
on the implied -guestdev (we use -netdev for this).

> Now, guest and host terms may suck.  But please pick one terminology and
> use it *everywhere*.  Documentation, code and cmdline.
> 
> Thanks,
> Rusty.

Re: [Qemu-devel] vhost acceleration broken?

[Michael S. Tsirkin]

On Sun, Jul 28, 2013 at 09:10:16PM -0500, Anthony Liguori wrote:
> On Sun, Jul 28, 2013 at 6:55 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> >> Or something vaguely understandable by a human?
> >
> > OK.  It seems to me that each net device has a host side and a guest
> > side, which you can mix and match.  So the commandline should reflect
> > that explicitly:
> >
> >         qemu -hostdev net,[tap|user|bridge|socket|vde],....  -guestdev net,....
> >
> > If you have a built-in net device on your emulated board, you've got one
> > implied -guestdev net.  And similar principles apply to other things
> > like consoles and disks.
> 
> See, we have this:
> 
> qemu -netdev tap,...  -device virtio-net-pci,...
> 
> > Now, guest and host terms may suck.  But please pick one terminology and
> > use it *everywhere*.  Documentation, code and cmdline.
> 
> But *this* is the problem.

It's not the only problem though. Here's a list off the
top of my head.

Use of -device lacks documentation almost completely
(Marcel's recent patches are a step in the right
direction here), many devices also lack any user-readable
description, legal parameters to -global are undocumented,
-global does not validate parameters,
device properties are undocumented,
bus address formats are undocumented,
for complex devices such as pci express switches,
which device can be connected to which is
also undocumented.


> Our documentation (man page, --help,
> qemu-doc.texi) hasn't been touched since the beginning.  I get the
> feedback, will take a look at it for 1.7.
> 
> Regards,
> 
> Anthony Liguori
> 
> > Thanks,
> > Rusty.