Hi,
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 [1], 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 [2].
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?
[1] To pause domU, I call domain_pause_for_debugger(); [2] To kill a process in domU, I call vmx_inject_hw_exception(v, TRAP_gp_fault, 0);
Thanks, Wu
email:wubingzheng@xxxxxxx在2009-08-26,"Tim Deegan" <Tim.Deegan@xxxxxxxxxx> 写道: >Hi, > >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. > >Cheers, > >Tim. > >-- >Tim Deegan <Tim.Deegan@xxxxxxxxxx> >Principal Software Engineer, Citrix Systems (R&D) Ltd. >[Company #02300071, SL9 0DZ, UK.]
没有广告的终身免费邮箱,www.yeah.net
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|