Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

[harry]

You are thinking about the code differences from the point of view of the code running inside the domain.  What about the code outside the domain, for example, is the code required to remove a device from one domain and give it to another going to have to be different depending on whether the target domain has been booted yet?


> Message date : Feb 28 2005, 01:01 PM
> From : "Rusty Russell" <rusty@rustcorp.com.au>
> To : harry@hebutterworth.freeserve.co.uk
> Copy to : "Anthony Liguori" <aliguori@us.ibm.com>, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>, "Jeremy Katz" <katzj@redhat.com>, "Xen Mailing List" <xen-devel@lists.sourceforge.net>
> Subject : Re: Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen
> 
> On Mon, 2005-02-28 at 13:22 +0100, harry@hebutterworth.freeserve.co.uk
> wrote:
> > Why have two separate mechanisms when the mechanism required for
> > hotplug can be used to build the tree from scratch?
> 
> The only difference would be the transport for hotplug events, which is
> infrastructure which needs to exist anyway to transport other
> information between domains.
> 
> We'll see when the code's finished, but I see the code being:
> 
> 	__init boot_devtree_setup()
> 	{
> 		devtree_add(boot_devtree_ptr);
> 	}
> 
> 	hotplug_receive_event()
> 	{
> 		receive data
> 		if (op == ADD)
> 			devtree_add(data);
> 		else if (op == REMOVE)
> 			devtree_remove(data);
> 	}
> 
> ie. the mere difference in transport should be a few lines of code.
> Rusty.
> -- 
> A bad analogy is like a leaky screwdriver -- Richard Braakman
> 
> 
> 

-- 

Whatever you Wanadoo:
http://www.wanadoo.co.uk/time/

This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

[Rusty Russell]

On Mon, 2005-02-28 at 14:08 +0100, harry@hebutterworth.freeserve.co.uk
wrote:
> You are thinking about the code differences from the point of view of
> the code running inside the domain.  What about the code outside the
> domain, for example, is the code required to remove a device from one
> domain and give it to another going to have to be different depending
> on whether the target domain has been booted yet?

Fundamentally true, because you can't send a hotplug event to a domain
which hasn't been booted yet.  Whatever your mechanism, the this
difference has to be handled at some level, and I don't think the
difference in transport makes it harder.

Cheers,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

[Harry Butterworth]

No, not fundamentally true.  The registry approach decouples the
generation of the hotplug events from the provider of devices such that
if the domain hasn't booted yet then the provider of devices doesn't
care: the registry will generate all the required hotplug events when
the domain connects after it boots.

As an aside, my previous messages were breaking threading so I changed
from the web based email to Evolution. Should be OK now.

On Tue, 2005-03-01 at 00:32 +1100, Rusty Russell wrote:
> On Mon, 2005-02-28 at 14:08 +0100, harry@hebutterworth.freeserve.co.uk
> wrote:
> > You are thinking about the code differences from the point of view of
> > the code running inside the domain.  What about the code outside the
> > domain, for example, is the code required to remove a device from one
> > domain and give it to another going to have to be different depending
> > on whether the target domain has been booted yet?
> 
> Fundamentally true, because you can't send a hotplug event to a domain
> which hasn't been booted yet.  Whatever your mechanism, the this
> difference has to be handled at some level, and I don't think the
> difference in transport makes it harder.
> 
> Cheers,
> Rusty.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Proposal for init/kexec/hotplug format for Xen

[Keir Fraser]

On 28 Feb 2005, at 13:40, Harry Butterworth wrote:

> No, not fundamentally true.  The registry approach decouples the
> generation of the hotplug events from the provider of devices such that
> if the domain hasn't booted yet then the provider of devices doesn't
> care: the registry will generate all the required hotplug events when
> the domain connects after it boots.

Yes, this is what I envision. Cooking things into binary-encoded device 
trees or hotplug events could also work, and might be less code in the 
guest OS, but I think it's a lerss clean design and would need more 
special-casing in domain0.

  -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

[Rusty Russell]

On Mon, 2005-02-28 at 13:40 +0000, Harry Butterworth wrote:
> No, not fundamentally true.  The registry approach decouples the
> generation of the hotplug events from the provider of devices such that
> if the domain hasn't booted yet then the provider of devices doesn't
> care: the registry will generate all the required hotplug events when
> the domain connects after it boots.

Good point; you are, of course, correct.  Moreover, the Xen guys have
convinced me that they want such a persistent store for other purposes.
So ignore my code and look at an explicit Xen interface to such a store,
rather than having the domain keep track of their own copy.

Cheers,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

[Harry Butterworth]

> So ignore my code and look at an explicit Xen interface to such a store,
> rather than having the domain keep track of their own copy.

I'm trying to get stuck into the USB code as not having finished it is
starting to look a bit lame.  I was assuming that you, Keir and Anthony
were looking at this stuff.

In any case, I'm not sure you want an explicit Xen interface for this.
It should be sufficient to define a good IDC API for Xen and then build
on top of that.

The registry is just a service accessible to a domain using the IDC API.

You need to solve the bootstrap issue for domain 0: two obvious
alternatives: A) have a root registry inside Xen and then domain 0 can
have the same interface as the other domains or B) push everything out
into domain 0 in a platform specific way and then have domain 0 build a
root registry out of the platform specific discovery.

I was under the impression that the architectural direction was to push
as much as possible out of Xen into domain 0 which is consistent with
the second alternative.

In a clustered system with FT domains, the code running in the FT domain
would be provided with access (over the IDC API) to one registry per
base domain which would give it hotplug notification about the devices
accessible via that base domain. This means that the code in the FT
domain would access multiple registries over the IDC API and pool the
results, doing multipathing for any devices which were accessible
through multiple base domains. OK, I'll take my bunny off the boil now.

The key to success is a good IDC API.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Proposal for init/kexec/hotplug format for Xen

[Keir Fraser]

On 1 Mar 2005, at 13:15, Harry Butterworth wrote:

> In any case, I'm not sure you want an explicit Xen interface for this.
> It should be sufficient to define a good IDC API for Xen and then build
> on top of that.
>
> The registry is just a service accessible to a domain using the IDC 
> API.

I think Rusty doesn't really mean a 'Xen' interface. Access to the PS 
will build on the primitives already provided by Xen, requiring no 
extra modifications in the hypervisor.

  -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: Re: Proposal for init/kexec/hotplug format for Xen

[Harry Butterworth]

[The mail reflector seems to have dropped the original of this so here's
another copy for the mail archive]

On Tue, 2005-03-01 at 03:46 +1100, Rusty Russell wrote:

> So ignore my code and look at an explicit Xen interface to such a store,
> rather than having the domain keep track of their own copy.

I'm trying to get stuck into the USB code as not having finished it is
starting to look a bit lame.  I was assuming that you, Keir and Anthony
were looking at this stuff.

In any case, I'm not sure you want an explicit Xen interface for this.
It should be sufficient to define a good IDC API for Xen and then build
on top of that.

The registry is just a service accessible to a domain using the IDC API.

You need to solve the bootstrap issue for domain 0: two obvious
alternatives: A) have a root registry inside Xen and then domain 0 can
have the same interface as the other domains or B) push everything out
into domain 0 in a platform specific way and then have domain 0 build a
root registry out of the platform specific discovery.

I was under the impression that the architectural direction was to push
as much as possible out of Xen into domain 0 which is consistent with
the second alternative.

In a clustered system with FT domains, the code running in the FT domain
would be provided with access (over the IDC API) to one registry per
base domain which would give it hotplug notification about the devices
accessible via that base domain. This means that the code in the FT
domain would access multiple registries over the IDC API and pool the
results, doing multipathing for any devices which were accessible
through multiple base domains. OK, I'll take my bunny off the boil now.

The key to success is a good IDC API.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click