On 10/16/15 11:06, Stefano Stabellini wrote: > 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.
Does the XenBus protocol support a device reset operation, regardless of what state the device is currently in? (I don't remember all the state transitions any longer, sorry.) Thanks Laszlo
