Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 16 Oct 2015, Laszlo Ersek wrote:
> 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.)

The PV block protocol doesn't unfortunately. At least the block backend
in QEMU doesn't support it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel