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@xxxxxxxxxxxxxxxxxxx
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home