BTW, this patch depends on several patches I sent out earlier, i.e the change
to suspend event channel and the changes to mod_lx_entry, although those
patches don't rely on this one.
Keir, as the page offline support is in HV already, so can this target for 3.4
if it pass the review?
Thanks
Yunhong Jiang
Jiang, Yunhong <> wrote:
> Tim, this is the implementation as discussed.
> The swap_page.patch is for HV side change, basically it call
> the mod_lx_entry to update the table.
> The free_page.patch is the function from user space tools to offlien a page.
>
> Thanks
> Yunhong Jiang
>
> Jiang, Yunhong <> wrote:
>> Tim Deegan <mailto:Tim.Deegan@xxxxxxxxxx> wrote:
>>> At 14:37 +0000 on 19 Feb (1235054276), Jiang, Yunhong wrote:
>>>>
>>>>>> It should be possible to have the tools do all the PTE manipulations
>>>>>> with MMU update hypercalls (I think -- Keir may correct me here). Then
>>>>>> the final hypercall to surrender the page will fail if the grant tables
>>>>>> are wrong; if it does, put the PTEs back and fall back to a live
>>>>>> migration. Isn't that what your in-xen code does anyway?
>>>>
>>>> Tim, after checking the code more carefully, seems currently
>>> the MMU update hypercalls (including mod_lx_entry ) assume it
>>> is for current domain, while in our usage model, it will
>>> update MMU for other domain, so I will try to do following
>>> changes: 1) change mod_lx_entry() to get a domain parameter 2)
>>> Add a new hypercall (or a new command to do_mmu_update ) to
>>> update the MMU for other domain. I'm not sure if there are
>>> other usage model for such requirement, and if such changes
>>> acceptable? Any feedback is welcome.
>>>>
>>>
>>> Sorry for the delay -- I was travelling around the summit and this got
>>> lost. Yes, I think this is an OK approach. I doubt there will be many
>>> other users of such a hypercall since most OSes will get upset by their
>>> PTEs changing under their feet, but I prefer it to the current patch.
>>
>> Sure, I will do this way.
>>
>> Thanks
>> Yunhong Jiang
>>
>>>
>>> Cheers,
>>>
>>> Tim.
>>>
>>> --
>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>> [Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home