Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 19/03/2009 09:57, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>>> Thirdly, perhaps this makes more sense as a MMU_* op hanging off
>>> mmu_update()? That call takes pairs of u64 values, which could give you
>>> the space you require. Then you can add a nice comment explaining how
>>> your new command differs from MMU_NORMAL_PT_UPDATE.
>>
>> I turn to the mmu_ext_op because it has only 1 entry left. So do you mean
>> it is ok to be there?
>
> Yes, I think it makes most sense there. It's close in behaviour to
> MMU_NORMAL_PT_UPDATE, except for the 'foreigness'.
>
> -- Keir
This is updated version.
Instead of add a new mmu_*op, I try to change the MMU_NORMAL_PT_UPDATE to
support update foreign page table. There will be some restirction for it,
including the pagetable and the new mfn pointed should be owned by same domain,
and the domain should be suspeneded already. The update_foregin_pt.patch is for
this. I'm not sure if this method is feasible.
The exchange_page.patch is to replace a mfn with a new one. Although there is
already a memory_exchange hypercall, but that hypercall will not accept new
page, add that support will break current ABI. Also it does not support foreign
domain. This function add those support
The other two have not much changes. The only change is the user space tools
need two hypercall, one is to update the page table, while the second is to
exchange the pages.
Please have a look on it.
Thanks
Yunhong Jiang
writable_p2m.patch
Description: writable_p2m.patch
update_foriegn_pt.patch
Description: update_foriegn_pt.patch
free_page.patch
Description: free_page.patch
exchange_page.patch
Description: exchange_page.patch
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|