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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.06.15 at 19:53, <edmund.h.white@xxxxxxxxx> wrote:
> On 06/24/2015 07:38 AM, Jan Beulich wrote:
>>>>> On 22.06.15 at 20:56, <edmund.h.white@xxxxxxxxx> wrote:
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -237,6 +237,19 @@ struct p2m_domain {
>>>                                         p2m_access_t *p2ma,
>>>                                         p2m_query_t q,
>>>                                         unsigned int *page_order);
>>> +    int                (*set_entry_full)(struct p2m_domain *p2m,
>>> +                                         unsigned long gfn,
>>> +                                         mfn_t mfn, unsigned int 
> page_order,
>>> +                                         p2m_type_t p2mt,
>>> +                                         p2m_access_t p2ma,
>>> +                                         unsigned int sve);
>>> +    mfn_t              (*get_entry_full)(struct p2m_domain *p2m,
>>> +                                         unsigned long gfn,
>>> +                                         p2m_type_t *p2mt,
>>> +                                         p2m_access_t *p2ma,
>>> +                                         p2m_query_t q,
>>> +                                         unsigned int *page_order,
>>> +                                         unsigned int *sve);
>> 
>> I have to admit that I find the _full suffixes here pretty odd. Based
>> on the functionality, they should be _sve. 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.
> 
> I did originally use _sve suffixes. I changed them because there
> may be some future case where these routines control some other
> EPTE bit too. I made them hooks because I thought calling ept...
> functions directly would be a layering violation.

Indeed it would. But thinking about it more, I would suggest to
extend the existing accessors rather than adding new ones.
Just consider what would result when further such return values
are going to be needed in the future: I don't see us adding
_fuller, _fullest, etc variants. Perhaps just make the new output
an optional generic "flags" one. One might even consider folding
it with order, or even consolidate all the outputs into a single
structure.

Jan


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