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

[Kevin O'Connor <kevin@xxxxxxxxxxxx>]

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?

-Kevin

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