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
eventually,
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
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.
>
> 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
us
to reuse it since XenLinux-IA64 is same with X86 in this area before
paravirt_ops.
Redhat guys are working on dma support, I think we can rely on them to
push
it upstream and then we implement IA64 specific things with same
concept.
>
> 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
stead,
it put a special initial code in ELF Linux image and let the dom builder
find
it and start from that point to make sure it is on top of Xen
hypervisor.
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
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home