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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox