Thanks very much for your detailed answer.
What I am doing is that:
I add a monitor in hypervisor to monitor some behaviors (like system call) of HVM domU.
If that behavior happens, the monitor 1) pauses this domU , 2) notify dom0.
When dom0 gets the notification, it makes a decision, like killing the process (who calls system-call) in domU, or not.
Then hypervisor gets the killing request. To do the killing, I implement like this:
1) set the domU's page, which contains the EIP before paused, NX (none-execute) in shadow page table;
2) then unpause domU
3) then domU will invoke a #PF. Hypervisor can catch this #PF, and then kill the process in domU .
So, I have to modify the domU's shadow PT in dom0's context, to make the domU trap into hypervisor.
Am I right? or is there a better way to make a paused domU trap into hypervisor?
 To pause domU, I call domain_pause_for_debugger();
 To kill a process in domU, I call vmx_inject_hw_exception(v, TRAP_gp_fault, 0);
email:wubingzheng@xxxxxxx在2009-08-26，"Tim Deegan" <Tim.Deegan@xxxxxxxxxx> 写道：
>At 09:35 +0100 on 26 Aug (1251279335), Wu Bingzheng wrote:
>> Can Xen hypervisor modify HVM domU's Shadow page table, under the
>> dom0's context, like trapped from dom0's hypercall?
>Yes, and it sometimes does (e.g. dom0 hypercalls that change domU's p2m
>tables cause changes indirectly in the shadows).
>> I think it have to call 2 functions at least: guest_walk_tables() and
>> flush_tlb_all(). Can these 2 functions called in dom0's context?
>Yes, but they're not nearly enough to safely modify the shadow
>pagetables. There's a lot of reference-counting and concurrency code in
>there. The paging_* function calls are really the only sensible way to
>interact with the shadow pagetables code.
>> In my test, if hypervisor tries to modify HVM's shadow page table, it
>> will bring down the whole system. I am not sure what's the reason.
>Why do you want to modify the shadow pagetables from dom0? They're
>probably the wrong place to be trying to do things since (a) they don't
>exist on EPT/NPT-capable hardware, and (b) they can get discarded and
>rebuilt by Xen at any time.
>Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>Principal Software Engineer, Citrix Systems (R&D) Ltd.
>[Company #02300071, SL9 0DZ, UK.]
Xen-devel mailing list