Hi Espen.
I think the issues exist in all functions in linux kernel
which uses MMU_MACHPHYS_UPDATE. gnttab_copy_grant_page(),
netbk_gop_frag(), xennet_get_responses() and netif_release_rx_bufs_flip()
The p2m/m2p table manipulation is done by MMU_MACHPHYS_UPDATE on x86.
(More exactly the p2m operation is done in linux kernel on x86.)
So at the line after steal_page(), the p2m/m2p table is supposed to be
already updated. It implys that iommu is also supposed to be
updated already.
Although I know that grant table page transfer is obsoleted,
what is the expected exact semantics of GNTTABOP_transfer with
the p2m/m2p table?
I suppose the right fix would be
- revert this patch and
- put the iommu opration of pv domain into MMU_MACHPHYS_UPDATE.
Some comments on xen/ia64 side:
This patch breaks xen/ia64 grant table page transfer.
When I made netback/netfront work on ia64, I thought the tranfer
operation shouldn't change the m2p/p2m table.
On the other hand, I didn't want to add new hypecall to manipulate
the m2p/p2m table for auto translated mode that corresponds
to MMU_MACHPHYS_UPDATE and set_phys_to_machine().
So I worked around it such that xen/ia64 steal_page() does
the p2m/m2p manipulation and fill new page after page owner change.
(There is a risk to fail to allocate a new page during page tranfer,
though.)
thanks
On Fri, May 23, 2008 at 01:30:16PM +0100, Espen Skoglund wrote:
> Mapping should be removed from current domain's p2m table when doing a
> grant table transfer.
>
> Signed-off-by: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
>
>
> ================================================================
> diff -r 2e6a51378451 xen/common/grant_table.c
> --- a/xen/common/grant_table.c Thu May 22 15:11:06 2008 +0100
> +++ b/xen/common/grant_table.c Fri May 23 13:23:56 2008 +0100
> @@ -1073,6 +1073,8 @@
> gop.status = GNTST_bad_page;
> goto copyback;
> }
> +
> + guest_physmap_remove_page(d, gop.mfn, mfn, 0);
>
> /* Find the target domain. */
> if ( unlikely((e = rcu_lock_domain_by_id(gop.domid)) == NULL) )
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
--
yamahata
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|