From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [PATCH -v2 0/4] EFI 1:1 mapping Date: Thu, 20 Jun 2013 10:15:37 +0100 Message-ID: <20130620091537.GA17159@srcf.ucam.org> References: <1371491416-11037-1-git-send-email-bp@alien8.de> <20130619125243.GD11209@gmail.com> <20130619130225.GA28311@pd.tnic> <20130619130434.GB24957@gmail.com> <20130619160804.GB27832@srcf.ucam.org> <20130620091321.GB6811@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20130620091321.GB6811-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ingo Molnar Cc: Borislav Petkov , Linux EFI , Matt Fleming , X86 ML , LKML , Borislav Petkov List-Id: linux-efi@vger.kernel.org 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? Wo= uld=20 > be very nice to avoid fundamentally fragile system specific quirks fo= r=20 > something as fundamental as the EFI runtime memory mapping model ... Apple is the only case where I'd expect there to be an issue, since the= y=20 only started supporting booting Windows via UEFI on very recent systems= =2E=20 However, unless they're actually sniffing the page tables on UEFI entry= ,=20 I can't see any way that this could break things=E2=80=A6 --=20 Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org