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

[Ed White <edmund.h.white@xxxxxxxxx>]

On 06/25/2015 11:04 PM, Jan Beulich wrote:
>>>> On 25.06.15 at 18:36, <edmund.h.white@xxxxxxxxx> wrote:
>> On 06/25/2015 01:12 AM, Jan Beulich wrote:
>>>>>> 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.
>>
>> The new functions are called in 3 places only, so changing them
>> later would have minimal impact. The existing functions are called
>> in many, many places. I *really* don't want to go changing the
>> amount of existing code that doing what you suggest would entail
>> at this late stage.
> 
> I continue to think differently (and I don't consider "at this late
> stage" a particularly relevant argument), but the maintainer will
> have the final say anyway - George?
> 

The patch as it is now doesn't disturb (and risk breaking) any
existing code. I'd much rather stick with that for 4.6, even if
only on the condition that I have to change it later. If I do
what you suggest, that sets me up to fail to get anything in
4.6. That may not matter to you, but it matters to me.

Ed


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