I also agree that this would be very useful, and I think the drivers
are stable enough now that it's a good idea.
In addition to the generic xend integration, it would be quite good if
the skeleton frontend/backend contained minimal demonstrator code to
set up a device channel (a.k.a. shared memory page and event mapping)
between the two VMs.
We've talked about having something like this in the tree in the past,
it would clearly be useful for people wanting to write new drivers,
but I think there was fear that it would rot too quickly (and it
certainly would have in the past). If the skeleton driver did
something simple but measurable (for correctness) like ping-pong
between the frontend and backend, we could add it to XenRT and make
sure that it stayed up to date.
just a thought...
a.
On 6/29/06, Ewan Mellor <ewan@xxxxxxxxxxxxx> wrote:
On Thu, Jun 29, 2006 at 02:53:26PM +0100, Nick Logan wrote:
> Ewan Mellor wrote:
>
> >On Wed, Jun 28, 2006 at 04:20:51PM +0100, Nick Logan wrote:
> >
> >
> >
> >>Ewan Mellor wrote:
> >>
> >>
> >>
> >>>On Wed, Jun 28, 2006 at 02:38:15PM +0100, Nick Logan wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The driver was started outside of xend, using a varient of Jacob's
> >>>>buscreate program to set the necessary values in xenstore. As this a
> >>>>3rd party driver, I'm looking for a solution that does not involve xm
> >>>>or xend changes, if that's possible. I'll take a look at the blktap
> >>>>patches to see if that helps.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Xend is explicitly bringing the devices back up on restore. If you
> >>>deliberately bypass it, then you are going to have to do that bringup
> >>>yourself.
> >>>
> >>>Ewan.
> >>>
> >>>
> >>>
> >>>
> >>I guessed that would be the case. The bringup for a restore would be
> >>quite straighforward but more complex for migration. Has anyone
> >>suggested hooks for xend to deal with 3rd party drivers so that it could
> >>initialise and restore devices that are supported by these drivers?
> >>This would enable new drivers to be implemented without changes to xend.
> >>
> >>
> >
> >One would have to write a device handler that parsed generic config, and
> >then
> >passed it through to the store unaltered, and then have hotplug scripts
> >that
> >could cope with this unparsed config. At the moment, the driver backends
> >do
> >special-case things like generating a MAC address when none is supplied,
> >converting device names to their major:minor, that kind of thing. There
> >isn't
> >a generic device path; adding one wouldn't be hard.
> >
> >Ewan.
> >
> >
> Can I just confirm what your proposal is:
>
> Add a generic device config to the xm config file that would contain the
> driver id, virtual device, physical device .....
> Add a generic device handler to xend that would pass the unparsed
> generic config through to xenstore.
> Add a hotplug script that would parse the unparsed config in xenstore
> and start the driver.
> When saving a domain, xend would save the generic device config.
> xend would call restore for the generic devices.
>
> If that's correct, I'll find some time to investigate how this could done.
Yes, that's it. It sounds like something that would be very useful.
Cheers,
Ewan.
_______________________________________________
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
|
Home