qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 30/53] spapr: Render full FDT on ibm,client-architecture-suppo


From: Laurent Vivier
Subject: Re: [PULL 30/53] spapr: Render full FDT on ibm,client-architecture-support
Date: Tue, 3 Dec 2019 17:11:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 04/10/2019 11:37, David Gibson wrote:
> From: Alexey Kardashevskiy <address@hidden>
> 
> The ibm,client-architecture-support call is a way for the guest to
> negotiate capabilities with a hypervisor. It is implemented as:
> - the guest calls SLOF via client interface;
> - SLOF calls QEMU (H_CAS hypercall) with an options vector from the guest;
> - QEMU returns a device tree diff (which uses FDT format with
> an additional header before it);
> - SLOF walks through the partial diff tree and updates its internal tree
> with the values from the diff.
> 
> This changes QEMU to simply re-render the entire tree and send it as
> an update. SLOF can handle this already mostly, [1] is needed before this
> can be applied. This stores the resulting tree in the spapr machine to have
> the latest valid FDT copy possible (this should not matter much as
> H_UPDATE_DT happens right after that but nevertheless).
> 
> The benefit is reduced code size as there is no need for another set of
> DT rendering helpers such as spapr_fixup_cpu_dt().
> 
> The downside is that the updates are bigger now (as they include all
> nodes and properties) but the difference on a '-smp 256,threads=1' system
> before/after is 2.35s vs. 2.5s.
> 
> [1] https://patchwork.ozlabs.org/patch/1152915/
> 
> Signed-off-by: Alexey Kardashevskiy <address@hidden>
> Signed-off-by: David Gibson <address@hidden>
> ---
>  hw/ppc/spapr.c | 88 ++++++--------------------------------------------
>  1 file changed, 9 insertions(+), 79 deletions(-)

[Resend the comment I sent to another patch by mistake]

This patch breaks pseries boot when we use a pci-bridge (since v4.2.0-rc0):

...
    -device pci-bridge,id=pci_bridge1,bus=pci.0,addr=0x3,chassis_nr=1 \
    -device virtio-scsi-pci,bus=pci_bridge1 \
...

OF stdout device is: /vdevice/vty@71000000
Preparing to boot Linux version 5.4.0-rc3+ (lvivier@localhost) (gcc
version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)) #2 SMP Wed Nov 13
09:08:20 EST 2019
Detected machine type: 0000000000000101
command line: BOOT_IMAGE=/vmlinuz-5.4.0-rc3+ root=/dev/mapper/rhel-root
ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap
Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
Calling ibm,client-architecture-support...

( 300 ) Data Storage Exception [ 1dc5f230 ]


    R0 .. R7           R8 .. R15         R16 .. R23         R24 .. R31
8000000000001000   000000001e477010   0000000000000000   000000001dc17500
000000001e67afe0   0000000020000004   0000000000000000   000000001dc1bf88
000000001dc21800   000000001dc5f248   000000001e477010   0000000000000003
000000001dc61000   000000001e78dc2d   000000001dc1c158   000000000000f001
0000000000000000   a000000000000001   0000000000008000   000000001e67b060
000000001dc5f230   0000000000000000   000000000000f003   ffffffffffffffff
000000001e745860   0000000000000000   0000000000000006   000000001dbf48f8
000000001dc5f248   0000000000000000   000000001e67b050   000000001dc1c350

    CR / XER           LR / CTR          SRR0 / SRR1        DAR / DSISR
        80000808   000000001dbf34d4   000000001dbf4194   0000000020000004
0000000020000000   000000001dbf48f8   8000000000001000           40000000


4a >

Thanks,
Laurent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]