[SeaBIOS] Xen PV block device support in Seabios

[Shannon Zhao]

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