From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
david.vrabel@citrix.com, hpa@zytor.com, ian.campbell@citrix.com,
jbeulich@suse.com, jeremy@goop.org, konrad.wilk@oracle.com,
matt.fleming@intel.com, mingo@redhat.com,
stefano.stabellini@eu.citrix.com, tglx@linutronix.de
Subject: Re: [PATCH 2/2] arch/x86/xen: Silence compiler warnings
Date: Fri, 11 Jul 2014 16:32:27 -0400 [thread overview]
Message-ID: <53C049DB.3050904@oracle.com> (raw)
In-Reply-To: <20140711201050.GJ13620@olila.local.net-space.pl>
On 07/11/2014 04:10 PM, Daniel Kiper wrote:
> On Fri, Jul 11, 2014 at 04:03:46PM -0400, Boris Ostrovsky wrote:
>> On 07/11/2014 03:54 PM, Daniel Kiper wrote:
>>> Compiler complains in the following way when x86 32-bit kernel
>>> with Xen support is build:
>>>
>>> CC arch/x86/xen/enlighten.o
>>> arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’:
>>> arch/x86/xen/enlighten.c:1726:3: warning: right shift count >= width of type [enabled by default]
>>>
>>> Such line contains following EFI initialization code:
>>>
>>> boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
>>>
>>> There is no issue if x86 64-bit kernel is build. However, 32-bit case
>>> generate warning (even if that code will not be executed because Xen
>>> does not work on 32-bit EFI platforms) due to __pa() returning unsigned long
>>> type which has 32-bits width. So move whole EFI initialization stuff
>>> to separate function and build its body conditionally to avoid above
>>> mentioned warning on x86 32-bit architecture.
>>>
>>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>>> ---
>>> arch/x86/xen/enlighten.c | 35 ++++++++++++++++++++++-------------
>>> 1 file changed, 22 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>> index bc89647..6abec74 100644
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -1516,12 +1516,32 @@ static void __init xen_pvh_early_guest_init(void)
>>> #endif
>>> }
>>> +static void __init xen_efi_init(void)
>>> +{
>>> +#ifdef CONFIG_XEN_EFI
>>> + efi_system_table_t *efi_systab_xen;
>>> +
>>> + efi_systab_xen = xen_efi_probe();
>>> +
>>> + if (efi_systab_xen == NULL)
>>> + return;
>>> +
>>> + strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
>>> + sizeof(boot_params.efi_info.efi_loader_signature));
>>> + boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
>>> + boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
>>> +
>>> + set_bit(EFI_BOOT, &efi.flags);
>>> + set_bit(EFI_PARAVIRT, &efi.flags);
>>> + set_bit(EFI_64BIT, &efi.flags);
>>> +#endif
>>> +}
>>> +
>>> /* First C function to be called on Xen boot */
>>> asmlinkage __visible void __init xen_start_kernel(void)
>>> {
>>> struct physdev_set_iopl set_iopl;
>>> int rc;
>>> - efi_system_table_t *efi_systab_xen;
>>> if (!xen_start_info)
>>> return;
>>> @@ -1717,18 +1737,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
>>> xen_setup_runstate_info(0);
>>> - efi_systab_xen = xen_efi_probe();
>>> -
>>> - if (efi_systab_xen) {
>>> - strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen",
>>> - sizeof(boot_params.efi_info.efi_loader_signature));
>>> - boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
>>> - boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
>>> -
>>> - set_bit(EFI_BOOT, &efi.flags);
>>> - set_bit(EFI_PARAVIRT, &efi.flags);
>>> - set_bit(EFI_64BIT, &efi.flags);
>>> - }
>>> + xen_efi_init();
>> I'd put ifdef CONFIG_XEN_EFI around the call instead of having it
>> inside the routine.
> Well, I thought about that a bit and I prefer function like Konrad.
> Could you agree with him which solution do you (as maintainers) prefer?
>
I am not arguing against having a separate routine. All I am saying is
that calling xen_efi_init() when CONFIG_XEN_EFI is not defined doesn't
look logical. It will also add an unnecessary call (although compiler
may optimize it out).
-boris
next prev parent reply other threads:[~2014-07-11 20:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 19:54 [PATCH 0/2] xen: Silence compiler warnings Daniel Kiper
2014-07-11 19:54 ` [PATCH 1/2] " Daniel Kiper
2014-07-11 19:54 ` Daniel Kiper
2014-07-11 19:54 ` [PATCH 2/2] arch/x86/xen: " Daniel Kiper
2014-07-11 19:54 ` Daniel Kiper
2014-07-11 20:03 ` Boris Ostrovsky
2014-07-11 20:03 ` Boris Ostrovsky
2014-07-11 20:10 ` Daniel Kiper
2014-07-11 20:32 ` Boris Ostrovsky [this message]
2014-07-11 23:45 ` Daniel Kiper
2014-07-11 23:45 ` Daniel Kiper
2014-07-11 20:32 ` Boris Ostrovsky
2014-07-11 20:10 ` Daniel Kiper
-- strict thread matches above, loose matches on Subject: below --
2014-07-12 0:14 Konrad Rzeszutek Wilk
2014-07-12 0:14 Konrad Rzeszutek Wilk
2014-07-12 0:47 Daniel Kiper
2014-07-12 1:33 ` Konrad Rzeszutek Wilk
2014-07-12 1:33 ` Konrad Rzeszutek Wilk
2014-07-12 0:47 Daniel Kiper
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=53C049DB.3050904@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=daniel.kiper@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=hpa@zytor.com \
--cc=ian.campbell@citrix.com \
--cc=jbeulich@suse.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.