回复：[edk2-devel] 转发：[edk2-devel] [PATCH V2 0/2] Initial commit for RISC-V Qemu-based Server

["Fu Siyuan via groups.io" <fusiyuan.fsy=alibaba-inc.com@groups.io>]

Hi Evan,

As a newcomer RISC-V server BIOS engineer (not new UEFI engineer) I hold the same opinion with Sunil - this Readme file contains too many details and make me confuse where to start. It's better to provide only the necessary content to start the work, like how to setup the build env, execute code, where to report/discuss issues, also the links to illustrate design and WIP tasks. 

For example the "Appendix 7.1 Building and running based on BRS environment" - I think this section should be the beginning of this doc, may be just after target audience and prerequisite knowledge. Also it's too heavy to use BRS test as a start, may be just boot to a simple kernel or even EFI shell, so people could easily check if their build environment is correct, then we can move to more complex case like how to enable the network stack (section 3.2.3), replace OS image or run BRS test suite.

I also have some questions as below:

> Table 1 Server SOC Requirement
Is this table a list of QEMU support status/plan of RISC-V Server SOC spec, or this RISC-V QEMU server platform status/plan?

> Figuire 1 RISC-V Platform EDK2 Firmware Enabling Philosophy
Is there a guide document to explain what's the required "Minimal changes" to enable a real server platform based on this QEMU reference, like which libraries/drivers need to be replaced by real hardware solution?

> It is essential to emphasize that RiscVVirt adopts a separate Flash Descriptor (FD) approach for firmware code and Variables. The advantage is clear as it allows for the protection of the firmware code by setting it as read-only, while conferring write permissions exclusively to the Variable FD, effectively ensuring the security of the firmware. 
It seems to me that the read-only FD in QEMU virtualized the ROM in real hardware, and the variable FD acts as a normal flash, that any execution mode can write to it. However there are security features in EDK2 (like auth variable) which require the variable storage should only be updated by more privileged code after some kinds of authentication, like x86 SMM or ARM TZ. Is there a similar security architecture in RISC-V, and is it possible to virtualize such flash in RISC-V QEMU server?

> In the upcoming server platform solution, we will continue to adopt a similar approach as RiscVVirt. However, there is a slight difference in the treatment of the Variable FD.
What's the "slight difference" here in server platform solution, can we provide a brief explanation, or a link to any material if it has been discussed somewhere else?

Best Regards,
Fu Siyuan

------------------------------------------------------------------
发件人：Sunil V L <sunilvl@ventanamicro.com>
发送时间：2024年7月10日(星期三) 22:33
收件人：devel<devel@edk2.groups.io>; "evan.chai"<evan.chai@linux.alibaba.com>
主　题：Re: [edk2-devel] 转发：[edk2-devel] [PATCH V2 0/2] Initial commit for RISC-V Qemu-based Server


Hi Evan,

On Wed, Jul 10, 2024 at 02:14:21AM -0700, EvanChai via groups.io wrote:
> Hi Sunil,
> I just saw two comments below.
> 'These images are generic. I don't think we need to have a copy here. Ifyou need to refer to this in any documentation, please add the link tooriginal image/document.'
> ‘It is better to split these documentation changes to a separate commit.’
> 
Oh OK. 

At high level, here is my feedback.

1) It is wonderful that you have added lot of details including design
of qemu, todo etc. However, I think it is better to keep Readme simple
and provide a reference to RISE wiki page where you can add all these
details. That way, we can avoid having stale data in Readme or need to
do several patches for updates. Better to keep readme with just build
and test instructions and a link to more details. For example, adding
qemu design (ex: memory map) in edk2 readme. Every time qemu design
changes, the edk2 readme becomes stale and keeping them in sync may
not be productive.

2) Please split documentation changes (readme) and platform changes (dsc
etc) to separate commits.

3) In the latest series, I see you have 2 commits where first commit
adds .inc file and in the next commit itself it gets removed. I see no
reason to do so.

4) Why would .inc files cause fragmentation? Rather, I think a common
.inc (qemu and real servers) will reduce the effort and copying same for
several platforms.

5) I have few more comments on the contents of readme as well. But if it
can be moved to wiki, we can discuss and correct there.

> BTW, the only uploaded picture comes from my presentation on the RV server platform proposal. It doesn't have an online source because I drew it myself. Do you have any recommended places where I can upload it? Then we can just reference its link in the README.
> 
My recommendation is to keep them in RISE wiki for now.

Thanks,
Sunil





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119902): https://edk2.groups.io/g/devel/message/119902
Mute This Topic: https://groups.io/mt/107166955/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-