From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d41; helo=mail-io1-xd41.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 4D46821144D0D for ; Wed, 19 Sep 2018 13:43:51 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id q5-v6so5635168iop.3 for ; Wed, 19 Sep 2018 13:43:51 -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:content-transfer-encoding; bh=z1LspFYdbfTtjPUFkdrQ5FmTSsCq0boh58Lm91KFBWI=; b=A4x+eyzIjSwF4XXbY2IlkYg9c28dwOIFVhEogN2BRdMUaXYB7k1REpCQOhIXOpLLa/ xdA4ySLPRWXRnw1gwh8qNmB3xqfyM1Uok48CrvQ+PB0kOM8xSOzLgIJwQEGb+sJDJ5sN O6mMvSTjoDgSHQbzZoMiFpmtV+2+5GC/Men6w= 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:content-transfer-encoding; bh=z1LspFYdbfTtjPUFkdrQ5FmTSsCq0boh58Lm91KFBWI=; b=KRFDm5EIjsP8w50jQiZlnHBTsUcH+0kUikr3tHO+IjwYOuefrJsZYxN6YZiEJ6tRZb 7pQUav/towfQm8sMweR1moLoT1YoSCVaEe8DBAuaV4ahTsmnkoYfw87I75lpY5hsJBgv iO2/RF4OftJiehGig3m81SMWnWzN/hUiwIWXYM3hTqRfQgH9zrlfEeCxdpGwDyuk/nDf IM0uTIHmmrpAn+4p2dtEQvkrYxlwJb5aBCcK73ZXTffrT4q3uSYc2KTi7C+Gmqy7Wjv6 S75MpvtqO8mdbAJ21687ZQvFAY802WqALQ5ONoLRqNv4x8XpvSWRW+t12n9hcl6a2MFf WUVA== X-Gm-Message-State: APzg51Cwl9TgxWJCKtCSUPXnzKd6J58wJjgjQuGL0JkCK8ZnFI9AX/ve x4kUiNmUUd2mNtr5uZ+T7wXMmuOTX4swKvWOYv+5Xg== X-Google-Smtp-Source: ANB0VdbqQ8HQalFydEOfYarxTLmQtMwn1NwTrNaK7eJLxxu0+qgWuh/2iV2MHdHuC3gi7V3kk2H+P8VuKBph0hfqST4= X-Received: by 2002:a6b:be83:: with SMTP id o125-v6mr30399142iof.173.1537389831058; Wed, 19 Sep 2018 13:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2848:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 13:43:50 -0700 (PDT) In-Reply-To: <158F7824-8679-4121-9E7D-5C3593808909@apple.com> References: <20180912132151.4258-1-ard.biesheuvel@linaro.org> <158F7824-8679-4121-9E7D-5C3593808909@apple.com> From: Ard Biesheuvel Date: Wed, 19 Sep 2018 13:43:50 -0700 Message-ID: To: Andrew Fish Cc: Mike Kinney , "Ni, Ruiyu" , Vincent Zimmer , "Dong, Eric" , "edk2-devel@lists.01.org" , "agraf@suse.de" , "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: Wed, 19 Sep 2018 20:43:52 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 19 September 2018 at 12:35, Andrew Fish wrote: > > >> On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel = wrote: >> >> 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. >> > > Ard, > > Not knowing the size of UINTN or a pointer was very painful in terms of h= ow EBC worked. The compiler was forced to generate code for sizeof vs. reso= lving it at compile time. > Oh, I'm sure - but my point is that whether architecture X can be emulated on architecture Y and how is a limitation that affects some implementations of the protocol, but at the abstract level that we deal with in the core code, it is not a concern. >>> 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? > > Paging is a function of the processor binding in the UEFI spec. It is not= required for IA32. For X64 you have to have paging enable to enter long mo= de. On other processors you need to turn on paging to control the cache. So= I guess the no paging is likely more of a i386 issue? > Michael spotted yesterday that RISC-V mandates paging disabled, which is peculiar in itself. But again, whether a certain implementation of the protocol relies on paging or not is an implementation detail. >> >> 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. > > I'd suggest passing an EFI device path to IS_PECOFF_IMAGE_SUPPORTED. At s= ome point it might be useful for the emulator to know what device is being = emulated. > I guess you mean for which device we are loading a driver that relies on emulation? I guess that makes sense for option ROMs, which is the primary use case, so yes, I can add that. > For bonus points we could check IsPecoffImageSupported() prior to the nat= ive check. Never say never, some one may want to have emulator run on nativ= e images for debugging etc. > Peter brought this up as well - in some cases, you may want to sandbox X86 drivers running on X86 by running them on an emulator. If you think the overhead of performing this check for each image rather than only for images that have already been found to be for a foreign architecture is acceptables then I'm happy to change this. But we can easily do that later as well.