[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Questions regarding implementing mem_event for PV
At 18:38 +0000 on 17 Oct (1382031502), Aravindh Puthiyaparambil (aravindp) wrote: > I am looking in to implementing mem_event for PV guests that use PV mmu_ops. > Initially I am thinking of supporting 64-bit PV guests. I think only RW, RX > and R permissions would be possible. I am looking at the hypercall interfaces > that do the pagetable manipulations. In addition to the hypercalls I am also > looking at the pagetable write emulation code. > > My plan is to set the page permissions in: > do_mmu_update() > do_mmuext_op(MMUEXT_PIN_L1_TABLE) > __do_update_va_mapping() > ptwr_emulated_update() > I'm afraid you can't do that, and still support the PV API as it stands. The guest had read access to its pagetables, and it does not expect Xen to change them underfoot. E.g. if you temporarily mark a page as inaccessible and the guest walks its own pagetables to diagnose a page fault, it could see your change and send SIGSEGV to the current process. So if you want to have permissions in the pagetables that aren't the ones the guest asked for, your choices are: (a) use shadow pagetables. This is what the live migration code does in order to intercept writes for tracking memory dirtying. Slow, but should work for most things. (b) Wait for the PVH patch series to go in (and the equivalent series in Linux and FreeBSD kernels). PVH guests are enough like HVM ones in the Xen code that mem_events will be much easier. (b) is probably much eaier, if you have the choice. > The default functions for p2m->set_entry() and p2m->get_entry() > default to the shadow PT variants which I am assuming cannot be used > in the PV cases and I would need to do something along the lines of > mod_l1_entry(). Is this correct? PV guests don't have a p2m in Xen -- they put MFNs directly in their pagetabels and Xen only checks the pagetables for safety. The guest itself will probably have an internal p2m for bookkeeping (and for save/restore) but again Xen isn't allowed to write to it. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |