On 04/05/2015 15:58, Laszlo Ersek wrote:
> So here's the *specific* issues I'm facing (and need help with):
> 
> * Problem #1 for task (4):
> 
> Because Quark is 32-bit only, the (mostly assembly) code under
> "OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32" that (partly) constitutes the
> SMM entry vector does not *build* for X64 guests.
> 
> I don't know what it would take to make that code build & work for X64
> guests:
> - just replace some registers and instructions, and maybe recalculate
> some offsets?
> - or else, is X64 architecturally different in this regard, and a
> rewrite from scratch is needed?
> 
> (But, again, this code should have always lived in edk2, under
> UefiCpuPkg...)

The SMM entry vector will start in a 16-bit real mode code segment,
albeit with 4GB segment limits.  So there must be yet another 32-bit
protected mode switching sequence somewhere.  So my guess is:

1) you can add a 32->64-bit mode world switch there.  I know your love
for this kind of code, I guess you can bribe someone to take care of
this part. :)

2) build the SMM code in 32-bit mode, similar to OVMFIA32X64.


My gut feeling is that (2) is simpler if one knows the edk2 build tools,
which I don't so I may be saying nonsense.

Regarding this, I'm going to ask a question though...  The way I read
the S3RestoreConfig2 function of
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c, is that the function
assumes it runs in 32-bit mode when SMM is available.  Is this correct?
 If it is, I wonder which parts of the existing SMM support assume the
OVMFIA32.dsc or OVMFIA32X64.dsc configurations.

Does OVMFIA32X64 work at all, or has it bitrotted?

> * Problem #2 (terrible) for task (4):
> 
> I audited all PCDs used by PiSmmCpuDxeSmm carefully. Most of them are
> fixed or feature PCDs, fine. However, there are two dynamic PCDs that
> carry important information (and we can't just go with a default):
> - PcdCpuConfigContextBuffer
> - PcdCpuS3DataAddress
> 
> PiSmmCpuDxeSmm *consumes* these PCDs, and the driver that produces them
> -- brace for impact -- is
> 
>   Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/
> 
> This means that PiSmmCpuDxeSmm will never work unless we throw out our
> current MpService implementation, located in edk2's
> 
>   UefiCpuPkg/CpuDxe/
> 
> (contributed by Chen Fan of Fujitsu), and replace it with the one from
> the Quark distribution.
> 
> Which means that I'd have to import *another* 300+ KB driver from the
> Quark package, get it to build, and pray that it doesn't have even
> *further* dependencies.

What do these PCDs do?  Can we backport them to the edk2 CpuDxe?

More important: who produces *the data pointed by* the PCDs?  Is it the
SMM driver or is it the CpuDxe driver?

Especially if the data is produced by the SMM driver, problem #1 seems
worse.

> * Problem #3 (smaller, in comparison) for task (4):
> 
> The default SMBASE area, starting at guest-phys address 0x30000, and
> continuing for 0x10000 bytes, doesn't seem to be protected with any kind
> of memory allocation HOB or similar in Quark_EDKII_v1.1.0. (Grep for
> SMM_DEFAULT_SMBASE).
> 
> Why is this okay? As far as I understand, when a CPU enters SMM for the
> very first time, it will happily scribble over this area (saving state
> etc). We should make sure in advance (starting from PEI) that no later
> memory allocation (in PEI or in DXE) will accidentally overlap with that
> memory range, because when the SMBASE relocation is performed, that
> allocation will be corrupted.

This seems right.  It should be an EfiACPIMemoryNVS HOB, I think.  I
think you do not need actual SMM stuff in order to check whether this
upsets OSes.

Paolo

> Can someone please advise wrt. to problems #1 to #3?

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to