Re: [Qemu-devel] [PATCH] spapr-pci: remove io ports workaround

[Greg Kurz]

On Fri, 03 Jan 2014 09:08:21 +1100
Alexey Kardashevskiy <address@hidden> wrote:
> 
> Please read the rest of this thread. It does not visibly break things but
> with this patch QEMU starts calling unassigned_mem_accepts() (normally
> silent) which is not a good sign.
> 
> 
> 

Hmm... this is only because this patch moves the PHB io region from the
system IO to the system memory space, but the bogus(?) write to unassigned
memory already exists.

I have tested against the current ppc-next (62d529a), with no
additional patch:

qemu-system-ppc64 \
-snapshot -S -monitor stdio -serial pty \
-nographic -nodefaults \
-machine type=pseries,accel=kvm -smp 1 -m 4G \
-device virtio-blk-pci,id=virtioiblk0,drive=drive0,bootindex=20,ioeventfd=on \
-drive file=/local/greg/qemu/fedora-be.qcow2,if=none,id=drive0,readonly=off,\
       format=qcow2,media=disk,werror=stop,rerror=stop,discard=on

where fedora-be.qcow2 contains a stock fedora 19 for ppc64.

I have attached gdb to qemu and set a breakpoint in unassigned_io_write(), and
here is what I get again:

(gdb) b unassigned_io_write 
Breakpoint 1 at 0x1045d308: file /home/greg/Work/ibm/linux/qemu-agraf/ioport.c, 
line 54.
(gdb) c
Continuing.
[Thread 0x1ffffc5deef0 (LWP 11946) exited]
[New Thread 0x1ffffc5deef0 (LWP 11955)]
[Switching to Thread 0x1ffffbdaeef0 (LWP 11947)]

Breakpoint 1, unassigned_io_write (opaque=0x0, addr=82, val=128, size=1) at 
/home/greg/Work/ibm/linux/qemu-agraf/ioport.c:54
54      {
(gdb) where
#0  unassigned_io_write (opaque=0x0, addr=82, val=128, size=1) at 
/home/greg/Work/ibm/linux/qemu-agraf/ioport.c:54
#1  0x0000000010468f38 in memory_region_write_accessor (mr=0x10027615940, 
addr=82, value=0x1ffffbdadd68, size=1, shift=0, mask=255) at 
/home/greg/Work/ibm/linux/qemu-agraf/memory.c:440
#2  0x00000000104690c4 in access_with_adjusted_size (addr=82, 
value=0x1ffffbdadd68, size=1, access_size_min=1, access_size_max=4, 
address@hidden: 0x10468e5c <memory_region_write_accessor>, mr=0x10027615940)
    at /home/greg/Work/ibm/linux/qemu-agraf/memory.c:472
#3  0x000000001046bc64 in memory_region_dispatch_write (mr=0x10027615940, 
addr=82, data=128, size=1) at /home/greg/Work/ibm/linux/qemu-agraf/memory.c:984
#4  0x000000001046fdc4 in io_mem_write (mr=0x10027615940, addr=82, val=128, 
size=1) at /home/greg/Work/ibm/linux/qemu-agraf/memory.c:1749
#5  0x00000000103aca0c in address_space_rw (as=0x10c19638 
<address_space_memory>, addr=1101659111506, buf=0x1ffffbdae117 "\200", len=1, 
is_write=true) at /home/greg/Work/ibm/linux/qemu-agraf/exec.c:2002
#6  0x00000000103acf3c in cpu_physical_memory_rw (addr=1101659111506, 
buf=0x1ffffbdae117 "\200", len=1, is_write=1) at 
/home/greg/Work/ibm/linux/qemu-agraf/exec.c:2071
#7  0x00000000103a44c4 in cpu_physical_memory_write (addr=1101659111506, 
buf=0x1ffffbdae117, len=1) at 
/home/greg/Work/ibm/linux/qemu-agraf/include/exec/cpu-common.h:68
#8  0x00000000103aeb2c in stb_phys (addr=1101659111506, val=128) at 
/home/greg/Work/ibm/linux/qemu-agraf/exec.c:2600
#9  0x0000000010438550 in h_logical_store (cpu=0x10027d0f0d0, 
spapr=0x100276bb210, opcode=64, args=0x1ffffff80030) at 
/home/greg/Work/ibm/linux/qemu-agraf/hw/ppc/spapr_hcall.c:564
#10 0x0000000010438e74 in spapr_hypercall (cpu=0x10027d0f0d0, opcode=64, 
args=0x1ffffff80030) at 
/home/greg/Work/ibm/linux/qemu-agraf/hw/ppc/spapr_hcall.c:737
#11 0x00000000104cf424 in kvm_arch_handle_exit (cs=0x10027d0f0d0, 
run=0x1ffffff80000) at 
/home/greg/Work/ibm/linux/qemu-agraf/target-ppc/kvm.c:1223
#12 0x00000000104648a4 in kvm_cpu_exec (cpu=0x10027d0f0d0) at 
/home/greg/Work/ibm/linux/qemu-agraf/kvm-all.c:1736
#13 0x0000000010397f00 in qemu_kvm_cpu_thread_fn (arg=0x10027d0f0d0) at 
/home/greg/Work/ibm/linux/qemu-agraf/cpus.c:874
#14 0x00001fffff92c29c in start_thread (arg=0x1ffffbdaeef0) at 
pthread_create.c:310
#15 0x00001ffffde5de10 in .__clone ()
at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:111

All I can say for the moment, is that I don't get that if I run qemu with
-kernel/-append/-initrd instead of following the grub2 path.

Any clue ?

Thanks.

-- 
Gregory Kurz                                     address@hidden
                                                 address@hidden
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.