Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 28.03.2011, at 21:52, Aurelien Jarno wrote: > On Mon, Mar 28, 2011 at 01:50:40PM -0500, Anthony Liguori wrote: >> On 03/28/2011 01:24 PM, Aurelien Jarno wrote: >>> On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: On 03/28/2011 12:42 PM, Blue Swirl wrote: > On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori > wrote: >> On 03/28/2011 04:03 AM, Alexander Graf wrote: Um, ok. Do I need to do anything about this? >>> I'm also not sure this is too important. >> It's GPL compliance so yes, it's very important. >> >>> Most of our firmware blobs come from svn repos which can't be >>> submoduled. >> The only firmware blob we're not currently including as a git submodule >> is >> OpenBIOS. > No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. Alex, what's the source of zipl? >> I believe the main reason is that different boards use different >> commits so a single submodule is a bit challenge. We probably ought to >> figure something out here though for the next release. >> >> Can anyone comment a bit more about OpenBIOS? >> >> BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's >> needed is a patch that does a git submodule add with the appropriate >> commit. > That would be an improvement. Though building various OpenBIOS images > depends on appropriate cross compilers. The situation is actually same > as with SeaBIOS. Can you do a git submodule add then? >>> And as long as we don't have a consistent policy about it, we can just >>> as >>> well stick with the README file. >> We do have a consistent policy :-) We're just not enforcing it as >> tightly >> as we should. >> >> Any binary we ship in the release tgz's should also have corresponding >> source in a submodule. > What about OpenHack'Ware (and PReP machine), should it be deleted? Yes. I don't think the source for that is available, correct? I don't think we have any other choice. >>> Debian still holds a copy of the code. >> >> I had thought that the actual binary was from Jocelyn and contains >> patches that noone else has. In fact, the last commit is: >> >> commit 55aa45ddde3283cdd781326d001f7456bf02f684 >> Author: j_mayer >> Date: Mon Oct 1 06:44:33 2007 + >> >>Quickly hack PowerPC BIOS able to boot on CDROM again. >> >>> People have worked recently to >>> restore prep support that has been broken by various patches, it would >>> be a pitty to remove it without before asking them. >> >> I'd be very happy to just submodule whatever sources Debian is using. >> > > I am not sure that it corresponds to the latest code, so it might have > some issues, but at least it is something that is usable. The code is a > vailable from: > > http://ftp.debian.org/debian/pool/main/o/openhackware/ > > Note that the .diff.gz contains a few patches needed to fix build > issues. I really wouldn't want to see PREP getting removed, now that we have a maintainer for it again :). It might be a good idea to recompile the binary we ship from that source though? Alex
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 28.03.2011, at 20:02, Anthony Liguori wrote: > On 03/28/2011 12:42 PM, Blue Swirl wrote: >> On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori >> wrote: >>> On 03/28/2011 04:03 AM, Alexander Graf wrote: > Um, ok. Do I need to do anything about this? I'm also not sure this is too important. >>> It's GPL compliance so yes, it's very important. >>> Most of our firmware blobs come from svn repos which can't be submoduled. >>> The only firmware blob we're not currently including as a git submodule is >>> OpenBIOS. >> No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > > Alex, what's the source of zipl? See the README file :P. git://repo.or.cz/s390-tools.git virtio-zipl Alex
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On Mon, Mar 28, 2011 at 08:13:04AM -0500, Anthony Liguori wrote: > On 03/27/2011 08:19 PM, David Gibson wrote: > >>We should pull in SLOF via a git submodule. That ensures we ship > >>the source code along with the binary. > >Um, ok. Do I need to do anything about this? > > We should introduce SLOF as one patch that adds the git submodule > and the binary. > > The best way to do this is for me to pull as binary diffs on the > list kind of suck. > > But before we do the git submodule, I need to mirror SLOF on > qemu.org such that everything can be fetched from one place. Ping > me later today when you get online and I'll explain how to do the > git submodule part. Sorry, I slept badly last night and wasn't up until after you'd gone. Can you email the instructions instead. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On Mon, Mar 28, 2011 at 01:50:40PM -0500, Anthony Liguori wrote: > On 03/28/2011 01:24 PM, Aurelien Jarno wrote: > >On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: > >>On 03/28/2011 12:42 PM, Blue Swirl wrote: > >>>On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori > >>>wrote: > On 03/28/2011 04:03 AM, Alexander Graf wrote: > >>Um, ok. Do I need to do anything about this? > >I'm also not sure this is too important. > It's GPL compliance so yes, it's very important. > > > Most of our firmware blobs come from svn repos which can't be > > submoduled. > The only firmware blob we're not currently including as a git submodule is > OpenBIOS. > >>>No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > >>Alex, what's the source of zipl? > >> > I believe the main reason is that different boards use different > commits so a single submodule is a bit challenge. We probably ought to > figure something out here though for the next release. > > Can anyone comment a bit more about OpenBIOS? > > BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's > needed is a patch that does a git submodule add with the appropriate > commit. > >>>That would be an improvement. Though building various OpenBIOS images > >>>depends on appropriate cross compilers. The situation is actually same > >>>as with SeaBIOS. > >>Can you do a git submodule add then? > >> > > And as long as we don't have a consistent policy about it, we can just > > as > >well stick with the README file. > We do have a consistent policy :-) We're just not enforcing it as tightly > as we should. > > Any binary we ship in the release tgz's should also have corresponding > source in a submodule. > >>>What about OpenHack'Ware (and PReP machine), should it be deleted? > >>Yes. I don't think the source for that is available, correct? I > >>don't think we have any other choice. > >> > >Debian still holds a copy of the code. > > I had thought that the actual binary was from Jocelyn and contains > patches that noone else has. In fact, the last commit is: > > commit 55aa45ddde3283cdd781326d001f7456bf02f684 > Author: j_mayer > Date: Mon Oct 1 06:44:33 2007 + > > Quickly hack PowerPC BIOS able to boot on CDROM again. > > > People have worked recently to > >restore prep support that has been broken by various patches, it would > >be a pitty to remove it without before asking them. > > I'd be very happy to just submodule whatever sources Debian is using. > I am not sure that it corresponds to the latest code, so it might have some issues, but at least it is something that is usable. The code is a vailable from: http://ftp.debian.org/debian/pool/main/o/openhackware/ Note that the .diff.gz contains a few patches needed to fix build issues. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/28/2011 01:24 PM, Aurelien Jarno wrote: On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: On 03/28/2011 12:42 PM, Blue Swirl wrote: On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori wrote: On 03/28/2011 04:03 AM, Alexander Graf wrote: Um, ok. Do I need to do anything about this? I'm also not sure this is too important. It's GPL compliance so yes, it's very important. Most of our firmware blobs come from svn repos which can't be submoduled. The only firmware blob we're not currently including as a git submodule is OpenBIOS. No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. Alex, what's the source of zipl? I believe the main reason is that different boards use different commits so a single submodule is a bit challenge. We probably ought to figure something out here though for the next release. Can anyone comment a bit more about OpenBIOS? BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's needed is a patch that does a git submodule add with the appropriate commit. That would be an improvement. Though building various OpenBIOS images depends on appropriate cross compilers. The situation is actually same as with SeaBIOS. Can you do a git submodule add then? And as long as we don't have a consistent policy about it, we can just as well stick with the README file. We do have a consistent policy :-) We're just not enforcing it as tightly as we should. Any binary we ship in the release tgz's should also have corresponding source in a submodule. What about OpenHack'Ware (and PReP machine), should it be deleted? Yes. I don't think the source for that is available, correct? I don't think we have any other choice. Debian still holds a copy of the code. I had thought that the actual binary was from Jocelyn and contains patches that noone else has. In fact, the last commit is: commit 55aa45ddde3283cdd781326d001f7456bf02f684 Author: j_mayer Date: Mon Oct 1 06:44:33 2007 + Quickly hack PowerPC BIOS able to boot on CDROM again. People have worked recently to restore prep support that has been broken by various patches, it would be a pitty to remove it without before asking them. I'd be very happy to just submodule whatever sources Debian is using. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote: > On 03/28/2011 12:42 PM, Blue Swirl wrote: > >On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori > >wrote: > >>On 03/28/2011 04:03 AM, Alexander Graf wrote: > Um, ok. Do I need to do anything about this? > >>>I'm also not sure this is too important. > >>It's GPL compliance so yes, it's very important. > >> > >>> Most of our firmware blobs come from svn repos which can't be submoduled. > >>The only firmware blob we're not currently including as a git submodule is > >>OpenBIOS. > >No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > > Alex, what's the source of zipl? > > >> I believe the main reason is that different boards use different > >>commits so a single submodule is a bit challenge. We probably ought to > >>figure something out here though for the next release. > >> > >>Can anyone comment a bit more about OpenBIOS? > >> > >>BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's > >>needed is a patch that does a git submodule add with the appropriate commit. > >That would be an improvement. Though building various OpenBIOS images > >depends on appropriate cross compilers. The situation is actually same > >as with SeaBIOS. > > Can you do a git submodule add then? > > >>> And as long as we don't have a consistent policy about it, we can just as > >>>well stick with the README file. > >>We do have a consistent policy :-) We're just not enforcing it as tightly > >>as we should. > >> > >>Any binary we ship in the release tgz's should also have corresponding > >>source in a submodule. > >What about OpenHack'Ware (and PReP machine), should it be deleted? > > Yes. I don't think the source for that is available, correct? I > don't think we have any other choice. > Debian still holds a copy of the code. People have worked recently to restore prep support that has been broken by various patches, it would be a pitty to remove it without before asking them. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/28/2011 12:42 PM, Blue Swirl wrote: On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori wrote: On 03/28/2011 04:03 AM, Alexander Graf wrote: Um, ok. Do I need to do anything about this? I'm also not sure this is too important. It's GPL compliance so yes, it's very important. Most of our firmware blobs come from svn repos which can't be submoduled. The only firmware blob we're not currently including as a git submodule is OpenBIOS. No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. Alex, what's the source of zipl? I believe the main reason is that different boards use different commits so a single submodule is a bit challenge. We probably ought to figure something out here though for the next release. Can anyone comment a bit more about OpenBIOS? BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's needed is a patch that does a git submodule add with the appropriate commit. That would be an improvement. Though building various OpenBIOS images depends on appropriate cross compilers. The situation is actually same as with SeaBIOS. Can you do a git submodule add then? And as long as we don't have a consistent policy about it, we can just as well stick with the README file. We do have a consistent policy :-) We're just not enforcing it as tightly as we should. Any binary we ship in the release tgz's should also have corresponding source in a submodule. What about OpenHack'Ware (and PReP machine), should it be deleted? Yes. I don't think the source for that is available, correct? I don't think we have any other choice. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori wrote: > On 03/28/2011 04:03 AM, Alexander Graf wrote: >> >>> Um, ok. Do I need to do anything about this? >> >> I'm also not sure this is too important. > > It's GPL compliance so yes, it's very important. > >> Most of our firmware blobs come from svn repos which can't be submoduled. > > The only firmware blob we're not currently including as a git submodule is > OpenBIOS. No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom. > I believe the main reason is that different boards use different > commits so a single submodule is a bit challenge. We probably ought to > figure something out here though for the next release. > > Can anyone comment a bit more about OpenBIOS? > > BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's > needed is a patch that does a git submodule add with the appropriate commit. That would be an improvement. Though building various OpenBIOS images depends on appropriate cross compilers. The situation is actually same as with SeaBIOS. >> And as long as we don't have a consistent policy about it, we can just as >> well stick with the README file. > > We do have a consistent policy :-) We're just not enforcing it as tightly > as we should. > > Any binary we ship in the release tgz's should also have corresponding > source in a submodule. What about OpenHack'Ware (and PReP machine), should it be deleted?
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On Mon, Mar 28, 2011 at 08:16:51AM -0500, Anthony Liguori wrote: > On 03/28/2011 04:03 AM, Alexander Graf wrote: > > > >>Um, ok. Do I need to do anything about this? > >I'm also not sure this is too important. > > It's GPL compliance so yes, it's very important. > > > Most of our firmware blobs come from svn repos which can't be submoduled. > > The only firmware blob we're not currently including as a git > submodule is OpenBIOS. I believe the main reason is that different > boards use different commits so a single submodule is a bit > challenge. We probably ought to figure something out here though > for the next release. Um.. where? I don't see these sources. > Can anyone comment a bit more about OpenBIOS? > > BTW, OpenBIOS is already actively mirrored on git.qemu.org so all > that's needed is a patch that does a git submodule add with the > appropriate commit. > > > And as long as we don't have a consistent policy about it, we can > > just as well stick with the README file. > > We do have a consistent policy :-) We're just not enforcing it as > tightly as we should. > > Any binary we ship in the release tgz's should also have > corresponding source in a submodule. So, again, what do I need to do? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/28/2011 08:08 AM, Alexander Graf wrote: It depends on how often the code changes. If it changes regularly and qemu is expected to take in newer versions, then we need to record which slof version comes with which qemu version. Submodules do just that. A commit id / tag in the README document it pretty well, no? Also, a README file is human readable. Submodules don't really buy anyone anything. When I do a release, I do the equivalent of: git submodule update --init rm -rf roms/*/.git rm -rf .git Having the information is submodules makes this process automated and repeatable. The main motivation is that we need to ship source for any binary we include in our tarball. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/28/2011 04:03 AM, Alexander Graf wrote: Um, ok. Do I need to do anything about this? I'm also not sure this is too important. It's GPL compliance so yes, it's very important. Most of our firmware blobs come from svn repos which can't be submoduled. The only firmware blob we're not currently including as a git submodule is OpenBIOS. I believe the main reason is that different boards use different commits so a single submodule is a bit challenge. We probably ought to figure something out here though for the next release. Can anyone comment a bit more about OpenBIOS? BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's needed is a patch that does a git submodule add with the appropriate commit. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. We do have a consistent policy :-) We're just not enforcing it as tightly as we should. Any binary we ship in the release tgz's should also have corresponding source in a submodule. Regards, Anthony Liguori Alex
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/27/2011 08:19 PM, David Gibson wrote: We should pull in SLOF via a git submodule. That ensures we ship the source code along with the binary. Um, ok. Do I need to do anything about this? We should introduce SLOF as one patch that adds the git submodule and the binary. The best way to do this is for me to pull as binary diffs on the list kind of suck. But before we do the git submodule, I need to mirror SLOF on qemu.org such that everything can be fetched from one place. Ping me later today when you get online and I'll explain how to do the git submodule part. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 28.03.2011, at 15:02, Avi Kivity wrote: > On 03/28/2011 02:53 PM, Alexander Graf wrote: >> On 28.03.2011, at 14:49, Avi Kivity wrote: >> >> > On 03/28/2011 11:03 AM, Alexander Graf wrote: >> >> I'm also not sure this is too important. Most of our firmware blobs come >> >> from svn repos which can't be submoduled. And as long as we don't have a >> >> consistent policy about it, we can just as well stick with the README >> >> file. >> >> >> > >> > We can have a git mirror of the subversion repository hosted on >> > git.qemu.org, and submodule that. >> >> *shrug* I'm fairly indifferent on that side. But whatever we do, it's out of >> scope of this patch set :). I personally don't mind the listing in the >> README file. > > It depends on how often the code changes. If it changes regularly and qemu > is expected to take in newer versions, then we need to record which slof > version comes with which qemu version. Submodules do just that. A commit id / tag in the README document it pretty well, no? Also, a README file is human readable. Submodules don't really buy anyone anything. Normal users don't care about the source - they use the bundled binaries. Distributers will have to bundle the source code anyways, because the build process is always offline. You can't always build everything either, as there are targets in qemu that people don't have cross-compilers for. It feels like the submodule idea is more of a feature that's "cool to play with" rather than of benefit for anyone. Alex
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/28/2011 02:53 PM, Alexander Graf wrote: On 28.03.2011, at 14:49, Avi Kivity wrote: > On 03/28/2011 11:03 AM, Alexander Graf wrote: >> I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. >> > > We can have a git mirror of the subversion repository hosted on git.qemu.org, and submodule that. *shrug* I'm fairly indifferent on that side. But whatever we do, it's out of scope of this patch set :). I personally don't mind the listing in the README file. It depends on how often the code changes. If it changes regularly and qemu is expected to take in newer versions, then we need to record which slof version comes with which qemu version. Submodules do just that. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 28.03.2011, at 14:49, Avi Kivity wrote: > On 03/28/2011 11:03 AM, Alexander Graf wrote: >> I'm also not sure this is too important. Most of our firmware blobs come >> from svn repos which can't be submoduled. And as long as we don't have a >> consistent policy about it, we can just as well stick with the README file. >> > > We can have a git mirror of the subversion repository hosted on git.qemu.org, > and submodule that. *shrug* I'm fairly indifferent on that side. But whatever we do, it's out of scope of this patch set :). I personally don't mind the listing in the README file. Alex
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/28/2011 11:03 AM, Alexander Graf wrote: I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. We can have a git mirror of the subversion repository hosted on git.qemu.org, and submodule that. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 28.03.2011, at 03:19, David Gibson wrote: > On Fri, Mar 25, 2011 at 01:29:17PM -0500, Anthony Liguori wrote: >> On 03/24/2011 10:21 PM, David Gibson wrote: >>> Currently, the emulated pSeries machine requires the use of the >>> -kernel parameter in order to explicitly load a guest kernel. This >>> means booting from the virtual disk, cdrom or network is not possible. >>> >>> This patch addresses this limitation by inserting a within-partition >>> firmware image (derived from the "SLOF" free Open Firmware project). >>> If -kernel is not specified, qemu will now load the SLOF image, which >>> has access to the qemu boot device list through the device tree, and >>> can boot from any of the usual virtual devices. >>> >>> In order to support the new firmware, an extension to the emulated >>> machine/hypervisor is necessary. Unlike Linux, which expects >>> multi-CPU entry to be handled kexec() style, the SLOF firmware expects >>> only one CPU to be active at entry, and to use a hypervisor RTAS >>> method to enable the other CPUs one by one. >>> >>> This patch also implements this 'start-cpu' method, so that SLOF can >>> start the secondary CPUs and marshal them into the kexec() holding >>> pattern ready for entry into the guest OS. Linux should, and in the >>> future might directly use the start-cpu method to enable initially >>> disabled CPUs, but for now it does require kexec() entry. >>> >>> Signed-off-by: Benjamin Herrenschmidt >>> Signed-off-by: Paul Mackerras >>> Signed-off-by: David Gibson >> >> We should pull in SLOF via a git submodule. That ensures we ship >> the source code along with the binary. > > Um, ok. Do I need to do anything about this? I'm also not sure this is too important. Most of our firmware blobs come from svn repos which can't be submoduled. And as long as we don't have a consistent policy about it, we can just as well stick with the README file. Alex
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On Fri, Mar 25, 2011 at 01:29:17PM -0500, Anthony Liguori wrote: > On 03/24/2011 10:21 PM, David Gibson wrote: > >Currently, the emulated pSeries machine requires the use of the > >-kernel parameter in order to explicitly load a guest kernel. This > >means booting from the virtual disk, cdrom or network is not possible. > > > >This patch addresses this limitation by inserting a within-partition > >firmware image (derived from the "SLOF" free Open Firmware project). > >If -kernel is not specified, qemu will now load the SLOF image, which > >has access to the qemu boot device list through the device tree, and > >can boot from any of the usual virtual devices. > > > >In order to support the new firmware, an extension to the emulated > >machine/hypervisor is necessary. Unlike Linux, which expects > >multi-CPU entry to be handled kexec() style, the SLOF firmware expects > >only one CPU to be active at entry, and to use a hypervisor RTAS > >method to enable the other CPUs one by one. > > > >This patch also implements this 'start-cpu' method, so that SLOF can > >start the secondary CPUs and marshal them into the kexec() holding > >pattern ready for entry into the guest OS. Linux should, and in the > >future might directly use the start-cpu method to enable initially > >disabled CPUs, but for now it does require kexec() entry. > > > >Signed-off-by: Benjamin Herrenschmidt > >Signed-off-by: Paul Mackerras > >Signed-off-by: David Gibson > > We should pull in SLOF via a git submodule. That ensures we ship > the source code along with the binary. Um, ok. Do I need to do anything about this? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
On 03/24/2011 10:21 PM, David Gibson wrote: Currently, the emulated pSeries machine requires the use of the -kernel parameter in order to explicitly load a guest kernel. This means booting from the virtual disk, cdrom or network is not possible. This patch addresses this limitation by inserting a within-partition firmware image (derived from the "SLOF" free Open Firmware project). If -kernel is not specified, qemu will now load the SLOF image, which has access to the qemu boot device list through the device tree, and can boot from any of the usual virtual devices. In order to support the new firmware, an extension to the emulated machine/hypervisor is necessary. Unlike Linux, which expects multi-CPU entry to be handled kexec() style, the SLOF firmware expects only one CPU to be active at entry, and to use a hypervisor RTAS method to enable the other CPUs one by one. This patch also implements this 'start-cpu' method, so that SLOF can start the secondary CPUs and marshal them into the kexec() holding pattern ready for entry into the guest OS. Linux should, and in the future might directly use the start-cpu method to enable initially disabled CPUs, but for now it does require kexec() entry. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Mackerras Signed-off-by: David Gibson We should pull in SLOF via a git submodule. That ensures we ship the source code along with the binary. Regards, Anthony Liguori
