From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.6 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5254C433DF for ; Wed, 19 Aug 2020 07:21:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B9B1B20738 for ; Wed, 19 Aug 2020 07:21:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727070AbgHSHVL (ORCPT ); Wed, 19 Aug 2020 03:21:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:54202 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727849AbgHSHVE (ORCPT ); Wed, 19 Aug 2020 03:21:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 804ADB5C3; Wed, 19 Aug 2020 07:21:26 +0000 (UTC) Subject: Re: [PATCH] efi: discover ESRT table on Xen PV too To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= , Ard Biesheuvel , linux-efi@vger.kernel.org, norbert.kaminski@3mdeb.com, xen-devel@lists.xenproject.org, open list References: <20200816001949.595424-1-marmarek@invisiblethingslab.com> <20200817090013.GN975@Air-de-Roger> <20200818120135.GK1679@mail-itl> <20200818124710.GK828@Air-de-Roger> From: Jan Beulich Message-ID: Date: Wed, 19 Aug 2020 09:20:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200818124710.GK828@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.08.2020 14:47, Roger Pau Monné wrote: > On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote: >> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote: >>> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote: >>>> In case of Xen PV dom0, Xen passes along info about system tables (see >>>> arch/x86/xen/efi.c), but not the memory map from EFI. >>> >>> I think that's because the memory map returned by >>> XENMEM_machine_memory_map is in e820 form, and doesn't contain the >>> required information about the EFI regions due to the translation done >>> by efi_arch_process_memory_map in Xen? >> >> Yes, I think so. >> >>>> This makes sense >>>> as it is Xen responsible for managing physical memory address space. >>>> In this case, it doesn't make sense to condition using ESRT table on >>>> availability of EFI memory map, as it isn't Linux kernel responsible for >>>> it. >>> >>> PV dom0 is kind of special in that regard as it can create mappings to >>> (almost) any MMIO regions, and hence can change it's memory map >>> substantially. >> >> Do you mean PV dom0 should receive full EFI memory map? Jan already >> objected this as it would be a layering violation. > > dom0 is already capable of getting the native e820 memory map using > XENMEM_machine_memory_map, I'm not sure why allowing to return the > memory map in EFI form would be any different (or a layering > violation in the PV dom0 case). The EFI memory map exposes more information than the E820 one, and this extra information should remain private to Xen if at all possible. I actually think that exposing the raw E820 map was a layering violation, too. Instead hypercalls should have been added for the specific legitimate uses that Dom0 may have for the memmap. Jan