Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.17 at 17:04, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/02/17 12:36, Jan Beulich wrote:
>>>>> On 13.02.17 at 12:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v);
>>>  int paging_set_allocation(struct domain *d, unsigned int pages,
>>>                            bool *preempted);
>>>  
>>> +/* Maxphysaddr supportable by the paging infrastructure. */
>>> +static inline unsigned int paging_max_paddr_bits(const struct domain *d)
>>> +{
>>> +    unsigned int bits = paging_mode_hap(d) ? hap_paddr_bits : paddr_bits;
>>> +
>>> +    if ( !IS_ENABLED(BIGMEM) && paging_mode_shadow(d) &&
>>> +         (!is_pv_domain(d) || opt_allow_superpage) )
>>> +    {
>>> +        /* Shadowed superpages store GFNs in 32-bit page_info fields. */
>>> +        bits = min(bits, 32U + PAGE_SHIFT);
>>> +    }
>>> +
>>> +    return bits;
>>> +}
>> Does this really need to be an inline function? With the overall goal
>> of not including every header everywhere, I particularly dislike the
>> need to include xen/kconfig.h here for things to build.
> 
> It is not on a critically path, but it seems wasteful to force something
> this small to be out of line.
> 
> As for kconfig.h, it is tiny.  What is the problem with adding it here? 
> We already pull generated/autoconf.h into everything via xen/config.h

Well, it's a general pattern, and hence should be of concern
irrespective of header size. Furthermore including such generic
headers in a frequently used header like this one will sooner or
later unavoidably lead to its explicit inclusion being omitted from
other source files. That in turn will require a patch touching
perhaps many unrelated files, should the inclusion in the header
here ever be removed again.

But no, I'm not intending to block the patch because of this
aspect, I merely wanted you to reconsider the placement.

Jan


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