From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH] x86/shim: fix build when !PV32
Date: Fri, 7 May 2021 11:08:20 +0200 [thread overview]
Message-ID: <YJUDhB1dBVDF8vmd@Air-de-Roger> (raw)
In-Reply-To: <c00c73a5-0d9c-9e1e-20d7-5d65ac23976e@suse.com>
On Fri, May 07, 2021 at 10:34:24AM +0200, Jan Beulich wrote:
> On 07.05.2021 10:21, Roger Pau Monné wrote:
> > On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
> >> In this case compat headers don't get generated (and aren't needed).
> >> The changes made by 527922008bce ("x86: slim down hypercall handling
> >> when !PV32") also weren't quite sufficient for this case.
> >>
> >> Try to limit #ifdef-ary by introducing two "fallback" #define-s.
> >>
> >> Fixes: d23d792478db ("x86: avoid building COMPAT code when !HVM && !PV32")
> >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>
> >> --- a/xen/arch/x86/pv/shim.c
> >> +++ b/xen/arch/x86/pv/shim.c
> >> @@ -34,8 +34,6 @@
> >> #include <public/arch-x86/cpuid.h>
> >> #include <public/hvm/params.h>
> >>
> >> -#include <compat/grant_table.h>
> >> -
> >> #undef virt_to_mfn
> >> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> >>
> >> @@ -300,8 +298,10 @@ static void write_start_info(struct doma
> >> &si->console.domU.mfn) )
> >> BUG();
> >>
> >> +#ifdef CONFIG_PV32
> >> if ( compat )
> >> xlat_start_info(si, XLAT_start_info_console_domU);
> >> +#endif
> >
> > Would it help the compiler logic if the 'compat' local variable was
> > made const?
>
> No, because XLAT_start_info_console_domU is undeclared when there are
> no compat headers.
>
> > I'm wondering if there's a way we can force DCE from the compiler and
> > avoid the ifdefs around the usage of compat.
>
> The issue isn't with DCE - I believe the compiler does okay in that
> regard. The issue is with things simply lacking a declaration /
> definition. That's no different from e.g. struct fields living
> inside an #ifdef - all uses then need to as well, no matter whether
> the compiler is capable of otherwise recognizing the code as dead.
Right, I see those are no longer declared anywhere. Since this is
gating compat code, would it make more sense to use CONFIG_COMPAT
rather than CONFIG_PV32 here?
Thanks, Roger.
next prev parent reply other threads:[~2021-05-07 9:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 6:22 [PATCH] x86/shim: fix build when !PV32 Jan Beulich
2021-05-07 8:21 ` Roger Pau Monné
2021-05-07 8:34 ` Jan Beulich
2021-05-07 9:08 ` Roger Pau Monné [this message]
2021-05-07 9:17 ` Jan Beulich
2021-05-07 10:14 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJUDhB1dBVDF8vmd@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.