[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m
On Wed, Jan 14, 2015 at 12:09 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>> On 14.01.15 at 11:31, <tamas.lengyel@xxxxxxxxxxxx> wrote: >> On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote: >>>>>> Ed White <edmund.h.white@xxxxxxxxx> 01/13/15 10:32 PM >>> >>>>On 01/13/2015 12:45 PM, Andrew Cooper wrote: >>>>> On 13/01/15 20:02, Ed White wrote: >>>>>> The set of mfn's is the same, but I do allow gfn->mfn mappings to be >>>>>> modified under certain circumstances. One use of this is to point the >>>>>> same VA to different physical pages (with different access permissions) >>>>>> in different p2m's to hide memory changes. >>>>> >>>>> What is the practical use of being able to play paging tricks like this >>>>> behind a VMs back? >>>> >>>>I'm restricted in how much detail I can go into on a public mailing list, >>>>but imagine that you want a data read to see one thing and an instruction >>>>fetch to see something else. >>> >>> How would that work? There can only be one P2M in use at a time, and that's >>> used for both translations. Or are you saying at least one of the two >>> accesses >>> would be emulated nevertheless? >> >> I can see it working by having data fetch access to a page trapped via >> mem_access, while instruction fetch is not. > > Understood, but how do you then carry out the data access? The > question I raised was whether that would then involve emulation. > > Jan At the mem_access trap point you can swap in an altp2m where the gfn->mfn mapping is the one where the breakpoints are hidden, singlestep, then swap the original p2m back. While this approach still has some overhead because of the use of singlestepping, it is going to be faster then what you currently have to do, which is removing all breakpoints, singlestep, then put breakpoints back. Now it would just be a matter of swapping a single pointer. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |