Re: [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Thu, Feb 4, 2016 at 3:10 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Thu, Feb 04, 2016 at 12:51:38AM +0000, Andrew Cooper wrote:
>> On 03/02/2016 23:59, Luis R. Rodriguez wrote:
>> > On Wed, Feb 03, 2016 at 08:52:50PM +0000, Andrew Cooper wrote:
>> >> On 03/02/16 18:55, Luis R. Rodriguez wrote:
>> >>> We add new hypervisor type to close the semantic gap for hypervisor types, and
>> >>> much like subarch enable also a subarch_data to let you pass and use your
>> >>> hvmlite_start_info. This would not only help with the semantics but also help
>> >>> avoid yet-another-entry point and force us to provide a well define structure
>> >>> for considering code that should not run by pegging it as required or supported
>> >>> for different early x86 code stubs.
>> >> Was I unclear last time?  Xen *will not* be introducing Linux-specifics
>> >> into the HVMLite starting ABI.
>> > This does not have to be "Linux specifics" but rather a light way to enable
>> > a hypervisor to clue in *any* OS of its hypervisor type, guest type, and
>> > custom hypervisor data that can be used to populate needed OS specifics
>> > about the guest. Perhaps Xen's own loader mechanism could be extended just
>> > slightly to become *that* standard, its just right now it doesn't seem to
>> > enable for generalizing this in a very useful way for OSes. Its all
>> > custom stubs.
>>
>> There are already standard x86 ways of doing this, via the hypervisor
>> cpuid bits.  Xen presents itself normally in this regard, as do all the
>> other hypervisors.
>
> I don't think this is availably early in asm boot? Its why I think the
> zero page is convenient. The boot loader should in theory know these
> things, as well as if its in 32-bit, 64-bit, etc.
>
>> It is completely backwards to expect a hypervisor (or toolstack in our
>> case) to deliberately prod what it suspects might be a Linux binary in a
>> way which it things a Linux binary might like to be prodded.
>
> Perhaps prodding tons of info seems ludicrous, however prodding at least a
> loader type and custom data pointer to interpret that so that then your stub
> can interpret seems sensible for many reasons and I don't think prodding two
> things is much to ask for, given the possible gains on clean architecture.
> Its why I am suggesting perhaps this should just be standardized.
>
> We need flexibility on both sides.

And... it seems EFI boot already does this!

A few of us have been discussing now the EFI boot prospect as a
complete alternative to this and avoiding adding
yet-another-boot-entry (TM) to x86. That deserves a full discussion on
its own so will send notes on that next on a separate new thread.

>> >> Your perceived problem with multiple entry points is not a problem with
>> >> multiple entry points; It is a problem with multiple different paths
>> >> performing the same initialisation.
>> > Its actually more of an issue with the lack of strong general semantics
>> > available for different hypervisors and guest types and requirements for x86's
>> > init path. What you end up with as collateral is multiple entry points, and
>> > these can be sloppy and as you note can perform the same initialisation.
>> > Another issue is the inability to proactively ensure new x86 init code
>> > addresses different x86 requirements (cr4 shadow regression and Kasan still
>> > being broken on Xen are two examples) and it just so happens that the lack of
>> > semantics for the different guest types required to be evaluated is one issue
>> > for x86.
>> >
>> > We can do better.
>>
>> Even with a perfect startup() routine which caters for all runtime
>> usecases, you cannot avoid having multiple entry stubs to cater for the
>> different ways the binary might be started.
>>
>> Unless you are volunteering to write a single stub which can first
>> evaluate whether it is in 16/32/64bit mode, then create a safe stack to
>> use, then evaluate how it was started (multiboot, legacy BIOS, EFI,
>> etc.) and turn all this information into a zeropage.
>>
>> I don't know that would be possible, but the point is moot as it
>> definitely wouldn't be maintainable if it were possible.
>
> I think some folks have hope at least some of it might be. I can't do this,
> otherwise I would have done it already. Given my review of the commit logs on
> different entry points, and code I do think its sensible to desire this to help
> with semantics on startup and this should in turn help duplication, bugs, but I
> obviously do not doubt its difficulty.

It would seem streamlining off of an EFI boot entry could boot strap
this effort. To this end I'll be sending out a new thread in which we
review that a bit more.

> Its at least sensible in my mind to strive towards the best possible semantics
> and code sharing from x86-64 bit onwards and if I can help with that I'll do
> what I can.

Me and Andy Lutomirski have been recently fending off some ill
conceived virtualization semantics in the kernel, that work seems to
have proven that the lack of appropriate semantics has only incurred
hacks on the kernel which can be replaced by properly thought out
solutions -- which ultimately should help with other guest types, and
avoid further virtualization hackery in the kernel. If we need to
extend semantics for another guest type I'd like for us to identify
that now and address it.

  Luis

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