On Thu, 15 Oct 2015, Kevin O'Connor wrote: > On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > > On 10/14/15 13:27, Ian Campbell wrote: > > > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > > >>> Can't you just teach SeaBIOS how to deal with your PV disks and then > > >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > > >>> it's done for virtio-blk, and it doesn't involve any insanities like > > >>> ripping out non-hotpluggable devices. > > >> > > >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > > >> support PV disks in OVMF. It is possible to boot Windows with OVMF > > >> without any IDE disks (patch pending for libxl to create a VM without > > >> emulated IDE disks). > > > > > > One stumbling block in the past has been how to know when the PV drivers > > > in > > > the BIOS are no longer required, such that the ring can be torn down > > > and/or > > > the connection etc handed over to the OS driver. > [...] > > > AFAIK the BIOS interfaces do not have anything as reliable as that. > > > > > > How does virtio deal with this in the BIOS case? > > > > It doesn't, as far as I can tell. > > > > I don't think it has to, though! On a BIOS box, you can always boot DOS, > > or another operating system that continues to use the BIOS interfaces > > forever. (Same as if you never call ExitBootServices() in UEFI.) > > > > Given that no starter pistol gets fired between the firmware and the OS > > on such a platform, they must always respect each other. I guess this > > could occur through the E820 map, or some such. > > One can use the "ACPI enable" SMI event to detect this if they really > wanted to. In SeaBIOS one could do this from > src/fw/smm.c:handle_smi() - however, no other drivers need this > notification today and it would be a bit ugly to have to handle it > from an SMI. (Assuming Xen were to support SMIs.) > > > No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > > but I guess the Linux kernel stays away from those areas until it's past > > device probing and binding. > > In SeaBIOS, the virtio memory is allocated from reserved memory. (See > the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > zone is taken from reserved memory: > http://seabios.org/Memory_Model#Memory_available_during_initialization > ) > > What's the reason for the "stumbling block" that requires the BIOS to > tear down the Xen ring prior to the OS being able to replace it? The > BIOS disk calls are all synchronous, so the ring wont be active when > the OS brings up its own ring. Is there some low-level interaction > that prevents the OS from just resetting the ring prior to enabling > it?
Xen only exports one PV disk interface for each disk to the guest, and each PV interface only supports one frontend -- only SeaBIOS or the OS can be connected to one PV disk, not both. In the case of OVMF, we handle that by disconnecting the PV frontend in OVMF when ExitBootServices is called, so that the OS driver can reconnect later.
