[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] (no subject)
Hi, I'm finally to a point where I can start looking at this more closely. I'm trying to wrap my head around the shadow code to figure out the right course of action.* HVMOP_set_mem_access is used to change the p2m_access_t for the target page(s). This should already be implemented I think? * During propagation, I'll check the p2m map to see if I should mask off any permission bits. * On a shadow paging fault, I'll check if the fault was caused by p2m permissions, somehow integrating that with the code for read-only guest page tables safely. Questions: * Just for background, am I correct in my understanding that the log_dirty code is used to track which gfns have been written to by the guest, in order to speed up migration? * Are multiple shadow tables maintained per domain? Is there one per VCPU? One shadow table per guest page table? Is it blown away every time the guest changes CR3? I'm having some trouble tracking this down. * How should I clear/update existing shadow entries after changing the p2m_access_t? Can I clear the shadow tables somehow and force everything to be repopulated? Is that insane? Thanks! On Thu, Nov 15, 2012 at 7:08 AM, Tim Deegan <tim@xxxxxxx> wrote: Bcc: Tim Deegan <tjd-xen@xxxxxxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |