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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965197Ab3FTJPs (ORCPT ); Thu, 20 Jun 2013 05:15:48 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:51957 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964817Ab3FTJPp (ORCPT ); Thu, 20 Jun 2013 05:15:45 -0400 Date: Thu, 20 Jun 2013 10:15:37 +0100 From: Matthew Garrett To: Ingo Molnar Cc: Borislav Petkov , Linux EFI , Matt Fleming , X86 ML , LKML , Borislav Petkov Subject: Re: [PATCH -v2 0/4] EFI 1:1 mapping 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130620091321.GB6811@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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? 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 case where I'd expect there to be an issue, since they only started supporting booting Windows via UEFI on very recent systems. However, unless they're actually sniffing the page tables on UEFI entry, I can't see any way that this could break things… -- Matthew Garrett | mjg59@srcf.ucam.org