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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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