| Message ID | 20221228192438.2835203-3-vannapurve@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Execute hypercalls according to host cpu | expand |
In shortlogs and changelogs, try to provide a synopsis of the change, not a literal description of the change. As suggested in the previous patch, this: KVM: selftests: Cache host CPU vendor (AMD vs. Intel) is more precise (vendor instead of "cpu type") and hints at the intent (caching the information), whereas this doesn't capture the vendor part, nor does it provide any hint whatsoever as to (a) how the variables will be used or (b) why we want to add variables to store KVM: selftests: x86: Add variables to store cpu type On Wed, Dec 28, 2022, Vishal Annapurve wrote: > Add variables to hold the cpu vendor type that are initialized early > during the selftest setup and later synced to guest vm post VM creation. > > These variables will be used in later patches to avoid querying CPU > type multiple times. Performance is a happy bonus, it is not the main reason for caching. The main reason for caching is so that the guest can select the native hypercall instruction without having to make assumptions about guest vs. host CPUID information.
On Mon, Jan 9, 2023 at 10:13 AM Sean Christopherson <seanjc@google.com> wrote: > > In shortlogs and changelogs, try to provide a synopsis of the change, not a > literal description of the change. As suggested in the previous patch, this: > > KVM: selftests: Cache host CPU vendor (AMD vs. Intel) > > is more precise (vendor instead of "cpu type") and hints at the intent (caching > the information), whereas this doesn't capture the vendor part, nor does it provide > any hint whatsoever as to (a) how the variables will be used or (b) why we want to > add variables to store > > KVM: selftests: x86: Add variables to store cpu type > > On Wed, Dec 28, 2022, Vishal Annapurve wrote: > > Add variables to hold the cpu vendor type that are initialized early > > during the selftest setup and later synced to guest vm post VM creation. > > > > These variables will be used in later patches to avoid querying CPU > > type multiple times. > > Performance is a happy bonus, it is not the main reason for caching. The main > reason for caching is so that the guest can select the native hypercall instruction > without having to make assumptions about guest vs. host CPUID information. Ack, that makes sense.
diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c index a799af572f3f..b3d2a9ab5ced 100644 --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c @@ -19,6 +19,8 @@ #define MAX_NR_CPUID_ENTRIES 100 vm_vaddr_t exception_handlers; +static bool host_cpu_is_amd; +static bool host_cpu_is_intel; static void regs_dump(FILE *stream, struct kvm_regs *regs, uint8_t indent) { @@ -555,6 +557,8 @@ static void vcpu_setup(struct kvm_vm *vm, struct kvm_vcpu *vcpu) void kvm_arch_vm_post_create(struct kvm_vm *vm) { vm_create_irqchip(vm); + sync_global_to_guest(vm, host_cpu_is_intel); + sync_global_to_guest(vm, host_cpu_is_amd); } struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, uint32_t vcpu_id, @@ -1264,3 +1268,9 @@ bool vm_is_unrestricted_guest(struct kvm_vm *vm) return get_kvm_intel_param_bool("unrestricted_guest"); } + +void kvm_selftest_arch_init(void) +{ + host_cpu_is_intel = this_cpu_is_intel(); + host_cpu_is_amd = this_cpu_is_amd(); +}
Add variables to hold the cpu vendor type that are initialized early during the selftest setup and later synced to guest vm post VM creation. These variables will be used in later patches to avoid querying CPU type multiple times. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Vishal Annapurve <vannapurve@google.com> --- tools/testing/selftests/kvm/lib/x86_64/processor.c | 10 ++++++++++ 1 file changed, 10 insertions(+)