On Mon, May 24, 2021 at 3:28 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, May 24, 2021, Paolo Bonzini wrote: > > On 24/04/21 02:46, Sean Christopherson wrote: > > > Don't waste time writing zeros via VMWRITE during vCPU RESET, the VMCS > > > is zero allocated. > > > > Is this guaranteed to be valid, or could the VMCS in principle use some > > weird encoding? (Like it does for the access rights, even though this does > > not matter for this patch). > > Phooey. In principle, the CPU can do whatever it wants, e.g. the SDM states that > software should never write to the data portion of the VMCS under any circumstance. > > In practice, I would be flabbergasted if Intel ever ships a CPU that doesn't play > nice with zero initiazing the VMCS via software writes. I'd bet dollars to > donuts that KVM isn't the only software that relies on that behavior. It's not just Intel. It's any manufacturer of physical or virtual CPUs that implement VT-x. Non-architected behavior isn't guaranteed. > That said, I'm not against switching to VMWRITE for everything, but regardless > of which route we choose, we should commit to one or the other. I.e. double down > on memset() and bet that Intel won't break KVM, or replace the memset() in > alloc_vmcs_cpu() with a sequence that writes all known (possible?) fields. The > current approach of zeroing the memory in software but initializing _some_ fields > is the worst option, e.g. I highly doubt vmcs01 and vmcs02 do VMWRITE(..., 0) on > the same fields. The memset should probably be dropped, unless it is there to prevent information leakage. However, it is not necessary to VMWRITE all known (or possible) fields--just those that aren't guarded by an enable bit.
