From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed White Subject: Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m Date: Tue, 13 Jan 2015 10:25:36 -0800 Message-ID: <54B56320.9020002@intel.com> References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com> <21683.47957.669490.636018@mariner.uk.xensource.com> <54B406E1.2030309@intel.com> <21684.1959.436449.231273@mariner.uk.xensource.com> <54B40954.3060401@intel.com> <21684.3010.12520.257102@mariner.uk.xensource.com> <54B41311.3000309@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel Cc: Keir Fraser , Ian Campbell , Ian Jackson , Tim Deegan , "xen-devel@lists.xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 01/13/2015 02:21 AM, Tamas K Lengyel wrote: > On Mon, Jan 12, 2015 at 7:31 PM, Ed White 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