From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Wed, 17 Feb 2016 08:58:29 +0000 Message-ID: <18f9277a243247739d1565f71accca8f@AMSPEX02CL03.citrite.net> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <56B1C93002000078000CDD4B@prv-mh.provo.novell.com> <6b6d0558d3c24f9483ad41d88ced9837@AMSPEX02CL03.citrite.net> <56B2023E02000078000CE01A@prv-mh.provo.novell.com> <7316ea5cb41543d69d7727721368e3c8@AMSPEX02CL03.citrite.net> <56B207EA02000078000CE0A8@prv-mh.provo.novell.com> <9467b97e15bc4cb1b8d6c948ad4fc926@AMSPEX02CL03.citrite.net> <56B20BFA02000078000CE0E7@prv-mh.provo.novell.com> <621ce95774ac4742b96ed9d504c08670@AMSPEX02CL03.citrite.net> <22194.4639.132613.604758@mariner.uk.xensource.com> <56B310D7.7010506@linux.intel.com> <44e528cd11744242961d46c6f87d2bb9@AMSPEX02CL03.citrite.net> <56B31C1C.3000907@linux.intel.com> <56B3373B02000078000CE86C@prv-mh.provo.novell.com> <22195.21299.624759.118961@mariner.uk.xensource.com> <56B3695E02000078000CE9D1@prv-mh.provo.novell.com> <56B38675.3050008@citrix.com> <56B46C3302000078000CEDF4@prv-mh.provo.novell.com> <012513b81f7b4da9af251d942ebae66c@AMSPEX02CL03.citrite.net> <4d9512d6068946e0921a784705f2d3f4@AMSPEX02CL03.citrite.net> <56C3092302000078000D28BE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kevin Tian , Jan Beulich Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , Zhang Yu , George Dunlap , "xen-devel@lists.xen.org" , Stefano Stabellini , "Lv, Zhiyuan" , Ian Jackson , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- [snip] > > > > > > > > I'm afraid I have made little progress due to the distractions of trying > get > > > > some patches into Linux but my thoughts are around replacing the > > > > HVM_mmio_write_dm with something like HVM_emulate_0 (i.e. the > zero- > > > th example > > > > of a type that requires emulation, to be followed by others in future) > and > > > > then add a hypercall along the lines of > > > HVMOP_map_mem_type_to_ioreq_server > > > > which will take an ioerq server id, a type and flags saying whether it > wishes > > > > to handle reads and/or writes to that type. > > > > > > > > Thoughts (anyone)? > > > > > > I think as a general idea also allowing reads to be intercepted is > > > nice, but would incur quite a few changes which we don't currently > > > have a user for. Hence I'd suggest making the public interface > > > ready for that without actually implementing hypervisor support. > > > > > > > Well, we need some form a hypervisor support to replace what's already > there. > > > > I'd envisaged that setting HVM_emulate_0 type on a page would mean > nothing until an > > for "mean nothing" what is the default policy then if guest happens to access > it > before any ioreq server claims it? > My thoughts were that, since no specific emulation has yet been requested (because no ioreq server has yet claimed it) that the default policy is to treat it as r/w RAM as I said below. This is because I think the only legal type transitions should be from HVMMEM_ram_rw to HVMMEM_emulate_0 and back again. > > ioreq server claims it (i.e. it stays as r/w RAM) but when the ioreq server > makes the claim > > the EPT is changed according to whether reads and/or writes are wanted > and then the fault > > handler steers transactions to the (single at the moment) ioreq server. I'll > need to code up > > a PoC to make sure I'm not barking up the wrong tree though. > > > > Curious any reason why we must have a HVM_emulate_0 placeholder > first and why we can't allow ioreq server to claim on any existing type? Which type were you thinking of? Remember that the ioreq server would be claiming *all* pages of that type. > Thinking about XenGT usage, I cannot envisage when a page should > be set to HVM_emulate_0 first. The write-protection operation is dynamic > according to guest page table operations, upon which we'll directly jump > to claim phase... I don't imagine that things would happen that way round in the common case. For XenGT I'd expect the ioreq server to immediately claim HVMMEM_emulate_0 and then set that type on any page that it wants to trap accesses on (which means that I am assuming that the same emulation - i.e. write accesses only - is desired for all pages... but I think that is indeed the case). > > btw does this design consider the case where multiple ioreq servers > may claim on same page? Yes it does and there are currently insufficient page types to allow any more than a single ioreq server to claim a type. My plan is that, in future, we can add a p2t mapping table to allow for more types and then introduce HVMMEM_ioreq_1, HVMMEM_ioreq_2, etc. > For example, different usages may both > want to capture write requests on the same set of pages (say XenGT > selectively write-protects a subset of pages due to shadow GTT, while > another agent wants to monitor all guest writes to any guest memory > page). Monitoring is a different thing altogether. Emulation is costly and not something you'd want to use for that purpose. If you want to monitor writes then log-dirty already exists for that purpose. > > Thanks > Kevin I hope my explanation helped. I think things will be clearer once I've had chance to actually put together a design doc. and hack up a PoC (probably only for EPT at first). Paul