[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] blktap, qdisk, xl cd-eject, and xencommons

On 04/30/2013 11:21 AM, Ian Campbell wrote:
On Tue, 2013-04-30 at 11:02 +0100, George Dunlap wrote:
The second is problems with xl cd-insert and eject, initially reported
by Fabio Fantoni, and then (accidentally) reproduced by me.  The
problem turns out to be libxl using blktap for cdroms.  Basically,
AFAICT, the whole cd-insert cd-eject thing completely doen't work if
blktap is used to provide it; and it's not a simple fix.

cd-insert/eject are suppose to operate on emulated CDROM, which blktap
simply isn't in a position to provide, even if it was capable of doing
so. So this is certainly wrong IMHO at some level.

All emulated disks have a PV counterpart. Many (all?) PVHVM drivers
choose not to unplug the emulated CDROM and use it in preference to the
PV version (since this way they get proper media change events etc) but
I don't think they are required to behave like this.

In principal it's not wrong to provide the PV face of a device from a
different backend to the emulated one (e.g. we do blkback+qdisk all the
time for disks), but in the interests of simplicity it seems like the
obvious thing to do is to unconditionally use qdisk for both faces of an
HVM guest's CDROM.

Right -- so I guess from a release perspective the best thing to do would just be to have tools/libxl/libxl_device.c:disk_try_backend() fail for TAP if disk->is_cdrom is true?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.