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

[Laszlo Ersek]

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