From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Rusty Russell" <rusty@rustcorp.com.au>,
"Andreas Färber" <afaerber@suse.de>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] vhost acceleration broken?
Date: Mon, 29 Jul 2013 10:33:41 +0300 [thread overview]
Message-ID: <20130729073341.GC2308@redhat.com> (raw)
In-Reply-To: <CA+aC4ksrU2--yYsO-LZqWBjAunKQyuHLaTR+gJB-p_mW3eWX+Q@mail.gmail.com>
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.
next prev parent reply other threads:[~2013-07-29 7:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 1:55 [Qemu-devel] vhost acceleration broken? Rusty Russell
2013-07-25 2:08 ` Anthony Liguori
2013-07-25 3:07 ` Rusty Russell
2013-07-25 13:28 ` Anthony Liguori
2013-07-25 14:52 ` Michael S. Tsirkin
2013-07-25 14:56 ` Andreas Färber
2013-07-25 15:24 ` Michael S. Tsirkin
2013-07-25 16:16 ` Anthony Liguori
2013-07-25 16:20 ` Peter Maydell
2013-07-25 16:32 ` Michael S. Tsirkin
2013-07-28 23:55 ` Rusty Russell
2013-07-29 2:10 ` Anthony Liguori
2013-07-29 7:33 ` Michael S. Tsirkin [this message]
2013-07-29 7:09 ` Michael S. Tsirkin
2013-07-25 14:12 ` Peter Maydell
2013-07-25 14:53 ` Michael S. Tsirkin
2013-07-26 9:25 ` Stefan Hajnoczi
2013-07-26 9:43 ` Peter Maydell
2013-07-28 8:10 ` Michael S. Tsirkin
2013-07-25 5:20 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130729073341.GC2308@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).