add flush_broadcast and tlbsync functions

[Freax13]

flush_broadcast can be used to broadcast TLB flushes to all CPU cores and tlbsync can be used to wait for those flushes to be done.

[Freax13]

Do we want to use the builder pattern for this? There are an awful lot of parameters and this doesn't seem very future proof in case AMD adds more options.

[josephlr]

I agree that we want some sort of builder or #[non_exhaustive] struct to be used for this.

A builder pattern would also better reflect:

• What reasonable defaults should be
• What parameters are optional

[Freax13]

This can also be used to make some parameters unsafe.

[tlendacky]

If count is greater than the CPUID value (0x80000008_EDX[15:0]), you can issue the instruction in a loop and then perform a single TLBSYNC.

[Freax13]

If count is greater than the CPUID value (0x80000008_EDX[15:0]), you can issue the instruction in a loop and then perform a single TLBSYNC.

Ah, good to know, I was wondering about that, thank you!

I don't think we want to execute cpuid inside that function to figure out how often we have to loop though: There is precedence for relying on the caller to ensure an instruction is valid to execute (e.g. see flush_pcid in this crate or _rdrand64_step inside the standard library). Also in my particular use-case, I want to execute these instructions inside an SEV-SNP VM where getting cpuid values is not trivial (the cpuid instruction still exists, but may be slow).

[tlendacky]

If count is greater than the CPUID value (0x80000008_EDX[15:0]), you can issue the instruction in a loop and then perform a single TLBSYNC.

Ah, good to know, I was wondering about that, thank you!

I don't think we want to execute cpuid inside that function to figure out how often we have to loop though: There is precedence for relying on the caller to ensure an instruction is valid to execute (e.g. see flush_pcid in this crate or _rdrand64_step inside the standard library). Also in my particular use-case, I want to execute these instructions inside an SEV-SNP VM where getting cpuid values is not trivial (the cpuid instruction still exists, but may be slow).

Yes, you definitely don't want to be executing CPUID each time. In an SEV-SNP VM it will generate a #VC exception, which will then use the CPUID page to satisfy the instruction without exiting to the hypervisor, at least.

I haven't looked closely at the crate, is there any way to set/save some kind of initialization state that can be referenced?

[Freax13]

If count is greater than the CPUID value (0x80000008_EDX[15:0]), you can issue the instruction in a loop and then perform a single TLBSYNC.

Ah, good to know, I was wondering about that, thank you!
I don't think we want to execute cpuid inside that function to figure out how often we have to loop though: There is precedence for relying on the caller to ensure an instruction is valid to execute (e.g. see flush_pcid in this crate or _rdrand64_step inside the standard library). Also in my particular use-case, I want to execute these instructions inside an SEV-SNP VM where getting cpuid values is not trivial (the cpuid instruction still exists, but may be slow).

Yes, you definitely don't want to be executing CPUID each time. In an SEV-SNP VM it will generate a #VC exception, which will then use the CPUID page to satisfy the instruction without exiting to the hypervisor, at least.

I haven't looked closely at the crate, is there any way to set/save some kind of initialization state that can be referenced?

We do something kind of like that for the rdrand instruction:

x86_64/src/instructions/random.rs

Lines 3 to 19 in 642956d

	#[derive(Copy, Clone, Debug)]
	/// Used to obtain random numbers using x86_64's RDRAND opcode
	pub struct RdRand(());
	impl RdRand {
	/// Creates Some(RdRand) if RDRAND is supported, None otherwise
	#[inline]
	pub fn new() -> Option<Self> {
	// RDRAND support indicated by CPUID page 01h, ecx bit 30
	// https://en.wikipedia.org/wiki/RdRand#Overview
	let cpuid = unsafe { core::arch::x86_64::__cpuid(0x1) };
	if cpuid.ecx & (1 << 30) != 0 {
	Some(RdRand(()))
	} else {
	None
	}
	}

For rdrand we cache that the processor is able to execute it by creating an instance of a type that can only be created when the processor supports rdrand, if the user keeps that instance around they don't need to check again. We could do the same for invlpgb and tlbsync.

[Freax13]

Implementing the loop for this turns out to be less trivial than I initially thought. Two things I'm not completely certain about:

1. using invlpgb with a count of zero still flushes one page. Can the max count reported in the cpuid leaf also be zero? I tried looking in the PPRs, but most processor don't seem to support the instructions. EPYC Milan supports it and always has a max count of 7 according to the PPR. The PPR for Family 19h Model 11h Revision B1 also has a fixed max count of 7 (I'm not sure which processors that actually applies to, but I think something with the either Zen3+ or Zen4 microarchitecture).
2. what happens if we flush an address right before the gap in the address space with a count of more than one i.e.0x7fff_ffff_f000 with a count of two? I assume that it only flushes the address in the lower half in the address space and doesn't automatically jump the gap in the address space. Either way we need to be careful.

[tlendacky]

Implementing the loop for this turns out to be less trivial than I initially thought. Two things I'm not completely certain about:

1. using invlpgb with a count of zero still flushes one page. Can the max count reported in the cpuid leaf also be zero? I tried looking in the PPRs, but most processor don't seem to support the instructions. EPYC Milan supports it and always has a max count of 7 according to the PPR. The PPR for Family 19h Model 11h Revision B1 also has a fixed max count of 7 (I'm not sure which processors that actually applies to, but I think something with the either Zen3+ or Zen4 microarchitecture).

fam19h/model11h is Genoa.

Yes, theoretically, the CPUID could report 0 for the maximum count, in which case you would only be able to do a single page at a time (#GP if the ECX[15:0] > maximum page count supported).

2. what happens if we flush an address right before the gap in the address space with a count of more than one i.e.0x7fff_ffff_f000 with a count of two? I assume that it only flushes the address in the lower half in the address space and doesn't automatically jump the gap in the address space. Either way we need to be careful.

I believe that the address would not be canonicalized, and would then just be a miss in the TLB since no addresses would match.

[josephlr]

Also, for the ASID related instructions, it seems like we would want some sort of common Asid abstraction (like what we currently do for Pcid). This would also allow us to support something like INVLPGA in the future.

[Freax13]

Also, for the ASID related instructions, it seems like we would want some sort of common Asid abstraction (like what we currently do for Pcid). This would also allow us to support something like INVLPGA in the future.

AFAICT the reason that we have a Pcid type is that Pcid always has to be a 12-bit integer and Rust doesn't provide that. For ASID the limit is not a fixed constant: The maximum supported value is reported CPUID_Fn8000000A_EBX as a 32-bit integer, INVLPGA also takes a 32-bit ASID in ecx and the ASID field in the VMCB is also 32-bit. INVLPGB is the outlier here as it only takes a 16-bit ASID. In pratice a common maximum supported value seems to be 0x8000. There don't seem to be any bounds checks for INVLPGA, but INVLPGB will cause a #GP if the ASID is out of range.

With that said I'm not sure what size the ASID type should be and how we should enforce the limit given by the CPUID function.

Perhaps we should start keeping these limits in global variables so that we can properly enforce them without executing cpuid every time.

[phil-opp]

Thanks a lot for tackling this! I left some superficial comments on the API. I didn't have time to look through the flush_broadcast implementation, but the rest looks good to me.