From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Tue, 16 Feb 2016 07:22:54 +0000 Message-ID: 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> 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: Paul Durrant , George Dunlap Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , "xen-devel@lists.xen.org" , Zhang Yu , "Lv, Zhiyuan" , Jan Beulich , Ian Jackson , Stefano Stabellini , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org > From: Paul Durrant [mailto:Paul.Durrant@citrix.com] > Sent: Friday, February 05, 2016 7:24 PM > > > -----Original Message----- > > From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of > > George Dunlap > > Sent: 05 February 2016 11:14 > > To: Paul Durrant > > Cc: Jan Beulich; George Dunlap; Kevin Tian; Wei Liu; Ian Campbell; Andrew > > Cooper; Zhang Yu; xen-devel@lists.xen.org; Stefano Stabellini; > > zhiyuan.lv@intel.com; Ian Jackson; Keir (Xen.org) > > Subject: Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter > > max_wp_ram_ranges. > > > > On Fri, Feb 5, 2016 at 9:24 AM, Paul Durrant > > wrote: > > > Utilizing the default server is a backwards step. GVT-g would have to use > > the old HVM_PARAM mechanism to cause it's emulator to become default. I > > think a more appropriate mechanism would be p2m_mmio_write_dm to > > become something like 'p2m_ioreq_server_write' and then have a hypercall > > to allow it to be mapped to a particular ioreq server. > > > Obviously only one could claim it but, with a p2t, the bit could be re- > > purposed to simply mean 'go look in the p2t' for more information and then > > the p2t could be structured to allow emulations to be steered to one of many > > ioreq servers (for read and/or write emulation). > > > > Right; I had in mind that Xen would allow at any given time a max of N > > ioreq servers to register for mmio_write_dm ranges, first-come > > first-served; with 'N' being '1' to begin with. If a second ioreq > > server requested mmio_write_dm functionality, it would get -EBUSY. > > This would allow their current setup (one qemu dm which doesn't do > > mmio_write_dm, one xengt dm which does) to work without needing to > > worry any more about how many pages might need to be tracked (either > > for efficiency or correctness). > > > > We could then extend this to some larger number (4 seems pretty > > reasonable to me) either by adding an extra 3 types, or by some other > > method (such as the one Paul suggests). > > I think it would be best to do away with the 'write dm' name though. I would like to see it > be possible to steer reads+writes, as well as writes (and maybe just reads?) to a particular > ioreq server based on type information. So maybe we just call the existing type > 'p2m_ioreq_server' and then, in the absence of a p2t, hardcode this to go to whichever > emulator makes the new TBD hypercall. > I think we need a proper design at this point. Given that it's Chinese New Year maybe I'll > have a stab in Yu's absence. > Hi, Paul, what about your progress on this? My feeling is that we do not need a new hypercall to explicitly claim whether a ioreq server wants to handle write requests. It can be implicitly marked upon whether a specific page is requested for write-protection through a specific ioreq channel, and then that ioreq server will claim the attribute automatically. Thanks Kevin