WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xend leaks/bugs/etc

To: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xend leaks/bugs/etc
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Mon, 18 Apr 2005 10:15:17 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Allen Short <washort@xxxxxxxxxx>
Delivery-date: Mon, 18 Apr 2005 15:15:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1113834723.7086.87.camel@localhost>
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: IBM
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3BE3@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1113804011.9189.46.camel@multivac> <1113834723.7086.87.camel@localhost>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Harry Butterworth wrote:

On Mon, 2005-04-18 at 01:00 -0500, Allen Short wrote:
With all due respect, I work on 5 projects that use Twisted and,
overall, they're the easiest codebases to extend that I've dealt with.
xend's code is by far some of the worst Python code I've worked on.

Working on xend has been my first experience of using Python.  Glad to
hear it's atypical :-)
In all fairness, Xend has a complex job that has evolved over time. I don't think it's poorly written rather that it hasn't aged well.

The problem here is that the inter-domain communication primitives are
very low level and separated into a notification channel, a message
channel and a facility for bulk-data transfer which are all provided
independently.  The client of these interfaces must use them together to
make a communications channel but, because they are provided separately
with no constraints on correct relative sequencing of the three
interfaces the complexity from the client's perspective is cubed.
From the perspective of the driver, the IDC primatives shouldn't matter. All a discovery-driver should have to do is maintain a discovery state and examine every message of a certain type and determine how to change it's state and generate additional messages when necessary.

The discovery-drivers should be obvilious to how the messages are actually delivered.

After getting over the hurdle of the inter-domain communication
mechanism, you come to the facts that the requirements for coping with
the domain lifecycle are unspecified, that the existing code doesn't
The domain lifecycle is a fundamental problem it seems. VIRQs are of limited use because they do not tell you what the event was (whether it was a crash or shutdown) or which domain it came from.

Not to mention the fact that you can only ever know about one domain at any point in time. Since you can only look up one domain with getdomaininfo, there's no guarentee that there hasn't been change in between multiple calls.

This is further complicated by the fact that getdomaininfo(domid=4) may return the info for domid=6 forcing you to enumerate domains in sequence order.

Finally, the xend code seems to trust input it receives from domains
which is incompatible with the architectural goal of VM isolation.
This is a very big problem. One very difficult issue to address is how to deal with very hostile domains that may attempt DoS attacks by flooding their own console.

2) Define a high level inter-domain communication API.  This should be
consistent with the cluster model, should define the domain lifecycle
and contain sufficient guarantees for general purpose use. In particular
the API should deal with domain connection/disconnection notification
and elimination of stale communications. The inter-domain communication
API must be compatible with a MAC security implementation.
I'm not sure this is necessary. The registry should all but implement the tools interaction with IDC. The real use will be for console data and there's been talk for a while about moving the console's out of the control channel. This would simplify things even further.

3) Define a dynamic resource discovery mechanism for use, for example,
by FE and BE driver domains.  This mechanism probably ought to be a
service accessible over the inter-domain communication API.
I believe this is the purpose of xenbus.

4) Define a configuration mechanism framework.  The last tools document
I read coupled the configuration aspects to the resource discovery
aspects.  I think they are distinct: the resource discovery mechanism
deals with dynamic changes which are not necessarily under user control
(loss of availability for example) whereas the configuration mechanism
is used by the user or higher level management tools to specify the
desired system configuration.
I'm wary of standardizing configuration although I'm curious to hear thoughts on it.

Anyway, the main points I'm trying to make are that 1) there is a big
discussion that needs to happen on the list to define the architecture
for the tools 2) reimplementing xend better won't address the core
architectural issues 3) choosing a language to implement the tools in is
a second order concern.
I agree with all three points. What I would like to see, and what I am working on now for VM-Tools, is the function of Xend broken up.

I think you need one daemon to multiplex the control channels and do device discovery, and then everything else can be independent tools. With the addition of the registry, the daemon is drastically simplified.

I think the goal should be to have the least amount of code (regardless of language) in whatever is running as a daemon.

Regards,

Harry


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel