Re: Disabling cirrus-vga

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

billy lau wrote:

> Okay, I have rechecked my codes, it is similar to what is done with your
> patch. This time, I tried a linux hvm guest as well. And it happens that
> this is in my xen log when i do a xm log:
> 
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for devices vif.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072)
> XendDomainInfo.handleShutdownWatch
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for 0.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback
> /local/domain/0/backend/vif/1/0/hotplug-status.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback 1.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for devices vscsi.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for devices vbd.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for 768.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback
> /local/domain/0/backend/vbd/1/768/hotplug-status.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback 1.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) Waiting for 5632.
> [2008-12-15 20:25:47 2588] DEBUG (__init__:1072) hotplugStatusCallback
> /local/domain/0/backend/vbd/1/5632/hotplug-status.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) hotplugStatusCallback
> /local/domain/0/backend/vbd/1/5632/hotplug-status.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) hotplugStatusCallback 1.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices irq.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices vkbd.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices vfb.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices
> console.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for 0.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices pci.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for 0.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices
> ioports.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices tap.
> [2008-12-15 20:25:48 2588] DEBUG (__init__:1072) Waiting for devices vtpm.
> [2008-12-15 20:25:48 2588] INFO (__init__:1072) Domain linux-test (1)
> unpaused.
> [2008-12-15 20:25:55 2588] WARNING (__init__:1072) domain linux-test:
> device model failure: pid 2999: died due to signal 7; see
> /var/log/xen/qemu-dm-linux-test.log
> 
> 
> But, again, looking at qemu-dm-linux-test.log, there is no error message:
> domid: 1
> qemu: the number of cpus is 1
> config qemu network with xen bridge for  tap1.0 xenbr0
> Watching /local/domain/0/device-model/1/logdirty/next-active
> Watching /local/domain/0/device-model/1/command
> xs_read(): vncpasswd get error.
> /vm/e9ccff9f-dc55-89e3-612f-5c4cad69cd87/vncpasswd.
> qemu_map_cache_init nr_buckets = 10000 size 3145728
> shared page at pfn 3fffe
> buffered io page at pfn 3fffc
> Time offset set 0
> register_real_device: Assigning real physical device 02:00.0 ...
> pt_register_regions: IO region registered (size=0x01000000
> base_addr=0xfa000000)
> pt_register_regions: IO region registered (size=0x10000000
> base_addr=0xd0000000)
> pt_register_regions: IO region registered (size=0x02000000
> base_addr=0xf8000000)
> pt_register_regions: IO region registered (size=0x00000080
> base_addr=0x0000dc80)
> pt_register_regions: Expansion ROM registered (size=0x00020000
> base_addr=0xfbd00000)
> register_real_device: Real physical device 02:00.0 registered successfuly!
> Register xen platform.
> Done register platform.
> xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
> medium change watch on `hdc' (index: 1):
> /home/billy/Desktop/debian-40r5-i386-netinst.iso
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> pt_iomem_map: e_phys=f0000000 maddr=f8000000 type=0 len=33554432 index=3
> first_map=1
> pt_iomem_map: e_phys=f3000000 maddr=fa000000 type=0 len=16777216 index=0
> first_map=1
> pt_iomem_map: e_phys=f4000000 maddr=fbd00000 type=8 len=131072 index=6
> first_map=1
> pt_ioport_map: e_phys=c200 pio_base=dc80 len=128 index=5 first_map=1
> 
> and it just ends there. xm list shows me this, which is the same as
> before, without state status:
> Name                                        ID   Mem VCPUs      State  
> Time(s)
> Domain-0                                    0  2951     4     r-----    
> 15.9
> linux-test                                     1  1024     1    
> ------      5.5
> 
> So, I guess the question is, what does it mean by device model failure
> due to signal 7?

It means qemu died because it received a SIGBUS signal; the problem
seems to be related to the ioport or memory mapping of passthrough device.