| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] paravirt_ops and its alternatives
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?
> 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.
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.
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home