Re: [Xen-devel] [PATCH V2] x86/ioreq server: Fix XenGT couldn't reboot when XenGT use p2m_ioreq_server p2m_type

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.05.17 at 12:21, <george.dunlap@xxxxxxxxxx> wrote:
> On 09/05/17 11:08, Jan Beulich wrote:
>>>>> On 09.05.17 at 11:44, <george.dunlap@xxxxxxxxxx> wrote:
>>> On 09/05/17 22:22, Xiong Zhang wrote:
>>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>>> @@ -502,7 +502,7 @@ static int ept_invalidate_emt_range(struct p2m_domain 
> *p2m,
>>>>   * - zero if no adjustment was done,
>>>>   * - a positive value if at least one adjustment was done.
>>>>   */
>>>> -static int resolve_misconfig(struct p2m_domain *p2m, unsigned long gfn)
>>>> +static int ept_resolve_misconfig(struct p2m_domain *p2m, unsigned long 
>>>> gfn)
>>>
>>> I think while we're renaming this I'd rename this to ept_do_recalc().
>> 
>> Which gets me to ask (once again) what purpose the ept_ prefix
>> has for a static function. I'd rather see this called do_recalc(), and
>> the p2m-pt variant could be left unchanged altogether.
> 
> Well we should have them both named do_recalc() (no prefix), or have
> them both tagged to specify which version they're for.  ISTR people
> complaining about duplicate static symbols making things harder to debug
> (i.e., is this do_recalc() in the stack trace the p2m-pt version or the
> p2m-ept version?), so the latter is probably preferable.

But that's the reason I had done d37d63d4b5 ("symbols: prefix static
symbols with their source file names") - they are distinguishable in
stack traces nowadays.

Jan


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