From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by mx.groups.io with SMTP id smtpd.web08.37423.1665982392636257960 for ; Sun, 16 Oct 2022 21:53:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ventanamicro.com header.s=google header.b=o5kwgUZx; spf=pass (domain: ventanamicro.com, ip: 209.85.214.181, mailfrom: sunilvl@ventanamicro.com) Received: by mail-pl1-f181.google.com with SMTP id n7so9764637plp.1 for ; Sun, 16 Oct 2022 21:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RFHwacFV23c5/Lc1KKW6d3dohvaX2AYgUdocyyPo4BM=; b=o5kwgUZxbLefslEX/xzGJm+E7kylPtKrOSPEt3h5HTaaoubaa6zcsF9Az0WW7hcqdF ecYcbCEShJiez3oTFY4MHmaRVdCND3OE9676jKZWdLznKHEXUHD1EbDBt9IRl7n62GYz NmwQvedL+/kggorbFLtP01XcDBMOl1qalwELTD9HSk813NtjhvebonNfCjap16AN7MNL ArvABZQQzmAxdD81UVmoNQQEQh0Jm09qvA+QeSAXXqk6kNHK5aoxSYqIV8t9yBEiC4oT xrzqtkQIcqCGa1lWJT7pdkBKQgadUxu2sNM3qDGC2VphR4cwLRAZwG1wnybWc7MF4Z+x /KQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RFHwacFV23c5/Lc1KKW6d3dohvaX2AYgUdocyyPo4BM=; b=8QmoOqyLQgKCXgPEFN+AuIjdojGMsXlEVwhjKd80k5ZnWUbF3+tbrsPlrEdv3dVVx/ iDQCVNdK+pqC869s+yQ+91kDJf9FoXBxWsoFpgi0Nae0J/Jb+gO2wNlo7KtaZHuZxSRB +8/xmAoRk+utoiiB5E536eurT5ffpkCFb8FdRVvEXMokAXC4n7zzvzZneS+HWQaVOQK7 bfZXMtO414yeKAwyAVk0BhwFJIlwjwhzJpkYgB+NDSUcK8mQTsNdMYq03bLd/cUDsWYU AdEkCuNXMZC+JgYEVH1N3rtA3KnnCyyOGSSbX5plKmACdCMQ631wl497EaEE5O/02xoZ bDZQ== X-Gm-Message-State: ACrzQf1MD/ULXKDZfyVo8oWhE6LQLaPKXTe3Qz+VRKuwof+rkl1WMOxY LAfzPK7xvZUK4PtTbXQu+lfkGQ== X-Google-Smtp-Source: AMsMyM7xbbKR8OqR4JiEKUib4uHuv0+UDrFH75jdsyy0JO6iNguCTrRIm/+eNONGr2eylO0Cd1jUNg== X-Received: by 2002:a17:903:24e:b0:179:b755:b82f with SMTP id j14-20020a170903024e00b00179b755b82fmr9953366plh.34.1665982391939; Sun, 16 Oct 2022 21:53:11 -0700 (PDT) Return-Path: Received: from sunil-laptop ([49.206.13.138]) by smtp.gmail.com with ESMTPSA id m8-20020a170902db0800b0018157b415dbsm5601573plx.63.2022.10.16.21.53.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Oct 2022 21:53:11 -0700 (PDT) Date: Mon, 17 Oct 2022 10:23:02 +0530 From: "Sunil V L" To: "Chang, Abner" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann , "Singh, Brijesh" , Erdem Aktas , James Bottomley , Min Xu , "Lendacky, Thomas" , Daniel Schaefer Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V4 10/34] OvmfPkg/Sec: Add RISC-V support Message-ID: References: <20221014164836.1513036-1-sunilvl@ventanamicro.com> <20221014164836.1513036-11-sunilvl@ventanamicro.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Oct 15, 2022 at 03:50:02PM +0000, Chang, Abner wrote: > [AMD Official Use Only - General] > > Hi Sunil, this is my comment for both 9/34 and 10/34. > The original RISC-V SecCore implementation can be used by RiscVVirt and the RISC-V platforms under edk2-platform. So my plan back to half year ago was to have SecCore under UefiCpuPkg, that would be Riscv64SecCore because current the SecCore under UeficpuPkg is hard to be leveraged. With this, one RISC-V SecCore driver can be used by RiscVVirt and RISC-V platforms. Of course we have to move some Pcds to under PCD Riscv64 arch section in UEfiCpuPkg.dec. Even through having PcdRiscVDbtFvBase(Size) for Riscv64 in UefiCpuPkg.dec makes sense to me because Device Tree is part of RISC-V processor initialization. > Could you please take some time having this change? I think that is doable and also an ideal implementation for RISC-V. > Hi Abner, Having SEC as part of SecCoreNative in UefiCpuPkg was my original proposal when I had sent the RFC series to discuss in the design meeting. But if you remember, Mike provided 2 major feedbacks in the meeting which made me to move to OvmfPkg. 1) We should not add FDF related PCD variables in common packges like UefiCpuPkg/MdeModulePkg. OvmfPkg is the only package (ofcourse ArmVirtPkg also currently) which is an exception to this since it actually has platform implementation useful for CI coverage. 2) Avoid new circular dependencies. We will have to use EmbeddedPkg in UefiCpuPkg/MdeModulePkg for FDT if we use SecCore in UefiCpuPkg. It made sense to me and OvmfPkg already had the required PCD variables and modules. Also, qemu virt can support different features (boot from flash vs memory, number of flash devices etc) compared to real platforms. So, it will be hard to use the same design for both virt machine and real platforms. The original SecCore in edk2-platforms can be continued to be used by real platforms. Like Ray suggested, I plan to look at MinPlatformPkg design for real platforms in edk2-platforms repo which will make the design flexible. Thanks Sunil > Thanks > Abner