Re: Qemu-upstream with Xen

[Roger Pau Monné <roger.pau%entel.upc.edu@localhost>]

On Wed, Jun 13, 2012 at 2:22 PM, Jean-Yves Migeon
<jeanyves.migeon%free.fr@localhost> wrote:
> Le 13/06/2012 13:05, Roger Pau Monné a écrit :
>
>> I've debugged this a little bit more, and I've found that
>> privpgop_fault gets called, and tries to map the address again after
>> the call to xc_domain_add_to_physmap. But the call to pmap_enter_ma
>> returns the error 'EFAULT', and thus the segfault in Qemu. The
>> previous call to this function in IOCTL_PRIVCMD_MMAPBATCH (which tries
>> to detect which pages can be mapped) didn't mark this page as invalid,
>> so something must have changed in between... Suggestions are welcome.
>
>
> Nothing appearing on hypervisor console (or xm dmesg?)

I'm not able to see anything relevant here, but here's the hypervisor output:

(XEN) HVM1: HVM Loader
(XEN) HVM1: Detected Xen v4.2-unstable
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 3
(XEN) HVM1: System requested SeaBIOS
(XEN) HVM1: CPU speed is 2661 MHz
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:2 INTD->IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 04:0 INTA->IRQ5
(XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM1: pci dev 02:0 bar 30 size 00010000: f3000000
(XEN) HVM1: pci dev 04:0 bar 30 size 00010000: f3010000
(XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3020000
(XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM1: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) HVM1: pci dev 04:0 bar 14 size 00000100: f3021000
(XEN) HVM1: pci dev 01:2 bar 20 size 00000020: 0000c201
(XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c221
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1: Testing HVM environment:
(XEN) HVM1:  - REP INSB across page boundaries ... passed
(XEN) HVM1:  - GS base MSRs and SWAPGS ... passed
(XEN) HVM1: Passed 2 of 2 tests
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading SeaBIOS ...
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1: vm86 TSS at fc00a080
(XEN) HVM1: BIOS map:
(XEN) HVM1:  10000-100d3: Scratch space
(XEN) HVM1:  e0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:000a0000: RAM
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [01]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [02]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM1:  HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM1:  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1: Invoking SeaBIOS ...
(XEN) stdvga.c:147:d1 entering stdvga and caching modes

> EFAULT is usually returned by hypervisor on mmu_update() calls when
> arguments are bogus (or pose a threat to hypervisor VM). Given the role of
> pmap_enter_ma(), I suspect the hypervisor is refusing the mapping.

It's strange that the hypervisor refuses them, because the same seems
to work ok on Linux, with probably different memory ranges mapped on
the Qemu side. The arguments passed to pmap_enter_ma are the
following:

vaddr: 7f7feec00000 (which corresponds to the Qemu vaddr that
generates the segfault)
paddr: 3f800000
prot: 3
flags: 35
domid: 1 (which belongs to the domu I'm trying to create)

> Can you obtain the arguments passed to the hypercall?

The arguments passed to the hypercall (HYPERVISOR_mmu_update), are:

ptr: 2014b9000
val: 800000003f800067

And of course it returns < 0, which causes the error.

Thanks, Roger.