[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HVM disc corruption (was Re: Xen won't start its device backend?)
On Wed, May 27, 2015 at 04:06:49PM +0200, Manuel Bouyer wrote:
> On Wed, May 27, 2015 at 12:52:07PM +0200, Manuel Bouyer wrote:
> > No, I think nobody tried to use a HVM guest with a physical block device
> > yet ...
> xentools33 and 41 have a patch to make qemu use the character device
> if given a block device:
> xentools42 has patch-qemu-xen-traditional_block-raw-posix.c which should
> do the same.
> But it seems that xentools42 has several qemu binaries; can you
> confirm which one you're using, and that is really opens the character
> device even if given a block device ?
I see that it uses qemu-dm and tries to use the raw device indeed:
5111 1 qemu-dm CALL open(0xa9baa0,2,0x1a4)
5111 1 qemu-dm NAMI "/dev/rwd1d"
5111 1 qemu-dm RET open 16/0x10
5111 1 qemu-dm CALL __fstat50(0x10,0x7f7fffffc560)
5111 1 qemu-dm RET __fstat50 0
5111 1 qemu-dm CALL ioctl(0x10,DIOCGWEDGEINFO,0x7f7fffffc2f0)
5111 1 qemu-dm RET ioctl -1 errno 25 Inappropriate ioctl for device
5111 1 qemu-dm CALL ioctl(0x10,DIOCGDINFO,0x7f7fffffc3c0)
5111 1 qemu-dm GIO fd 16 read 408 bytes
It then reads the disklabel fine. Inspecting the code it seems to open the
disc with O_BINARY, with a possible O_DIRECT / O_DSYNC. Reading it seems to do
on a 512 block boundary for files opened with O_DIRECT and it uses lseek() in
combination with the qemu_read(fd, buf, cnt) function.
Is there any special behaviour on raw devices for such flags / functions that
could trigger the bug?
Main Index |
Thread Index |