Isaku Yamahata wrote:
> On Fri, Mar 28, 2008 at 01:43:23PM +0800, Dong, Eddie wrote:
>
>>> Eventually those running_on_xen checks should be removed somehow.
>>> Are you just thinking that the multi compile with binary patching
>>> should be introduced after the first merge?
>>> Or do you have any
On Fri, Mar 28, 2008 at 01:43:23PM +0800, Dong, Eddie wrote:
> > Eventually those running_on_xen checks should be removed somehow.
> > Are you just thinking that the multi compile with binary patching
> > should be introduced after the first merge?
> > Or do you have any idea other than the multi
Isaku Yamahata wrote:
> Oh, I misunderstood your patch.
> I thought it just revert entry.S to original state. But it
> paravirtualized conver and rfi with running_on_xen check.
> Now I'm convinced that your patch works. Only one comment on
> the patch itself is,
> #ifdef CONFIG_XEN is necessary for
Oh, I misunderstood your patch.
I thought it just revert entry.S to original state. But it
paravirtualized conver and rfi with running_on_xen check.
Now I'm convinced that your patch works. Only one comment on
the patch itself is,
#ifdef CONFIG_XEN is necessary for !CONFIG_XEN case.
Then the lef
Isaku Yamahata wrote:
> Hi Eddie.
>
> I looked into entry.S closely.
> Unfortunately I found that ia64_leave_syscall() and
> ia64_leave_kernel() includes invirtualizable instructions,
> cover instruction with psr.ic = 0 so that those paravirtualization
> is inevitable. (ia64_switch_to() doesn't ne
Hi Eddie.
I looked into entry.S closely.
Unfortunately I found that ia64_leave_syscall() and
ia64_leave_kernel() includes invirtualizable instructions,
cover instruction with psr.ic = 0 so that those paravirtualization
is inevitable. (ia64_switch_to() doesn't need paravirtualization though.)
Doe
