From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::241; helo=mail-it0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A5D9121962301 for ; Sat, 15 Sep 2018 06:28:11 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id j198-v6so7072735ita.0 for ; Sat, 15 Sep 2018 06:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=afJxKHT2HM6qln28T2F7ZiFNn1ug7xK3rYGi319fE+U=; b=K3gP8Pk9PO8udeWmc2E21+U2FzuS/saajKffXeOj2HKMRb+htRbvEUssJkbLvVcrs9 LoEDg7MzzrnFmGrWlyfRxW+sed2zNGPxB2vIulr3z5BkG7K9eYGfG1ba3NBWEADwnt5V Vi+7n62CUs9Rkfll4Npl0kvx5dtkrmcGwtheU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=afJxKHT2HM6qln28T2F7ZiFNn1ug7xK3rYGi319fE+U=; b=eK2MnZA30o3NHUy2dESSt+5ynM5/iJwzCJZpgGtBHgi4hHkOOc/pUa0V24faWknl0j sDjGB/bEWh9D/gHTNWPC4pr12rJTewynFxaNizQBRKAMKPOj2Uh0lLbtMbBDA9L1I0TP Kf652m6AjXhSqbIL/IseWGtwHsRj4kBObOeFL6Q+rl9sYfjAyR4yp7rCReZy+AiCLlUD 8zVvJNcvkfv3gUpSm2GOixyjFkp1gzhxXQU3w+U4sOYBHNKApr7SfnO+WmUTGXsucDUH FoKOpHmcfRimMnDftQPQ55eUwH9jLcxty1cdhgDJ956rd6W/7+77eo08xilQOQ3PT1dX 8BlQ== X-Gm-Message-State: APzg51CPiq+eoI1JdgKiPv6JRIJBimD2An5fqKgbC+cK9G7Tka7JgLBn guIgijHqKED0g1pgb82H+WJezrjcymI0si+uo0/UKA== X-Google-Smtp-Source: ANB0VdYsDEaJ1lJS8q01dRLS7Cix1xdjLdbsCKnq/ziTyFR/nS4vRB8nhSu2qHI7ng9sVAfkET01FpMZgXAzj1JTvwo= X-Received: by 2002:a24:52cd:: with SMTP id d196-v6mr6027790itb.58.1537018090076; Sat, 15 Sep 2018 06:28:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2848:0:0:0:0:0 with HTTP; Sat, 15 Sep 2018 06:28:09 -0700 (PDT) In-Reply-To: References: <20180912132151.4258-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Sat, 15 Sep 2018 15:28:09 +0200 Message-ID: To: "Kinney, Michael D" Cc: "Ni, Ruiyu" , "Zimmer, Vincent" , "Dong, Eric" , "edk2-devel@lists.01.org" , "agraf@suse.de" , Andrew Fish , "Richardson, Brian" , Laszlo Ersek , "Zeng, Star" Subject: Re: [PATCH 0/4] MdeModulePkg: add support for dispatching foreign arch PE/COFF images X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 13:28:11 -0000 Content-Type: text/plain; charset="UTF-8" On 13 September 2018 at 19:20, Kinney, Michael D wrote: > Ard, > > I think there is a fundamental assumption that > the sizeof(UINTN) and size of pointers of > the native CPU are the same as the emulated CPU. > If that is not the case, then I would like to see > more details. Otherwise that is a significant > restriction that needs to be clearly documented. > There is no such assumption. The PE/COFF emulator protocol is an abstract protocol that leaves it fully up to the implementation to decide whether it can support images of machine type X and image type Y. > Protocols that only allow a single instance need to > clearly document that assumption. > I will remove that restriction. > If we decide to treat EBC as an emulated CPU, then > we would want to support multiple instances of the > protocol. The updates to the DXE Core are a bit > confusing because it has separate handling of EBC > and emulated CPUs. I think it would make the DXE > Core logic simpler and easier to understand if they > were combined. > Yes, excellent idea, and it results in a nice cleanup as well > I asked about the startup case because if we do EBC, > then we may need more services in the protocol because > of the thunk code between native and EBC code. At the > time EBC was originally implemented, we did not have > paging enabled and the EBC interpreter work without > depending on a page fault handler. > > The way the protocol is currently defined, I believe it > fundamentally assumes paging is enabled. If paging is > not enabled, then the current protocol services are not > sufficient for any emulated CPU. Do we want this to work > for paging disabled cases? If not, another assumption > to clearly document. > The paging disabled case is interesting. Does the UEFI spec even permit running in DXE with paging disabled? In any case, I will send out a v2 as the basis for further discussion. We can also sit down and discuss it in Vancouver the coming week.