diff mbox series

[2/6] x86/mm: p2m_add_foreign() is HVM-only

Message ID cf4569c5-a9c5-7b4b-d576-d1521c369418@suse.com (mailing list archive)
State New, archived
Headers show
Series x86/p2m: restrict more code to build just for HVM | expand

Commit Message

Jan Beulich Dec. 15, 2020, 4:26 p.m. UTC
This is together with its only caller, xenmem_add_to_physmap_one(). Move
the latter next to p2m_add_foreign(), allowing this one to become static
at the same time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

Comments

Andrew Cooper Dec. 17, 2020, 7:18 p.m. UTC | #1
On 15/12/2020 16:26, Jan Beulich wrote:
> This is together with its only caller, xenmem_add_to_physmap_one().

I can't parse this sentence.  Perhaps "... as is it's only caller," as a
follow-on from the subject sentence.

>  Move
> the latter next to p2m_add_foreign(), allowing this one to become static
> at the same time.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>, although...

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2639,7 +2646,114 @@ int p2m_add_foreign(struct domain *tdom,
>      return rc;
>  }
>  
> -#ifdef CONFIG_HVM
> +int xenmem_add_to_physmap_one(
> +    struct domain *d,
> +    unsigned int space,
> +    union add_to_physmap_extra extra,
> +    unsigned long idx,
> +    gfn_t gpfn)
> +{
> +    struct page_info *page = NULL;
> +    unsigned long gfn = 0 /* gcc ... */, old_gpfn;
> +    mfn_t prev_mfn;
> +    int rc = 0;
> +    mfn_t mfn = INVALID_MFN;
> +    p2m_type_t p2mt;
> +
> +    switch ( space )
> +    {
> +        case XENMAPSPACE_shared_info:
> +            if ( idx == 0 )
> +                mfn = virt_to_mfn(d->shared_info);
> +            break;
> +        case XENMAPSPACE_grant_table:
> +            rc = gnttab_map_frame(d, idx, gpfn, &mfn);
> +            if ( rc )
> +                return rc;
> +            break;
> +        case XENMAPSPACE_gmfn:
> +        {
> +            p2m_type_t p2mt;
> +
> +            gfn = idx;
> +            mfn = get_gfn_unshare(d, gfn, &p2mt);
> +            /* If the page is still shared, exit early */
> +            if ( p2m_is_shared(p2mt) )
> +            {
> +                put_gfn(d, gfn);
> +                return -ENOMEM;
> +            }
> +            page = get_page_from_mfn(mfn, d);
> +            if ( unlikely(!page) )
> +                mfn = INVALID_MFN;
> +            break;
> +        }
> +        case XENMAPSPACE_gmfn_foreign:
> +            return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
> +        default:
> +            break;

... seeing as the function is moving wholesale, can we at least correct
the indention, to save yet another large churn in the future?  (If it
were me, I'd go as far as deleting the default case as well.)

~Andrew
Jan Beulich Dec. 18, 2020, 8:48 a.m. UTC | #2
On 17.12.2020 20:18, Andrew Cooper wrote:
> On 15/12/2020 16:26, Jan Beulich wrote:
>> This is together with its only caller, xenmem_add_to_physmap_one().
> 
> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
> follow-on from the subject sentence.

Yeah, changed along these lines.

>>  Move
>> the latter next to p2m_add_foreign(), allowing this one to become static
>> at the same time.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> , although...
> 
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2639,7 +2646,114 @@ int p2m_add_foreign(struct domain *tdom,
>>      return rc;
>>  }
>>  
>> -#ifdef CONFIG_HVM
>> +int xenmem_add_to_physmap_one(
>> +    struct domain *d,
>> +    unsigned int space,
>> +    union add_to_physmap_extra extra,
>> +    unsigned long idx,
>> +    gfn_t gpfn)
>> +{
>> +    struct page_info *page = NULL;
>> +    unsigned long gfn = 0 /* gcc ... */, old_gpfn;
>> +    mfn_t prev_mfn;
>> +    int rc = 0;
>> +    mfn_t mfn = INVALID_MFN;
>> +    p2m_type_t p2mt;
>> +
>> +    switch ( space )
>> +    {
>> +        case XENMAPSPACE_shared_info:
>> +            if ( idx == 0 )
>> +                mfn = virt_to_mfn(d->shared_info);
>> +            break;
>> +        case XENMAPSPACE_grant_table:
>> +            rc = gnttab_map_frame(d, idx, gpfn, &mfn);
>> +            if ( rc )
>> +                return rc;
>> +            break;
>> +        case XENMAPSPACE_gmfn:
>> +        {
>> +            p2m_type_t p2mt;
>> +
>> +            gfn = idx;
>> +            mfn = get_gfn_unshare(d, gfn, &p2mt);
>> +            /* If the page is still shared, exit early */
>> +            if ( p2m_is_shared(p2mt) )
>> +            {
>> +                put_gfn(d, gfn);
>> +                return -ENOMEM;
>> +            }
>> +            page = get_page_from_mfn(mfn, d);
>> +            if ( unlikely(!page) )
>> +                mfn = INVALID_MFN;
>> +            break;
>> +        }
>> +        case XENMAPSPACE_gmfn_foreign:
>> +            return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
>> +        default:
>> +            break;
> 
> ... seeing as the function is moving wholesale, can we at least correct
> the indention, to save yet another large churn in the future?  (If it
> were me, I'd go as far as deleting the default case as well.)

Oh, indeed. I did look for obvious style issues but didn't spot this
(still quite obvious) one. I've done so and also added blank lines
between the case blocks.

Jan
Jan Beulich Dec. 21, 2020, 8:10 a.m. UTC | #3
On 17.12.2020 20:18, Andrew Cooper wrote:
> On 15/12/2020 16:26, Jan Beulich wrote:
>> This is together with its only caller, xenmem_add_to_physmap_one().
> 
> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
> follow-on from the subject sentence.
> 
>>  Move
>> the latter next to p2m_add_foreign(), allowing this one to become static
>> at the same time.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

So I had to ask Andrew to revert this (I was already at home when
noticing the breakage), as it turned out to break the shim build.
The problem is that xenmem_add_to_physmap() is non-static and
hence can't be eliminated altogether by the compiler when !HVM.
We could make the function conditionally static
"#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
looks uglier to me than this extra hunk:

--- unstable.orig/xen/common/memory.c
+++ unstable/xen/common/memory.c
@@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
     union add_to_physmap_extra extra = {};
     struct page_info *pages[16];
 
-    ASSERT(paging_mode_translate(d));
+    if ( !paging_mode_translate(d) )
+    {
+        ASSERT_UNREACHABLE();
+        return -EACCES;
+    }
 
     if ( xatp->space == XENMAPSPACE_gmfn_foreign )
         extra.foreign_domid = DOMID_INVALID;

Andrew, please let me know whether your ack stands with this (or
said alternative) added, or whether you'd prefer me to re-post.

Jan
Andrew Cooper Dec. 22, 2020, 10:40 a.m. UTC | #4
On 21/12/2020 08:10, Jan Beulich wrote:
> On 17.12.2020 20:18, Andrew Cooper wrote:
>> On 15/12/2020 16:26, Jan Beulich wrote:
>>> This is together with its only caller, xenmem_add_to_physmap_one().
>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>> follow-on from the subject sentence.
>>
>>>  Move
>>> the latter next to p2m_add_foreign(), allowing this one to become static
>>> at the same time.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> So I had to ask Andrew to revert this (I was already at home when
> noticing the breakage), as it turned out to break the shim build.
> The problem is that xenmem_add_to_physmap() is non-static and
> hence can't be eliminated altogether by the compiler when !HVM.
> We could make the function conditionally static
> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
> looks uglier to me than this extra hunk:
>
> --- unstable.orig/xen/common/memory.c
> +++ unstable/xen/common/memory.c
> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>      union add_to_physmap_extra extra = {};
>      struct page_info *pages[16];
>  
> -    ASSERT(paging_mode_translate(d));
> +    if ( !paging_mode_translate(d) )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return -EACCES;
> +    }
>  
>      if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>          extra.foreign_domid = DOMID_INVALID;
>
> Andrew, please let me know whether your ack stands with this (or
> said alternative) added, or whether you'd prefer me to re-post.

Yeah, this is probably neater than the ifdefary.  My ack stands.

~Andrew
Oleksandr Tyshchenko Jan. 4, 2021, 4:57 p.m. UTC | #5
Hello all.

[Sorry for the possible format issues]

On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 21/12/2020 08:10, Jan Beulich wrote:
> > On 17.12.2020 20:18, Andrew Cooper wrote:
> >> On 15/12/2020 16:26, Jan Beulich wrote:
> >>> This is together with its only caller, xenmem_add_to_physmap_one().
> >> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
> >> follow-on from the subject sentence.
> >>
> >>>  Move
> >>> the latter next to p2m_add_foreign(), allowing this one to become
> static
> >>> at the same time.
> >>>
> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > So I had to ask Andrew to revert this (I was already at home when
> > noticing the breakage), as it turned out to break the shim build.
> > The problem is that xenmem_add_to_physmap() is non-static and
> > hence can't be eliminated altogether by the compiler when !HVM.
> > We could make the function conditionally static
> > "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
> > looks uglier to me than this extra hunk:
> >
> > --- unstable.orig/xen/common/memory.c
> > +++ unstable/xen/common/memory.c
> > @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
> >      union add_to_physmap_extra extra = {};
> >      struct page_info *pages[16];
> >
> > -    ASSERT(paging_mode_translate(d));
> > +    if ( !paging_mode_translate(d) )
> > +    {
> > +        ASSERT_UNREACHABLE();
> > +        return -EACCES;
> > +    }
> >
> >      if ( xatp->space == XENMAPSPACE_gmfn_foreign )
> >          extra.foreign_domid = DOMID_INVALID;
> >
> > Andrew, please let me know whether your ack stands with this (or
> > said alternative) added, or whether you'd prefer me to re-post.
>
> Yeah, this is probably neater than the ifdefary.  My ack stands.
>
> ~Andrew
>

I might miss something or did incorrect tests, but ...
... trying to build current staging
(7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
not set) I got the following:

/media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
undefined reference to `xenmem_add_to_physmap_one'
/media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`xenmem_add_to_physmap_one'
ld:
/media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
hidden symbol `xenmem_add_to_physmap_one' isn't defined
ld: final link failed: Bad value

It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
support via menuconfig manually before building).
Jan Beulich Jan. 5, 2021, 8:48 a.m. UTC | #6
On 04.01.2021 17:57, Oleksandr Tyshchenko wrote:
> Hello all.
> 
> [Sorry for the possible format issues]
> 
> On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
> wrote:
> 
>> On 21/12/2020 08:10, Jan Beulich wrote:
>>> On 17.12.2020 20:18, Andrew Cooper wrote:
>>>> On 15/12/2020 16:26, Jan Beulich wrote:
>>>>> This is together with its only caller, xenmem_add_to_physmap_one().
>>>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>>>> follow-on from the subject sentence.
>>>>
>>>>>  Move
>>>>> the latter next to p2m_add_foreign(), allowing this one to become
>> static
>>>>> at the same time.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> So I had to ask Andrew to revert this (I was already at home when
>>> noticing the breakage), as it turned out to break the shim build.
>>> The problem is that xenmem_add_to_physmap() is non-static and
>>> hence can't be eliminated altogether by the compiler when !HVM.
>>> We could make the function conditionally static
>>> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
>>> looks uglier to me than this extra hunk:
>>>
>>> --- unstable.orig/xen/common/memory.c
>>> +++ unstable/xen/common/memory.c
>>> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>>>      union add_to_physmap_extra extra = {};
>>>      struct page_info *pages[16];
>>>
>>> -    ASSERT(paging_mode_translate(d));
>>> +    if ( !paging_mode_translate(d) )
>>> +    {
>>> +        ASSERT_UNREACHABLE();
>>> +        return -EACCES;
>>> +    }
>>>
>>>      if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>>>          extra.foreign_domid = DOMID_INVALID;
>>>
>>> Andrew, please let me know whether your ack stands with this (or
>>> said alternative) added, or whether you'd prefer me to re-post.
>>
>> Yeah, this is probably neater than the ifdefary.  My ack stands.
>>
>> ~Andrew
>>
> 
> I might miss something or did incorrect tests, but ...
> ... trying to build current staging
> (7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
> not set) I got the following:
> 
> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
> undefined reference to `xenmem_add_to_physmap_one'
> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `xenmem_add_to_physmap_one'
> ld:
> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
> hidden symbol `xenmem_add_to_physmap_one' isn't defined
> ld: final link failed: Bad value
> 
> It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
> support via menuconfig manually before building).

The specific .config may matter. The specific compiler version may
also matter. Things work fine for me, both for the shim config and
a custom !HVM one, with gcc10.

Jan
Oleksandr Tyshchenko Jan. 8, 2021, 4:38 p.m. UTC | #7
On 05.01.21 10:48, Jan Beulich wrote:

Hi Jan


> On 04.01.2021 17:57, Oleksandr Tyshchenko wrote:
>> Hello all.
>>
>> [Sorry for the possible format issues]
>>
>> On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
>> wrote:
>>
>>> On 21/12/2020 08:10, Jan Beulich wrote:
>>>> On 17.12.2020 20:18, Andrew Cooper wrote:
>>>>> On 15/12/2020 16:26, Jan Beulich wrote:
>>>>>> This is together with its only caller, xenmem_add_to_physmap_one().
>>>>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>>>>> follow-on from the subject sentence.
>>>>>
>>>>>>   Move
>>>>>> the latter next to p2m_add_foreign(), allowing this one to become
>>> static
>>>>>> at the same time.
>>>>>>
>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> So I had to ask Andrew to revert this (I was already at home when
>>>> noticing the breakage), as it turned out to break the shim build.
>>>> The problem is that xenmem_add_to_physmap() is non-static and
>>>> hence can't be eliminated altogether by the compiler when !HVM.
>>>> We could make the function conditionally static
>>>> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
>>>> looks uglier to me than this extra hunk:
>>>>
>>>> --- unstable.orig/xen/common/memory.c
>>>> +++ unstable/xen/common/memory.c
>>>> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>>>>       union add_to_physmap_extra extra = {};
>>>>       struct page_info *pages[16];
>>>>
>>>> -    ASSERT(paging_mode_translate(d));
>>>> +    if ( !paging_mode_translate(d) )
>>>> +    {
>>>> +        ASSERT_UNREACHABLE();
>>>> +        return -EACCES;
>>>> +    }
>>>>
>>>>       if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>>>>           extra.foreign_domid = DOMID_INVALID;
>>>>
>>>> Andrew, please let me know whether your ack stands with this (or
>>>> said alternative) added, or whether you'd prefer me to re-post.
>>> Yeah, this is probably neater than the ifdefary.  My ack stands.
>>>
>>> ~Andrew
>>>
>> I might miss something or did incorrect tests, but ...
>> ... trying to build current staging
>> (7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
>> not set) I got the following:
>>
>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
>> undefined reference to `xenmem_add_to_physmap_one'
>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>> `xenmem_add_to_physmap_one'
>> ld:
>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
>> hidden symbol `xenmem_add_to_physmap_one' isn't defined
>> ld: final link failed: Bad value
>>
>> It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
>> support via menuconfig manually before building).
> The specific .config may matter. The specific compiler version may
> also matter. Things work fine for me, both for the shim config and
> a custom !HVM one, with gcc10.

ok, after updating my a little bit ancient compiler to the latest 
possible (?) on xenial gcc-9 the build issue had gone away. Sorry for 
the noise.
Jan Beulich Jan. 8, 2021, 5:01 p.m. UTC | #8
On 08.01.2021 17:38, Oleksandr wrote:
> On 05.01.21 10:48, Jan Beulich wrote:
>> On 04.01.2021 17:57, Oleksandr Tyshchenko wrote:
>>> Hello all.
>>>
>>> [Sorry for the possible format issues]
>>>
>>> On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
>>> wrote:
>>>
>>>> On 21/12/2020 08:10, Jan Beulich wrote:
>>>>> On 17.12.2020 20:18, Andrew Cooper wrote:
>>>>>> On 15/12/2020 16:26, Jan Beulich wrote:
>>>>>>> This is together with its only caller, xenmem_add_to_physmap_one().
>>>>>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>>>>>> follow-on from the subject sentence.
>>>>>>
>>>>>>>   Move
>>>>>>> the latter next to p2m_add_foreign(), allowing this one to become
>>>> static
>>>>>>> at the same time.
>>>>>>>
>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> So I had to ask Andrew to revert this (I was already at home when
>>>>> noticing the breakage), as it turned out to break the shim build.
>>>>> The problem is that xenmem_add_to_physmap() is non-static and
>>>>> hence can't be eliminated altogether by the compiler when !HVM.
>>>>> We could make the function conditionally static
>>>>> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
>>>>> looks uglier to me than this extra hunk:
>>>>>
>>>>> --- unstable.orig/xen/common/memory.c
>>>>> +++ unstable/xen/common/memory.c
>>>>> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>>>>>       union add_to_physmap_extra extra = {};
>>>>>       struct page_info *pages[16];
>>>>>
>>>>> -    ASSERT(paging_mode_translate(d));
>>>>> +    if ( !paging_mode_translate(d) )
>>>>> +    {
>>>>> +        ASSERT_UNREACHABLE();
>>>>> +        return -EACCES;
>>>>> +    }
>>>>>
>>>>>       if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>>>>>           extra.foreign_domid = DOMID_INVALID;
>>>>>
>>>>> Andrew, please let me know whether your ack stands with this (or
>>>>> said alternative) added, or whether you'd prefer me to re-post.
>>>> Yeah, this is probably neater than the ifdefary.  My ack stands.
>>>>
>>>> ~Andrew
>>>>
>>> I might miss something or did incorrect tests, but ...
>>> ... trying to build current staging
>>> (7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
>>> not set) I got the following:
>>>
>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
>>> undefined reference to `xenmem_add_to_physmap_one'
>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
>>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>>> `xenmem_add_to_physmap_one'
>>> ld:
>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
>>> hidden symbol `xenmem_add_to_physmap_one' isn't defined
>>> ld: final link failed: Bad value
>>>
>>> It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
>>> support via menuconfig manually before building).
>> The specific .config may matter. The specific compiler version may
>> also matter. Things work fine for me, both for the shim config and
>> a custom !HVM one, with gcc10.
> 
> ok, after updating my a little bit ancient compiler to the latest 
> possible (?) on xenial gcc-9 the build issue had gone away. Sorry for 
> the noise.

There's no reason to be sorry - we want Xen to build with a wide
range of compiler versions. It's just that if a build issue is
version dependent, it is often up to the person running into it
to determine how to address the issue (and submit a patch).

Jan
Oleksandr Tyshchenko Jan. 8, 2021, 5:37 p.m. UTC | #9
On 08.01.21 19:01, Jan Beulich wrote:

Hi Jan

> On 08.01.2021 17:38, Oleksandr wrote:
>> On 05.01.21 10:48, Jan Beulich wrote:
>>> On 04.01.2021 17:57, Oleksandr Tyshchenko wrote:
>>>> Hello all.
>>>>
>>>> [Sorry for the possible format issues]
>>>>
>>>> On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
>>>> wrote:
>>>>
>>>>> On 21/12/2020 08:10, Jan Beulich wrote:
>>>>>> On 17.12.2020 20:18, Andrew Cooper wrote:
>>>>>>> On 15/12/2020 16:26, Jan Beulich wrote:
>>>>>>>> This is together with its only caller, xenmem_add_to_physmap_one().
>>>>>>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>>>>>>> follow-on from the subject sentence.
>>>>>>>
>>>>>>>>    Move
>>>>>>>> the latter next to p2m_add_foreign(), allowing this one to become
>>>>> static
>>>>>>>> at the same time.
>>>>>>>>
>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>> So I had to ask Andrew to revert this (I was already at home when
>>>>>> noticing the breakage), as it turned out to break the shim build.
>>>>>> The problem is that xenmem_add_to_physmap() is non-static and
>>>>>> hence can't be eliminated altogether by the compiler when !HVM.
>>>>>> We could make the function conditionally static
>>>>>> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
>>>>>> looks uglier to me than this extra hunk:
>>>>>>
>>>>>> --- unstable.orig/xen/common/memory.c
>>>>>> +++ unstable/xen/common/memory.c
>>>>>> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>>>>>>        union add_to_physmap_extra extra = {};
>>>>>>        struct page_info *pages[16];
>>>>>>
>>>>>> -    ASSERT(paging_mode_translate(d));
>>>>>> +    if ( !paging_mode_translate(d) )
>>>>>> +    {
>>>>>> +        ASSERT_UNREACHABLE();
>>>>>> +        return -EACCES;
>>>>>> +    }
>>>>>>
>>>>>>        if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>>>>>>            extra.foreign_domid = DOMID_INVALID;
>>>>>>
>>>>>> Andrew, please let me know whether your ack stands with this (or
>>>>>> said alternative) added, or whether you'd prefer me to re-post.
>>>>> Yeah, this is probably neater than the ifdefary.  My ack stands.
>>>>>
>>>>> ~Andrew
>>>>>
>>>> I might miss something or did incorrect tests, but ...
>>>> ... trying to build current staging
>>>> (7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
>>>> not set) I got the following:
>>>>
>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
>>>> undefined reference to `xenmem_add_to_physmap_one'
>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
>>>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>>>> `xenmem_add_to_physmap_one'
>>>> ld:
>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
>>>> hidden symbol `xenmem_add_to_physmap_one' isn't defined
>>>> ld: final link failed: Bad value
>>>>
>>>> It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
>>>> support via menuconfig manually before building).
>>> The specific .config may matter. The specific compiler version may
>>> also matter. Things work fine for me, both for the shim config and
>>> a custom !HVM one, with gcc10.
>> ok, after updating my a little bit ancient compiler to the latest
>> possible (?) on xenial gcc-9 the build issue had gone away. Sorry for
>> the noise.
> There's no reason to be sorry - we want Xen to build with a wide
> range of compiler versions. It's just that if a build issue is
> version dependent, it is often up to the person running into it
> to determine how to address the issue (and submit a patch).

ok, the issue was observed with gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 
5.4.0 20160609

I think (but not 100% sure), to address the build issue something like 
the stub below could help:


diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 85a8df9..ed35352 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -609,9 +609,19 @@ union add_to_physmap_extra {
      domid_t foreign_domid;
  };

+#ifdef CONFIG_HVM
  int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
                                union add_to_physmap_extra extra,
                                unsigned long idx, gfn_t gfn);
+#else
+static inline int xenmem_add_to_physmap_one(struct domain *d,
+                                            unsigned int space,
+                                            union add_to_physmap_extra 
extra,
+                                            unsigned long idx, gfn_t gfn)
+{
+    return -EACCES;
+}
+#endif

  int xenmem_add_to_physmap(struct domain *d, struct xen_add_to_physmap 
*xatp,
                            unsigned int start);
Jan Beulich Jan. 11, 2021, 7:41 a.m. UTC | #10
On 08.01.2021 18:37, Oleksandr wrote:
> 
> On 08.01.21 19:01, Jan Beulich wrote:
> 
> Hi Jan
> 
>> On 08.01.2021 17:38, Oleksandr wrote:
>>> On 05.01.21 10:48, Jan Beulich wrote:
>>>> On 04.01.2021 17:57, Oleksandr Tyshchenko wrote:
>>>>> Hello all.
>>>>>
>>>>> [Sorry for the possible format issues]
>>>>>
>>>>> On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> wrote:
>>>>>
>>>>>> On 21/12/2020 08:10, Jan Beulich wrote:
>>>>>>> On 17.12.2020 20:18, Andrew Cooper wrote:
>>>>>>>> On 15/12/2020 16:26, Jan Beulich wrote:
>>>>>>>>> This is together with its only caller, xenmem_add_to_physmap_one().
>>>>>>>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>>>>>>>> follow-on from the subject sentence.
>>>>>>>>
>>>>>>>>>    Move
>>>>>>>>> the latter next to p2m_add_foreign(), allowing this one to become
>>>>>> static
>>>>>>>>> at the same time.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>> So I had to ask Andrew to revert this (I was already at home when
>>>>>>> noticing the breakage), as it turned out to break the shim build.
>>>>>>> The problem is that xenmem_add_to_physmap() is non-static and
>>>>>>> hence can't be eliminated altogether by the compiler when !HVM.
>>>>>>> We could make the function conditionally static
>>>>>>> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
>>>>>>> looks uglier to me than this extra hunk:
>>>>>>>
>>>>>>> --- unstable.orig/xen/common/memory.c
>>>>>>> +++ unstable/xen/common/memory.c
>>>>>>> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>>>>>>>        union add_to_physmap_extra extra = {};
>>>>>>>        struct page_info *pages[16];
>>>>>>>
>>>>>>> -    ASSERT(paging_mode_translate(d));
>>>>>>> +    if ( !paging_mode_translate(d) )
>>>>>>> +    {
>>>>>>> +        ASSERT_UNREACHABLE();
>>>>>>> +        return -EACCES;
>>>>>>> +    }
>>>>>>>
>>>>>>>        if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>>>>>>>            extra.foreign_domid = DOMID_INVALID;
>>>>>>>
>>>>>>> Andrew, please let me know whether your ack stands with this (or
>>>>>>> said alternative) added, or whether you'd prefer me to re-post.
>>>>>> Yeah, this is probably neater than the ifdefary.  My ack stands.
>>>>>>
>>>>>> ~Andrew
>>>>>>
>>>>> I might miss something or did incorrect tests, but ...
>>>>> ... trying to build current staging
>>>>> (7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
>>>>> not set) I got the following:
>>>>>
>>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
>>>>> undefined reference to `xenmem_add_to_physmap_one'
>>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
>>>>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>>>>> `xenmem_add_to_physmap_one'
>>>>> ld:
>>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
>>>>> hidden symbol `xenmem_add_to_physmap_one' isn't defined
>>>>> ld: final link failed: Bad value
>>>>>
>>>>> It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
>>>>> support via menuconfig manually before building).
>>>> The specific .config may matter. The specific compiler version may
>>>> also matter. Things work fine for me, both for the shim config and
>>>> a custom !HVM one, with gcc10.
>>> ok, after updating my a little bit ancient compiler to the latest
>>> possible (?) on xenial gcc-9 the build issue had gone away. Sorry for
>>> the noise.
>> There's no reason to be sorry - we want Xen to build with a wide
>> range of compiler versions. It's just that if a build issue is
>> version dependent, it is often up to the person running into it
>> to determine how to address the issue (and submit a patch).
> 
> ok, the issue was observed with gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 
> 5.4.0 20160609
> 
> I think (but not 100% sure), to address the build issue something like 
> the stub below could help:

I'm sure this would help, but personally I'd prefer if we could limit
the number of such stubs and rely on the compiler DCE-ing the calls.
Hence it would be at least desirable (imo necessary) to understand
what prevents this to happen here, with this gcc version.

If you could also provide your exact .config, I could see whether I
can repro here with some of the gcc5 versions I have laying around.

Jan
Oleksandr Tyshchenko Jan. 11, 2021, 8:23 a.m. UTC | #11
On 11.01.21 09:41, Jan Beulich wrote:

Hi Jan


> On 08.01.2021 18:37, Oleksandr wrote:
>> On 08.01.21 19:01, Jan Beulich wrote:
>>
>> Hi Jan
>>
>>> On 08.01.2021 17:38, Oleksandr wrote:
>>>> On 05.01.21 10:48, Jan Beulich wrote:
>>>>> On 04.01.2021 17:57, Oleksandr Tyshchenko wrote:
>>>>>> Hello all.
>>>>>>
>>>>>> [Sorry for the possible format issues]
>>>>>>
>>>>>> On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 21/12/2020 08:10, Jan Beulich wrote:
>>>>>>>> On 17.12.2020 20:18, Andrew Cooper wrote:
>>>>>>>>> On 15/12/2020 16:26, Jan Beulich wrote:
>>>>>>>>>> This is together with its only caller, xenmem_add_to_physmap_one().
>>>>>>>>> I can't parse this sentence.  Perhaps "... as is it's only caller," as a
>>>>>>>>> follow-on from the subject sentence.
>>>>>>>>>
>>>>>>>>>>     Move
>>>>>>>>>> the latter next to p2m_add_foreign(), allowing this one to become
>>>>>>> static
>>>>>>>>>> at the same time.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>> So I had to ask Andrew to revert this (I was already at home when
>>>>>>>> noticing the breakage), as it turned out to break the shim build.
>>>>>>>> The problem is that xenmem_add_to_physmap() is non-static and
>>>>>>>> hence can't be eliminated altogether by the compiler when !HVM.
>>>>>>>> We could make the function conditionally static
>>>>>>>> "#if !defined(CONFIG_X86) && !defined(CONFIG_HVM)", but this
>>>>>>>> looks uglier to me than this extra hunk:
>>>>>>>>
>>>>>>>> --- unstable.orig/xen/common/memory.c
>>>>>>>> +++ unstable/xen/common/memory.c
>>>>>>>> @@ -788,7 +788,11 @@ int xenmem_add_to_physmap(struct domain
>>>>>>>>         union add_to_physmap_extra extra = {};
>>>>>>>>         struct page_info *pages[16];
>>>>>>>>
>>>>>>>> -    ASSERT(paging_mode_translate(d));
>>>>>>>> +    if ( !paging_mode_translate(d) )
>>>>>>>> +    {
>>>>>>>> +        ASSERT_UNREACHABLE();
>>>>>>>> +        return -EACCES;
>>>>>>>> +    }
>>>>>>>>
>>>>>>>>         if ( xatp->space == XENMAPSPACE_gmfn_foreign )
>>>>>>>>             extra.foreign_domid = DOMID_INVALID;
>>>>>>>>
>>>>>>>> Andrew, please let me know whether your ack stands with this (or
>>>>>>>> said alternative) added, or whether you'd prefer me to re-post.
>>>>>>> Yeah, this is probably neater than the ifdefary.  My ack stands.
>>>>>>>
>>>>>>> ~Andrew
>>>>>>>
>>>>>> I might miss something or did incorrect tests, but ...
>>>>>> ... trying to build current staging
>>>>>> (7ba2ab495be54f608cb47440e1497b2795bd301a) for x86 (with # CONFIG_HVM is
>>>>>> not set) I got the following:
>>>>>>
>>>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:
>>>>>> undefined reference to `xenmem_add_to_physmap_one'
>>>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/common/memory.c:941:(.text+0x1e391):
>>>>>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>>>>>> `xenmem_add_to_physmap_one'
>>>>>> ld:
>>>>>> /media/b/build/build/tmp/work/x86_64-xt-linux/domd-image-weston/1.0-r0/repo/build/tmp/work/aarch64-poky-linux/xen/4.14.0+gitAUTOINC+2c6e5a8ceb-r0/git/xen/.xen-syms.0:
>>>>>> hidden symbol `xenmem_add_to_physmap_one' isn't defined
>>>>>> ld: final link failed: Bad value
>>>>>>
>>>>>> It is worth mentioning that I do not use pvshim_defconfig (I disable HVM
>>>>>> support via menuconfig manually before building).
>>>>> The specific .config may matter. The specific compiler version may
>>>>> also matter. Things work fine for me, both for the shim config and
>>>>> a custom !HVM one, with gcc10.
>>>> ok, after updating my a little bit ancient compiler to the latest
>>>> possible (?) on xenial gcc-9 the build issue had gone away. Sorry for
>>>> the noise.
>>> There's no reason to be sorry - we want Xen to build with a wide
>>> range of compiler versions. It's just that if a build issue is
>>> version dependent, it is often up to the person running into it
>>> to determine how to address the issue (and submit a patch).
>> ok, the issue was observed with gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12)
>> 5.4.0 20160609
>>
>> I think (but not 100% sure), to address the build issue something like
>> the stub below could help:
> I'm sure this would help, but personally I'd prefer if we could limit
> the number of such stubs and rely on the compiler DCE-ing the calls.
> Hence it would be at least desirable (imo necessary) to understand
> what prevents this to happen here, with this gcc version.

Sounds reasonable


>
> If you could also provide your exact .config, I could see whether I
> can repro here with some of the gcc5 versions I have laying around.

Please see attached
Jan Beulich Jan. 12, 2021, 11:58 a.m. UTC | #12
On 11.01.2021 09:23, Oleksandr wrote:
> On 11.01.21 09:41, Jan Beulich wrote:
>> If you could also provide your exact .config, I could see whether I
>> can repro here with some of the gcc5 versions I have laying around.
> 
> Please see attached

Builds perfectly fine with 5.4.0 here.

Jan
Oleksandr Tyshchenko Jan. 13, 2021, 3:06 p.m. UTC | #13
On 12.01.21 13:58, Jan Beulich wrote:

Hi Jan.

> On 11.01.2021 09:23, Oleksandr wrote:
>> On 11.01.21 09:41, Jan Beulich wrote:
>>> If you could also provide your exact .config, I could see whether I
>>> can repro here with some of the gcc5 versions I have laying around.
>> Please see attached
> Builds perfectly fine with 5.4.0 here.

Thank you for testing.


I wonder whether I indeed missed something. I have switched to 5.4.0 
again (from 9.3.0) and rechecked, a build issue was still present.
I even downloaded 5.4.0 sources and built them to try to build Xen, and 
got the same effect.  What I noticed is that for non-debug builds the 
build issue wasn't present.
Then I decided to build today's staging 
(414be7b66349e7dca42bc1fd47c2b2f5b2d27432 xen/memory: Fix compat 
XENMEM_acquire_resource for size requests) instead of 9-day's old one when
I had initially reported about that build issue 
(7ba2ab495be54f608cb47440e1497b2795bd301a x86/p2m: Fix 
paging_gva_to_gfn() for nested virt). Today's staging builds perfectly 
fine with 5.4.0.
It seems that commit in the middle 
(994f6478a48a60e3b407c7defc2d36a80f880b04 xsm/dummy: harden against 
speculative abuse) indirectly fixes that weird build issue with 5.4.0...
Julien Grall Jan. 23, 2021, 1:22 p.m. UTC | #14
Hi Jan & Oleksandr,

On 13/01/2021 15:06, Oleksandr wrote:
> 
> On 12.01.21 13:58, Jan Beulich wrote:
> 
> Hi Jan.
> 
>> On 11.01.2021 09:23, Oleksandr wrote:
>>> On 11.01.21 09:41, Jan Beulich wrote:
>>>> If you could also provide your exact .config, I could see whether I
>>>> can repro here with some of the gcc5 versions I have laying around.
>>> Please see attached
>> Builds perfectly fine with 5.4.0 here.
> 
> Thank you for testing.
> 
> 
> I wonder whether I indeed missed something. I have switched to 5.4.0 
> again (from 9.3.0) and rechecked, a build issue was still present.
> I even downloaded 5.4.0 sources and built them to try to build Xen, and 
> got the same effect.  What I noticed is that for non-debug builds the 
> build issue wasn't present.
> Then I decided to build today's staging 
> (414be7b66349e7dca42bc1fd47c2b2f5b2d27432 xen/memory: Fix compat 
> XENMEM_acquire_resource for size requests) instead of 9-day's old one when
> I had initially reported about that build issue 
> (7ba2ab495be54f608cb47440e1497b2795bd301a x86/p2m: Fix 
> paging_gva_to_gfn() for nested virt). Today's staging builds perfectly 
> fine with 5.4.0.
> It seems that commit in the middle 
> (994f6478a48a60e3b407c7defc2d36a80f880b04 xsm/dummy: harden against 
> speculative abuse) indirectly fixes that weird build issue with 5.4.0...

The gitlab CI reported a similar issue today (see [1]) when building 
with randconfig ([2]). This is happening on Debian sid with GCC 9.3.

Note that the default compiler on sid is GCC 10.2.1. So you will have to 
install the package gcc-9 and then use CC=gcc-9 make <...>.


 From a local repro, I get the following message:

ld: ld: prelink.o: in function `xenmem_add_to_physmap_batch':
/root/xen/xen/common/memory.c:942: undefined reference to 
`xenmem_add_to_physmap_one'
/root/xen/xen/common/memory.c:942:(.text+0x22145): relocation truncated 
to fit: R_X86_64_PLT32 against undefined symbol `xenmem_add_to_physmap_one'
prelink-efi.o: in function `xenmem_add_to_physmap_batch':
/root/xen/xen/common/memory.c:942: undefined reference to 
`xenmem_add_to_physmap_one'
make[2]: *** [Makefile:215: /root/xen/xen/xen.efi] Error 1
make[2]: *** Waiting for unfinished jobs....
ld: /root/xen/xen/.xen-syms.0: hidden symbol `xenmem_add_to_physmap_one' 
isn't defined
ld: final link failed: bad value


This points to the call in xenmem_add_to_physmap_batch(). I have played 
a bit with the .config options. I was able to get it built as soon as I 
disabled CONFIG_COVERAGE=y.

So maybe the optimizer is not clever enough on GCC 9 when building with 
coverage enabled?

With the diff below applied (borrowed from 
xenmem_add_to_physmap_batch()), I can build without tweaking the .config 
[1]:

diff --git a/xen/common/memory.c b/xen/common/memory.c
index ccb4d49fc6..5cfd36a53d 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -903,6 +903,12 @@ static int xenmem_add_to_physmap_batch(struct 
domain *d,
  {
      union add_to_physmap_extra extra = {};

+    if ( !paging_mode_translate(d) )
+    {
+        ASSERT_UNREACHABLE();
+        return -EACCES;
+    }
+
      if ( unlikely(xatpb->size < extent) )
          return -EILSEQ;

Cheers,

[1] https://gitlab.com/xen-project/xen/-/jobs/981624525
[2] https://pastebin.com/vTbQXXV9


https://gitlab.com/xen-project/xen/-/jobs/981624525

> 
>
Jan Beulich Jan. 25, 2021, 9:10 a.m. UTC | #15
On 23.01.2021 14:22, Julien Grall wrote:
> On 13/01/2021 15:06, Oleksandr wrote:
>> On 12.01.21 13:58, Jan Beulich wrote:
>>> On 11.01.2021 09:23, Oleksandr wrote:
>>>> On 11.01.21 09:41, Jan Beulich wrote:
>>>>> If you could also provide your exact .config, I could see whether I
>>>>> can repro here with some of the gcc5 versions I have laying around.
>>>> Please see attached
>>> Builds perfectly fine with 5.4.0 here.
>>
>> Thank you for testing.
>>
>>
>> I wonder whether I indeed missed something. I have switched to 5.4.0 
>> again (from 9.3.0) and rechecked, a build issue was still present.
>> I even downloaded 5.4.0 sources and built them to try to build Xen, and 
>> got the same effect.  What I noticed is that for non-debug builds the 
>> build issue wasn't present.
>> Then I decided to build today's staging 
>> (414be7b66349e7dca42bc1fd47c2b2f5b2d27432 xen/memory: Fix compat 
>> XENMEM_acquire_resource for size requests) instead of 9-day's old one when
>> I had initially reported about that build issue 
>> (7ba2ab495be54f608cb47440e1497b2795bd301a x86/p2m: Fix 
>> paging_gva_to_gfn() for nested virt). Today's staging builds perfectly 
>> fine with 5.4.0.
>> It seems that commit in the middle 
>> (994f6478a48a60e3b407c7defc2d36a80f880b04 xsm/dummy: harden against 
>> speculative abuse) indirectly fixes that weird build issue with 5.4.0...
> 
> The gitlab CI reported a similar issue today (see [1]) when building 
> with randconfig ([2]). This is happening on Debian sid with GCC 9.3.
> 
> Note that the default compiler on sid is GCC 10.2.1. So you will have to 
> install the package gcc-9 and then use CC=gcc-9 make <...>.
> 
> 
>  From a local repro, I get the following message:
> 
> ld: ld: prelink.o: in function `xenmem_add_to_physmap_batch':
> /root/xen/xen/common/memory.c:942: undefined reference to 
> `xenmem_add_to_physmap_one'
> /root/xen/xen/common/memory.c:942:(.text+0x22145): relocation truncated 
> to fit: R_X86_64_PLT32 against undefined symbol `xenmem_add_to_physmap_one'
> prelink-efi.o: in function `xenmem_add_to_physmap_batch':
> /root/xen/xen/common/memory.c:942: undefined reference to 
> `xenmem_add_to_physmap_one'
> make[2]: *** [Makefile:215: /root/xen/xen/xen.efi] Error 1
> make[2]: *** Waiting for unfinished jobs....
> ld: /root/xen/xen/.xen-syms.0: hidden symbol `xenmem_add_to_physmap_one' 
> isn't defined
> ld: final link failed: bad value
> 
> 
> This points to the call in xenmem_add_to_physmap_batch(). I have played 
> a bit with the .config options. I was able to get it built as soon as I 
> disabled CONFIG_COVERAGE=y.
> 
> So maybe the optimizer is not clever enough on GCC 9 when building with 
> coverage enabled?
> 
> With the diff below applied (borrowed from 
> xenmem_add_to_physmap_batch()), I can build without tweaking the .config 
> [1]:
> 
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index ccb4d49fc6..5cfd36a53d 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -903,6 +903,12 @@ static int xenmem_add_to_physmap_batch(struct 
> domain *d,
>   {
>       union add_to_physmap_extra extra = {};
> 
> +    if ( !paging_mode_translate(d) )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return -EACCES;
> +    }
> +
>       if ( unlikely(xatpb->size < extent) )
>           return -EILSEQ;

Interesting. So despite the function being static and
xatp_permission_check() already doing this check, the function
doesn't get squashed. Looking at my gcov build this might be
due to xatp_permission_check() not getting inlined in this
case, but I will need to try one with HVM=n to be certain. In
any event, I wouldn't mind the above as a workaround to the
issue, as long as its description makes clear this is a
workaround only.

Thanks for investigating!

Jan
Jan Beulich Jan. 25, 2021, 10:33 a.m. UTC | #16
On 23.01.2021 14:22, Julien Grall wrote:
> On 13/01/2021 15:06, Oleksandr wrote:
>> On 12.01.21 13:58, Jan Beulich wrote:
>>> On 11.01.2021 09:23, Oleksandr wrote:
>>>> On 11.01.21 09:41, Jan Beulich wrote:
>>>>> If you could also provide your exact .config, I could see whether I
>>>>> can repro here with some of the gcc5 versions I have laying around.
>>>> Please see attached
>>> Builds perfectly fine with 5.4.0 here.
>>
>> Thank you for testing.
>>
>>
>> I wonder whether I indeed missed something. I have switched to 5.4.0 
>> again (from 9.3.0) and rechecked, a build issue was still present.
>> I even downloaded 5.4.0 sources and built them to try to build Xen, and 
>> got the same effect.  What I noticed is that for non-debug builds the 
>> build issue wasn't present.
>> Then I decided to build today's staging 
>> (414be7b66349e7dca42bc1fd47c2b2f5b2d27432 xen/memory: Fix compat 
>> XENMEM_acquire_resource for size requests) instead of 9-day's old one when
>> I had initially reported about that build issue 
>> (7ba2ab495be54f608cb47440e1497b2795bd301a x86/p2m: Fix 
>> paging_gva_to_gfn() for nested virt). Today's staging builds perfectly 
>> fine with 5.4.0.
>> It seems that commit in the middle 
>> (994f6478a48a60e3b407c7defc2d36a80f880b04 xsm/dummy: harden against 
>> speculative abuse) indirectly fixes that weird build issue with 5.4.0...
> 
> The gitlab CI reported a similar issue today (see [1]) when building 
> with randconfig ([2]). This is happening on Debian sid with GCC 9.3.
> 
> Note that the default compiler on sid is GCC 10.2.1. So you will have to 
> install the package gcc-9 and then use CC=gcc-9 make <...>.
> 
> 
>  From a local repro, I get the following message:
> 
> ld: ld: prelink.o: in function `xenmem_add_to_physmap_batch':
> /root/xen/xen/common/memory.c:942: undefined reference to 
> `xenmem_add_to_physmap_one'
> /root/xen/xen/common/memory.c:942:(.text+0x22145): relocation truncated 
> to fit: R_X86_64_PLT32 against undefined symbol `xenmem_add_to_physmap_one'
> prelink-efi.o: in function `xenmem_add_to_physmap_batch':
> /root/xen/xen/common/memory.c:942: undefined reference to 
> `xenmem_add_to_physmap_one'
> make[2]: *** [Makefile:215: /root/xen/xen/xen.efi] Error 1
> make[2]: *** Waiting for unfinished jobs....
> ld: /root/xen/xen/.xen-syms.0: hidden symbol `xenmem_add_to_physmap_one' 
> isn't defined
> ld: final link failed: bad value
> 
> 
> This points to the call in xenmem_add_to_physmap_batch(). I have played 
> a bit with the .config options. I was able to get it built as soon as I 
> disabled CONFIG_COVERAGE=y.
> 
> So maybe the optimizer is not clever enough on GCC 9 when building with 
> coverage enabled?

Possibly, albeit I can't repro this locally. Even with gcc9
the code gets collapsed sufficiently. I do notice though
that overall gcc10 does quite a bit better a job, so I could
see further factors potentially leading to what you did
observe, and then possibly independent of the specific gcc9
build in use.

Jan
diff mbox series

Patch

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -118,7 +118,6 @@ 
 #include <xen/vmap.h>
 #include <xen/xmalloc.h>
 #include <xen/efi.h>
-#include <xen/grant_table.h>
 #include <xen/hypercall.h>
 #include <xen/mm.h>
 #include <asm/paging.h>
@@ -142,10 +141,7 @@ 
 #include <asm/pci.h>
 #include <asm/guest.h>
 #include <asm/hvm/ioreq.h>
-
-#include <asm/hvm/grant_table.h>
 #include <asm/pv/domain.h>
-#include <asm/pv/grant_table.h>
 #include <asm/pv/mm.h>
 
 #ifdef CONFIG_PV
@@ -4591,114 +4587,6 @@  static int handle_iomem_range(unsigned l
     return err || s > e ? err : _handle_iomem_range(s, e, p);
 }
 
-int xenmem_add_to_physmap_one(
-    struct domain *d,
-    unsigned int space,
-    union add_to_physmap_extra extra,
-    unsigned long idx,
-    gfn_t gpfn)
-{
-    struct page_info *page = NULL;
-    unsigned long gfn = 0 /* gcc ... */, old_gpfn;
-    mfn_t prev_mfn;
-    int rc = 0;
-    mfn_t mfn = INVALID_MFN;
-    p2m_type_t p2mt;
-
-    switch ( space )
-    {
-        case XENMAPSPACE_shared_info:
-            if ( idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        case XENMAPSPACE_grant_table:
-            rc = gnttab_map_frame(d, idx, gpfn, &mfn);
-            if ( rc )
-                return rc;
-            break;
-        case XENMAPSPACE_gmfn:
-        {
-            p2m_type_t p2mt;
-
-            gfn = idx;
-            mfn = get_gfn_unshare(d, gfn, &p2mt);
-            /* If the page is still shared, exit early */
-            if ( p2m_is_shared(p2mt) )
-            {
-                put_gfn(d, gfn);
-                return -ENOMEM;
-            }
-            page = get_page_from_mfn(mfn, d);
-            if ( unlikely(!page) )
-                mfn = INVALID_MFN;
-            break;
-        }
-        case XENMAPSPACE_gmfn_foreign:
-            return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
-        default:
-            break;
-    }
-
-    if ( mfn_eq(mfn, INVALID_MFN) )
-    {
-        rc = -EINVAL;
-        goto put_both;
-    }
-
-    /* Remove previously mapped page if it was present. */
-    prev_mfn = get_gfn(d, gfn_x(gpfn), &p2mt);
-    if ( mfn_valid(prev_mfn) )
-    {
-        if ( is_special_page(mfn_to_page(prev_mfn)) )
-            /* Special pages are simply unhooked from this phys slot. */
-            rc = guest_physmap_remove_page(d, gpfn, prev_mfn, PAGE_ORDER_4K);
-        else if ( !mfn_eq(mfn, prev_mfn) )
-            /* Normal domain memory is freed, to avoid leaking memory. */
-            rc = guest_remove_page(d, gfn_x(gpfn));
-    }
-    /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
-    put_gfn(d, gfn_x(gpfn));
-
-    if ( rc )
-        goto put_both;
-
-    /* Unmap from old location, if any. */
-    old_gpfn = get_gpfn_from_mfn(mfn_x(mfn));
-    ASSERT(!SHARED_M2P(old_gpfn));
-    if ( space == XENMAPSPACE_gmfn && old_gpfn != gfn )
-    {
-        rc = -EXDEV;
-        goto put_both;
-    }
-    if ( old_gpfn != INVALID_M2P_ENTRY )
-        rc = guest_physmap_remove_page(d, _gfn(old_gpfn), mfn, PAGE_ORDER_4K);
-
-    /* Map at new location. */
-    if ( !rc )
-        rc = guest_physmap_add_page(d, gpfn, mfn, PAGE_ORDER_4K);
-
- put_both:
-    /*
-     * In the XENMAPSPACE_gmfn case, we took a ref of the gfn at the top.
-     * We also may need to transfer ownership of the page reference to our
-     * caller.
-     */
-    if ( space == XENMAPSPACE_gmfn )
-    {
-        put_gfn(d, gfn);
-        if ( !rc && extra.ppage )
-        {
-            *extra.ppage = page;
-            page = NULL;
-        }
-    }
-
-    if ( page )
-        put_page(page);
-
-    return rc;
-}
-
 int arch_acquire_resource(struct domain *d, unsigned int type,
                           unsigned int id, unsigned long frame,
                           unsigned int nr_frames, xen_pfn_t mfn_list[])
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -27,6 +27,7 @@ 
 #include <xen/mem_access.h>
 #include <xen/vm_event.h>
 #include <xen/event.h>
+#include <xen/grant_table.h>
 #include <xen/param.h>
 #include <public/vm_event.h>
 #include <asm/domain.h>
@@ -42,6 +43,10 @@ 
 
 #include "mm-locks.h"
 
+/* Override macro from asm/page.h to make work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(v) _mfn(__virt_to_mfn(v))
+
 /* Turn on/off host superpage page table support for hap, default on. */
 bool_t __initdata opt_hap_1gb = 1, __initdata opt_hap_2mb = 1;
 boolean_param("hap_1gb", opt_hap_1gb);
@@ -2535,6 +2540,8 @@  out_p2m_audit:
 }
 #endif /* P2M_AUDIT */
 
+#ifdef CONFIG_HVM
+
 /*
  * Add frame from foreign domain to target domain's physmap. Similar to
  * XENMAPSPACE_gmfn but the frame is foreign being mapped into current,
@@ -2551,8 +2558,8 @@  out_p2m_audit:
  *
  * Returns: 0 ==> success
  */
-int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
-                    unsigned long gpfn, domid_t foreigndom)
+static int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
+                           unsigned long gpfn, domid_t foreigndom)
 {
     p2m_type_t p2mt, p2mt_prev;
     mfn_t prev_mfn, mfn;
@@ -2639,7 +2646,114 @@  int p2m_add_foreign(struct domain *tdom,
     return rc;
 }
 
-#ifdef CONFIG_HVM
+int xenmem_add_to_physmap_one(
+    struct domain *d,
+    unsigned int space,
+    union add_to_physmap_extra extra,
+    unsigned long idx,
+    gfn_t gpfn)
+{
+    struct page_info *page = NULL;
+    unsigned long gfn = 0 /* gcc ... */, old_gpfn;
+    mfn_t prev_mfn;
+    int rc = 0;
+    mfn_t mfn = INVALID_MFN;
+    p2m_type_t p2mt;
+
+    switch ( space )
+    {
+        case XENMAPSPACE_shared_info:
+            if ( idx == 0 )
+                mfn = virt_to_mfn(d->shared_info);
+            break;
+        case XENMAPSPACE_grant_table:
+            rc = gnttab_map_frame(d, idx, gpfn, &mfn);
+            if ( rc )
+                return rc;
+            break;
+        case XENMAPSPACE_gmfn:
+        {
+            p2m_type_t p2mt;
+
+            gfn = idx;
+            mfn = get_gfn_unshare(d, gfn, &p2mt);
+            /* If the page is still shared, exit early */
+            if ( p2m_is_shared(p2mt) )
+            {
+                put_gfn(d, gfn);
+                return -ENOMEM;
+            }
+            page = get_page_from_mfn(mfn, d);
+            if ( unlikely(!page) )
+                mfn = INVALID_MFN;
+            break;
+        }
+        case XENMAPSPACE_gmfn_foreign:
+            return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
+        default:
+            break;
+    }
+
+    if ( mfn_eq(mfn, INVALID_MFN) )
+    {
+        rc = -EINVAL;
+        goto put_both;
+    }
+
+    /* Remove previously mapped page if it was present. */
+    prev_mfn = get_gfn(d, gfn_x(gpfn), &p2mt);
+    if ( mfn_valid(prev_mfn) )
+    {
+        if ( is_special_page(mfn_to_page(prev_mfn)) )
+            /* Special pages are simply unhooked from this phys slot. */
+            rc = guest_physmap_remove_page(d, gpfn, prev_mfn, PAGE_ORDER_4K);
+        else if ( !mfn_eq(mfn, prev_mfn) )
+            /* Normal domain memory is freed, to avoid leaking memory. */
+            rc = guest_remove_page(d, gfn_x(gpfn));
+    }
+    /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
+    put_gfn(d, gfn_x(gpfn));
+
+    if ( rc )
+        goto put_both;
+
+    /* Unmap from old location, if any. */
+    old_gpfn = get_gpfn_from_mfn(mfn_x(mfn));
+    ASSERT(!SHARED_M2P(old_gpfn));
+    if ( space == XENMAPSPACE_gmfn && old_gpfn != gfn )
+    {
+        rc = -EXDEV;
+        goto put_both;
+    }
+    if ( old_gpfn != INVALID_M2P_ENTRY )
+        rc = guest_physmap_remove_page(d, _gfn(old_gpfn), mfn, PAGE_ORDER_4K);
+
+    /* Map at new location. */
+    if ( !rc )
+        rc = guest_physmap_add_page(d, gpfn, mfn, PAGE_ORDER_4K);
+
+ put_both:
+    /*
+     * In the XENMAPSPACE_gmfn case, we took a ref of the gfn at the top.
+     * We also may need to transfer ownership of the page reference to our
+     * caller.
+     */
+    if ( space == XENMAPSPACE_gmfn )
+    {
+        put_gfn(d, gfn);
+        if ( !rc && extra.ppage )
+        {
+            *extra.ppage = page;
+            page = NULL;
+        }
+    }
+
+    if ( page )
+        put_page(page);
+
+    return rc;
+}
+
 /*
  * Set/clear the #VE suppress bit for a page.  Only available on VMX.
  */
@@ -2792,7 +2906,8 @@  int p2m_set_altp2m_view_visibility(struc
 
     return rc;
 }
-#endif
+
+#endif /* CONFIG_HVM */
 
 /*
  * Local variables:
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -661,10 +661,6 @@  int set_identity_p2m_entry(struct domain
                            p2m_access_t p2ma, unsigned int flag);
 int clear_identity_p2m_entry(struct domain *d, unsigned long gfn);
 
-/* Add foreign mapping to the guest's p2m table. */
-int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
-                    unsigned long gpfn, domid_t foreign_domid);
-
 /* 
  * Populate-on-demand
  */