Re: [Xen-devel] [PATCH v2 07/12] x86/altp2m: add control of suppress_ve.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.07.15 at 20:29, <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 07/06/2015 06:35 PM, Ed White wrote:
>> I certainly don't want to speak for Jan, but my reading of his
>> comments suggests that wouldn't be enough to satisfy him. He
>> seemed to me to object to the whole idea of adding something
>> specifically to handle suppress_ve, and thought any change should
>> offer a more general 'control extra (E)PTE bits' interface.
> 
> I understood Jan's objection to be to adding two extra hooks ("But then
> it seems questionable how they could be useful to the generic p2m layer
> anyway, i.e. why there would need to be such hooks in the first
> place."), instead of just adding an extra field to the existing
> [gs]et_p2m_entry() ("But thinking about it more, I would suggest to
> extend the existing accessors rather than adding new ones.")
> 
> He does suggest the idea of making the interface generic, by for example
> making it an extentable "flags" argument, or by changing the whole thing
> to accept a pointer to a struct, rather than adding more and more
> arguments that need to be set (and which, like p2m_access_t, almost
> everybody just either uses the default or passes on what was passed to
> them), add a pointer to a struct ("One might even consider folding it
> with order, or even consolidate all the outputs into a single
> structure.") But I think that may be a clean-up thing we do next round.
> 
> The first quote above isn't 100% clear, so I can see why you might think
> he meant not to expose SVE directly.

Indeed you split it up exactly like it was meant: No new, redundant
hook is a requirement in my view, and consolidating the multitude of
parameters would be a (rather desirable) cleanup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel