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-ia64-devel

Re: [Xen-ia64-devel] paravirt_ops and its alternatives

On Wed, Jan 30, 2008 at 08:23:54PM -0700, Alex Williamson wrote:

>    We discussed this a little on the phone conference today.  It's going
> to be a bit of a learning curve (at least for me), but it should
> probably be in git.  This will allow us to better coordinate with the
> other upstream linux trees and we might even be able to get other
> maintainers to pull from it.

Yes the git rep. is usefull for other maintainers.
So git rep + patch queues sound reasonable.


> Isaku, I think you might be pretty close
> to getting domU booting on 2.6.24, but if it might be a while, perhaps
> you could send out a snapshot.

I see. Anyway please wait until the next week.


>    Yes, I hope the xen machine vector will be useful, but dom0 currently
> still runs with the bare metal machine vector.  I don't know if we can
> get away with that, or somehow make a paravirt wrapper for the machine
> vectors.  For DMA, we've taken the approach of turning the swiotlb and
> sba_iommu drivers into transparently paravirtualized drivers.  These
> don't feel clean enough for upstream as they are, so I hope we can
> abstract the interfaces further.  I would guess for interrupts, we
> probably need to transform the upstream code to create a more modular
> interrupt controller infrastructure.  Then the Xen virtual irq chip
> would just be a driver that plugs into that interface.

Yes, what I mind are also irq chip and dma api.

-- 
yamahata

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