Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On Mon Jun 12, 2023 at 10:19 AM CDT, George Dunlap wrote: > Shawn, > > Again sorry that you've sort of bumped a hornet's nest here. > > Just to clarify, the situation as I understand it is: Hi George, No problem, and thank you for the detailed explanation. > HOWEVER, as Andrew says, there is no official policy at this point; all the > document say is that GPLv2-only is the default unless explicitly stated > otherwise. > > Furthermore, the concerns raised by ARM's legal team were nearly a decade > ago; it's not clear to me whether they still care that much. > > All that to say: If you don't mind and feel that you can do so legally, > then consider switching to GPLv2-only; but if you don't want to and/or feel > that you can't do so legally, feel free to leave it as-is. I'll definitely keep this in mind when creating new files that don't need to include GPLv2+ code. > -George Thanks, Shawn
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
Hi George, Thanks for the summary! A couple of comments below. On 12/06/2023 16:19, George Dunlap wrote: On Fri, Jun 9, 2023 at 5:07 PM Julien Grall wrote: Hi Shawn, On 09/06/2023 16:01, Shawn Anastasio wrote: On Fri Jun 9, 2023 at 5:12 AM CDT, Julien Grall wrote: Strictly speaking we can refuse any code. That count for license as well. Anyway, I didn't request a change here. I merely pointed out that any use of GPLv2+ should be justified because on Arm most of the people don't pay attention on the license and pick the one from an existing file. Hi Julien, The choice of GPLv2+ for many of the files in this patchset was indeed inherited from old IBM-written Xen code that the files in question were derived from. I did not realize it was permissible or even desirable to relicense those to GPLv2-only. As for the new files, GPLv2+ was chosen to remain consistent and to open the door for future derivations from GPLv2+ licensed code, either from the older Xen tree or from the Linux ppc tree, much of which is also licensed as GPLv2+. If it would reduce friction, these files could be relicensed to GPLv2-only. (Before someone points out, I know this is already a problem on other part of Xen. But it would be ideal if we avoid spreading this mess on new architectures :). Thanks for the explanations. To clarify, are you saying that all the files will be GPLv2+ or just some? If the latter, then my concern would be that if you need to import GPLv2-only code, then you may need to write your code in a different file. This may become messy to handle and some developer may end up to be confused. I am not a lawyer though, so you may want to check the implications here. Shawn, Again sorry that you've sort of bumped a hornet's nest here. Just to clarify, the situation as I understand it is: 1. Large parts of Xen, being inherited from the Linux Kernel, are GPLv2-only; and the documentation clearly states that code is GPLv2-only unless explicitly stated otherwise. 2. Some individual files in Xen are labelled as GPLv2-or-later; but as they rely on the "only" files, Xen as a whole can only be compiled under a GPLv2 license. 3. New contributions to a file assumed to have the same license as the header of the file; i.e., the code contained in patches to GPLv2-or-later files is assumed to be granted according to a GPLv2-or-later license. The new contribution here could be code imported from Linux that would be GPLv2-only in GPLv2-or-later file. It is not clear to me what would be the legal implication. 4. In the past, the legal teams of some contributors -- namely ARM -- were wary of the GPLv3; specifically the patent grant. Since ARM doesn't make anything themselves, their patents are literally their product; they need to be very careful of not accidentally granting them to the world. I think one thing ARM may have been afraid of at some point is one of their engineers accidentally submitting a patch to a GPLv2-or-later file which would, when taken with a GPLv3 (or GPLv4 license, once it comes out) cause them to lose too much control over their IP. My understanding is that Julien is afraid that if the "GPLv2-or-later" files start to proliferate, that companies like ARM will start to become more wary of contributing; and so has been generally trying to encourage new files to be labelled "GPLv2-only" unless there's a good reason to do otherwise. (Other issues like copying code from GPLv2-only are potential pitfalls as well, but probably less important.) There is that and also the fact that we now need to be more careful when importing code from Linux. In Shawn's case this is mitigated by the fact that the license in Xen files should match the one in Linux. Additionally, I think it would be good if the community *did* have a discussion about whether we want an official policy; so that either we can point people to the relevant doc (with explanation), or stop bothering about it. :-) +1. Do you think that would be a good topic for Xen Summit? Cheers, -- Julien Grall
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On Fri, Jun 9, 2023 at 5:07 PM Julien Grall wrote: > Hi Shawn, > > On 09/06/2023 16:01, Shawn Anastasio wrote: > > On Fri Jun 9, 2023 at 5:12 AM CDT, Julien Grall wrote: > >> Strictly speaking we can refuse any code. That count for license as > >> well. Anyway, I didn't request a change here. I merely pointed out that > >> any use of GPLv2+ should be justified because on Arm most of the people > >> don't pay attention on the license and pick the one from an existing > file. > > > > Hi Julien, > > > > The choice of GPLv2+ for many of the files in this patchset was indeed > > inherited from old IBM-written Xen code that the files in question were > > derived from. I did not realize it was permissible or even desirable to > > relicense those to GPLv2-only. > > > > As for the new files, GPLv2+ was chosen to remain consistent and to open > > the door for future derivations from GPLv2+ licensed code, either from > > the older Xen tree or from the Linux ppc tree, much of which is also > > licensed as GPLv2+. If it would reduce friction, these files could be > > relicensed to GPLv2-only. > > (Before someone points out, I know this is already a problem on other > part of Xen. But it would be ideal if we avoid spreading this mess on > new architectures :). > > Thanks for the explanations. To clarify, are you saying that all the > files will be GPLv2+ or just some? > > If the latter, then my concern would be that if you need to import > GPLv2-only code, then you may need to write your code in a different > file. This may become messy to handle and some developer may end up to > be confused. > > I am not a lawyer though, so you may want to check the implications here. > Shawn, Again sorry that you've sort of bumped a hornet's nest here. Just to clarify, the situation as I understand it is: 1. Large parts of Xen, being inherited from the Linux Kernel, are GPLv2-only; and the documentation clearly states that code is GPLv2-only unless explicitly stated otherwise. 2. Some individual files in Xen are labelled as GPLv2-or-later; but as they rely on the "only" files, Xen as a whole can only be compiled under a GPLv2 license. 3. New contributions to a file assumed to have the same license as the header of the file; i.e., the code contained in patches to GPLv2-or-later files is assumed to be granted according to a GPLv2-or-later license. 4. In the past, the legal teams of some contributors -- namely ARM -- were wary of the GPLv3; specifically the patent grant. Since ARM doesn't make anything themselves, their patents are literally their product; they need to be very careful of not accidentally granting them to the world. I think one thing ARM may have been afraid of at some point is one of their engineers accidentally submitting a patch to a GPLv2-or-later file which would, when taken with a GPLv3 (or GPLv4 license, once it comes out) cause them to lose too much control over their IP. My understanding is that Julien is afraid that if the "GPLv2-or-later" files start to proliferate, that companies like ARM will start to become more wary of contributing; and so has been generally trying to encourage new files to be labelled "GPLv2-only" unless there's a good reason to do otherwise. (Other issues like copying code from GPLv2-only are potential pitfalls as well, but probably less important.) HOWEVER, as Andrew says, there is no official policy at this point; all the document say is that GPLv2-only is the default unless explicitly stated otherwise. Furthermore, the concerns raised by ARM's legal team were nearly a decade ago; it's not clear to me whether they still care that much. All that to say: If you don't mind and feel that you can do so legally, then consider switching to GPLv2-only; but if you don't want to and/or feel that you can't do so legally, feel free to leave it as-is. Additionally, I think it would be good if the community *did* have a discussion about whether we want an official policy; so that either we can point people to the relevant doc (with explanation), or stop bothering about it. :-) -George
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On Fri Jun 9, 2023 at 11:07 AM CDT, Julien Grall wrote: > Thanks for the explanations. To clarify, are you saying that all the > files will be GPLv2+ or just some? My idea was to license any file where I expect there to derivations from existing code as GPLv2+, and fall back to GPLv2-only for newly-written files for which I expect there to be no reuse of existing GPLv2+ code. > If the latter, then my concern would be that if you need to import > GPLv2-only code, then you may need to write your code in a different > file. This may become messy to handle and some developer may end up to > be confused. Agreed, and I definitely want to minimize confusion. Ultimately I think situations like this will be unavoidable, though, since derivations will likely need to be made from both GPLv2-only and GPLv2+ code. > Cheers, Thanks, Shawn
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
Hi Shawn, On 09/06/2023 16:01, Shawn Anastasio wrote: On Fri Jun 9, 2023 at 5:12 AM CDT, Julien Grall wrote: Strictly speaking we can refuse any code. That count for license as well. Anyway, I didn't request a change here. I merely pointed out that any use of GPLv2+ should be justified because on Arm most of the people don't pay attention on the license and pick the one from an existing file. Hi Julien, The choice of GPLv2+ for many of the files in this patchset was indeed inherited from old IBM-written Xen code that the files in question were derived from. I did not realize it was permissible or even desirable to relicense those to GPLv2-only. As for the new files, GPLv2+ was chosen to remain consistent and to open the door for future derivations from GPLv2+ licensed code, either from the older Xen tree or from the Linux ppc tree, much of which is also licensed as GPLv2+. If it would reduce friction, these files could be relicensed to GPLv2-only. (Before someone points out, I know this is already a problem on other part of Xen. But it would be ideal if we avoid spreading this mess on new architectures :). Thanks for the explanations. To clarify, are you saying that all the files will be GPLv2+ or just some? If the latter, then my concern would be that if you need to import GPLv2-only code, then you may need to write your code in a different file. This may become messy to handle and some developer may end up to be confused. I am not a lawyer though, so you may want to check the implications here. Cheers, -- Julien Grall
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On Fri Jun 9, 2023 at 4:22 AM CDT, Jan Beulich wrote: > > xen/arch/ppc/Kconfig.debug | 5 + > > xen/arch/ppc/Makefile| 3 +- > > xen/arch/ppc/boot_of.c | 122 +++ > > xen/arch/ppc/configs/openpower_defconfig | 1 + > > xen/arch/ppc/early_printk.c | 36 +++ > > xen/arch/ppc/include/asm/boot.h | 31 ++ > > xen/arch/ppc/include/asm/bug.h | 6 ++ > > xen/arch/ppc/include/asm/byteorder.h | 74 ++ > > xen/arch/ppc/include/asm/cache.h | 6 ++ > > xen/arch/ppc/include/asm/config.h| 3 + > > xen/arch/ppc/include/asm/early_printk.h | 14 +++ > > xen/arch/ppc/include/asm/processor.h | 54 +- > > xen/arch/ppc/include/asm/string.h| 6 ++ > > xen/arch/ppc/include/asm/types.h | 64 > > xen/arch/ppc/ppc64/asm-offsets.c | 55 ++ > > xen/arch/ppc/ppc64/head.S| 59 +++ > > xen/arch/ppc/setup.c | 20 +++- > > 17 files changed, 555 insertions(+), 4 deletions(-) > > create mode 100644 xen/arch/ppc/boot_of.c > > Unless required, in new additions we tend to prefer dashes over > underscores. In filenames it is pretty rare that dashes really need > avoiding. Thanks for pointing that out -- I'll fix this in v2. > > --- a/xen/arch/ppc/Kconfig.debug > > +++ b/xen/arch/ppc/Kconfig.debug > > @@ -0,0 +1,5 @@ > > +config EARLY_PRINTK > > +bool "Enable early printk" > > +default DEBUG > > +help > > + Enables early printk debug messages > > \ No newline at end of file > > There are many examples of this throughout the patch, which you want to > take care of. Ditto. > > --- /dev/null > > +++ b/xen/arch/ppc/boot_of.c > > @@ -0,0 +1,122 @@ > > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > > By default we mean to use ... > > > --- /dev/null > > +++ b/xen/arch/ppc/early_printk.c > > @@ -0,0 +1,36 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > ... the more modern form of this (GPL-2.0-only). Anything deviating from > that may want justifying in the description. Got it -- I'll clean this up as well. > Jan Thanks, Shawn
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On Fri Jun 9, 2023 at 5:12 AM CDT, Julien Grall wrote: > Strictly speaking we can refuse any code. That count for license as > well. Anyway, I didn't request a change here. I merely pointed out that > any use of GPLv2+ should be justified because on Arm most of the people > don't pay attention on the license and pick the one from an existing file. Hi Julien, The choice of GPLv2+ for many of the files in this patchset was indeed inherited from old IBM-written Xen code that the files in question were derived from. I did not realize it was permissible or even desirable to relicense those to GPLv2-only. As for the new files, GPLv2+ was chosen to remain consistent and to open the door for future derivations from GPLv2+ licensed code, either from the older Xen tree or from the Linux ppc tree, much of which is also licensed as GPLv2+. If it would reduce friction, these files could be relicensed to GPLv2-only. Thanks, Shawn
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
Hi Andrew, On 09/06/2023 10:54, Andrew Cooper wrote: On 09/06/2023 10:46 am, Julien Grall wrote: On 09/06/2023 10:43, Andrew Cooper wrote: On 09/06/2023 10:38 am, Jan Beulich wrote: On 09.06.2023 11:29, Andrew Cooper wrote: On 09/06/2023 10:22 am, Jan Beulich wrote: --- /dev/null +++ b/xen/arch/ppc/boot_of.c @@ -0,0 +1,122 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ By default we mean to use ... --- /dev/null +++ b/xen/arch/ppc/early_printk.c @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ ... the more modern form of this (GPL-2.0-only). Anything deviating from that may want justifying in the description. GPL-2.0-or-later is fine. Hmm, I was merely following https://lists.xen.org/archives/html/xen-devel/2023-06/msg00415.html. The text at the top of ./COPYING looks to suggest -only, and I'm unaware of any other place where our default is actually written down. The license is chosen by the submitter/copyright holder, based on their preferences/wishes. It's fine for Xen to say "if you've got no vested interest, we recommend GPL-2.0-only", but that is strictly a recommendation and no more. If the submitter chooses GPL-2.0-or-later, that is their prerogative. We have plenty of GPL-2.0-or-later code in Xen. From my past experience, the submitters tend to just copy the license from an existing file in Xen rather than explicitly choosing it. So I think it is fair to ask the question because our original and default license is GPLv2 nor GPLv2+. Did you read the bit in the cover letter about part of this code being derived from the out-of-tree port years ago? Yes I read it... But I didn't check the original license and ... You're blindly assuming that there is even a choice of license available to be used. ... I didn't assume anything here. I made a generic statement because your e-mail lead to think that all the submitter made a conscious decision. Note that, from past discussion, we agreed that it would be fine to re-license from gplv2+ to gplv2-only without requesting the original author. So technically there is a choice. As a side note, "blindly" is not very inclusive. We may have different view, but it doesn't mean yours is better than mine (and vice-versa). You could have express your opinion without saying "blindly" and it would have come across less rude. The submitter chooses the license to use. You can request that they justify it, but you cannot demand that they change it. Strictly speaking we can refuse any code. That count for license as well. Anyway, I didn't request a change here. I merely pointed out that any use of GPLv2+ should be justified because on Arm most of the people don't pay attention on the license and pick the one from an existing file. Cheers, -- Julien Grall
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On 09/06/2023 10:46 am, Julien Grall wrote: > On 09/06/2023 10:43, Andrew Cooper wrote: >> On 09/06/2023 10:38 am, Jan Beulich wrote: >>> On 09.06.2023 11:29, Andrew Cooper wrote: On 09/06/2023 10:22 am, Jan Beulich wrote: >> --- /dev/null >> +++ b/xen/arch/ppc/boot_of.c >> @@ -0,0 +1,122 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ > By default we mean to use ... > >> --- /dev/null >> +++ b/xen/arch/ppc/early_printk.c >> @@ -0,0 +1,36 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ > ... the more modern form of this (GPL-2.0-only). Anything > deviating from > that may want justifying in the description. GPL-2.0-or-later is fine. >>> Hmm, I was merely following >>> https://lists.xen.org/archives/html/xen-devel/2023-06/msg00415.html. >>> The text at the top of ./COPYING looks to suggest -only, and I'm >>> unaware of any other place where our default is actually written down. >> >> The license is chosen by the submitter/copyright holder, based on their >> preferences/wishes. >> >> It's fine for Xen to say "if you've got no vested interest, we recommend >> GPL-2.0-only", but that is strictly a recommendation and no more. >> >> If the submitter chooses GPL-2.0-or-later, that is their prerogative. >> We have plenty of GPL-2.0-or-later code in Xen. > > From my past experience, the submitters tend to just copy the license > from an existing file in Xen rather than explicitly choosing it. So I > think it is fair to ask the question because our original and default > license is GPLv2 nor GPLv2+. Did you read the bit in the cover letter about part of this code being derived from the out-of-tree port years ago? You're blindly assuming that there is even a choice of license available to be used. The submitter chooses the license to use. You can request that they justify it, but you cannot demand that they change it. ~Andrew
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
Hi Andrew, On 09/06/2023 10:43, Andrew Cooper wrote: On 09/06/2023 10:38 am, Jan Beulich wrote: On 09.06.2023 11:29, Andrew Cooper wrote: On 09/06/2023 10:22 am, Jan Beulich wrote: --- /dev/null +++ b/xen/arch/ppc/boot_of.c @@ -0,0 +1,122 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ By default we mean to use ... --- /dev/null +++ b/xen/arch/ppc/early_printk.c @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ ... the more modern form of this (GPL-2.0-only). Anything deviating from that may want justifying in the description. GPL-2.0-or-later is fine. Hmm, I was merely following https://lists.xen.org/archives/html/xen-devel/2023-06/msg00415.html. The text at the top of ./COPYING looks to suggest -only, and I'm unaware of any other place where our default is actually written down. The license is chosen by the submitter/copyright holder, based on their preferences/wishes. It's fine for Xen to say "if you've got no vested interest, we recommend GPL-2.0-only", but that is strictly a recommendation and no more. If the submitter chooses GPL-2.0-or-later, that is their prerogative. We have plenty of GPL-2.0-or-later code in Xen. From my past experience, the submitters tend to just copy the license from an existing file in Xen rather than explicitly choosing it. So I think it is fair to ask the question because our original and default license is GPLv2 nor GPLv2+. Cheers, -- Julien Grall
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On 09/06/2023 10:38 am, Jan Beulich wrote: > On 09.06.2023 11:29, Andrew Cooper wrote: >> On 09/06/2023 10:22 am, Jan Beulich wrote: --- /dev/null +++ b/xen/arch/ppc/boot_of.c @@ -0,0 +1,122 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ >>> By default we mean to use ... >>> --- /dev/null +++ b/xen/arch/ppc/early_printk.c @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ >>> ... the more modern form of this (GPL-2.0-only). Anything deviating from >>> that may want justifying in the description. >> GPL-2.0-or-later is fine. > Hmm, I was merely following > https://lists.xen.org/archives/html/xen-devel/2023-06/msg00415.html. > The text at the top of ./COPYING looks to suggest -only, and I'm > unaware of any other place where our default is actually written down. The license is chosen by the submitter/copyright holder, based on their preferences/wishes. It's fine for Xen to say "if you've got no vested interest, we recommend GPL-2.0-only", but that is strictly a recommendation and no more. If the submitter chooses GPL-2.0-or-later, that is their prerogative. We have plenty of GPL-2.0-or-later code in Xen. ~Andrew
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
Hi, On 09/06/2023 10:38, Jan Beulich wrote: On 09.06.2023 11:29, Andrew Cooper wrote: On 09/06/2023 10:22 am, Jan Beulich wrote: --- /dev/null +++ b/xen/arch/ppc/boot_of.c @@ -0,0 +1,122 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ By default we mean to use ... --- /dev/null +++ b/xen/arch/ppc/early_printk.c @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ ... the more modern form of this (GPL-2.0-only). Anything deviating from that may want justifying in the description. GPL-2.0-or-later is fine. Hmm, I was merely following https://lists.xen.org/archives/html/xen-devel/2023-06/msg00415.html. The text at the top of ./COPYING looks to suggest -only, and I'm unaware of any other place where our default is actually written down. We had several discussion in the past about using GPLv2+ license in Xen (see [1], [2]). It has always been unclear what is the impact on contribution with such license. So I think we should stick with GPL-2.0 for new code unless there is a reason to diverge. Cheers, [1] https://patchwork.kernel.org/project/xen-devel/patch/1474985810-12289-1-git-send-email-lars.ku...@citrix.com/#19650817 [2] https://lore.kernel.org/all/alpine.DEB.2.22.394.2208231140140.15247@ubuntu-linux-20-04-desktop/ -- Julien Grall
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On 09.06.2023 11:29, Andrew Cooper wrote: > On 09/06/2023 10:22 am, Jan Beulich wrote: >>> --- /dev/null >>> +++ b/xen/arch/ppc/boot_of.c >>> @@ -0,0 +1,122 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >> By default we mean to use ... >> >>> --- /dev/null >>> +++ b/xen/arch/ppc/early_printk.c >>> @@ -0,0 +1,36 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >> ... the more modern form of this (GPL-2.0-only). Anything deviating from >> that may want justifying in the description. > > GPL-2.0-or-later is fine. Hmm, I was merely following https://lists.xen.org/archives/html/xen-devel/2023-06/msg00415.html. The text at the top of ./COPYING looks to suggest -only, and I'm unaware of any other place where our default is actually written down. Jan > It's only the un-qualified GPL-2.0 form which is deprecated, and should > be replaced with an -or-later or -only suffix, as chosen by the > copyright holder. > > ~Andrew
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On 09/06/2023 10:22 am, Jan Beulich wrote: >> --- /dev/null >> +++ b/xen/arch/ppc/boot_of.c >> @@ -0,0 +1,122 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ > By default we mean to use ... > >> --- /dev/null >> +++ b/xen/arch/ppc/early_printk.c >> @@ -0,0 +1,36 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ > ... the more modern form of this (GPL-2.0-only). Anything deviating from > that may want justifying in the description. GPL-2.0-or-later is fine. It's only the un-qualified GPL-2.0 form which is deprecated, and should be replaced with an -or-later or -only suffix, as chosen by the copyright holder. ~Andrew
Re: [PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On 07.06.2023 17:06, Shawn Anastasio wrote: > On typical Power VMs (e.g. QEMU's -M pseries), a variety of services > are provided by OpenFirmware, including an early serial console. > Implement the required interfaces to call into OpenFirmware and write > to the serial console. > > Since OpenFirmware runs in 32-bit Big Endian mode and Xen runs in > 64-bit Little Endian mode, a thunk is required to save/restore > any potentially-clobbered registers as well as to perform the > required endianness switch. Thankfully, linux already has such > a routine, which was imported into head.S. > > Support for bare metal (PowerNV) will be implemented in a future > patch. > > Signed-off-by: Shawn Anastasio Just a couple of nits: > xen/arch/ppc/Kconfig.debug | 5 + > xen/arch/ppc/Makefile| 3 +- > xen/arch/ppc/boot_of.c | 122 +++ > xen/arch/ppc/configs/openpower_defconfig | 1 + > xen/arch/ppc/early_printk.c | 36 +++ > xen/arch/ppc/include/asm/boot.h | 31 ++ > xen/arch/ppc/include/asm/bug.h | 6 ++ > xen/arch/ppc/include/asm/byteorder.h | 74 ++ > xen/arch/ppc/include/asm/cache.h | 6 ++ > xen/arch/ppc/include/asm/config.h| 3 + > xen/arch/ppc/include/asm/early_printk.h | 14 +++ > xen/arch/ppc/include/asm/processor.h | 54 +- > xen/arch/ppc/include/asm/string.h| 6 ++ > xen/arch/ppc/include/asm/types.h | 64 > xen/arch/ppc/ppc64/asm-offsets.c | 55 ++ > xen/arch/ppc/ppc64/head.S| 59 +++ > xen/arch/ppc/setup.c | 20 +++- > 17 files changed, 555 insertions(+), 4 deletions(-) > create mode 100644 xen/arch/ppc/boot_of.c Unless required, in new additions we tend to prefer dashes over underscores. In filenames it is pretty rare that dashes really need avoiding. > --- a/xen/arch/ppc/Kconfig.debug > +++ b/xen/arch/ppc/Kconfig.debug > @@ -0,0 +1,5 @@ > +config EARLY_PRINTK > +bool "Enable early printk" > +default DEBUG > +help > + Enables early printk debug messages > \ No newline at end of file There are many examples of this throughout the patch, which you want to take care of. > --- /dev/null > +++ b/xen/arch/ppc/boot_of.c > @@ -0,0 +1,122 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ By default we mean to use ... > --- /dev/null > +++ b/xen/arch/ppc/early_printk.c > @@ -0,0 +1,36 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ ... the more modern form of this (GPL-2.0-only). Anything deviating from that may want justifying in the description. Jan
[PATCH 2/3] xen/ppc: Implement early serial printk on PaPR/pseries
On typical Power VMs (e.g. QEMU's -M pseries), a variety of services
are provided by OpenFirmware, including an early serial console.
Implement the required interfaces to call into OpenFirmware and write
to the serial console.
Since OpenFirmware runs in 32-bit Big Endian mode and Xen runs in
64-bit Little Endian mode, a thunk is required to save/restore
any potentially-clobbered registers as well as to perform the
required endianness switch. Thankfully, linux already has such
a routine, which was imported into head.S.
Support for bare metal (PowerNV) will be implemented in a future
patch.
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/Kconfig.debug | 5 +
xen/arch/ppc/Makefile| 3 +-
xen/arch/ppc/boot_of.c | 122 +++
xen/arch/ppc/configs/openpower_defconfig | 1 +
xen/arch/ppc/early_printk.c | 36 +++
xen/arch/ppc/include/asm/boot.h | 31 ++
xen/arch/ppc/include/asm/bug.h | 6 ++
xen/arch/ppc/include/asm/byteorder.h | 74 ++
xen/arch/ppc/include/asm/cache.h | 6 ++
xen/arch/ppc/include/asm/config.h| 3 +
xen/arch/ppc/include/asm/early_printk.h | 14 +++
xen/arch/ppc/include/asm/processor.h | 54 +-
xen/arch/ppc/include/asm/string.h| 6 ++
xen/arch/ppc/include/asm/types.h | 64
xen/arch/ppc/ppc64/asm-offsets.c | 55 ++
xen/arch/ppc/ppc64/head.S| 59 +++
xen/arch/ppc/setup.c | 20 +++-
17 files changed, 555 insertions(+), 4 deletions(-)
create mode 100644 xen/arch/ppc/boot_of.c
create mode 100644 xen/arch/ppc/early_printk.c
create mode 100644 xen/arch/ppc/include/asm/boot.h
create mode 100644 xen/arch/ppc/include/asm/bug.h
create mode 100644 xen/arch/ppc/include/asm/byteorder.h
create mode 100644 xen/arch/ppc/include/asm/cache.h
create mode 100644 xen/arch/ppc/include/asm/early_printk.h
create mode 100644 xen/arch/ppc/include/asm/string.h
create mode 100644 xen/arch/ppc/include/asm/types.h
diff --git a/xen/arch/ppc/Kconfig.debug b/xen/arch/ppc/Kconfig.debug
index e69de29bb2..3c25a446e8 100644
--- a/xen/arch/ppc/Kconfig.debug
+++ b/xen/arch/ppc/Kconfig.debug
@@ -0,0 +1,5 @@
+config EARLY_PRINTK
+bool "Enable early printk"
+default DEBUG
+help
+ Enables early printk debug messages
\ No newline at end of file
diff --git a/xen/arch/ppc/Makefile b/xen/arch/ppc/Makefile
index b3ad837d4b..00b3b7baf3 100644
--- a/xen/arch/ppc/Makefile
+++ b/xen/arch/ppc/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_PPC64) += ppc64/
-obj-y += setup.o
+obj-y += setup.o boot_of.o
+obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
$(TARGET): $(TARGET)-syms
cp -f $< $@
diff --git a/xen/arch/ppc/boot_of.c b/xen/arch/ppc/boot_of.c
new file mode 100644
index 00..9447d92661
--- /dev/null
+++ b/xen/arch/ppc/boot_of.c
@@ -0,0 +1,122 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2005, 2006, 2007
+ * Copyright Raptor Engineering, LLC
+ *
+ * Authors: Jimi Xenidis
+ * Hollis Blanchard
+ * Shawn Anastasio
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define ADDR(x) (uint32_t)(unsigned long)(x)
+
+/* OF entrypoint*/
+static unsigned long of_vec;
+
+/* OF device handles*/
+static int bof_chosen;
+static int of_out;
+
+static int of_call(const char *service, uint32_t nargs, uint32_t nrets,
+ int32_t rets[], ...)
+{
+int rc;
+va_list args;
+int i;
+struct of_service s = { 0 };
+
+s.ofs_service = cpu_to_be32(ADDR(service));
+s.ofs_nargs = cpu_to_be32(nargs);
+s.ofs_nrets = cpu_to_be32(nrets);
+
+/* copy all the params into the args array */
+va_start(args, rets);
+
+for ( i = 0; i < nargs; i++ )
+{
+s.ofs_args[i] = cpu_to_be32(va_arg(args, uint32_t));
+}
+
+va_end(args);
+
+rc = enter_prom(, of_vec);
+
+/* yes always to the copy, just in case */
+for ( i = 0; i < nrets; i++ )
+{
+rets[i] = be32_to_cpu(s.ofs_args[i + nargs]);
+}
+
+return rc;
+}
+
+static int of_finddevice(const char *devspec)
+{
+int rets[1] = { OF_FAILURE };
+
+
