[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160414203847.GB21657@localhost.localdomain>
Date: Thu, 14 Apr 2016 16:38:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: George Dunlap <george.dunlap@...rix.com>,
Matt Fleming <matt@...eblueprint.co.uk>, jeffm@...e.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jim Fehlig <jfehlig@...e.com>, Jan Beulich <JBeulich@...e.com>,
"H. Peter Anvin" <hpa@...or.com>,
Daniel Kiper <daniel.kiper@...cle.com>,
the arch/x86 maintainers <x86@...nel.org>,
Takashi Iwai <tiwai@...e.de>,
Vojtěch Pavlík <vojtech@...e.cz>,
Gary Lin <GLin@...e.com>,
xen-devel <xen-devel@...ts.xenproject.org>,
Jeffrey Cheung <JCheung@...e.com>,
Charles Arndol <carnold@...e.com>,
Julien Grall <julien.grall@....com>,
Stefano Stabellini <stefano.stabellini@...citrix.com>,
joeyli <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Michael Chang <MChang@...e.com>,
Andy Lutomirski <luto@...capital.net>,
David Vrabel <david.vrabel@...rix.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Roger Pau Monné <roger.pau@...rix.com>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry
> This has nothing to do with dominance or anything nefarious, I'm asking
> simply for a full engineering evaluation of all possibilities, with
> the long term in mind. Not for now, but for hardware assumptions which
> are sensible 5 years from now.
There are two different things in my mind about this conversation:
1). semantics of low-level code wrapped around pvops. On baremetal
it is easy - just look at Intel and AMD SDM.
And this is exactly what running in HVM or HVMLite mode will do -
all those low-level operations will have the same exact semantic
as baremetal.
There is no hope for the pv_ops to fix that.
And I am pretty sure the HVMLite in 5 years will have no
trouble in this as it will be running in VMX mode (HVM).
2). Boot entry.
The semantics on Linux are well known - they are documented in
Documentation/x86/boot.txt.
HVMLite Linux guests have to somehow provide that.
And how it is done seems to be tied around:
a) Use existing boot paths - which means making some
extra stub code to call in those existing boot paths
(for example Xen could bundle with an GRUB2-alike
code to be run when booting Linux using that boot-path).
Or EFI (for a ton more code). Granted not all OSes
support those, so not very OS agnostic.
Hard part - if the bootparams change then have to
rev up the code in there. May be out of sync
with Linux bootparams.
b) Add another simpler boot entry point which has to copy
"some" strings from its format in bootparams.
So this part of the discussion does not fall in the
hardware assumptions. Intel SDM or AMD mention nothing about
boot loaders or how to boot an OS - that is all in realms
of how software talks to software.
3). And there is the discussion on man-power to make this
happen.
4). Lastly which one is simpler and involves less code so
that there is a less chance of bitrot.
Powered by blists - more mailing lists