xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Shannon Zhao <zhaoshenglong@huawei.com>
To: Ian Campbell <ijc@hellion.org.uk>,
	evil.dani@gmail.com, kevin@koconnor.net, keir@xen.org,
	wei.liu2@citrix.com
Cc: "Jinjian (Ken)" <jinjian@huawei.com>,
	seabios@seabios.org,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [SeaBIOS] Xen PV block device support in Seabios
Date: Wed, 16 Mar 2016 20:31:06 +0800	[thread overview]
Message-ID: <56E9520A.3050102__45492.4860191115$1458131577$gmane$org@huawei.com> (raw)
In-Reply-To: <1458130952.30744.14.camel@hellion.org.uk>



On 2016/3/16 20:22, Ian Campbell wrote:
> On Wed, 2016-03-16 at 20:13 +0800, Shannon Zhao wrote:
>> > 
>> > On 2016/3/16 19:20, Ian Campbell wrote:
>>> > > 
>>> > > (nb, my citrix.com email is no longer valid)
>>> > > On Wed, 2016-03-16 at 11:33 +0800, Shannon Zhao wrote:
>>>> > > > 
>>>>> > > > > 
>>>>> > > > > Hi,
>>>>> > > > > 
>>>>> > > > > I noticed there are some efforts to add Xen PV block device support in
>>>>> > > > > Seabios in a GSoC project and there is a wiki page [1] for it. I found
>>>>> > > > > some patches [2] to add Xenstore R/W support for Seabios. But I didn't
>>>>> > > > > find the patches to add PV block device driver in Seabios.
>>>>> > > > > 
>>>>> > > > > If you know please tell me where I can find these patches. And I noticed
>>>>> > > > > that the patches [2] and this GSoC project work didn't get applied to
>>>>> > > > > Seabios eventually, is there any reason? Does it mean that there are
>>>>> > > > > some difficulties to support Xen PV block device in Seabios?
>>> > > This work was never finished, IIRC (and it was a long time ago so this
>>> > > might be a faulty recollection) the main stumbling block was that there
>>> > > is no reasonable BIOS level event which could be used to tear down the
>>> > > PV interfaces in order to hand them over to the OS (unlike, say, EFI
>>> > > where there is ExitBootServices).
>>> > > 
>> > Ian, thanks for your reply! It looks like the problem is how and when to
>> > clear PV resources in seabios before handing over to guest. But I wonder
>> > why virtio works in seabios. Does seabios using virtio need to clear
>> > things like vrings? Or seabios doesn't clear the things and guest just
>> > covers the configuration with new values?
> I think virtio covered this use case from day 1 by having the reset,
> but also by not having a xenstore ring etc.
> 
>>> > > So making this work would require something like a complete set of
>>> > > parallel PV infrastructure (devices, corresponding xenstore nodes,
>>> > > grant table) for the use of the BIOS firmware, or perhaps a (tricky
>>> > > to
>>> > > retrofit in a backwards compatible manner) PV facility for the
>>> > > guest to
>>> > > reset everything before starting to use them.
>>> > > 
>> > Like guest front-end driver checks if the backend state is
>> > XenbusStateInitWait, if not, tell the backend to reset to
>> > XenbusStateInitWait state?
> Before it can do this the guest needs to recover the xenbus ring (which
> was used by SeaBIOS) into a usable state -- so you need to be thinking
> at least one layer further down before you can start to think about
> individual devices, and don't forget the grant table (which may have in
> use entries from the BIOS) and event channels (which the BIOS may have
> setup).
> 
> I'm afraid I don't have any concrete answer for what exactly needs to
> be done to make this work, but I do know that it is a (IMHO very) non-
> trivial amount of investigation, prototyping and coding.
> 
>>> > > Ultimately it didn't seem worth the effort to engineer all that
>>> > > given
>>> > > that mostly the same aims (faster PV assisted boot) could be
>>> > > achieved
>>> > > by using UEFI for most modern OSes.
>> > Yes, for modern OSes it could UEFI. But for some old OSes or some
>> > existing VMs, if we want to use PV assisted boot, it needs to add this
>> > in seabios.
> Sure, it's a completely reasonable feature to want, but you should be
> aware that there are some very non-trivial issue to be resolved, at
> which point you need to ask whether it is worth your time and effort.
Hmm, right. I'll think about this. Anyway, thanks a lot!

-- 
Shannon


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-03-16 12:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16  3:33 Xen PV block device support in Seabios Shannon Zhao
2016-03-16 10:39 ` Wei Liu
2016-03-16 11:20 ` [SeaBIOS] " Ian Campbell
2016-03-16 12:13   ` Shannon Zhao
2016-03-16 12:22     ` Ian Campbell
     [not found]     ` <1458130952.30744.14.camel@hellion.org.uk>
2016-03-16 12:31       ` Shannon Zhao [this message]
2016-03-16 12:58       ` Gerd Hoffmann
2016-03-16 13:15       ` Konrad Rzeszutek Wilk
2016-03-16 13:33         ` Jan Beulich
2016-03-16 13:41           ` Ian Campbell

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='56E9520A.3050102__45492.4860191115$1458131577$gmane$org@huawei.com' \
    --to=zhaoshenglong@huawei.com \
    --cc=evil.dani@gmail.com \
    --cc=ijc@hellion.org.uk \
    --cc=jinjian@huawei.com \
    --cc=keir@xen.org \
    --cc=kevin@koconnor.net \
    --cc=peter.huangpeng@huawei.com \
    --cc=seabios@seabios.org \
    --cc=wei.liu2@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).