Re: [Qemu-devel] [PULL 05/21] arm/boot: split load_dtb() from arm_load_kernel()

[Igor Mammedov]

On Wed, 23 May 2018 09:38:33 +0200
Auger Eric <address@hidden> wrote:

> Hi,
> 
> On 05/10/2018 07:45 PM, Peter Maydell wrote:
> > From: Igor Mammedov <address@hidden>
> > 
> > load_dtb() depends on arm_load_kernel() to figure out place
> > in RAM where it should be loaded, but it's not required for
> > arm_load_kernel() to work. Sometimes it's neccesary for
> > devices added with -device/device_add to be enumerated in
> > DTB as well, which's lead to [1] and surrounding commits to
> > add 2 more machine_done notifiers with non obvious ordering
> > to make dynamic sysbus devices initialization happen in
> > the right order.
> > 
> > However instead of moving whole arm_load_kernel() in to
> > machine_done, it's sufficient to move only load_dtb() into
> > virt_machine_done() notifier and remove ArmLoadKernelNotifier/
> > /PlatformBusFDTNotifierParams notifiers, which saves us ~90LOC
> > and simplifies code flow quite a bit.
> > Later would allow to consolidate DTB generation within one
> > function for 'mach-virt' board and make it reentrant so it
> > could generate updated DTB in device hotplug secenarios.
> > 
> > While at it rename load_dtb() to arm_load_dtb() since it's
> > public now.
> > 
> > Add additional field skip_dtb_autoload to struct arm_boot_info
> > to allow manual DTB load later in mach-virt and to avoid touching
> > all other boards to explicitly call arm_load_dtb().
> > 
> >  1) (ac9d32e hw/arm/boot: arm_load_kernel implemented as a machine init 
> > done notifier)  
> 
> I face a regression that looks to be caused by this patch (bisect
> session result). Reverting it allows the guest to boot. Otherwise I get:
> 
> in kvm_device_access() at
> /home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164:
> 2018-05-22T18:02:17.210175Z qemu-system-aarch64: KVM_SET_DEVICE_ATTR
> failed: Group 6 attr 0x000000000000c665: Invalid argument
> 
> It happens when booting with -bios option only (with dt, it boots fine).
> 
> I have not identified the root cause yet.
Problem was with broken reset order, thanks for catching it early.
Quick fix is posted under title
  "arm: fix qemu crash on startup with -bios option"