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

[Laszlo Ersek]

On 10/16/15 04:38, 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.

Perfect! That gives Xen drivers precedence to do the same.

>  (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.

Yes, that's an argument that works well in practice. However...

> Is there some low-level interaction
> that prevents the OS from just resetting the ring prior to enabling
> it?

the assumption was that the ring would be placed into normal memory. If
GRUB or the kernel overwrote the memory (reallocating the same pages for
completely unrelated purposes) that used to contain the ring while
SeaBIOS was serving requests, the hypervisor would be allowed to notice
and act upon writes to those pages *without* any explicit "kick" (=
guest-to-host notification). The hypervisor is allowed to look at the
ring any time it wishes, so guest code uses barriers while populating
the ring, and kicks the hypervisor "just in case it's not looking right
now".

But if the firmware's ring is in reserved memory, then the OS will stay
away forever. That's great -- it answers the question for virtio, and
should also guide a Xen PV driver implementation.

Thanks!
Laszlo

> 
> -Kevin
>