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

[George Dunlap <george.dunlap@citrix.com>]

On 09/05/17 11:08, Jan Beulich wrote:
>>>> On 09.05.17 at 11:44, <george.dunlap@citrix.com> 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.

"p2m_pt_" does seem like kind of a long prefix, but that seems to be
what the rest of the p2m_pt.c functions are called, so at this point
it's probably best to follow suit.

 -George

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