[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/2] x86: report use of PCID together with reporting XPTI status

>>> On 18.07.18 at 16:47, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 18/07/18 10:19, Jan Beulich wrote:
>>>>> On 18.07.18 at 10:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 18/07/2018 09:33, Jan Beulich wrote:
>>>> --- a/xen/include/asm-x86/spec_ctrl.h
>>>> +++ b/xen/include/asm-x86/spec_ctrl.h
>>>> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>>>>  #define OPT_XPTI_DOM0  0x01
>>>>  #define OPT_XPTI_DOMU  0x02
>>>> +bool xpti_pcid_enabled(void);
>>> This still should be inside an CONFIG_PV to avoid scenarios which will
>>> compile correctly but fail to link.  It should live in pv/domain.h at
>>> which point everything should be fine.
>> It was intentional that I didn't move the declaration: Whether the build
>> fails at the compile or link stage is irrelevant imo.
> It is extremely relevant.
> A compiler error points to the file/line here something is wrong, while
> a linker error says "something somewhere went wrong", and grepping for
> the symbol identified in the error won't be helpful for tracking down
> the problem.

I think you didn't run into linker errors in the last so many years - ld
has become quite good at pointing at the place the reference comes
from. Or maybe this is functionality that can be configured off, but
then I'd say it's a quality issue of your binutils.

>>  All we need is that it
>> fail at all. I would have moved it if its current placement wasn't again
>> very intentional, next to the other XPTI pieces.
> You provided a reasonable justification for why the body of this
> function should be in pv/domain.c  Therefore, its declaration lives in
> pv/domain.h

Then the other XPTI stuff should move there too.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.