From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn1D2-0007x4-ID for qemu-devel@nongnu.org; Fri, 16 Oct 2015 05:21:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn1D1-0004Xr-Ei for qemu-devel@nongnu.org; Fri, 16 Oct 2015 05:21:56 -0400 References: <561D2966.9070007@m2r.biz> <561D3513.8060005@redhat.com> <20151014094727.GE4281@noname.str.redhat.com> <1444822072.23192.160.camel@citrix.com> <5620327E.2030406@redhat.com> <20151016023814.GA21357@morn.lan> From: Laszlo Ersek Message-ID: <5620C1A9.2000005@redhat.com> Date: Fri, 16 Oct 2015 11:21:45 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini , Kevin O'Connor Cc: Kevin Wolf , Matt Fleming , Ian Campbell , qemu-block@nongnu.org, Ard Biesheuvel , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Fabio Fantoni , Anthony.Perard@citrix.com, John Snow 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