From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m Date: Mon, 06 Jul 2015 10:50:49 +0100 Message-ID: <559A6B99020000780008C90D@mail.emea.novell.com> References: <1435774177-6345-1-git-send-email-edmund.h.white@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1435774177-6345-1-git-send-email-edmund.h.white@intel.com> Content-Disposition: inline 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: Tim Deegan , Ravi Sahita , Wei Liu , George Dunlap , Andrew Cooper , Ian Jackson , xen-devel@lists.xen.org, tlengyel@novetta.com, Daniel De Graaf List-Id: xen-devel@lists.xenproject.org >>> On 01.07.15 at 20:09, wrote: > Changes since v2: > > Addressed all v2 feedback *except*: > > In patch 5, the per-domain EPTP list page is still allocated from the > Xen heap. If allocated from the domain heap Xen panics - IIRC on Haswell > hardware when walking the EPTP list during exit processing in patch 6. With this little detail I can't take this as a valid reason not to make this change. Also - weren't we aiming at getting the page from the HAP pool of the domain anyway? > HVM_ops are not merged. Tamas suggested merging the memory access ops, > but in practice they are not as similar as they appear on the surface. > Razvan suggested merging the implementation code in p2m.c, but that is > also not as common as it appears on the surface. > Andrew suggested merging all altp2m ops into one with a subop code in > the input stucture. His point that only 255 ops can be defined is well > taken, but altp2m uses only 2 more ops than the recently introduced > ioreq ops, and <15% of the available ops have been defined. Since we > don't know how to implement XSM hooks and policy with the subop model, > we have not adopted this suggestion. Again, not very convincing an argument, but I'll need to take another look at the patches for a final opinion. > The p2m set/get interface is not modified. The altp2m code needs to > write suppress_ve in 2 places and read it in 1 place. The original > patch series managed this by coupling the state of suppress_ve to the > p2m memory type, which Tim disliked. In v2 of the series, special > set/get interaces were added to access suppress_ve only when required. > Jan has suggested changing the existing interfaces, but we feel this > is inappropriate for this experimental patch series. Changing the > existing interfaces would require a design agreement to be reached > and would impact a large amount of existing code. I continue to think the adjustment should be made as suggested. Jan