Message ID | e9a4878544d264688578d7899867df7e8207aba5.1686148363.git.shawn@anastas.io (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | Initial support for Power | expand |
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 <shawnanastasio@raptorengineering.com> 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
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
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
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.kurth@citrix.com/#19650817 [2] https://lore.kernel.org/all/alpine.DEB.2.22.394.2208231140140.15247@ubuntu-linux-20-04-desktop/
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
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,
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
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,
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
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
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,
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
On Fri, Jun 9, 2023 at 5:07 PM Julien Grall <julien@xen.org> 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
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 <julien@xen.org> 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,
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
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 0000000000..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 <jimix@watson.ibm.com> + * Hollis Blanchard <hollisb@us.ibm.com> + * Shawn Anastasio <sanastasio@raptorengineering.com> + */ + +#include <xen/kernel.h> +#include <xen/init.h> +#include <xen/lib.h> +#include <asm/byteorder.h> +#include <asm/boot.h> + +#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(&s, 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 }; + + of_call("finddevice", 1, 1, rets, devspec); + if ( rets[0] == OF_FAILURE ) + return OF_FAILURE; + + return rets[0]; +} + +static int of_getprop(int ph, const char *name, void *buf, uint32_t buflen) +{ + int rets[1] = { OF_FAILURE }; + + of_call("getprop", 4, 1, rets, ph, ADDR(name), buf, buflen); + + if ( rets[0] == OF_FAILURE ) + return OF_FAILURE; + + return rets[0]; +} + +int of_write(int ih, const char *addr, uint32_t len) +{ + int rets[1] = { OF_FAILURE }; + + if ( of_call("write", 3, 1, rets, ih, addr, len) == OF_FAILURE ) + return OF_FAILURE; + + return rets[0]; +} + +void of_putchar(char c) +{ + if ( c == '\n' ) + { + char buf = '\r'; + (void) of_write(of_out, &buf, 1); + } + (void) of_write(of_out, &c, 1); +} + +void boot_of_init(unsigned long vec) +{ + of_vec = vec; + bof_chosen = of_finddevice("/chosen"); + of_getprop(bof_chosen, "stdout", &of_out, sizeof(of_out)); + of_out = be32_to_cpu(of_out); +} \ No newline at end of file diff --git a/xen/arch/ppc/configs/openpower_defconfig b/xen/arch/ppc/configs/openpower_defconfig index 8783eb3488..f7cc075e45 100644 --- a/xen/arch/ppc/configs/openpower_defconfig +++ b/xen/arch/ppc/configs/openpower_defconfig @@ -10,4 +10,5 @@ CONFIG_PPC64=y CONFIG_DEBUG=y CONFIG_DEBUG_INFO=y +CONFIG_EARLY_PRINTK=y CONFIG_EXPERT=y diff --git a/xen/arch/ppc/early_printk.c b/xen/arch/ppc/early_printk.c new file mode 100644 index 0000000000..ab9213d801 --- /dev/null +++ b/xen/arch/ppc/early_printk.c @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Power early printk using OpenFirmware or OPAL + * + * Copyright Raptor Engineering, LLC + * + * Authors: Shawn Anastasio <sanastasio@raptorengineering.com> + */ + +#include <xen/lib.h> +#include <asm/boot.h> + +static void (*putchar_func)(char); + +void early_printk_init(bool is_of) +{ + putchar_func = is_of ? of_putchar : NULL; +} + +void early_puts(const char *s, size_t nr) +{ + if ( !putchar_func ) + return; + + while ( nr-- > 0 ) + putchar_func(*s++); +} + +void early_printk(const char *s) +{ + if ( !putchar_func ) + return; + + while ( *s ) + putchar_func(*s++); +} \ No newline at end of file diff --git a/xen/arch/ppc/include/asm/boot.h b/xen/arch/ppc/include/asm/boot.h new file mode 100644 index 0000000000..96d56f9650 --- /dev/null +++ b/xen/arch/ppc/include/asm/boot.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Copyright Raptor Engineering, LLC + * + * Authors: Shawn Anastasio <@raptorengineering.com> + */ + +#ifndef _ASM_PPC_BOOT_H +#define _ASM_PPC_BOOT_H + +#include <xen/types.h> + +/* a collection of interfaces used during boot. */ +enum { + OF_FAILURE = -1, + OF_SUCCESS = 0, +}; + +struct of_service { + __be32 ofs_service; + __be32 ofs_nargs; + __be32 ofs_nrets; + __be32 ofs_args[10]; +}; + +extern int enter_prom(struct of_service *args, unsigned long entry); + +void boot_of_init(unsigned long); +void of_putchar(char c); + +#endif /* _ASM_PPC_BOOT_H */ \ No newline at end of file diff --git a/xen/arch/ppc/include/asm/bug.h b/xen/arch/ppc/include/asm/bug.h new file mode 100644 index 0000000000..40022a757b --- /dev/null +++ b/xen/arch/ppc/include/asm/bug.h @@ -0,0 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _ASM_PPC_BUG_H +#define _ASM_PPC_BUG_H + +#endif /* _ASM_PPC_BUG_H */ \ No newline at end of file diff --git a/xen/arch/ppc/include/asm/byteorder.h b/xen/arch/ppc/include/asm/byteorder.h new file mode 100644 index 0000000000..ac840f9b1c --- /dev/null +++ b/xen/arch/ppc/include/asm/byteorder.h @@ -0,0 +1,74 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_BYTEORDER_H +#define _ASM_POWERPC_BYTEORDER_H + +#include <asm/types.h> +#include <xen/compiler.h> + +static inline __u16 ld_le16(const volatile __u16 *addr) +{ + __u16 val; + + asm volatile ("lhbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr)); + return val; +} + +static inline void st_le16(volatile __u16 *addr, const __u16 val) +{ + asm volatile ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); +} + +static inline __u32 ld_le32(const volatile __u32 *addr) +{ + __u32 val; + + asm volatile ("lwbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr)); + return val; +} + +static inline void st_le32(volatile __u32 *addr, const __u32 val) +{ + asm volatile ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); +} + +static inline __attribute_const__ __u16 ___arch__swab16(__u16 value) +{ + __u16 result; + + asm("rlwimi %0,%1,8,16,23" + : "=r" (result) + : "r" (value), "0" (value >> 8)); + return result; +} + +static inline __attribute_const__ __u32 ___arch__swab32(__u32 value) +{ + __u32 result; + + asm("rlwimi %0,%1,24,16,23\n\t" + "rlwimi %0,%1,8,8,15\n\t" + "rlwimi %0,%1,24,0,7" + : "=r" (result) + : "r" (value), "0" (value >> 24)); + return result; +} + +#define __arch__swab16(x) ___arch__swab16(x) +#define __arch__swab32(x) ___arch__swab32(x) + +/* The same, but returns converted value from the location pointer by addr. */ +#define __arch__swab16p(addr) ld_le16(addr) +#define __arch__swab32p(addr) ld_le32(addr) + +/* The same, but do the conversion in situ, ie. put the value back to addr. */ +#define __arch__swab16s(addr) st_le16(addr,*addr) +#define __arch__swab32s(addr) st_le32(addr,*addr) + +#define __BYTEORDER_HAS_U64__ +#ifndef __powerpc64__ +#define __SWAB_64_THRU_32__ +#endif /* __powerpc64__ */ + +#include <xen/byteorder/little_endian.h> + +#endif /* _ASM_POWERPC_BYTEORDER_H */ diff --git a/xen/arch/ppc/include/asm/cache.h b/xen/arch/ppc/include/asm/cache.h new file mode 100644 index 0000000000..677a2b3915 --- /dev/null +++ b/xen/arch/ppc/include/asm/cache.h @@ -0,0 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _ASM_PPC_CACHE_H +#define _ASM_PPC_CACHE_H + +#endif /* _ASM_PPC_CACHE_H */ \ No newline at end of file diff --git a/xen/arch/ppc/include/asm/config.h b/xen/arch/ppc/include/asm/config.h index 7a2862ef7a..a3438de92b 100644 --- a/xen/arch/ppc/include/asm/config.h +++ b/xen/arch/ppc/include/asm/config.h @@ -52,6 +52,9 @@ /* size of minimum stack frame; C code can write into the caller's stack */ #define STACK_FRAME_OVERHEAD 32 +/* size of minimum stack frame that can hold an entire cpu_user_regs struct */ +#define STACK_SWITCH_FRAME_SIZE (UREGS_sizeof + STACK_FRAME_OVERHEAD) + #endif /* __PPC_CONFIG_H__ */ /* * Local variables: diff --git a/xen/arch/ppc/include/asm/early_printk.h b/xen/arch/ppc/include/asm/early_printk.h new file mode 100644 index 0000000000..a9566a1240 --- /dev/null +++ b/xen/arch/ppc/include/asm/early_printk.h @@ -0,0 +1,14 @@ +#ifndef __EARLY_PRINTK_H__ +#define __EARLY_PRINTK_H__ + +#include <xen/early_printk.h> + +#ifdef CONFIG_EARLY_PRINTK +void early_printk_init(bool is_of); +void early_printk(const char *str); +#else +static inline void early_printk_init(bool is_of) {} +static inline void early_printk(const char *s) {} +#endif + +#endif /* __EARLY_PRINTK_H__ */ \ No newline at end of file diff --git a/xen/arch/ppc/include/asm/processor.h b/xen/arch/ppc/include/asm/processor.h index 0ab7bfc9df..63409f003a 100644 --- a/xen/arch/ppc/include/asm/processor.h +++ b/xen/arch/ppc/include/asm/processor.h @@ -114,7 +114,42 @@ #define PVR_970MP 0x0044 #define PVR_BE 0x0070 -#ifdef __ASSEMBLY__ +#ifndef __ASSEMBLY__ + +#include <xen/types.h> + +/* User-accessible registers: nost of these need to be saved/restored + * for every nested Xen invocation. */ +struct cpu_user_regs +{ + uint64_t gprs[32]; + uint64_t lr; + uint64_t ctr; + uint64_t srr0; + uint64_t srr1; + uint64_t pc; + uint64_t msr; + uint64_t fpscr; /* XXX Is this necessary */ + uint64_t xer; + uint64_t hid4; /* debug only */ + uint64_t dar; /* debug only */ + uint32_t dsisr; /* debug only */ + uint32_t cr; + uint32_t __pad; /* good spot for another 32bit reg */ + uint32_t entry_vector; +}; + +static __inline__ void sync(void) +{ + __asm__ __volatile__("sync"); +} + +static __inline__ void isync(void) +{ + __asm__ __volatile__("isync"); +} + +#else #define LOADADDR(rn, name) \ lis rn, name##@highest; \ @@ -152,6 +187,22 @@ .long 0xa6037b7d; /* mtsrr1 r11 */ \ .long 0x2400004c /* rfid */ +/* Taken from Linux kernel source (arch/powerpc/boot/crt0.S) */ +.macro OP_REGS op, width, start, end, base, offset + .Lreg=\start + .rept (\end - \start + 1) + \op .Lreg,\offset+\width*.Lreg(\base) + .Lreg=.Lreg+1 + .endr +.endm + +#define SAVE_GPRS(start, end, base) OP_REGS std, 8, start, end, base, 0 +#define REST_GPRS(start, end, base) OP_REGS ld, 8, start, end, base, 0 +#define SAVE_GPR(n, base) SAVE_GPRS(n, n, base) +#define REST_GPR(n, base) REST_GPRS(n, n, base) +#define SAVE_NVGPRS(base) SAVE_GPRS(14, 31, base) +#define REST_NVGPRS(base) REST_GPRS(14, 31, base) + #define _GLOBAL(name) \ .section ".text"; \ .align 2; \ @@ -167,7 +218,6 @@ #define _ENTRY(name) name -#else /* __ASSEMBLY__ */ #endif /* __ASSEMBLY__ */ #endif diff --git a/xen/arch/ppc/include/asm/string.h b/xen/arch/ppc/include/asm/string.h new file mode 100644 index 0000000000..aed83b0d47 --- /dev/null +++ b/xen/arch/ppc/include/asm/string.h @@ -0,0 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _ASM_PPC_STRING_H +#define _ASM_PPC_STRING_H + +#endif /* _ASM_PPC_STRING_H */ \ No newline at end of file diff --git a/xen/arch/ppc/include/asm/types.h b/xen/arch/ppc/include/asm/types.h new file mode 100644 index 0000000000..44b5df49f2 --- /dev/null +++ b/xen/arch/ppc/include/asm/types.h @@ -0,0 +1,64 @@ +/* from xen/include/asm-x86/types.h */ + +#ifndef _PPC_TYPES_H +#define _PPC_TYPES_H + +#ifndef __ASSEMBLY__ +typedef unsigned short umode_t; + +/* + * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the + * header files exported to user space + */ + +typedef __signed__ char __s8; +typedef unsigned char __u8; + +typedef __signed__ short __s16; +typedef unsigned short __u16; + +typedef __signed__ int __s32; +typedef unsigned int __u32; + +#if defined(__GNUC__) && !defined(__STRICT_ANSI__) +#if defined(__ppc__) +typedef __signed__ long long __s64; +typedef unsigned long long __u64; + +#elif defined(__PPC64__) +typedef __signed__ long __s64; +typedef unsigned long __u64; +#endif +#endif + +typedef signed char s8; +typedef unsigned char u8; + +typedef signed short s16; +typedef unsigned short u16; + +typedef signed int s32; +typedef unsigned int u32; + +#if defined(__ppc__) +typedef signed long long s64; +typedef unsigned long long u64; +typedef unsigned int size_t; +#elif defined(__PPC64__) +typedef signed long s64; +typedef unsigned long u64; +typedef unsigned long size_t; +#endif + +typedef unsigned long paddr_t; +#define PRIpaddr "08lx" + +/* DMA addresses come in generic and 64-bit flavours. */ + +typedef unsigned long dma_addr_t; +typedef u64 dma64_addr_t; + +typedef unsigned short xmem_bufctl_t; + +#endif /* __ASSEMBLY__ */ +#endif diff --git a/xen/arch/ppc/ppc64/asm-offsets.c b/xen/arch/ppc/ppc64/asm-offsets.c index e69de29bb2..a6de2b2768 100644 --- a/xen/arch/ppc/ppc64/asm-offsets.c +++ b/xen/arch/ppc/ppc64/asm-offsets.c @@ -0,0 +1,55 @@ +/* + * Generate definitions needed by assembly language modules. + * This code generates raw asm output which is post-processed + * to extract and format the required data. + */ + +#include <asm/processor.h> + +#define DEFINE(_sym, _val) \ + asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \ + : : "i" (_val) ) +#define BLANK() \ + asm volatile ( "\n.ascii\"==><==\"" : : ) +#define OFFSET(_sym, _str, _mem) \ + DEFINE(_sym, offsetof(_str, _mem)); + +/* base-2 logarithm */ +#define __L2(_x) (((_x) & 0x00000002) ? 1 : 0) +#define __L4(_x) (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x)) +#define __L8(_x) (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x)) +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x)) +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x)) + +void __dummy__(void) +{ + DEFINE(GPR_WIDTH, sizeof(unsigned long)); + DEFINE(FPR_WIDTH, sizeof(double)); + + OFFSET(UREGS_gprs, struct cpu_user_regs, gprs); + OFFSET(UREGS_r0, struct cpu_user_regs, gprs[0]); + OFFSET(UREGS_r1, struct cpu_user_regs, gprs[1]); + OFFSET(UREGS_r13, struct cpu_user_regs, gprs[13]); + OFFSET(UREGS_srr0, struct cpu_user_regs, srr0); + OFFSET(UREGS_srr1, struct cpu_user_regs, srr1); + OFFSET(UREGS_pc, struct cpu_user_regs, pc); + OFFSET(UREGS_msr, struct cpu_user_regs, msr); + OFFSET(UREGS_lr, struct cpu_user_regs, lr); + OFFSET(UREGS_ctr, struct cpu_user_regs, ctr); + OFFSET(UREGS_xer, struct cpu_user_regs, xer); + OFFSET(UREGS_hid4, struct cpu_user_regs, hid4); + OFFSET(UREGS_dar, struct cpu_user_regs, dar); + OFFSET(UREGS_dsisr, struct cpu_user_regs, dsisr); + OFFSET(UREGS_cr, struct cpu_user_regs, cr); + OFFSET(UREGS_fpscr, struct cpu_user_regs, fpscr); + DEFINE(UREGS_sizeof, sizeof(struct cpu_user_regs)); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/ppc/ppc64/head.S b/xen/arch/ppc/ppc64/head.S index d91b0972ae..d5ca1c08ad 100644 --- a/xen/arch/ppc/ppc64/head.S +++ b/xen/arch/ppc/ppc64/head.S @@ -65,3 +65,62 @@ cpu0_boot_stack_bottom: .space STACK_SIZE cpu0_boot_stack: .space STACK_FRAME_OVERHEAD + +/* Adapted from Linux kernel source (arch/powerpc/boot/crt0.S) */ +_GLOBAL(enter_prom) + mflr r0 + std r0,16(r1) + stdu r1,-STACK_SWITCH_FRAME_SIZE(r1) /* Save SP and create stack space */ + + /* Because PROM is running in 32b mode, it clobbers the high order half + * of all registers that it saves. We therefore save those registers + * PROM might touch to the stack. (r0, r3-r13 are caller saved) + */ + SAVE_GPR(2, r1) + SAVE_GPR(13, r1) + SAVE_NVGPRS(r1) + mfcr r10 + mfmsr r11 + std r10,UREGS_cr(r1) + std r11,UREGS_msr(r1) + + /* Put PROM address in SRR0 */ + mtsrr0 r4 + + /* Setup our trampoline return addr in LR */ + bcl 20,31,$+4 +0: mflr r4 + addi r4,r4,(1f - 0b) + mtlr r4 + + /* Prepare a 32-bit mode big endian MSR + */ + SET_REG_TO_CONST(r12, MSR_SF | MSR_LE) + andc r11,r11,r12 + mtsrr1 r11 + rfid + +1: /* Return from OF */ + FIXUP_ENDIAN + + /* Just make sure that r1 top 32 bits didn't get + * corrupt by OF + */ + rldicl r1,r1,0,32 + + /* Restore the MSR (back to 64 bits) */ + ld r0,UREGS_msr(r1) + mtmsrd r0 + isync + + /* Restore other registers */ + REST_GPR(2, r1) + REST_GPR(13, r1) + REST_NVGPRS(r1) + ld r4,UREGS_cr(r1) + mtcr r4 + + addi r1,r1,STACK_SWITCH_FRAME_SIZE + ld r0,16(r1) + mtlr r0 + blr diff --git a/xen/arch/ppc/setup.c b/xen/arch/ppc/setup.c index c9509fb6a6..fb12d4df34 100644 --- a/xen/arch/ppc/setup.c +++ b/xen/arch/ppc/setup.c @@ -1,9 +1,27 @@ /* SPDX-License-Identifier: GPL-2.0-or-later */ #include <xen/compile.h> #include <xen/init.h> +#include <asm/boot.h> +#include <asm/early_printk.h> -void __init noreturn start_xen(void) +void __init noreturn start_xen(unsigned long r3, unsigned long r4, + unsigned long r5, unsigned long r6, + unsigned long r7) { + if ( r5 ) + { + /* OF boot protocol */ + boot_of_init(r5); + early_printk_init(true); + } + else + { + /* kexec boot: Unimplemented */ + __builtin_trap(); + } + + early_printk("Hello, ppc64le!\n"); + for ( ;; ) { // Set current hardware thread to very low priority
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 <shawnanastasio@raptorengineering.com> --- 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