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


  • To: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 15 May 2020 22:38:13 +0100
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 15 May 2020 21:38:52 +0000
  • Ironport-sdr: 6sBbulZbKKT8BljoNnbmu89Zx+L6x6D1rpSEj8KKNMCiv8B/ReEmTvE0AoFmzas/hxnzmGZFfO WlZLQqiBd+t7j6O9wvDTJ1xQaR/7lOgUt36re8TLsAwkXUTfXpMFIaJbUbC20S/CbGjNBND/Hf GequjRboVj2z3YriWvksJqJ2jYZ6xbbwMLVkgQO1VTTp8HkpMS0F3YfLN/Hr6gIPwlQewKR2i+ h4XtNPWx8dpQ+9xKN+ztcP8jHX1huEfIGy9Po2YOFJDq3ahLF8hIput+sCHLXNSU8FNx+sO5it aYA=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15/05/2020 22:06, Manuel Bouyer wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> unless you have verified the sender and know the content is safe.
> On Fri, May 15, 2020 at 10:00:07PM +0100, Andrew Cooper wrote:
>> What is qemu doing at the time?  Is it by any chance trying to map the
>> IOREQ server frame?
> Here's what gdb says about it:
> Core was generated by `qemu-dm'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000000000046997d in cpu_x86_init (
>     cpu_model=cpu_model@entry=0x4d622d "qemu32")
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/i386-dm/helper2.c:156
> 156                 rc = xenevtchn_bind_interdomain(
> --Type <RET> for more, q to quit, c to continue without paging--
> [Current thread is 1 (process 1480)]
> (gdb) where
> #0  0x000000000046997d in cpu_x86_init (
>     cpu_model=cpu_model@entry=0x4d622d "qemu32")
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/i386-dm/helper2.c:156
> #1  0x000000000043628d in pc_init1 (ram_size=<optimized out>, 
>     vga_ram_size=4194304, boot_device=0x7f7fff460397 "cda", pci_enabled=1, 
>     cpu_model=0x4d622d "qemu32", initrd_filename=<optimized out>, 
>     kernel_cmdline=<optimized out>, kernel_filename=<optimized out>)
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/hw/pc.c:829
> #2  0x00000000004636e7 in xen_init_fv (ram_size=0, vga_ram_size=4194304, 
>     boot_device=0x7f7fff460397 "cda", kernel_filename=0x0, 
>     kernel_cmdline=0x4abff6 "", initrd_filename=0x0, cpu_model=0x0, 
>     direct_pci=0x0)
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/hw/xen_machine_fv.c:405
> #3  0x00000000004a975b in main (argc=23, argv=0x7f7fff45fc78, 
>     envp=<optimized out>)
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/vl.c:6014
> Does it help ?

Yes and no.  This is collateral damage of earlier bug.

What failed was xen_init_fv()'s

    shared_page = xc_map_foreign_range(xc_handle, domid, XC_PAGE_SIZE,
                                       PROT_READ|PROT_WRITE, ioreq_pfn);
    if (shared_page == NULL) {
        fprintf(logfile, "map shared IO page returned error %d\n", errno);

because we've ended up with a non-NULL pointer with no mapping behind
it, hence the SIGSEGV for the first time we try to use the pointer.

Whatever logic is behind xc_map_foreign_range() should have returned
NULL or a real mapping.

ioreq_pfn ought to be something just below the 4G boundary, and the
toolstack ought to put memory there in the first place.  Can you
identify what value ioreq_pfn has, and whether it matches up with the
magic gfn range as reported by `xl create -vvv` for the guest?




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