Re: [Qemu-devel] [PATCH qemu v3] ppc/spapr: Receive and store device tree blob from SLOF

[Greg Kurz]

On Tue, 18 Dec 2018 18:54:33 +1100
Alexey Kardashevskiy <address@hidden> wrote:

> On 18/12/2018 15:30, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 18/12/2018 14:49, David Gibson wrote:  
> >> On Tue, Dec 18, 2018 at 02:04:54PM +1100, Alexey Kardashevskiy wrote:  
> >>>
> >>>
> >>> On 18/12/2018 13:09, David Gibson wrote:  
> >>>> On Mon, Dec 17, 2018 at 05:21:33PM +1100, David Gibson wrote:  
> >>>>> On Fri, Dec 14, 2018 at 12:55:20PM +1100, Alexey Kardashevskiy wrote:  
> >>>>>> SLOF receives a device tree and updates it with various properties
> >>>>>> before switching to the guest kernel and QEMU is not aware of any 
> >>>>>> changes
> >>>>>> made by SLOF. Since there is no real RTAS (QEMU implements it), it 
> >>>>>> makes
> >>>>>> sense to pass the SLOF final device tree to QEMU to let it implement
> >>>>>> RTAS related tasks better, such as PCI host bus adapter hotplug.
> >>>>>>
> >>>>>> Specifially, now QEMU can find out the actual XICS phandle (for PHB
> >>>>>> hotplug) and the RTAS linux,rtas-entry/base properties (for firmware
> >>>>>> assisted NMI - FWNMI).
> >>>>>>
> >>>>>> This stores the initial DT blob in the sPAPR machine and replaces it
> >>>>>> in the KVMPPC_H_UPDATE_DT (new private hypercall) handler.
> >>>>>>
> >>>>>> This adds an @update_dt_enabled machine property to allow backward
> >>>>>> migration.
> >>>>>>
> >>>>>> SLOF already has a hypercall since
> >>>>>> https://github.com/aik/SLOF/commit/e6fc84652c9c0073f9183
> >>>>>>
> >>>>>> This makes use of the new fdt_check_full() helper. In order to allow
> >>>>>> the configure script to pick the correct DTC version, this adjusts
> >>>>>> the DTC presense test.
> >>>>>>
> >>>>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>  
> >>>>>
> >>>>> Applied, thanks.  
> >>>>
> >>>> And now, unapplied.
> >>>>
> >>>> I don't know quite how, but somehow this patch is causing aarch64
> >>>> tests to SEGV.  
> >>>
> >>>
> >>> /home/aik/p/qemu/configure --target-list=aarch64-softmmu
> >>> --source-path=/home/aik/p/qemu/ --disable-git-update --with-git=false
> >>>    --enable-trace-backend=log
> >>>
> >>> and
> >>>
> >>> make -C /home/aik/pbuild/qemu-localhost-aarch64-rel/ -j24 check
> >>>
> >>> did not produce segv. I am running this all on a power8 box + ubuntu
> >>> 1804, what is your config?  
> >>
> >> Hm, curious.  I'm using Fedora 29 on an x86 host.  
> > 
> > 
> > Fedora 27 on x86_64 is all right too :-/ Let's upgrade...  
> 
> Upgraded, bad experience - usb ethernet module did not load, and now it
> does not remember the screen configuration - when the external monitor
> is detached - all windows jump to the laptop screen and never come back
> to the external one when reattached :(
> 
> 
> Aaaaand the latest QEMU does not compile with gcc 8.2.1 from fc28:
> 
> /home/aik/p/qemu-dwg/util/memfd.c:38:12: error: static declaration of
> ‘memfd_create’ follows non-static declaration
>  static int memfd_create(const char *name, unsigned int flags)
>             ^~~~~~~~~~~~
> In file included from /usr/include/bits/mman-linux.h:117,
>                  from /usr/include/bits/mman.h:49,
>                  from /usr/include/sys/mman.h:41,
>                  from /home/aik/p/qemu-dwg/include/sysemu/os-posix.h:29,
>                  from /home/aik/p/qemu-dwg/include/qemu/osdep.h:119,
>                  from /home/aik/p/qemu-dwg/util/memfd.c:28:
> /usr/include/bits/mman-shared.h:46:5: note: previous declaration of
> ‘memfd_create’ was here
>  int memfd_create (const char *__name, unsigned int __flags) __THROW;
>      ^~~~~~~~~~~~
> 
> 
> /home/aik/p/qemu-dwg/block/file-posix.c:1585:14: error: static
> declaration of ‘copy_file_range’ follows non-static declaration
>  static off_t copy_file_range(int in_fd, off_t *in_off, int out_fd,
>               ^~~~~~~~~~~~~~~
> In file included from /home/aik/p/qemu-dwg/include/qemu/osdep.h:90,
>                  from /home/aik/p/qemu-dwg/block/file-posix.c:25:
> /usr/include/unistd.h:1107:9: note: previous declaration of
> ‘copy_file_range’ was here
>  ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
>          ^~~~~~~~~~~~~~~
> 
> 
> after fixing these, there is still no segv anyway. Hm :(
> 
> 

Weird... Unlike you, no compile problems for me with gcc-8.2.1-5.fc28.x86_64, 
but
same as you, no segv...