From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: Planning for 0.13
Date: Wed, 6 Jan 2010 15:20:45 +0200 [thread overview]
Message-ID: <20100106132043.GC2248@redhat.com> (raw)
In-Reply-To: <4B4483CA.2030101@linux.vnet.ibm.com>
On Wed, Jan 06, 2010 at 06:36:26AM -0600, Anthony Liguori wrote:
> On 01/06/2010 04:49 AM, Michael S. Tsirkin wrote:
>>> What's the remaining problem?
>>>
>> IIRC, proper memory/IO access filtering (get rid of map functions) and
>> PCI Express.
>>
>>
>>>> vepa networking
>>>>
>>>>
>>> To me, this is covered with helpers. I really want to get qemu out of
>>> the network setup business specifically because of things like vepa,
>>> vmtag, and all of the other weird things that can be done.
>>>
>> I don't think you can now make vepa work this way. For existing
>> kernels, they only way I see is using packet sockets, and that code
>> already mostly works. One day, when macvtap is ready - who knows. But
>> waiting for that would mean we won't have it in 0.13.
>>
>
> We can use helpers for more than just tun/tap. My current thinking for
> helpers is that they would give qemu an fd and then tell qemu how to
> work with it. Basically, use read/write vs. send/recv, whether to use a
> virtio-net header or not, etc.
Frankly I think this is too ambitious for 0.13, and I would like to
avoid typing features that users need today to this effort.
Note that management still needs ability to hand fd to qemu, so we can
not require use of helpers for everyone. If the helpers are part of
qemu itself, we do not gain anything from them besides (limited)
security. But if not, we also get a protocol qemu<->helpers to
maintain. Ugh.
What I think is reasonable for 0.13, is what you posted: just allow
helper script as an alternative way to get device fd, and have qemu do
all the querying and feature negotiation exactly the way it already
does. No protocol to maintain, command line users get some extra
security, management is not affected at all. The only risk is that a new
suid binary is installed.
> That would allow a helper to open a raw socket, configure macvlan, and
> then hand the fd over to qemu and tell qemu how to use it.
Note binding to macvlan in a script buys you zero extra security
as compared to opening socket and binding in qemu.
> Regards,
>
> Anthony Liguori
--
MST
next prev parent reply other threads:[~2010-01-06 13:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-05 12:43 [Qemu-devel] Planning for 0.13 Anthony Liguori
2010-01-05 12:44 ` [Qemu-devel] " Anthony Liguori
2010-01-05 20:50 ` [Qemu-devel] " Stefan Weil
2010-01-05 21:33 ` [Qemu-devel] " Michael S. Tsirkin
2010-01-06 0:32 ` Anthony Liguori
2010-01-06 10:49 ` Michael S. Tsirkin
2010-01-06 12:36 ` Anthony Liguori
2010-01-06 13:20 ` Michael S. Tsirkin [this message]
2010-01-06 13:34 ` Anthony Liguori
2010-01-06 13:55 ` Michael S. Tsirkin
2010-01-06 15:10 ` Anthony Liguori
2010-01-06 15:16 ` Michael S. Tsirkin
2010-01-06 15:24 ` Anthony Liguori
2010-01-06 15:41 ` Michael S. Tsirkin
2010-01-06 17:19 ` Jamie Lokier
2010-01-06 18:19 ` Michael S. Tsirkin
2010-01-06 22:49 ` Jamie Lokier
2010-01-06 23:59 ` Michael S. Tsirkin
2010-01-06 19:48 ` Paolo Bonzini
2010-01-06 19:54 ` Michael S. Tsirkin
2010-01-06 19:59 ` Paolo Bonzini
2010-01-06 20:07 ` Michael S. Tsirkin
2010-01-06 23:00 ` Jamie Lokier
2010-01-07 0:05 ` Michael S. Tsirkin
2010-01-05 22:31 ` [Qemu-devel] " Aurelien Jarno
2010-01-06 2:46 ` Roy Tam
2010-01-06 9:37 ` Gerd Hoffmann
2010-01-06 15:34 ` Adam Litke
2010-01-12 13:43 ` Pasi Kärkkäinen
2010-01-12 15:07 ` Stefano Stabellini
2010-02-09 14:50 ` Artyom Tarasenko
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=20100106132043.GC2248@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/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).