Re: HVM disc corruption (was Re: Xen won't start its device backend?)

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

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?

Cheers,
Reinoud