NetBSD qemu-dm problem

NetBSD qemu-dm problem

[Adam Hamsik]

Hi folks, 

As you probably know NetBSD can supports dom0, domU in i386, i386PAE, amd64 modes. I have found one bug which I would like to fix in our implementation, but I need some guidance to be able to identify what's wrong.

If I create HVM domain with disk located on hw device or Logical Volume 

disk = [ 'file:/home/xenstuff/FreeBSD.img,ioemu:hda,w', 
         'phy:/dev/mapper/rvg00-testlv,ioemu:hdb,w'
        ]

disk hdb(size 20Gb) is detected as this (from xm dmesg)

(XEN) HVM27: ata0-0: PCHS=14563/16/63 translation=none LCHS=1024/16/63
(XEN) HVM27: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (7168 MBytes)
(XEN) HVM27: ata0-1: PCHS=81/16/63 translation=none LCHS=81/16/63
(XEN) HVM27: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  40 MBytes)
(XEN) HVM27: 
(XEN) HVM27: Press F10 to select boot device.
(XEN) HVM27: Booting from Hard Disk...
(XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=82
(XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=83
(XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=84
(XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=85
(XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=86
(XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=87
(XEN) io.c:199:d27 MMIO emulation failed @ 0020:c0bab5d0: 0f ae 3b 01 d3 01

In qemu.log(I have added some fprintfs to raw_open) I can find this.

# less qemu-dm-FreeBSD8.log                                                                                                                                        
domid: 27
qemu: the number of cpus is 1
CAlling bdrv_open2 /home/xenstuff/FreeBSD.img
raw open called /home/xenstuff/FreeBSD.img
open syscall errno 2 -- open_flags 2 - |/home/xenstuff/FreeBSD.img|
CAlling bdrv_open2 /dev/mapper/rvg00-testlv
raw open called /dev/mapper/rvg00-testlv
open syscall errno 2 -- open_flags 2 - |/dev/mapper/rvg00-testlv|
Watching /local/domain/0/device-model/27/logdirty/next-active
Watching /local/domain/0/device-model/27/command
Opening device /home/xenstuff/FreeBSD.img
Opening device /dev/mapper/rvg00-testlv
qemu_map_cache_init nr_buckets = 10000 size 3145728
shared page at pfn 17ffe
buffered io page at pfn 17ffc
Time offset set 0
Register xen platform.
Done register platform.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0

I have changed raw_getlength to support NetBSD, so there shouldn't be problem in device size detection. I think that problem is somewhere in NetBSD but I need some guidance where to look in xen source tree to find out what can be wrong. This problem was found on xen-3.3.2 and xen-unstable. Do you have any ideas where I should look to fix this problem ?

Regards

Adam.

Re: NetBSD qemu-dm problem

[Christoph Egger]

On Monday 08 March 2010 19:47:31 Adam Hamsik wrote:
> Hi folks,
>
> As you probably know NetBSD can supports dom0, domU in i386, i386PAE, amd64
> modes. I have found one bug which I would like to fix in our
> implementation, but I need some guidance to be able to identify what's
> wrong.
>
> If I create HVM domain with disk located on hw device or Logical Volume
>
> disk = [ 'file:/home/xenstuff/FreeBSD.img,ioemu:hda,w',
>          'phy:/dev/mapper/rvg00-testlv,ioemu:hdb,w'
>         ]
>
> disk hdb(size 20Gb) is detected as this (from xm dmesg)
>
> (XEN) HVM27: ata0-0: PCHS=14563/16/63 translation=none LCHS=1024/16/63
> (XEN) HVM27: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (7168 MBytes)
> (XEN) HVM27: ata0-1: PCHS=81/16/63 translation=none LCHS=81/16/63

Are the PCHS and LCHS numbers correct ?

> (XEN) HVM27: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  40 MBytes)
> (XEN) HVM27:
> (XEN) HVM27: Press F10 to select boot device.
> (XEN) HVM27: Booting from Hard Disk...
> (XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=82
> (XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=83
> (XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=84
> (XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=85
> (XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=86
> (XEN) HVM27: int13_harddisk: function 08, unmapped device for ELDL=87
> (XEN) io.c:199:d27 MMIO emulation failed @ 0020:c0bab5d0: 0f ae 3b 01 d3 01

If the dump is correct/complete, this is a clflush in MMIO space.
This might make sense if the MMIO area is mapped write-combined instead of
write-through. This may also make sense if the guest re-programs a
PCI BAR.

Xen does not emulate clflush. That's why the MMIO emulation failed.
Keir: Do you consider this a Xen bug or missing feature ?


>
> In qemu.log(I have added some fprintfs to raw_open) I can find this.
>
> # less qemu-dm-FreeBSD8.log
> domid: 27
> qemu: the number of cpus is 1
> CAlling bdrv_open2 /home/xenstuff/FreeBSD.img
> raw open called /home/xenstuff/FreeBSD.img
> open syscall errno 2 -- open_flags 2 - |/home/xenstuff/FreeBSD.img|
> CAlling bdrv_open2 /dev/mapper/rvg00-testlv
> raw open called /dev/mapper/rvg00-testlv
> open syscall errno 2 -- open_flags 2 - |/dev/mapper/rvg00-testlv|

errno 2 == ENOENT

> Watching /local/domain/0/device-model/27/logdirty/next-active
> Watching /local/domain/0/device-model/27/command
> Opening device /home/xenstuff/FreeBSD.img
> Opening device /dev/mapper/rvg00-testlv
> qemu_map_cache_init nr_buckets = 10000 size 3145728
> shared page at pfn 17ffe
> buffered io page at pfn 17ffc
> Time offset set 0
> Register xen platform.
> Done register platform.
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
>
> I have changed raw_getlength to support NetBSD, so there shouldn't be
> problem in device size detection. I think that problem is somewhere in
> NetBSD but I need some guidance where to look in xen source tree to find
> out what can be wrong. This problem was found on xen-3.3.2 and
> xen-unstable. Do you have any ideas where I should look to fix this problem
> ?
>
> Regards
>
> Adam.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632