[some question] some question about `build_save_area()`

[JustPlay]

in build_save_area()

1. the py code use cr0=0x10, but based-on https://www.amd.com/system/files/TechDocs/24593.pdf (page 103, 526), it said cr0=6000_0010h , why ?
2. g_pat=0x7040600070406, i can not find where the value comes from
3. cs=VmcbSeg(0xf000, 0x9b, 0xffff, eip & 0xffff0000), why eip & 0xffff0000?
4. how the attribute was calc-ed? (e.g. 0x93, 0x9b in VmcbSeg) ?

thanks

[dubek]

Good questions. Some of this is from empirical attempt of launching an SEV-ES guest and looking at the VMSA that KVM sees before encrypting it.

I'll look into this and add better documentation to the code.

[dubek]

For cr0, AMD APM Vol 2 Table 14-1 (page 526 in PDF) says:

Value after INIT:
CD and NW are unchanged
Bit 4 (reserved) = 1
All others = 0

So if CD and NW are 0, and bit 4 is 1, you get cr0=0x10.

[dubek]

Value of g_pat is taken from this line in the QEMU initialization. It also appears in kvm's code as MSR_IA32_CR_PAT_DEFAULT.

[JustPlay]

For cr0, AMD APM Vol 2 Table 14-1 (page 526 in PDF) says:

Value after INIT:
CD and NW are unchanged
Bit 4 (reserved) = 1
All others = 0

So if CD and NW are 0, and bit 4 is 1, you get cr0=0x10.

should we use the INIT status, not RESET ？， why?
and，what's more， in amd‘s doc, it saids "CD and NW are unchanged", so how do you know the initial value? (because in RESET, CD=NW=1, not 0)

[dubek]

should we use the INIT status, not RESET ？， why?
and，what's more， in amd‘s doc, it saids "CD and NW are unchanged", so how do you know the initial value? (because in RESET, CD=NW=1, not 0)

You're right, I'm not sure. But empirically this is the case (this is the CR0 value in the VMSA) when starting SEV-ES guests with QEMU and KVM. Maybe the documentation or git history there give some explanations for these choice. Let me know if you find anything.

[tlendacky]

Value of g_pat is taken from this line in the QEMU initialization. It also appears in kvm's code as MSR_IA32_CR_PAT_DEFAULT.

This is the PAT MSR reset value as documented in APM Volume 2, Section A.3.