From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "Matt Fleming" <matt@codeblueprint.co.uk>,
jeffm@suse.com, "Michael Chang" <MChang@suse.com>,
"Julien Grall" <julien.grall@arm.com>,
"Jan Beulich" <JBeulich@suse.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Daniel Kiper" <daniel.kiper@oracle.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Takashi Iwai" <tiwai@suse.de>,
"Vojtěch Pavlík" <vojtech@suse.cz>, "Gary Lin" <GLin@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>,
"Jeffrey Cheung" <JCheung@suse.com>,
"Juergen Gross" <jgross@suse.com>,
"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
"Jim Fehlig" <jfehlig@suse.com>,
"George Dunlap" <george.dunlap@citrix.com>,
joeyli <jlee@suse.com>, "Borislav Petkov" <bp@alien8.de>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Charles Arndol" <carnold@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: HVMLite / PVHv2 - using x86 EFI boot entry
Date: Thu, 14 Apr 2016 22:14:22 -0400 [thread overview]
Message-ID: <20160415021422.GB6956@localhost.localdomain> (raw)
In-Reply-To: <20160414211201.GS1990@wotan.suse.de>
On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote:
> > > 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.
>
> Today Linux is KVM stupid for early boot code. I've pointed this out
-EPARSE?
> before, but again, there has been no reason found to need this. Perhaps
> for HVMLite we won't need this...
Are you talking about kvmtools? Which BTW are similar to how HVMLite
would expose the platform.
>
> > There is no hope for the pv_ops to fix that.
>
> Actually I beg to differ. See my patches and ongoing work.
I meant in terms of semantics. As in I cannot see some of
those pv-ops to have the same semantics as baremetal. For example
set_pte is simple on x86 (movq $<some value>, <memory address>).
While on Xen PV it is a potential batching hypercall with
lookup in an P2M table, then perhaps a sidelong look at
the M2P, then maybe the M2P override.
>
> > 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).
>
> HVMLite may still use PV drivers for some things, its not super
> obvious to me that low level semantics will not be needed yet.
PV drivers are very different from low-level semantics.
And it will have to use them.
Maybe it is easier to think of this in terms of kvmtool - it
is pretty much how this would work - but instead of VirtIO
drivers you would be using the Xen PV drivers (thought one
could also use VirtIO ones if you wanted).
>
> > 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.
>
> What other OSes do is something to consider but if they don't
> do it because they are slacking in one domain should by no means
> be a reason to not evaluate the long term possible gains.
> Specially if we have reasons to believe more architectures will
> consider it and standardize on it.
>
> It'd be silly not to take this a bit more seriously.
Complexity vs simplicity.
>
> > Hard part - if the bootparams change then have to
> > rev up the code in there. May be out of sync
> > with Linux bootparams.
>
> If we are going to ultimately standardize on EFI boot for new
> hardware it'd be rather silly to extend the boot params further.
Whoa there... Have you spoken to hpa,tglrx about this?
>
> > 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.
>
> Right -- so one question to ask here is what other uses are there
> for this outside of say HVMLite. You mentioned Multiboot so far.
>
> > 3). And there is the discussion on man-power to make this
> > happen.
>
> Sure.
>
> > 4). Lastly which one is simpler and involves less code so
> > that there is a less chance of bitrot.
>
> Indeed.
>
> You also forgot the tie-in between dead-code and semantics but
Wait, I just spoke about CPU semantics?! Which semantics
are you talking about?
> that clearly is not on your mind. But I'd say this is a good
> summary.
I put 'dead code' in the same realm as device drivers work.
And they seem to always have some issue or another.
Or maybe I getting unlucky and getting copied on those bugs.
>
> Luis
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-15 2:15 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160406024027.GX1990@wotan.suse.de>
2016-04-06 9:40 ` HVMLite / PVHv2 - using x86 EFI boot entry David Vrabel
2016-04-06 11:07 ` George Dunlap
2016-04-06 11:11 ` Daniel Kiper
[not found] ` <CAFLBxZbRjB6QWH5GbG6osCXat9NQVUAyDYrAMrdALbCofpX3Dg@mail.gmail.com>
2016-04-06 15:02 ` Matt Fleming
2016-04-07 18:51 ` Luis R. Rodriguez
[not found] ` <20160406150240.GO2701@codeblueprint.co.uk>
2016-04-06 16:05 ` Konrad Rzeszutek Wilk
2016-04-06 16:23 ` Konrad Rzeszutek Wilk
2016-04-08 21:53 ` Luis R. Rodriguez
2016-04-13 10:03 ` Roger Pau Monné
[not found] ` <20160413100312.647eocdtbmak4btk@mac>
2016-04-13 10:21 ` Matt Fleming
[not found] ` <20160407185148.GL1990@wotan.suse.de>
2016-04-08 14:16 ` George Dunlap
[not found] ` <5707BD2E.20204@citrix.com>
2016-04-08 21:58 ` Luis R. Rodriguez
[not found] ` <20160408215854.GU1990@wotan.suse.de>
2016-04-12 22:12 ` Luis R. Rodriguez
2016-04-13 9:54 ` Roger Pau Monné
[not found] ` <20160412221225.GN1990@wotan.suse.de>
2016-04-13 10:05 ` George Dunlap
2016-04-13 10:25 ` Roger Pau Monné
[not found] ` <CAFLBxZbiGppNad=Z6-fLgx89O0yAFrSyARTCwv=vHBR3zJ=NsA@mail.gmail.com>
2016-04-13 18:54 ` Luis R. Rodriguez
[not found] ` <20160413185451.GY1990@wotan.suse.de>
2016-04-14 9:42 ` George Dunlap
[not found] ` <570F65F7.5050108@citrix.com>
2016-04-14 19:59 ` Luis R. Rodriguez
[not found] ` <20160413102156.b4qwhwbqvnnpmxgw@mac>
2016-04-13 19:10 ` Luis R. Rodriguez
[not found] ` <20160413095428.5mcbrimvc6vxffcw@mac>
2016-04-13 18:50 ` Luis R. Rodriguez
[not found] ` <20160413185010.GX1990@wotan.suse.de>
2016-04-13 19:02 ` Konrad Rzeszutek Wilk
2016-04-13 19:14 ` Luis R. Rodriguez
[not found] ` <20160413191408.GA1990@wotan.suse.de>
2016-04-13 19:22 ` Konrad Rzeszutek Wilk
2016-04-13 20:01 ` Luis R. Rodriguez
[not found] ` <20160413200118.GC1990@wotan.suse.de>
2016-04-13 20:11 ` Konrad Rzeszutek Wilk
2016-04-13 20:35 ` Luis R. Rodriguez
[not found] ` <CAB=NE6VdTB1Bc=c0oCd_tTHpwwkQcxhnOFdcLfck2jX=JjuOAQ@mail.gmail.com>
2016-04-13 20:48 ` Konrad Rzeszutek Wilk
2016-04-14 10:13 ` George Dunlap
2016-04-13 15:44 ` George Dunlap
[not found] ` <CAFLBxZbJ4QyJQ1-ZuXg_Q-9YNXnWzDyPNp4SX=d9g0DS8mJKaw@mail.gmail.com>
2016-04-13 19:52 ` Luis R. Rodriguez
[not found] ` <20160413195257.GB1990@wotan.suse.de>
2016-04-14 9:53 ` George Dunlap
[not found] ` <570F68AB.2040400@citrix.com>
2016-04-14 19:44 ` Luis R. Rodriguez
[not found] ` <20160414194408.GP1990@wotan.suse.de>
2016-04-14 20:38 ` Konrad Rzeszutek Wilk
[not found] ` <20160414203847.GB21657@localhost.localdomain>
2016-04-14 21:12 ` Luis R. Rodriguez
[not found] ` <20160414211201.GS1990@wotan.suse.de>
2016-04-15 2:14 ` Konrad Rzeszutek Wilk [this message]
2016-04-15 5:50 ` Juergen Gross
2016-04-15 9:59 ` George Dunlap
[not found] ` <57108121.1070307@suse.com>
2016-04-15 15:24 ` Luis R. Rodriguez
[not found] ` <5710BB74.2060409@citrix.com>
2016-04-15 15:30 ` Luis R. Rodriguez
[not found] ` <20160415153028.GX1990@wotan.suse.de>
2016-04-15 16:03 ` George Dunlap
[not found] ` <571110BB.2000408@citrix.com>
2016-04-15 17:17 ` Luis R. Rodriguez
[not found] ` <5704D978.1050101@citrix.com>
2016-04-08 20:40 ` Luis R. Rodriguez
[not found] ` <20160408204032.GR1990@wotan.suse.de>
2016-04-11 5:12 ` Juergen Gross
[not found] ` <570B3228.90400@suse.com>
2016-04-12 21:02 ` Andy Lutomirski
[not found] ` <CALCETrXvGR3XKJf5Ab_ZPc-iuNuzR8AzLpRBciemKz4r0vSrGA@mail.gmail.com>
2016-04-13 9:02 ` Roger Pau Monné
[not found] ` <20160413090202.bg2vfdl3iol7eedv@mac>
2016-04-13 10:15 ` Matt Fleming
[not found] ` <20160413101515.GJ2829@codeblueprint.co.uk>
2016-04-13 10:40 ` Matt Fleming
2016-04-13 11:12 ` George Dunlap
2016-04-13 11:59 ` Roger Pau Monné
[not found] ` <20160413115846.hyt4lg24rfkenbxu@mac>
2016-04-15 22:53 ` Matt Fleming
2016-04-13 18:29 ` Luis R. Rodriguez
[not found] ` <20160413182951.GW1990@wotan.suse.de>
2016-04-13 18:56 ` Konrad Rzeszutek Wilk
2016-04-13 20:40 ` Luis R. Rodriguez
[not found] ` <20160413204055.GD1990@wotan.suse.de>
2016-04-13 21:08 ` Konrad Rzeszutek Wilk
2016-04-13 22:23 ` Luis R. Rodriguez
[not found] ` <20160413222317.GH1990@wotan.suse.de>
2016-04-14 1:01 ` Konrad Rzeszutek Wilk
[not found] ` <20160414010131.GA21510@localhost.localdomain>
2016-04-14 18:40 ` Luis R. Rodriguez
[not found] ` <20160414184048.GM1990@wotan.suse.de>
2016-04-14 19:56 ` Konrad Rzeszutek Wilk
2016-04-14 20:56 ` Luis R. Rodriguez
[not found] ` <20160414205619.GR1990@wotan.suse.de>
2016-04-15 2:02 ` Konrad Rzeszutek Wilk
2016-04-15 10:06 ` Julien Grall
[not found] ` <5710BD0B.2070306@arm.com>
2016-04-15 14:55 ` Luis R. Rodriguez
[not found] ` <CAB=NE6UDuLOnW8xfTcgCGSbJ1aS4TkkokcGdeJGHMBps0T9=Sg@mail.gmail.com>
2016-04-15 18:44 ` Stefano Stabellini
[not found] ` <20160415020246.GA6956@localhost.localdomain>
2016-04-15 17:08 ` Luis R. Rodriguez
[not found] ` <20160406111130.GG3489@olila.local.net-space.pl>
2016-04-07 19:12 ` Luis R. Rodriguez
2016-04-09 17:02 ` Luis R. Rodriguez
2016-04-06 2:40 Luis R. Rodriguez
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=20160415021422.GB6956@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=GLin@suse.com \
--cc=JBeulich@suse.com \
--cc=JCheung@suse.com \
--cc=MChang@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=carnold@suse.com \
--cc=daniel.kiper@oracle.com \
--cc=george.dunlap@citrix.com \
--cc=hpa@zytor.com \
--cc=jeffm@suse.com \
--cc=jfehlig@suse.com \
--cc=jgross@suse.com \
--cc=jlee@suse.com \
--cc=julien.grall@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mcgrof@kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tiwai@suse.de \
--cc=vojtech@suse.cz \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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).