cpu/tlb: do not broadcast per-cpu TLB flushes

[msft-jlange]

VM ranges that are specific to a single CPU do not require TLB invalidations to be broadcast to multiple processors. This is especially important during the early boot phase when no other processors are online and when the infrastructure required to broadcast TLB invalidations may not yet be fully initialized. The same is true for temporary mappings established in a per-CPU address range.

[00xc]

Left a few minor suggestions, other than that this looks good to me. I'll merge once comments are marked as resolved.

[00xc]

In-SVSM tests fail after the last commit in this PR (e1c168b):

[SVSM] test greq::msg::tests::encrypt_decrypt_payload ...
[SVSM] ERROR: Panic: CPU[0] KVM: entry failed, hardware error 0xffffffff
EAX=00000020 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT=     0000000000000000 00000000
IDT=     0000000000000000 00000000
CR0=80010031 CR2=0000000000000000 CR3=0000000000000000 CR4=000000f0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=0000000000000000 DR7=0000000000000000
EFER=0000000000000d00
Code=<??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

[00xc]

In-SVSM tests fail after the last commit in this PR (e1c168b):

Happens only on debug builds it seems. It also can happen even earlier, so the test that failed above is not to blame:

[SVSM] COCONUT Secure Virtual Machine Service Module
[SVSM] Order-00: total pages:    47 free pages:     0
[SVSM] Order-01: total pages:     1 free pages:     1
[SVSM] Order-02: total pages:     0 free pages:     0
[SVSM] Order-03: total pages:     0 free pages:     0
[SVSM] Order-04: total pages:     0 free pages:     0
[SVSM] Order-05: total pages:   117 free pages:   117
[SVSM] Total memory: 15172KiB free memory: 14984KiB
[SVSM] Boot stack starts        @ 0xffffff800011f000
[SVSM] BSP Runtime stack starts @ 0xffffff000020c000
[SVSM] Guest Memory Regions:
[SVSM]   000000000000000000-000000000080000000
[SVSM]   000000000100000000-000000000280000000
[SVSM] Invalidating boot region 000000000000000000-0000000000000a0000
KVM: entry failed, hardware error 0xffffffff
EAX=0000000a EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT=     0000000000000000 00000000
IDT=     0000000000000000 00000000
CR0=80010031 CR2=0000000000000000 CR3=0000000000000000 CR4=000000f0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=0000000000000000 DR7=0000000000000000
EFER=0000000000000d00
Code=<??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

[00xc]

Aaaand it went away with the latest nightly toolchain version, so not sure why it was failing. It also only failed when applying the VMR changes - applying only the PerCPUPageMappingGuard changes made the tests pass.

I'll try again tomorrow and see if everything works properly.