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 21C4C21B02822 for ; Thu, 13 Sep 2018 03:36:32 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id h3-v6so7139478ita.2 for ; Thu, 13 Sep 2018 03:36:32 -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=d0IVcuwVL2KDN1sYknQddUf6BkHYMy/yvhrx1vm/6q0=; b=eXCMs5Z3XcHJ3/o9s8ru8I76uaS/+em/Lwo/TDB5Ao87Me/sDj4CPfxuwojBnC119K tjkbeGID/FzTCOH4nHUUtX2VbIIVMrFoZMrwTC/2sIbnCBFvR1lCnyUaDSVUpSa82LFs nuZ1pYvK0+9B/qUTVYHDNsBSY013Hae3BU2v8= 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=d0IVcuwVL2KDN1sYknQddUf6BkHYMy/yvhrx1vm/6q0=; b=U6f+w6KX+wwkT5SUY1ivga6uV2ahgydNKMB1/qwsT460mozYr3rGKX+HjP24VNvtkT wV9mZhMHEgqLTHLQZqYfo2Zi5mnHNuViQvf2exU3szw0ym7OI3XfNQriKgML087ZJM8E jus9C0ZCqxO6XSE5InlU6ndI4Qdws83fAmS6hnzW/cr/2xE43ZzE5NSVZwUbfYqsNw56 SYb8zlA0950QGMs0HVXduT8GtbxylSN+xkQZlO0e2vVLLbTGoWj+qiMeMmZ2HYurT57E UUmHyfH6xjh/PUkb84q9OkLov7YZgH3L5n6End1QV74lXB9TJjfnLfUwi9zfW+hhtc1S ibcQ== X-Gm-Message-State: APzg51Cs5HYufqXUVqEq773Rmyeu3hvrdAXVsy1Bl1sGuaanJdoeSOni upbyV6svTckljXrXXObT+NZHfJmhBo4yEdE2WAlPTw== X-Google-Smtp-Source: ANB0VdbPmIxR2dy5vuHFMrvVIevMMT7H1O7LeoAnGpzKvfgOXPEvJNRc5zptURzbMMYOA2a1vo6DIH7x1DtOq9enpI4= X-Received: by 2002:a24:52cd:: with SMTP id d196-v6mr5512524itb.58.1536834991862; Thu, 13 Sep 2018 03:36:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2848:0:0:0:0:0 with HTTP; Thu, 13 Sep 2018 03:36:31 -0700 (PDT) In-Reply-To: References: <20180912132151.4258-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Thu, 13 Sep 2018 12:36:31 +0200 Message-ID: To: "Kinney, Michael D" Cc: "edk2-devel@lists.01.org" , "agraf@suse.de" , "Zimmer, Vincent" , "Richardson, Brian" , Andrew Fish , Laszlo Ersek , Leif Lindholm , "Zeng, Star" , "Dong, Eric" , "Ni, Ruiyu" 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: Thu, 13 Sep 2018 10:36:33 -0000 Content-Type: text/plain; charset="UTF-8" On 12 September 2018 at 17:10, Kinney, Michael D wrote: > Ard, > > I think there may be a lot of assumptions in this > proposal that are not documented. > > I do not see any description of how an image is > started or how calls between native code and emulated > code are handled. > It is the job of the implementation of the emulator to use the information provided to it at registration time to ensure that calls to its entry point are handled. One way could be to remap the code region non-exec (which is what X86EmulatorPkg does) and hook the exceptions that result when calling into the non-native code. Another approach could be to do binary translation at load time, hook the PE/COFF entry point in the header to point to a load stub etc etc. These are all implementation details of the emulator, and so I am not sure what exactly we need to document at the protocol level. Does the above paragraph capture more or less what you mean? > Also, are multiple emulated CPUs supported? It looks > like there can only be one instance of this new protocol. > Yes. I am not sure what the added value is of having multiple emulators. Do you have anything in mind? In any case, the singleton protocol could be implemented by a wrapper driver that encapsulates this multiple dispatch functionality. I don't think it makes sense to duplicate logic for that purpose in the various places that I touch in this series, and so it shouldn't affect the protocol prototypes. > Can you please provide more detailed comments for the > functions in the new protocol and document the assumptions > and known limitation in the header? > Of course. But note that they are fairly simple prototypes that don't impose any limitations by themselves, other than that you should call RegisterImage() before attempting to invoke its entry point. > From one perspective, EBC is an emulated instruction set. > Would it make sense to have EBC be one of the emulated > CPU types that can be plugged in? > We could definitely abstract away the EBC handling in the DXE core to be routed via this protocol, but that would make the changes more intrusive. I could look into making those changes on top if there is interest.