If you cap it you are basically imposing a constraint on the firmware and may
not run properly (or at least have to turn off EFI runtime calls with all that
implies.) It might be good to have a sanity check but it needs to be pretty
generous.
Borislav Petkov b...@alien8.de wrote:
On Thu, Jun
On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote:
If you cap it you are basically imposing a constraint on the firmware
and may not run properly (or at least have to turn off EFI runtime
calls with all that implies.)
I don't want to cap EFI just for the fun of it but rather set a
* Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
And yet there are the Macs which reportedly cannot stomach this.
Do we know why?
I got lost in a maze of pointer arithmetic. There seems
On Thu, Jun 20, 2013 at 11:13:21AM +0200, Ingo Molnar wrote:
Cool - and supposedly this will work in a Mac environment as well? Would
be very nice to avoid fundamentally fragile system specific quirks for
something as fundamental as the EFI runtime memory mapping model ...
Apple is the only
On Thu, Jun 20, 2013 at 11:22:37AM +0200, Ingo Molnar wrote:
Cool - and supposedly this will work in a Mac environment as well? Would
be very nice to avoid fundamentally fragile system specific quirks for
something as fundamental as the EFI runtime memory mapping model ...
Apple is
On Thu, 20 Jun 2013, Matthew Garrett wrote:
This will break the Macs so maybe we can do
efi=no_11_map
so the Macs can still boot but use the 1:1 map by default.
I'm going to guess that there are more people running unmodified Linux
kernels on Macs than there are people using
On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote:
Can't we detect Macs from some of the UEFI strings at boot time and do
the right thing with the boot switch (which can be overriden from the
kernel command line if we get it wrong)?
Yes, and then our behaviour differs from
On Thu, 20 Jun 2013, Matthew Garrett wrote:
Can't we detect Macs from some of the UEFI strings at boot time and do
the right thing with the boot switch (which can be overriden from the
kernel command line if we get it wrong)?
Yes, and then our behaviour differs from Windows
How so?
On Thu, 2013-06-20 at 17:29 +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote:
Can't we detect Macs from some of the UEFI strings at boot time and do
the right thing with the boot switch (which can be overriden from the
kernel command line if we
On Thu, Jun 20, 2013 at 06:44:46PM +0200, Jiri Kosina wrote:
So if we properly detect those (and only those), we mimic Windows
completely, right?
No. Windows passes addresses above the phys/virt split to
SetVirtualAddressMap().
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe
On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote:
Unless you can think of the way out of this, we seem to have the stark
choice of behave like windows or allow kexec. For the server market,
kexec wins, so either we find a way not to have to make the choice or we
do something
On Thu, Jun 20, 2013 at 05:54:26PM +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote:
Unless you can think of the way out of this, we seem to have the stark
choice of behave like windows or allow kexec. For the server market,
kexec wins, so
On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote:
If we can detect the Macs, we can make this decision automatic. And
since no Mac boots windoze, a single DMI check of the sort if (Mac)
should suffice.
Yes, we can special-case Macs. But since our behaviour is then obviously
On Thu, Jun 20, 2013 at 06:12:10PM +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote:
If we can detect the Macs, we can make this decision automatic. And
since no Mac boots windoze, a single DMI check of the sort if (Mac)
should suffice.
Yes,
On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
Because Windows passes high addresses to SetVirtualAddressMap(), and
because if you can imagine firmware developers getting it wrong then
firmware developers will have got it wrong.
Can we reversely assume that if we'd used fixed
On Thu, Jun 20, 2013 at 07:17:31PM +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 08:14:45PM +0200, Borislav Petkov wrote:
On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
Because Windows passes high addresses to SetVirtualAddressMap(), and
because if you can
* Borislav Petkov b...@alien8.de wrote:
From: Borislav Petkov b...@suse.de
Hi all,
this is just a snapshot of the current state of affairs. The patchset
starts to boot successfully on real hardware now but we're far away from
the coverage we'd like to have before we even consider
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
I hope making it a weird boot option is not the end plan, there's
little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to emulate a Windows compatible EFI
environment better and is expected
* Borislav Petkov b...@alien8.de wrote:
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
I hope making it a weird boot option is not the end plan, there's
little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to emulate a Windows
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
Do we know why?
Well, according to mjg59 some Macs break if we don't give them a map
which uses high addresses.
I can imagine flipping the meaning of this option to be on by default
and efi=no_11_map to disable the 1:1 map for those
On Wed, Jun 19, 2013 at 03:02:25PM +0200, Borislav Petkov wrote:
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
I hope making it a weird boot option is not the end plan, there's
little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
And yet there are the Macs which reportedly cannot stomach this.
Do we know why?
I got lost in a maze of pointer arithmetic. There seems to be an
assumption that nvram writes should be
On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote:
But, as always, the only reliable thing to do here is to behave as
much like Windows as possible. Which means performing the 1:1 mapping
but maintaining the high mapping, and passing the high values via
SetVirtualAddressMap.
We
On Wed, Jun 19, 2013 at 06:18:27PM +0200, Borislav Petkov wrote:
On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote:
But, as always, the only reliable thing to do here is to behave as
much like Windows as possible. Which means performing the 1:1 mapping
but maintaining the high
On Wed, 2013-06-19 at 18:38 +0200, Borislav Petkov wrote:
On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote:
Yes, kexec needs a different solution.
No need. If we say, efi=use_11_map, the 1:1 map will be shoved down
SetVirtualAddressMap. Otherwise the high mappings.
On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote:
Ok, so it sounds like we want to *always* create both mappings but,
depending on what we want, to shove down SetVirtualAddressMap a
different set. And the 1:1 map will be the optional one which we give
SetVirtualAddressMap
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
And yet there are the Macs which reportedly cannot stomach this.
No, the reports are that if you use the 1:1 map as the primary address
on Macs the drivers fail... not that you can't have a 1:1 map.
-hpa
--
To unsubscribe from this
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote:
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
And yet there are the Macs which reportedly cannot stomach this.
No, the reports are that if you use the 1:1 map as the primary address
on Macs the drivers fail... not that you
On 06/19/2013 12:37 PM, Borislav Petkov wrote:
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote:
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
And yet there are the Macs which reportedly cannot stomach this.
No, the reports are that if you use the 1:1 map as the primary
On Wed, Jun 19, 2013 at 12:38:24PM -0500, H. Peter Anvin wrote:
I thought that was the plan?
Well, currently if I'm booted with efi=1:1_map I'm creating only the
1:1 mapping in -trampoline_pgd and switching the pagetable only then.
Otherwise, I'm using the high, ioremapped mappings - i.e., what
From: Borislav Petkov b...@suse.de
Hi all,
this is just a snapshot of the current state of affairs. The patchset
starts to boot successfully on real hardware now but we're far away from
the coverage we'd like to have before we even consider upstreaming it.
And yes, considering the sick f*ck EFI
31 matches
Mail list logo
