From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn1R6-0005BS-8Y for qemu-devel@nongnu.org; Fri, 16 Oct 2015 05:36:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn1R1-0003oL-Gv for qemu-devel@nongnu.org; Fri, 16 Oct 2015 05:36:28 -0400 Date: Fri, 16 Oct 2015 10:33:31 +0100 From: Stefano Stabellini In-Reply-To: <5620C1A9.2000005@redhat.com> Message-ID: 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> <5620C1A9.2000005@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: Laszlo Ersek Cc: Kevin Wolf , Matt Fleming , Ian Campbell , qemu-block@nongnu.org, Stefano Stabellini , Ard Biesheuvel , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Fabio Fantoni , Kevin O'Connor , Anthony.Perard@citrix.com, John Snow 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.