From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4fW-0000Dv-8B for qemu-devel@nongnu.org; Fri, 16 Oct 2015 09:03:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn4fR-0006n8-9d for qemu-devel@nongnu.org; Fri, 16 Oct 2015 09:03:34 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:34873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4fR-0006mx-6i for qemu-devel@nongnu.org; Fri, 16 Oct 2015 09:03:29 -0400 Received: by qkap81 with SMTP id p81so53723151qka.2 for ; Fri, 16 Oct 2015 06:03:28 -0700 (PDT) Date: Fri, 16 Oct 2015 09:03:25 -0400 From: Kevin O'Connor Message-ID: <20151016130325.GA19840@morn.lan> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Cc: Kevin Wolf , Matt Fleming , Ian Campbell , qemu-block@nongnu.org, Ard Biesheuvel , John Snow , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Fabio Fantoni , Anthony.Perard@citrix.com, Laszlo Ersek On Fri, Oct 16, 2015 at 10:06:48AM +0100, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: > > 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. Well, there isn't a requirement for both SeaBIOS and the OS to be connected at the same time - it's fine for the OS to replace SeaBIOS. With the hardware I'm familiar with (eg, usb, ahci, virtio) the OS just ends up replacing SeaBIOS' DMA rings when it configures its own. I guess something in the low-level interface of Xen makes that not work. Is plugging/unplugging very high overhead? Since the SeaBIOS disk interface is fully synchronous, in theory one could have it plug/unplug on every read request. -Kevin