Re: [Xen-devel] [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.07.15 at 20:09, <edmund.h.white@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel