On Mon, 2013-02-11 at 12:43 +0000, Ian Campbell wrote:
I don't know if distros prefer to have fewer images or not, once you have 2 I guess having N is not such a big deal for something the size and build time of SeaBIOS.
Probably not. It's not as if supporting Xen is an otherwise trivial exercise for the distros anyway; the effort of having an extra SeaBIOS binary is probably lost in the noise.
I don't have any objections to either approach from the Xen PoV.
Thoroughly untested patch on top of your series at git://github.com/KevinOConnor/seabios.git test-20130209
How would I go about testing this myself?
You would need to install and configure Xen. It's not as complex as it once was but it isn't a 5 minute hack either. I'm happy to give details if you like though.
Yes please.
I take it the first step is running 'yum install xen' on my Fedora workstation, and rebooting into Xen with the Fedora kernel as Dom0?
And should CONFIG_XEN select CONFIG_QEMU_HARDWARE, as CONFIG_QEMU does?
Does QEMU_HARDWARE mean hardware "defined" (so to speak) by QEMU (e.g. virtio type stuff) or does it include regular hardware emulated by QEMU (e.g. real IDE disks etc). Xen uses the latter but not the former. The use of the symbol in both the CONFIG_VIRTIO_FOO and scsi_drive_setup() suggests it covers both?
I think it's supposed to be the former, and would argue (and submit patches) that it *should* be the case even if Kevin's patch series doesn't quite do that. So that includes virtio *and* the emulated LSI and ESP SCSI controllers, since nobody's ever actually tested those on real hardware. The bit in scsi_driver_setup() looks right. It's doing the mode sense *only* if it's a qemu-emulated drive and it therefore knows it's safe to do so.