Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Ed White <edmund.h.white@xxxxxxxxx>]

On 01/13/2015 02:21 AM, Tamas K Lengyel wrote:
> On Mon, Jan 12, 2015 at 7:31 PM, Ed White <edmund.h.white@xxxxxxxxx> wrote:
>> On 01/12/2015 10:00 AM, Ian Jackson wrote:
>>> Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies 
>>> of host p2m"):
>>>> The hypercalls are all there. My testing is all done in a Windows
>>>> domU with the tests running inside that domain, so I couldn't use
>>>> tools support even if I had it.
>>>
>>> To support this code in-tree, I think we will need Open Source code
>>> for exercising it, surely ?
>>>
>>
>> I'm hoping that, as Andrew says, there will be people interested
>> in using these capabilities, and that some of them will be prepared
>> to help fill in the gaps. That's why I wanted to send the series to
>> the list very early in the 4.6 development cycle.
>>
>> If that doesn't turn out to be the case, I'll see if I can find some
>> help internally, but I have neither the bandwidth nor the expertise
>> to do everything myself.
>>
>> Ed
> 
> Hi Ed,
> we are certainly very interested in this feature so thanks for posting
> this series!
> 
> I also see a usecase for multiple copies of host p2m by enabling
> better performance for monitoring with the existing memaccess API.
> Currently the problem is that if a memaccess violation occurs on one
> vcpu, the memaccess settings need to be cleared, then re-applied again
> after the operation has passed (usually done via singlestepping). With
> multiple vCPUs there is a potential racecondition here, unless all
> other vCPUs are paused while the memaccess settings are cleared. With
> multiple copies of the host p2m, we could easily just swap in a table
> for the violating vCPU where the permissions are clear, without
> affecting any of the other vCPUs. This could be exercised by extending
> the xen-access test tool!
> 
> Is this something you think would be within scope for the envisioned
> use-case for this series?
> 
> Tamas
> 

Yes, this is definitely within scope. The last patch in the series
adds a request flag to indicate that a memory access violation occurred
in an alternate p2m and a field containing the index of the p2m, and
the response can use the same flag and field to cause a p2m switch
for the violating vcpu.

Ed

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel