> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 November 2017 09:53 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Anthony Perard <anthony.per...@citrix.com>; Roger Pau Monne > <roger....@citrix.com>; Mike Reardon <m...@inso.org>; Stefano Stabellini > <sstabell...@kernel.org>; xen-devel@lists.xen.org; Konrad Rzeszutek Wilk > <konrad.w...@oracle.com> > Subject: RE: [Xen-devel] [BUG] blkback reporting incorrect number of > sectors, unable to boot > > >>> On 10.11.17 at 10:40, <paul.durr...@citrix.com> wrote: > >> Anthony PERARD > >> Sent: 09 November 2017 17:50 > >> The problem is that QEMU 4.10 have a lock on the disk image. When > >> booting an HVM guest with a qdisk backend, the disk is open twice, but > >> can only be locked once, so when the pv disk is been initialized, the > >> initialisation kind of fail. > >> Unfortunatly, OVMF will wait indefinitly until the PV disk is > >> initialized. > > > > That's presumably because the OVMF frontend leaves the emulated disk > plugged > > in despite talking via PV? > > Well, how could it not? It can't know whether the OS to be booted > is going to have PV drivers, and iirc the unplug is not reversible.
Oh, quite, but this is a fundamental problem if QEMU believes that it is not safe to open the underlying storage shared read-write (which would be the case for a qcow, or vhd where there is metadata to worry about). QEMU will open the storage as soon as the emulated device is realised so when xen_disk tries to open it again at connect time, it's always going to fail. Paul > Shouldn't OVMF close the blkif connection, with the backend > responding to this by unlocking (and maybe closing) the image? > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
