|
|
|
|
|
|
|
|
|
|
xen-ppc-devel
Re: [Xen-devel] [PATCH] xencomm, xenmem and hypercall continuation
On Fri, Nov 10, 2006 at 08:03:51AM +0000, Keir Fraser wrote:
> On 10/11/06 5:49 am, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx> wrote:
>
> > fix xenmem hypercall for non-trivial xencomm arch(i.e. ia64, and powerpc)
> > On ia64 and powerpc, guest_handle_add_offset() effect persists over
> > hypercall continuation because its consumed offset is recorced in
> > guest domains memory space.
> > On the other hand, x86 guest_handle_add_offset() effect is volatile
> > over hypercall continuation.
> > So xenmem hypercall(more specifically increase_reservation,
> > decrease_reservaton, populate_memory and exchange) is broken on
> > ia64 and powerpc.
> > #ifdef/ifndef CONFIG_X86 is used to solve this issue without breaking
> > the existing ABI. #ifdef is ugly, but it would be difficult to solve
> > this issue without #ifdef and to preserve the existing ABI simaltaneously.
>
> There must be a cleaner solution. We're not going to ifdef all over the
> place.
>
> Does xencomm have to persist the offset increments in guest memory (does the
> guest depend on this)?
The guest domain doesn't depend on this.
(at least it doesn't on ia64.
Probably on powerpc neither. please correct me if I'm wrong)
The other callers of guest_handle_add_offset() depend on this.
do_multicall() @ xen/common/multicall.c and
guest_console_write() @ xen/drivers/char/console.c.
> Could it undo these effects across continuations so
> that guest_handle_add_offset works properly?
- introduce guest_handle_putback_offset_for_continuation()
(or something like that) and
call it right before hypercall_create_continuation() in memory.c
on x86 define it as nop.
on ia64 and powerpc, define it as something to prepare
hypercall continuation.
leave do_multicall() and guest_console_write() as is.
- introduce guest_handle_add_offset_after_continuatiton() and
replace guest_handle_add_offset() in memory.c with it.
leave do_multicall() and guest_console_write() as is.
- any other better idea?
--
yamahata
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|