This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] XenLoop - Inter-VM Network Loopback

To: Kartik Gopalan <kartik@xxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] XenLoop - Inter-VM Network Loopback
From: Daniel Stodden <stodden@xxxxxxxxxx>
Date: Tue, 12 Feb 2008 11:33:53 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Feb 2008 02:34:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <bccdd85d0802111851q20eadf87u19f41c1de6fdc5b@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fakultät für Informatik I10, Technische Universität München
References: <bccdd85d0802091807n624345ecpc71b207f07dcabf8@xxxxxxxxxxxxxx> <1202672478.2916.6.camel@xxxxxxxxxxxxxxxxxxxx> <bccdd85d0802111851q20eadf87u19f41c1de6fdc5b@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2008-02-11 at 21:51 -0500, Kartik Gopalan wrote:
> The analogy, though not perfect, is that a loopback carries traffic
> between different network endpoints within the same (virtual)
> machine -- the endpoints may be in different processes, not just
> the originator. XenLoop carries traffic between different network
> endpoints resident in the same "physical" machine but in
> different VMs. Your virtual crossover cable analogy is just how
> it happens to be currently implemented. One could implement
> XenLoop using other non-crossover-type designs, resulting in
> more VM crosstalk or less security, but functionally what it does
> would remain unchanged, which is to bypass the network
> datapath through Dom0.

I retreat. :) Just found that it does not reflect the difference to the
dom0 switch, which functionally qualifies as a loopback by the same
definition. And it's certainly not meant to question your work.

I've got a couple of additional questions and comments. 

1. Netfilter setup: You're hooking into the output chain, just before
the packet is passed to the guest eth0? Did I get this right, or
something more esoteric? I'm asking because I'm definitely no netfilter

2. Periodic scanning of XenStore entries: Why not callbacks?

3. Announcement messages: This is a layer 3 (IP) packet? I'd rather
expected an ethertype.

4. Personally (this is dicussible) I don't like the XenStore/Message
*mixture* the directory is maintained with. I agree that due to the fact
that guests are limited to their private subtrees, maintenance of a
common directory is non-obvious but this is a defect in XenStore if the
directory should be there. XenStore is obvious, messages dissemination
as well. A dedicated resolution protocol (i.e. a domain-arp) appears
cleaner to me. I suppose there are issues in getting this to work
cleanly during migration (i.e. the need for invalidation messages before
leaving the host), or why did you choose this design?

Still not through, therefore likely more to come.


Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>