Re: [Qemu-devel] [PATCH] mark nic as trusted

[Dor Laor <dlaor@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]

Carl-Daniel Hailfinger wrote:
> On 11.01.2009 08:10, Blue Swirl wrote:
>   
>> On 1/11/09, Jamie Lokier <jamie@shareable.org> wrote:
>>   
>>     
>>>  > But we also have to think about how to support newer platforms and newer
>>>  > kernels and this will often mean that we have to make intrusive changes
>>>  > so that the integration makes everyone happy.  This does not mean that
>>>  > we cannot support older platforms though, we just have to do it a little
>>>  > differently on the older platforms.
>>>
>>>  Sure, but don't make it _deliberately_ hard to support
>>>  older/obscure/can't-compile-a-kernel-module guests by designing
>>>  something that's obviously going to require a totally different
>>>  mechanism on those other guests.  It would make it unnecessarily hard
>>>  to integrate diverse guests with management apps from different
>>>  authors if they do adopt the vmchannel mechanism.
>>>     
>>>       
>> I think a serial port device should be universally supported by any OS
>> and it's portable to many systems. Older OS may accidentally enable
>> forwarding between the trusted nic and other nics, this doesn't happen
>> with serial lines.
>>   
>>     
>
> I remember the old days of DOS networking where the Kirschbaum-Netz
> software provided some sort of routed/forwarded networking between PCs
> over serial ports. It was a default on choice in many corporate and
> private "LANs" in Germany at the beginning of the last decade.
>
> Except for machines with that software (which is really hard to get
> nowadays), my concern should be a non-issue, especially for virtual
> machines which are unlikely to have such software installed.
>
> Regards,
> Carl-Daniel
>
>   

Actually vmchannel started as a pv serial implementation. Standard serial is
a bit low performing and demand an vmexit per byte (maybe it's not that 
bad for us).
Moreover, various guest do not support more than 4 serial channels. 
Since there
should be several channels and we like to preserve some for 
console/debug, it is
not enough.
Originally, vmchannel was a virtio interface with netlink interface to 
the kernel.
Then, Anthony asked to change it to a socket interface with new address 
family. It
was indeed a logical step. Then, David Miller was reluctant to add such 
interface to the
kernel. Instead, he offered the network device solution.
Are we close to begin this loop again?  :)

Let's try to stick to the nic solution. It has some advantages over pv 
serial:
    - Reliable communication if tcp is used
    - Migration support for slirp
    - No new driver in the guest.
    - Might even work for older guests
The disadvantages are:
    - Need to 'teach' guest daemons/firewalls not to handle/block the 
new nic
    - Link local addresses for ipv4 are problematic when using on other 
nics in parallel
       - We should either 1. not use link local on other links 2. Use 
standard dhcp addresses 3. do
          not use tcp/ip for vmchannel communication.

So additional nic can do the job and we have several flavours to choose 
from.

Regards,
Dor

[-- Attachment #2: Type: text/html, Size: 3774 bytes --]