From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] ARM VM System Sepcification
Date: Sat, 22 Mar 2014 20:19:52 -0700 [thread overview]
Message-ID: <20140323031952.GB30885@cbox> (raw)
In-Reply-To: <532D4505.1090603@redhat.com>
On Sat, Mar 22, 2014 at 09:08:37AM +0100, Paolo Bonzini wrote:
> Il 22/03/2014 03:29, Christoffer Dall ha scritto:
> >1. Simply mandate that VM implementations support persistent variables
> > for their UEFI implementation - with whatever constraints that may
> > put on higher level tools.
> >
> >2. Require that OSes shipped as part of compliant VM images make no
> > assumption that changes to the UEFI environment will be stored.
> >
> >I feel that option number two will break in all sorts of cases, just
> >like Grant stated above, and it is fundamentally not practical; if a
> >distribution ships Linux with a UEFI stub that expects to be able to do
> >something, distributions must modify Linux to conform to this spec. I
> >think imagining that this spec controls how UEFI support in Linux/Grub
> >is done in general would be overreaching. Additionally, Michael brought
> >up the fact that it would be non-UEFI compliant.
>
> OSes are already able to cope with loss of changes to UEFI
> environment are stored, because losing persistent variables is what
> happens if you copy an image to a new hard disk.
>
> Asking implementations for support of persistent variables is a good
> idea; however, independent of what is in the spec, OSes should not
> expect that users will enable that support---most of them won't.
>
OK, fair enough, mandating support for persistent variable storage may
be overreaching but at the same time I feel it is unlikely for this spec
to reach far enough that a generic UEFI Linux loader, for example,
actually follows it, and therefore explicitly mandating that guest OSes
must be completely portable in all that they do is a non-practical
constraint. That was the request that kicked this discussion off, and
what I was trygint to address.
-Christoffer
next prev parent reply other threads:[~2014-03-23 3:19 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 18:34 [RFC] ARM VM System Sepcification Christoffer Dall
[not found] ` < CACxGe6tjuytsYAn6Hadf0AK+REzHgRydgbHPafL8+Sdtd_tMUA@mail.gmail.com>
2014-02-26 19:27 ` Christopher Covington
2014-02-26 19:51 ` Christoffer Dall
2014-02-27 13:12 ` Christopher Covington
2014-02-27 16:02 ` Christoffer Dall
2014-03-01 15:41 ` Grant Likely
2014-02-26 19:55 ` Arnd Bergmann
2014-02-26 20:05 ` Christoffer Dall
2014-02-26 20:22 ` Arnd Bergmann
[not found] ` < CABGGisxHOVqLcG7hVAuAzdeic41KWSLLBSjQLSJQcjTXLhNCow@mail.gmail.com>
2014-02-26 21:56 ` Rob Herring
2014-02-26 22:21 ` Christoffer Dall
2014-02-27 7:30 ` Arnd Bergmann
2014-02-27 10:05 ` Paolo Bonzini
2014-03-01 19:12 ` Grant Likely
2014-02-27 9:35 ` Catalin Marinas
2014-02-26 20:19 ` Paolo Bonzini
2014-02-26 20:20 ` Peter Maydell
2014-02-26 21:48 ` Leif Lindholm
2014-02-26 22:25 ` Christoffer Dall
2014-03-01 19:20 ` Grant Likely
2014-02-27 12:31 ` Stefano Stabellini
2014-02-27 14:00 ` Arnd Bergmann
2014-02-27 14:24 ` Alexander Graf
2014-02-27 19:56 ` Arnd Bergmann
2014-02-28 0:05 ` Alexander Graf
2014-02-28 10:01 ` Arnd Bergmann
2014-02-28 14:44 ` Stefano Stabellini
2014-03-01 19:25 ` Grant Likely
2014-02-26 22:49 ` Rob Herring
2014-02-26 22:54 ` Peter Maydell
2014-02-26 23:08 ` Rob Herring
2014-02-26 23:14 ` Peter Maydell
2014-02-27 4:06 ` Nicolas Pitre
2014-02-27 11:36 ` Robie Basak
2014-02-26 23:13 ` Christopher Covington
2014-02-26 21:05 ` Michael Hudson-Doyle
2014-02-26 21:08 ` Christoffer Dall
2014-02-27 0:41 ` Blibbet
[not found] ` <CACxGe6tjuytsYAn6Hadf0AK+REzHgRydgbHPafL8+Sdtd_tMUA@mail.gmail.com>
2014-02-26 22:47 ` Christoffer Dall
2014-02-27 12:27 ` Stefano Stabellini
2014-03-01 19:54 ` Grant Likely
2014-03-02 9:29 ` Peter Maydell
2014-02-27 12:55 ` Peter Maydell
[not found] ` <20140226134251.0436294e@anubis.ausil.us>
[not found] ` <CAMJs5B9bCs8Oz2Zg4UK--A3H4AaZRPMwy7SpxYom-1--_=qhBQ@mail.gmail.com>
[not found] ` <20140226151536.58154704@anubis.ausil.us>
2014-02-27 17:34 ` Grant Likely
2014-03-01 15:27 ` Grant Likely
2014-03-03 1:13 ` Christoffer Dall
2014-03-06 8:52 ` Robie Basak
2014-03-06 9:46 ` Paolo Bonzini
2014-03-06 11:44 ` Laszlo Ersek
2014-03-06 12:04 ` Robie Basak
2014-03-06 12:10 ` Paolo Bonzini
2014-03-07 12:24 ` Grant Likely
[not found] ` < 20140322010206.GF25519@cbox>
2014-03-22 2:29 ` Christoffer Dall
2014-03-22 8:08 ` Paolo Bonzini
2014-03-23 3:19 ` Christoffer Dall [this message]
2014-03-23 3:29 ` Christoffer Dall
2014-03-24 9:57 ` Robie Basak
2014-03-24 10:46 ` Paolo Bonzini
2014-03-22 12:23 ` Grant Likely
2014-03-22 19:57 ` Paolo Bonzini
2014-03-22 22:35 ` Grant Likely
2014-03-22 23:38 ` Michael Casadevall
2014-03-23 0:33 ` Laszlo Ersek
2014-03-23 3:23 ` Christoffer Dall
2014-03-24 9:03 ` Ian Campbell
2014-03-24 10:41 ` Paolo Bonzini
2014-03-24 10:47 ` Ian Campbell
2014-03-24 12:13 ` Grant Likely
2014-03-24 12:16 ` Ian Campbell
2014-03-07 12:19 ` Grant Likely
2014-03-08 11:41 ` Michael Casadevall
2014-03-08 20:41 ` Laszlo Ersek
2014-03-07 12:09 ` Grant Likely
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=20140323031952.GB30885@cbox \
--to=christoffer.dall@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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).