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 |
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
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
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
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
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).
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
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.
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
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);
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
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
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
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...
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 > >
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
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
--- 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 */
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>