From: Ian Campbell <ian.campbell@citrix.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Kevin O'Connor <kevin@koconnor.net> Cc: Kevin Wolf <kwolf@redhat.com>, Matt Fleming <matt.fleming@intel.com>, qemu-block@nongnu.org, Ard Biesheuvel <ard.biesheuvel@linaro.org>, John Snow <jsnow@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Fabio Fantoni <fabio.fantoni@m2r.biz>, Anthony.Perard@citrix.com, Laszlo Ersek <lersek@redhat.com> Subject: Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu Date: Fri, 16 Oct 2015 10:34:37 +0100 [thread overview] Message-ID: <1444988077.12442.27.camel@citrix.com> (raw) In-Reply-To: <alpine.DEB.2.02.1510161002510.27957@kaball.uk.xensource.com> On Fri, 2015-10-16 at 10:06 +0100, Stefano Stabellini 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. Which I think is just another way of saying that the Xen PV protocol currently lacks an explicit requirement for the OS to reset the device (or indeed the general PV infrastructure, grant tables etc) before use. Retrofitting that requirement is of course a little tricky. The unplug protocol might be extensible neough though. IIRC it does include provisions for the OS to specify a version and the reject the unplug, so upreving that to include a reset requirement _might_ be possible. At which point it can at least be made a config option which can be switch on for new enough guests. i.e. if the guest is configured to use PV drivers from SeaBIOS the unplug protocol would reject the attempt to unplug the (non-existent) IDE devices and the guest therefore should fail to bind to the PV devices, while a newer guest which knows it has to do a reset would declare itself to be newer and succeed in the unplug. (NB: details of the protocol are sketchy in my memory, and the above may need actual though applied to make it practical, but you get the gist I hope). Then you are just into some sort of multiyear transition/deprecation sequence before you make it the default. > 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.
WARNING: multiple messages have this Message-ID (diff)
From: Ian Campbell <ian.campbell@citrix.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Kevin O'Connor <kevin@koconnor.net> Cc: Kevin Wolf <kwolf@redhat.com>, Matt Fleming <matt.fleming@intel.com>, qemu-block@nongnu.org, Ard Biesheuvel <ard.biesheuvel@linaro.org>, John Snow <jsnow@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Fabio Fantoni <fabio.fantoni@m2r.biz>, Anthony.Perard@citrix.com, Laszlo Ersek <lersek@redhat.com> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu Date: Fri, 16 Oct 2015 10:34:37 +0100 [thread overview] Message-ID: <1444988077.12442.27.camel@citrix.com> (raw) In-Reply-To: <alpine.DEB.2.02.1510161002510.27957@kaball.uk.xensource.com> On Fri, 2015-10-16 at 10:06 +0100, Stefano Stabellini 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. Which I think is just another way of saying that the Xen PV protocol currently lacks an explicit requirement for the OS to reset the device (or indeed the general PV infrastructure, grant tables etc) before use. Retrofitting that requirement is of course a little tricky. The unplug protocol might be extensible neough though. IIRC it does include provisions for the OS to specify a version and the reject the unplug, so upreving that to include a reset requirement _might_ be possible. At which point it can at least be made a config option which can be switch on for new enough guests. i.e. if the guest is configured to use PV drivers from SeaBIOS the unplug protocol would reject the attempt to unplug the (non-existent) IDE devices and the guest therefore should fail to bind to the PV devices, while a newer guest which knows it has to do a reset would declare itself to be newer and succeed in the unplug. (NB: details of the protocol are sketchy in my memory, and the above may need actual though applied to make it practical, but you get the gist I hope). Then you are just into some sort of multiyear transition/deprecation sequence before you make it the default. > 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.
next prev parent reply other threads:[~2015-10-16 9:34 UTC|newest] Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-13 15:55 [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu Fabio Fantoni 2015-10-13 15:55 ` Fabio Fantoni 2015-10-13 16:45 ` [Qemu-devel] " John Snow 2015-10-13 16:45 ` John Snow 2015-10-13 17:10 ` Stefano Stabellini 2015-10-14 9:47 ` Kevin Wolf 2015-10-14 11:06 ` Stefano Stabellini 2015-10-14 11:27 ` [Qemu-devel] [Xen-devel] " Ian Campbell 2015-10-14 11:27 ` [Qemu-devel] " Ian Campbell 2015-10-15 23:10 ` Laszlo Ersek 2015-10-15 23:10 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 2:38 ` [Qemu-devel] " Kevin O'Connor 2015-10-16 2:38 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor 2015-10-16 9:06 ` Stefano Stabellini 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini 2015-10-16 9:21 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 9:21 ` [Qemu-devel] " Laszlo Ersek 2015-10-16 9:33 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini 2015-10-16 9:33 ` [Qemu-devel] " Stefano Stabellini 2015-10-16 9:34 ` Ian Campbell [this message] 2015-10-16 9:34 ` Ian Campbell 2015-10-16 13:03 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor 2015-10-16 13:03 ` [Qemu-devel] " Kevin O'Connor 2015-10-16 9:13 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 9:13 ` [Qemu-devel] " Laszlo Ersek 2015-10-14 11:32 ` Kevin Wolf 2015-10-14 11:44 ` Stefano Stabellini 2015-10-15 16:27 ` Fabio Fantoni 2015-10-15 16:27 ` Fabio Fantoni 2015-10-15 18:02 ` Anthony PERARD 2015-10-15 18:02 ` Anthony PERARD 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 10:13 ` Anthony PERARD 2015-10-16 10:23 ` Fabio Fantoni 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 19:09 ` Laszlo Ersek 2015-10-16 19:09 ` Laszlo Ersek 2015-10-19 20:32 ` Laszlo Ersek 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 14:52 ` Stefano Stabellini 2015-10-20 14:52 ` Stefano Stabellini 2015-10-19 20:32 ` Laszlo Ersek 2015-10-16 10:23 ` Fabio Fantoni 2015-10-14 11:11 ` Fabio Fantoni 2015-10-14 12:48 ` Paul Durrant 2015-10-15 23:35 ` Laszlo Ersek 2015-10-15 23:35 ` Laszlo Ersek 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 15:10 ` Paul Durrant 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:20 ` Paul Durrant 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:53 ` Paul Durrant 2015-10-16 17:03 ` Kevin Wolf 2015-10-16 17:03 ` Kevin Wolf 2015-10-19 13:42 ` Fabio Fantoni 2015-10-19 13:42 ` Fabio Fantoni 2015-10-16 16:53 ` Paul Durrant 2015-10-16 16:53 ` Eric Blake 2015-10-16 16:53 ` Eric Blake 2015-10-16 16:20 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 20:40 ` John Snow 2015-10-16 20:40 ` John Snow 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 19:55 ` Laszlo Ersek 2015-10-19 19:55 ` Laszlo Ersek 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:57 ` Stefano Stabellini 2015-10-19 14:57 ` Stefano Stabellini
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1444988077.12442.27.camel@citrix.com \ --to=ian.campbell@citrix.com \ --cc=Anthony.Perard@citrix.com \ --cc=ard.biesheuvel@linaro.org \ --cc=fabio.fantoni@m2r.biz \ --cc=jsnow@redhat.com \ --cc=kevin@koconnor.net \ --cc=kwolf@redhat.com \ --cc=lersek@redhat.com \ --cc=matt.fleming@intel.com \ --cc=qemu-block@nongnu.org \ --cc=qemu-devel@nongnu.org \ --cc=stefano.stabellini@eu.citrix.com \ --cc=xen-devel@lists.xen.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.