Re: [Qemu-devel] [Qemu-ppc] [GIT PULL for qemu-pseries] spapr: Render full FDT on ibm, client-architecture-support

[Greg Kurz]

On Wed, 28 Aug 2019 15:57:40 +1000
David Gibson <address@hidden> wrote:

> On Wed, Aug 28, 2019 at 01:27:35PM +1000, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 28/08/2019 12:12, David Gibson wrote:
> > > On Wed, Aug 28, 2019 at 10:46:34AM +1000, David Gibson wrote:
> > > > On Tue, Aug 27, 2019 at 04:56:50PM +1000, Alexey Kardashevskiy wrote:
> > > > > The following changes since commit 
> > > > > d6bb8b27204eaa58f1da948b65454e3a598ab2a4:
> > > > > 
> > > > >    pseries: Update SLOF firmware image (2019-08-27 16:47:04 +1000)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >    address@hidden:aik/qemu.git tags/qemu-slof-20190827
> > > > > 
> > > > > for you to fetch changes up to 
> > > > > da9960a5aaa25d27c9798c3d94c7b4c2d8af31ac:
> > > > > 
> > > > >    spapr: Render full FDT on ibm,client-architecture-support 
> > > > > (2019-08-27 16:47:46 +1000)
> > > > > 
> > > > > ----------------------------------------------------------------
> > > > > Alexey Kardashevskiy (1):
> > > > >        spapr: Render full FDT on ibm,client-architecture-support
> > > > > 
> > > > >   hw/ppc/spapr.c | 90 
> > > > > +++++++---------------------------------------------------
> > > > >   1 file changed, 10 insertions(+), 80 deletions(-)
> > > > > 
> > > > > 
> > > > > *** Note: this is not for master, this is for pseries
> > > > > 
> > > > 
> > > > Merged, thanks.
> > > 
> > > Urgh.  And the qemu change is now un-merged.  Alas, as soon as we had
> > > a CAS reboot for XIVE the guest didn't boot on the second attempt.
> > > Haven't had a chance to investigate yet.
> > 
> > QEMU command line, guest kernel version? I'd give it a try.
> 
> RHEL8.1 in guest and host, booting via GRUB into a XIVE capable
> kernel.
> 
> I've now been able to investigate, dumping the dtb at H_UPDATE_DT
> time.

FWIW I sent a patch to do just that some times ago:

https://patchwork.ozlabs.org/patch/1095705/

>  Comparing before and after the fully-render-dt change, I get:
> 
> @@ -24,13 +24,13 @@
>         };
>  
>         chosen {
> -               bootargs = "BOOT_IMAGE=/vmlinuz-4.18.0-137.el8.ppc64le 
> root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root 
> rd.lvm.lv=rhel/swap";
> +               bootargs = [00];
>                 bootpath = "/pci@800000020000000/scsi@0";
>                 cpu = <0xe45ee80>;
>                 ibm,arch-vec-5-platform-support = <0x17801880 0x19001a40>;
>                 ibm,architecture-vec-5 = [19 00 20 00 00 80 05 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00 80 40 40 00 40];
> -               linux,initrd-end = <0x00 0x588ed7d>;
> -               linux,initrd-start = <0x00 0x3c00000>;
> +               linux,initrd-end = <0x00>;
> +               linux,initrd-start = <0x00>;
>                 linux,pci-probe-only = <0x00>;
>                 linux,stdout-package = <0xe733a70>;
>                 linux,stdout-path = "/vdevice/vty@71000001";
> @@ -252,7 +252,7 @@
>                 used-by-rtas;
>  
>                 ethernet@1 {
> -                       assigned-addresses = <0x82000830 0x00 0x80040000 0x00 
> 0x40000 0x81000810 0x00 0x100 0x00 0x20 0x82000814 0x00 0x80010000 0x00 
> 0x1000 0xc3000820 0x2100 0x10000 0x00 0x4000>;
> +                       assigned-addresses;
>                         cache-line-size = <0x00>;
>                         class-code = <0x20000>;
>                         device-id = <0x1000>;
> @@ -274,7 +274,7 @@
>                 };
>  
>                 scsi@0 {
> -                       assigned-addresses = <0x81000010 0x00 0x80 0x00 0x80 
> 0x82000014 0x00 0x80000000 0x00 0x1000 0xc3000020 0x2100 0x00 0x00 0x4000>;
> +                       assigned-addresses;
>                         cache-line-size = <0x00>;
>                         class-code = <0x10000>;
>                         device-id = <0x1001>;
> 
> So basically the bootargs, initrd params and assigned-addresses have
> been lost.
> 
> For bootargs and initrd, I think what's happening is that because qemu
> isn't setting those (with no -kernel parameter) SLOF is creating them,
> but they're now being overwritten by qemu's post-CAS DT.
> 
> I'm not sure what's going on with assigned-addresses.
>

pgpFx4nCNe5sI.pgp
Description: OpenPGP digital signature