Port-xen archive

[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?)



El 27/05/15 a les 21.29, Reinoud Zandijk ha escrit:
> 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:
>> xentools33/patches/patch-qemu-phy-devices
>>
>> 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?

FWIW I had to craft the following patch for FreeBSD:

http://git.qemu.org/?p=qemu.git;a=patch;h=3cad83075c7b847fe0eb6e61316fdf50984d4570

Note that this is for Qemu upstream, not the qemu-xen fork that's used
by NetBSD, but I guess the issue could also be there.

Roger.



Home | Main Index | Thread Index | Old Index