From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m Date: Tue, 13 Jan 2015 11:21:31 +0100 Message-ID: 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: <54B41311.3000309@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ed White Cc: Keir Fraser , Ian Campbell , Ian Jackson , Tim Deegan , "xen-devel@lists.xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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