Re: [PATCH] x86/mem_sharing: Fix build folloing VM Fork work

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/04/2020 23:38, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
> wrote:
>> On 09/04/2020 22:24, Tamas K Lengyel wrote:
>>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>> wrote:
>>>> A default build fails with:
>>>>
>>>>   mem_sharing.c: In function ‘copy_special_pages’:
>>>>   mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use 
>>>> in this function)
>>>>            HVM_PARAM_STORE_PFN,
>>>>            ^~~~~~~~~~~~~~~~~~~
>>>>
>>>> I suspect this is a rebasing issue with respect to c/s 12f0c69f2709 
>>>> "x86/HVM:
>>>> reduce hvm.h include dependencies".
>>>>
>>>> Fixes: 41548c5472a "mem_sharing: VM forking"
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> So staging definitely compiles for me both with and without
>>> CONFIG_MEM_SHARING enabled. By default its off, so this shouldn't even
>>> be compiled so I'm curious what's happening in your build. That said,
>>> I have no objection to the extra include if it turns out to be
>>> actually necessary.
>> Exact config attached.  I've just double checked that staging fails.
>>
>> We should get  to the bottom of exactly what is going on here, if it
>> isn't the obvious thing.
> Strange, with your config it does produce the error. With "echo
> CONFIG_MEM_SHARING=y > .config && XEN_CONFIG_EXPERT=y make
> olddefconfig && make" it does compile.

You lose XEN_CONFIG_EXPERT=y in the second make, so it rewrites your
.config behind your back.  (This behaviour is totally obnoxious).

Diff the current config against original?

~Andrew