From: Sean Christopherson <seanjc@google.com>
To: Ackerley Tng <ackerleytng@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
David Matlack <dmatlack@google.com>,
Wei Wang <wei.w.wang@intel.com>,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: selftests: Reuse kvm_setup_gdt in vcpu_init_descriptor_tables
Date: Wed, 18 Jan 2023 19:01:24 +0000 [thread overview]
Message-ID: <Y8hCBOndYMD9zsDL@google.com> (raw)
In-Reply-To: <20230114161557.499685-3-ackerleytng@google.com>
On Sat, Jan 14, 2023, Ackerley Tng wrote:
> Refactor vcpu_init_descriptor_tables to use kvm_setup_gdt
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> tools/testing/selftests/kvm/lib/x86_64/processor.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> index 33ca7f5232a4..8d544e9237aa 100644
> --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c
> +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> @@ -1119,8 +1119,7 @@ void vcpu_init_descriptor_tables(struct kvm_vcpu *vcpu)
> vcpu_sregs_get(vcpu, &sregs);
> sregs.idt.base = vm->idt;
> sregs.idt.limit = NUM_INTERRUPTS * sizeof(struct idt_entry) - 1;
> - sregs.gdt.base = vm->gdt;
> - sregs.gdt.limit = getpagesize() - 1;
> + kvm_setup_gdt(vcpu->vm, &sregs.gdt);
*sigh*
The selftests infrastructure is so misguided. Forcing tests to opt-in to
installing an IDT just to avoid allocating two pages is such an awful tradeoff.
Now that we have kvm_arch_vm_post_create(), I think we should always allocate
the GDT, IDT, and handlers, and then vCPU setup/creation can simply grab the
already-allocated values and stuff them into KVM. That would then eliminate
kvm_setup_gdt() entirely.
And much of the setup code is also backwards and unnecessarily thread-unsafe, e.g.
vCPU initialization shouldn't need to fill GDT entries.
So, while I agree that using kvm_setup_gdt() is a good change on its own, I'd
rather go the more aggressive route and clean up the underlying mess.
I'll send patches sometime this week, unfortunately typing up what I have in mind
is harder than just reworking the code :-/
next prev parent reply other threads:[~2023-01-18 19:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-14 16:15 [PATCH 0/2] Fix kvm_setup_gdt and reuse in vcpu_init_descriptor_tables Ackerley Tng
2023-01-14 16:15 ` [PATCH 1/2] KVM: selftests: Fix initialization of GDT limit Ackerley Tng
2023-01-18 18:03 ` Sean Christopherson
2023-01-18 19:02 ` Sean Christopherson
2023-01-14 16:15 ` [PATCH 2/2] KVM: selftests: Reuse kvm_setup_gdt in vcpu_init_descriptor_tables Ackerley Tng
2023-01-18 19:01 ` Sean Christopherson [this message]
2023-01-18 19:15 ` David Matlack
2023-01-18 19:36 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8hCBOndYMD9zsDL@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=wei.w.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.