[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.