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

Re: sysbus failed assert for xen_sysdev



On Wed, Jun 24, 2020 at 6:29 AM Paul Durrant <xadimgnik@xxxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Jason Andryuk <jandryuk@xxxxxxxxx>
> > Sent: 24 June 2020 04:24
> > To: Paul Durrant <paul@xxxxxxx>
> > Cc: Markus Armbruster <armbru@xxxxxxxxxx>; Mark Cave-Ayland 
> > <mark.cave-ayland@xxxxxxxxxxxx>; Anthony
> > PERARD <anthony.perard@xxxxxxxxxx>; xen-devel 
> > <xen-devel@xxxxxxxxxxxxxxxxxxxx>; QEMU <qemu-
> > devel@xxxxxxxxxx>
> > Subject: Re: sysbus failed assert for xen_sysdev
> >
> > On Tue, Jun 23, 2020 at 7:46 AM Paul Durrant <xadimgnik@xxxxxxxxx> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Markus Armbruster <armbru@xxxxxxxxxx>
> > > > Sent: 23 June 2020 09:41
> > > > To: Jason Andryuk <jandryuk@xxxxxxxxx>
> > > > Cc: Mark Cave-Ayland <mark.cave-ayland@xxxxxxxxxxxx>; Anthony PERARD 
> > > > <anthony.perard@xxxxxxxxxx>;
> > xen-
> > > > devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; Paul Durrant <paul@xxxxxxx>; 
> > > > QEMU <qemu-devel@xxxxxxxxxx>
> > > > Subject: Re: sysbus failed assert for xen_sysdev
> > > >
> > > > Jason Andryuk <jandryuk@xxxxxxxxx> writes:
> > > > > Then it gets farther... until
> > > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly:
> > > > > Assertion `dev->realized' failed.
> > > > >
> > > > > dev->id is NULL. The failing device is:
> > > > > (gdb) p *dev.parent_obj.class.type
> > > > > $12 = {name = 0x555556207770 "cfi.pflash01",
> > > > >
> > >
> > > Having commented out the call to xen_be_init() entirely (and 
> > > xen_bus_init() for good measure) I also
> > get this assertion failure, so
> > > I don't think is related.
> >
> > Yes, this is something different.  pc_pflash_create() calls
> > qdev_new(TYPE_PFLASH_CFI01), but it is only realized in
> > pc_system_flash_map()...  and pc_system_flash_map() isn't called for
> > Xen.
> >
> > Removing the call to pc_system_flash_create() from pc_machine_initfn()
> > lets QEMU startup and run a Xen HVM again.  xen_enabled() doesn't work
> > there since accelerators have not been initialized yes, I guess?
>
> Looks like it can be worked round by the following:

Yes, thank you.

Tested-by: Jason Andryuk <jandryuk@xxxxxxxxx>

> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 1497d0e4ae..977d40afb8 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine,
>      if (!xen_enabled()) {
>          pc_memory_init(pcms, system_memory,
>                         rom_memory, &ram_memory);
> -    } else if (machine->kernel_filename != NULL) {
> -        /* For xen HVM direct kernel boot, load linux here */
> -        xen_load_linux(pcms);
> +    } else {
> +        pc_system_flash_cleanup_unused(pcms);
> +        if (machine->kernel_filename != NULL) {
> +            /* For xen HVM direct kernel boot, load linux here */
> +            xen_load_linux(pcms);
> +        }
>      }
>
>      gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled);
> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> index ec2a3b3e7e..0ff47a4b59 100644
> --- a/hw/i386/pc_sysfw.c
> +++ b/hw/i386/pc_sysfw.c
> @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms)
>      }
>  }
>
> -static void pc_system_flash_cleanup_unused(PCMachineState *pcms)
> +void pc_system_flash_cleanup_unused(PCMachineState *pcms)
>  {
>      char *prop_name;
>      int i;
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index e6135c34d6..497f2b7ab7 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0);
>
>  /* pc_sysfw.c */
>  void pc_system_flash_create(PCMachineState *pcms);
> +void pc_system_flash_cleanup_unused(PCMachineState *pcms);
>  void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
>
>  /* acpi-build.c */
>
>
> >
> > Regards,
> > Jason
>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.