On 04/19/21 23:42, Brijesh Singh wrote:
>
> On 4/13/21 4:49 AM, Laszlo Ersek wrote:
>> On 04/12/21 16:52, Brijesh Singh wrote:
>>> Hi James and Laszlo,
>>>
>>> I was planning to work to add the support to reserve the Secrets and
>>> CPUID page in E820 map and then create the EFI configuration tabl
On 4/13/21 4:49 AM, Laszlo Ersek wrote:
> On 04/12/21 16:52, Brijesh Singh wrote:
>> Hi James and Laszlo,
>>
>> I was planning to work to add the support to reserve the Secrets and
>> CPUID page in E820 map and then create the EFI configuration table entry
>> for it so that guest OS can reach to
On 04/13/21 13:29, Brijesh Singh wrote:
>
> On 4/13/21 4:49 AM, Laszlo Ersek wrote:
>> On 04/12/21 16:52, Brijesh Singh wrote:
>>> Hi James and Laszlo,
>>>
>>> I was planning to work to add the support to reserve the Secrets and
>>> CPUID page in E820 map and then create the EFI configuration tabl
On 4/13/21 4:49 AM, Laszlo Ersek wrote:
> On 04/12/21 16:52, Brijesh Singh wrote:
>> Hi James and Laszlo,
>>
>> I was planning to work to add the support to reserve the Secrets and
>> CPUID page in E820 map and then create the EFI configuration table entry
>> for it so that guest OS can reach to
On 04/12/21 16:52, Brijesh Singh wrote:
> Hi James and Laszlo,
>
> I was planning to work to add the support to reserve the Secrets and
> CPUID page in E820 map and then create the EFI configuration table entry
> for it so that guest OS can reach to it. We have two packages
> "SecretDxe" and "Secr
Hi James and Laszlo,
I was planning to work to add the support to reserve the Secrets and
CPUID page in E820 map and then create the EFI configuration table entry
for it so that guest OS can reach to it. We have two packages
"SecretDxe" and "SecretPei" in OvmfPkg/AmdSev. Any issues if I use them
i
Min M
> Cc: devel@edk2.groups.io; thomas.lenda...@amd.com; j...@linux.ibm.com;
> Brijesh Singh ; Yao, Jiewen ;
> Justen, Jordan L ; Ard Biesheuvel
> ; Paolo Bonzini
> Subject: Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and
> Cpuid page for the SEV-SNP guest
>
Hi Min,
On 04/08/21 15:31, Lendacky, Thomas wrote:
> On 4/8/21 1:24 AM, Xu, Min M wrote:
>> Yes this is the root cause. TDX requires the startup mode to be 32-bit
>> protected mode while the legacy VM startup mode is 16-bit real mode.
>> Add more BITS directives can work round this. I have tried
On 04/08/21 15:31, Tom Lendacky wrote:
> On 4/8/21 1:24 AM, Xu, Min M wrote:
>> On Wednesday, April 7, 2021 11:03 PM, Laszlo wrote:
>>> On 04/07/21 02:44, James Bottomley wrote:
On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
> Hi, Laszlo
>
> For Intel TDX supported guest, all
On 4/8/21 1:24 AM, Xu, Min M wrote:
> On Wednesday, April 7, 2021 11:03 PM, Laszlo wrote:
>> On 04/07/21 02:44, James Bottomley wrote:
>>> On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
Hi, Laszlo
For Intel TDX supported guest, all processors start in 32-bit
protected mode,
On Wednesday, April 7, 2021 11:03 PM, Laszlo wrote:
> On 04/07/21 02:44, James Bottomley wrote:
> > On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
> >> Hi, Laszlo
> >>
> >> For Intel TDX supported guest, all processors start in 32-bit
> >> protected mode, while for Non-Td guest, it starts in 1
On April 7, 2021 9:23 PM, Laszlo wrote:
>
> On 04/07/21 02:21, Xu, Min M wrote:
>
> > Intel TDX also has metadata which is consumed by QEMU. We put the
> > metadata in a single file (TdxMetadata.asm) and put it at the end of
> ResetVectorVtf0.
> > Then a pointer is placed in a known location in R
On Wed, 2021-04-07 at 17:02 +0200, Laszlo Ersek wrote:
> On 04/07/21 02:44, James Bottomley wrote:
> > On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
> > > Hi, Laszlo
> > >
> > > For Intel TDX supported guest, all processors start in 32-bit
> > > protected mode, while for Non-Td guest, it sta
On 04/07/21 02:44, James Bottomley wrote:
> On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
>> Hi, Laszlo
>>
>> For Intel TDX supported guest, all processors start in 32-bit
>> protected
>> mode, while for Non-Td guest, it starts in 16-bit real mode. To make
>> the
>> ResetVector work on both T
On 04/07/21 15:22, Laszlo Ersek wrote:
> On 04/07/21 02:21, Xu, Min M wrote:
>
>> Intel TDX also has metadata which is consumed by QEMU. We put the metadata
>> in a single file (TdxMetadata.asm) and put it at the end of ResetVectorVtf0.
>> Then a pointer is placed in a known location in ResetVecto
On 04/07/21 02:21, Xu, Min M wrote:
> Intel TDX also has metadata which is consumed by QEMU. We put the metadata
> in a single file (TdxMetadata.asm) and put it at the end of ResetVectorVtf0.
> Then a pointer is placed in a known location in ResetVector.nasm. In this way
> QEMU can easily read the
On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
> Hi, Laszlo
>
> For Intel TDX supported guest, all processors start in 32-bit
> protected
> mode, while for Non-Td guest, it starts in 16-bit real mode. To make
> the
> ResetVector work on both Td-guest and Non-Td guest, ResetVector are
> update
On Tue, 2021-04-06 at 14:16 +0200, Laszlo Ersek wrote:
> On 04/06/21 10:11, Xu, Min M wrote:
> > Hi, Singh
> > I have a concern about the sevSnpBlock in ResetVectorVtf0.asm.
> > Actually
> > SEV has inserted 3 blocks in ResetVectorVtf0.asm and the total
> > bytes are
> > (26 + 22 + 20 = 68 bytes).
Hi, Laszlo
For Intel TDX supported guest, all processors start in 32-bit protected
mode, while for Non-Td guest, it starts in 16-bit real mode. To make the
ResetVector work on both Td-guest and Non-Td guest, ResetVector are
updated as below:
On 04/06/21 10:11, Xu, Min M wrote:
> Hi, Singh
> I have a concern about the sevSnpBlock in ResetVectorVtf0.asm. Actually
> SEV has inserted 3 blocks in ResetVectorVtf0.asm and the total bytes are
> (26 + 22 + 20 = 68 bytes). If sevSnpBlock is added, then the total bytes
> will be (68 +26 = 94 byte
Hi, Singh
I have a concern about the sevSnpBlock in ResetVectorVtf0.asm. Actually
SEV has inserted 3 blocks in ResetVectorVtf0.asm and the total bytes are
(26 + 22 + 20 = 68 bytes). If sevSnpBlock is added, then the total bytes
will be (68 +26 = 94 bytes).
I am not sure whether there will be more
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
During the SEV-SNP guest launch sequence, two special pages need to
be inserted, the secrets page and cpuid page. The secrets page,
contain the VM platform communication keys. The guest BIOS and OS
can use this key to communicate with the SEV
22 matches
Mail list logo
