blktap, qdisk, xl cd-eject, and xencommons

[George Dunlap <george.dunlap@eu.citrix.com>]

Following on from the recent discussion about qdisk, there are two other 
issues related to blktap and qdisk that need to be sorted out.

There are two bugs on the Xen release "blocker" list related to qdisk.

The first is "remove hard-coded modprobe's from xencommons".

Background:
- libxl will use blktap by default if it can

- but libxl only knows it can use it if it's already loaded

- QDEV used to use O_DIRECT, which tickled a bug in PVOPS kernels that 
would cause it to crash

- So it used to be the case that if you booted on (for example) a Debian 
Squeeze kernel with Xen, and had a cd-rom (or anything using qdisk), 
your system would eventually crash

- Adding "modprobe blktap" to xencommons fixed this by causing libxl to 
use blktap instead

- But Jan (rightly) objected to having such a hard-coded thing, and 
accepted it for 4.2 only on the condition that it would be removed for 4.3

- However, the initial problem (qdev crashing on pvops kernels) has been 
fixed in a different way now: by removing O_DIRECT from qdev.  I have 
verified that the same configuration (Debian Squeeze) running with a 
qdev cdrom does not crash anymore.

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.

To address these issue for 4.3, I would like to propose:

1. Have libxl default to qdev for everything, except for things that it 
needs blktap for (like vhd, IIRC)

2. Simply remove the hard-coded modprobe from xencommons

3. Add code into libxl to do modprobe-ing as part of the "does this 
system support blktap" check.

But I think #3 can probably wait until 4.4.

Thoughts?

  -George