>>> On 01.07.15 at 20:09, <edmund.h.wh...@intel.com> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel