Moving this to xen-ia64-devel...
I think it would be great if we could all start working
together on getting the virtual drivers working (for both
VTI and non-VTI), getting multiple domains stable and solid,
and starting to test all the Xen infrastructure built on top
that will hopefully all just work (if we did our jobs right).
Further, it would be great to get all the necessary driver
patches into the main xen-unstable tree so that the same
source can be used for both x86 (32/64) and ia64, with all
differences abstracted into macros in arch-dep include files.
And then to assist Chris Wright and others to ensure that the
Xen virtual drivers get into the mainline Linux source.
Matt made a good start on this, but its really going to
take a community effort to finish. Current status is
that virtual console and virtual disk are working (in
non-VTI), though not very well tested so far and I'm
sure many bugs remain to be shaken out. Several patches
have been submitted (and accepted) upstream but there
are a couple more that require some work before submission.
John is starting on the VNIF driver (non-IPF) and
will post some proposed changes in the next week or so.
Any suggestions on how to divide up this work and
coordinate?
Dan
> -----Original Message-----
> From: Chapman, Matthew (HP Labs Fort Collins)
> Sent: Friday, August 05, 2005 4:25 PM
> To: Arun Sharma
> Cc: Ling, Xiaofeng; Magenheimer, Dan (HP Labs Fort Collins);
> Byrne, John (HP Labs)
> Subject: Re: [Xen-devel] [PATCH] blkif include fixes
>
> Hi Arun,
>
> I've been looking at getting the virtual drivers working in IPF
> Xenlinux, and merging as much as possible back into the original
> Xen drivers. While it is a paravirtualised kernel, we're trying
> to keep the modifications to a minimum, and so I expect most of
> what I've done will be relevant to the unmodified case as well.
>
> The include file rearrangements I sent were simply to get it to
> build with the IPF kernel; previously there were assumptions
> about certain include files including other include files.
>
> Have a look at drivers/xen in:
>
> http://xenbits.xensource.com/ext/xenlinux-ia64-2.6.12.hg
>
> Notice that I have put the "core" code that was previously in
> arch/xen/kernel (event channels, grant tables, etc) in
> drivers/xen/core. I understand that x86 Xen will eventually move
> in this direction too.
>
> We have working console and VBD using the above tree, but
> currently not VNIF.
>
> I've submitted most of the non-IPF-specific patches. I've
> attached a couple of outstanding ones - to convert ctrl_if and
> console to the new bind_evtchn_to_irqhandler interface - but
> these break x86 Xenlinux so I haven't submitted them yet (ctrl_if
> because it's initialised before it's safe to call request_irq;
> and I'm not sure what to do about irq_suspend/irq_resume for
> bind_virq_to_evtchn, maybe there needs to be
> bind_virq_to_irqhandler instead so the evtchn can change
> transparently).
>
> Matt
>
>
> On Fri, Aug 05, 2005 at 02:50:37PM -0700, Arun Sharma wrote:
> > Matt Chapman wrote:
> > >Tested to work on x86 too.
> > >
> > >- include linux/vmalloc.h for vmalloc
> > >- include grant table includes from common.h rather than blkback.c,
> > > since both C files use grant tables
> > >- include linux/version.h from block.h (a macro there uses it)
> > >- include asm-xen/hypervisor.h from block.h (virt_to_machine)
> > >
> >
> > Hi Matt, Xiaofeng and I are working on getting VBD/VNIF working on
> > unmodified Linux on x86 now and IPF in the future. So
> several of your
> > patches look interesting to us.
> >
> > Can you explain what you're trying to accomplish here, so
> that we can
> > coordinate the work?
> >
> > My thinking was to:
> >
> > a) Create a bunch of patches that refactor the VBD/VNIF code without
> > changing anything for the xenlinux case. This should be
> low risk and
> > would be a candidate for 3.0
> >
> > b) Create header files that do things differently for the unmodified
> > case. This is not gated by 3.0 release.
> >
> > We wish to reuse the existing drivers as much as possible,
> rather than
> > forking them.
> >
> > Xiaofeng prototyped this several months ago - but things need to be
> > cleaned up to the point where they can actually be accepted
> upstream.
> >
> > It looks like you're further along on (a). So if you want
> us to review
> > some patches, we'd be very happy to :)
> >
> > -Arun
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home