From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted
Date: Thu, 08 Jan 2009 17:26:09 -0600 [thread overview]
Message-ID: <49668B91.3000705@codemonkey.ws> (raw)
In-Reply-To: <20090108224942.GA12848@shareable.org>
Jamie Lokier wrote:
> Anthony Liguori wrote:
>
>> Are we going to have a standard way of doing this in Linux distros such
>> that these nics are treated differently from other nics? Have we gotten
>> the appropriate distro folks to agree to this?
>>
>
> That wouldn't work for older distros and Windows anyway. But you
> might reasonably want to run apps doing guest-host communication on
> older guest distros too, simply as an app, not requiring guest
> customisation.
>
That's probably going to be difficult.
> Is there some way to mark a PCI device so it will be ignored at boot
> time generically?
No.
> Changing the PCI ID will do that for all guests,
> but is it then feasible for the vmchannel guest admin software to bind
> a NIC driver to a non-standard PCI ID, on the major OSes?
>
I don't see how changing the PCI ID (I presume you mean vendor/device
ID?) would help.
> Suppose you start a guest with two "trusted" nics, because you want to
> run two unrelated vmchannel-using admin apps. How does each app know
> which nic to use - or do they share it?
>
Unrelated vmchannel apps will use different ports on the same nic.
There will only ever be one trusted nic.
> As the guest OS's TCP is being used, what do you do about IP address
> space conflicts?
>
The user can choose what address is used for the host.
> Perhaps vmchannel will only use IPv6, so it can confidently pick a
> unique link-local address?
>
slirp only supports IPv4.
Regards,
Anthony Liguori
> -- Jamie
>
>
>
next prev parent reply other threads:[~2009-01-08 23:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 14:26 [Qemu-devel] [PATCH] mark nic as trusted Gleb Natapov
2009-01-07 15:04 ` Mark McLoughlin
2009-01-07 15:19 ` Gleb Natapov
2009-01-07 15:41 ` Mark McLoughlin
2009-01-07 16:02 ` Gleb Natapov
2009-01-07 16:34 ` Anthony Liguori
2009-01-07 16:50 ` Gleb Natapov
2009-01-07 17:53 ` Anthony Liguori
2009-01-07 17:54 ` Anthony Liguori
2009-01-07 18:41 ` Gleb Natapov
2009-01-07 19:26 ` Anthony Liguori
2009-01-07 19:46 ` Gleb Natapov
2009-01-08 19:58 ` Anthony Liguori
2009-01-08 21:26 ` Gleb Natapov
2009-01-08 21:42 ` Anthony Liguori
2009-01-08 22:49 ` Jamie Lokier
2009-01-08 23:14 ` Dor Laor
2009-01-09 10:41 ` Daniel P. Berrange
2009-01-10 2:18 ` Jamie Lokier
2009-01-10 18:22 ` Anthony Liguori
2009-01-11 4:55 ` Jamie Lokier
2009-01-11 7:10 ` Blue Swirl
2009-01-11 14:08 ` Carl-Daniel Hailfinger
2009-01-11 15:07 ` Dor Laor
2009-01-11 15:34 ` Blue Swirl
2009-01-11 16:01 ` Dor Laor
2009-01-12 2:20 ` Jamie Lokier
2009-01-12 8:05 ` Gleb Natapov
2009-01-12 12:26 ` Dor Laor
2009-01-10 2:27 ` Jamie Lokier
2009-01-08 23:26 ` Anthony Liguori [this message]
2009-01-10 2:31 ` Jamie Lokier
2009-01-10 18:24 ` Anthony Liguori
2009-01-11 4:40 ` Jamie Lokier
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=49668B91.3000705@codemonkey.ws \
--to=anthony@codemonkey.ws \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.