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

[Alex Williamson <alex.williamson@xxxxxx>]

Hi Isaku & Eddie,

On Thu, 2008-01-31 at 10:44 +0900, Isaku Yamahata wrote:
> On Thu, Jan 31, 2008 at 08:21:51AM +0800, Dong, Eddie wrote:
> > Alex & All:
> 
> Hi Eddie.
> At first I'd like to make it clear. The goal is to merge xenLinux/ia64
> modification into upstream kenrel. Hence reduce maintenane cost
> etc...  And you want to dicuss how to do it. Is this correct?
> 
> Now I'm forward poring domU code to 2.6.24. (In fact to 2.6.24-rc, but
> I'm going to rebase to 2.6.24 release). I haven't got it work yet.
> I'm planning to post it as a single jumbo patch once I get it work.
> 
> To make our collaboration effective, we should have some kind of
> repository for that purpose. What kind of repository is best?
> Considering upstream merge, having our modification as patch queues
> might be easy. But should we also have git or hg repo to track our change?

   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.  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.

> >     Here is a gap analysis for paravirt_ops, can you all comment?
> >     In summary we have 4 catagory of jobs:
> >     1: CPU paravirt_ops including MMU & timer & interrupt
> >     2: Xen hooks
> >     3: irq chip paravirt_ops, xen irq chip or vSAPIC?
> >     4: dma for driver domain
> > 
> >     My understanding is that the effort is almost similar for each
> > part, while all various alternatives such as pre-virtualization, binary
> > patching (privify) or even unmodified Linux as dom0 only save part of #1
> > effort, which means less than 25% effort saving. Do we really want a
> > temporary solution for 25%- effort saving?
> >     So I would suggest we go with paravirt_ops which is the Linux
> > community direction to avoid resource fragmentation.
> >     The writeup is very draft and I am planning to spend more time
> > in investigation, comments are welcome.
> 
> Probably as you know it,  Linux/ia64 already has the machine vector frame
> work so that many basic functinality like dma api are called
> indiretly. So it would be wise to utilize machine vector at first
> and I fact we already defined xen machine vector which is due to
> Alex Williamson. If there were something unsuitable to machine vector,
> then we could introduce pv_ops.
> Anyway this is the only implementation details and how we call it.
> Conceptually they are same.

   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.

> About CPU virtualization.
> Last year I wrote the patch which does binary patching like x86
> paravirt_alt. And I called it paravirt_alt patch.
> But I'm not sure about paravirtulized hand written assembly code.
> I'm afraid Linux people may dislike such code duplication.
> Yes it's possible to use binary patch technique somehow, however
> it is inevitable make the hand written assembly code less readable
> to some extent.
> 
> To detect environment, mov from cpuid can't be used on PV case because
> it isn't privileged instructions. On VT-i environment cpuid can be
> hooked though.
> Current we check only priveleged level on which kenrel is runinng.
> Possibley more sophisticated way is necessary to allow another pv
> technology.

   Yes, we're going to need to work on that.  We need to make sure the
interfaces we're adding are reusable by other paravirtualization
technologies, or upstream will have every right to refuse them.  Thanks,

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


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