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/
Home Products Support Community News


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

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] paravirt_ops and its alternatives
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Thu, 31 Jan 2008 11:44:57 +0800
Cc: jeremy@xxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 30 Jan 2008 19:47:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080131014457.GB26750%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <10EA09EFD8728347A513008B6B0DA77A02B655F0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080131014457.GB26750%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchjqwyBfuCUhcwwQxC6js6PAOK5kwADoYpg
Thread-topic: [Xen-ia64-devel] paravirt_ops and its alternatives
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?   

Mmm, Kind of mix. I want to know the gap, and then see how we 
can across the gap:)

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

This work is still useful. If we decide to go with paravirt_ops
we can refer what you have in 2.6.24 kernel, replacing one by one to
paravirt_ops, and it will reduce debug effort in latest kernel.

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

Yes, Alex will work on this I think.

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

Yes. One issue in my mind is that binary patching couldn't solve the 
high level virtualization issues in Xen today such as xen irqchip & dma
patch. It could work for domU but very difficult for dom0 or driver 
domain without these.

X86 side has xen irqchip in Linux upstream today, so it should be ok for
to reuse it since XenLinux-IA64 is same with X86 in this area before

Redhat guys are working on dma support, I think we can rely on them to
it upstream and then we implement IA64 specific things with same

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

Actually paravirt_ops version of X86 Linux doesn;t detect this. In
it put a special initial code in ELF Linux image and let the dom builder
it and start from that point to make sure it is on top of Xen
For VMI stuff, there is a new code in Linux startup sequence to check
if the VMI support ROM exist.

For us, we can use same mechanism right now, Jeremy is working on 
dom0 detection support. Any way that is not a big issue.

CC jeremy & Keir in case they are not in this mailinglist.
thx, eddie

Xen-ia64-devel mailing list