All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Arnd Bergmann <arnd@arndb.de>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Denis Efremov <efremov@linux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
Date: Sat, 7 Sep 2019 11:05:45 +0100	[thread overview]
Message-ID: <95dbd972-fe78-d0ca-f7b4-1a6bdd418eab@arm.com> (raw)
In-Reply-To: <bda2a05b-e2d0-feee-761b-88deeeac2449@citrix.com>

Hi Andrew,

On 9/6/19 6:20 PM, Andrew Cooper wrote:
> On 06/09/2019 17:00, Arnd Bergmann wrote:
>> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>>> HYPERVISOR_platform_op() is an inline function and should not
>>>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>>>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>>>
>>>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>>>
>>>> Remove the extraneous export.
>>>>
>>>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Something is wonky.  That symbol is (/ really ought to be) in the
>>> hypercall page and most definitely not inline.
>>>
>>> Which tree is that changeset from?  I can't find the SHA.
>> This is from linux-next, I think from the kbuild tree.
> 
> Thanks.
> 
> Julien/Stefano: Why are any of these hypercalls out-of-line?  ARM
> doesn't use the hypercall page, and there is no argument translation
> (not even in arm32 as there are no 5-argument hypercalls declared).

I am not sure how the hypercall page makes things different. You still 
have to store the arguments in the correct register so...

> 
> They'd surely be easier to implement with a few static inlines and some
> common code, than to try and replicate the x86 side hypercall_page
> interface ?

... I don't think they will be easier to implement with a few static 
inlines. The implementation will likely end up to be similar to 
arch/x86/asm/xen/hypercall.h.

Furthermore, one of the downside of per-arch static inline is it is more 
difficult to ensure the prototype match for all the architectures. 
Although, it might be possible to make them common by only requesting 
per-arch to implement HYPERCALL_N(...).

So I think the code is better as it is.

While looking at the code, I also realized that the implementation of 
HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call, 
I think dm_op call should enable user access as they will be used by 
userspace.

We don't use dm_op on Arm so far, hence why I think this was unnoticed. 
I will see if I can reproduce it and send a patch.

Cheers,

-- 
Julien Grall

WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@arm.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Arnd Bergmann <arnd@arndb.de>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Denis Efremov <efremov@linux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
Date: Sat, 7 Sep 2019 11:05:45 +0100	[thread overview]
Message-ID: <95dbd972-fe78-d0ca-f7b4-1a6bdd418eab@arm.com> (raw)
In-Reply-To: <bda2a05b-e2d0-feee-761b-88deeeac2449@citrix.com>

Hi Andrew,

On 9/6/19 6:20 PM, Andrew Cooper wrote:
> On 06/09/2019 17:00, Arnd Bergmann wrote:
>> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>>> HYPERVISOR_platform_op() is an inline function and should not
>>>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>>>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>>>
>>>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>>>
>>>> Remove the extraneous export.
>>>>
>>>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Something is wonky.  That symbol is (/ really ought to be) in the
>>> hypercall page and most definitely not inline.
>>>
>>> Which tree is that changeset from?  I can't find the SHA.
>> This is from linux-next, I think from the kbuild tree.
> 
> Thanks.
> 
> Julien/Stefano: Why are any of these hypercalls out-of-line?  ARM
> doesn't use the hypercall page, and there is no argument translation
> (not even in arm32 as there are no 5-argument hypercalls declared).

I am not sure how the hypercall page makes things different. You still 
have to store the arguments in the correct register so...

> 
> They'd surely be easier to implement with a few static inlines and some
> common code, than to try and replicate the x86 side hypercall_page
> interface ?

... I don't think they will be easier to implement with a few static 
inlines. The implementation will likely end up to be similar to 
arch/x86/asm/xen/hypercall.h.

Furthermore, one of the downside of per-arch static inline is it is more 
difficult to ensure the prototype match for all the architectures. 
Although, it might be possible to make them common by only requesting 
per-arch to implement HYPERCALL_N(...).

So I think the code is better as it is.

While looking at the code, I also realized that the implementation of 
HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call, 
I think dm_op call should enable user access as they will be used by 
userspace.

We don't use dm_op on Arm so far, hence why I think this was unnoticed. 
I will see if I can reproduce it and send a patch.

Cheers,

-- 
Julien Grall

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@arm.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Arnd Bergmann <arnd@arndb.de>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Denis Efremov <efremov@linux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
Date: Sat, 7 Sep 2019 11:05:45 +0100	[thread overview]
Message-ID: <95dbd972-fe78-d0ca-f7b4-1a6bdd418eab@arm.com> (raw)
In-Reply-To: <bda2a05b-e2d0-feee-761b-88deeeac2449@citrix.com>

Hi Andrew,

On 9/6/19 6:20 PM, Andrew Cooper wrote:
> On 06/09/2019 17:00, Arnd Bergmann wrote:
>> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>>> HYPERVISOR_platform_op() is an inline function and should not
>>>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>>>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>>>
>>>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>>>
>>>> Remove the extraneous export.
>>>>
>>>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Something is wonky.  That symbol is (/ really ought to be) in the
>>> hypercall page and most definitely not inline.
>>>
>>> Which tree is that changeset from?  I can't find the SHA.
>> This is from linux-next, I think from the kbuild tree.
> 
> Thanks.
> 
> Julien/Stefano: Why are any of these hypercalls out-of-line?  ARM
> doesn't use the hypercall page, and there is no argument translation
> (not even in arm32 as there are no 5-argument hypercalls declared).

I am not sure how the hypercall page makes things different. You still 
have to store the arguments in the correct register so...

> 
> They'd surely be easier to implement with a few static inlines and some
> common code, than to try and replicate the x86 side hypercall_page
> interface ?

... I don't think they will be easier to implement with a few static 
inlines. The implementation will likely end up to be similar to 
arch/x86/asm/xen/hypercall.h.

Furthermore, one of the downside of per-arch static inline is it is more 
difficult to ensure the prototype match for all the architectures. 
Although, it might be possible to make them common by only requesting 
per-arch to implement HYPERCALL_N(...).

So I think the code is better as it is.

While looking at the code, I also realized that the implementation of 
HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call, 
I think dm_op call should enable user access as they will be used by 
userspace.

We don't use dm_op on Arm so far, hence why I think this was unnoticed. 
I will see if I can reproduce it and send a patch.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-09-07 10:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06 15:39 [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function Arnd Bergmann
2019-09-06 15:39 ` [Xen-devel] " Arnd Bergmann
2019-09-06 15:39 ` Arnd Bergmann
2019-09-06 15:55 ` [Xen-devel] " Andrew Cooper
2019-09-06 15:55   ` Andrew Cooper
2019-09-06 15:55   ` Andrew Cooper
2019-09-06 15:59   ` Jan Beulich
2019-09-06 15:59     ` Jan Beulich
2019-09-06 15:59     ` Jan Beulich
2019-09-06 16:00   ` Arnd Bergmann
2019-09-06 16:00     ` Arnd Bergmann
2019-09-06 16:00     ` Arnd Bergmann
2019-09-06 17:20     ` Andrew Cooper
2019-09-06 17:20       ` Andrew Cooper
2019-09-06 17:20       ` Andrew Cooper
2019-09-07 10:05       ` Julien Grall [this message]
2019-09-07 10:05         ` Julien Grall
2019-09-07 10:05         ` Julien Grall
2019-10-01 14:33         ` Mark Rutland
2019-10-01 14:33           ` Mark Rutland
2019-10-01 14:33           ` Mark Rutland
2019-10-01 14:39           ` Julien Grall
2019-10-01 14:39             ` Julien Grall
2019-10-01 14:39             ` Julien Grall
2019-10-01 14:46             ` Mark Rutland
2019-10-01 14:46               ` Mark Rutland
2019-10-01 14:46               ` Mark Rutland
2019-10-01 17:38 ` Stefano Stabellini
2019-10-01 17:38   ` [Xen-devel] " Stefano Stabellini
2019-10-01 17:38   ` Stefano Stabellini
2019-10-01 18:57   ` Arnd Bergmann
2019-10-01 18:57     ` [Xen-devel] " Arnd Bergmann
2019-10-01 18:57     ` Arnd Bergmann

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=95dbd972-fe78-d0ca-f7b4-1a6bdd418eab@arm.com \
    --to=julien.grall@arm.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=arnd@arndb.de \
    --cc=efremov@linux.com \
    --cc=emil.l.velikov@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yamada.masahiro@socionext.com \
    /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.