public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Andrew Jones <andrew.jones@linux.dev>
Cc: Peter Gonda <pgonda@google.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	marcorr@google.com, michael.roth@amd.com,
	thomas.lendacky@amd.com, joro@8bytes.org, mizhang@google.com,
	pbonzini@redhat.com, vannapurve@google.com
Subject: Re: [V3 10/11] KVM: selftests: Add ucall pool based implementation
Date: Fri, 19 Aug 2022 18:02:39 +0000	[thread overview]
Message-ID: <Yv/QPxeKczzmxR9H@google.com> (raw)
In-Reply-To: <20220819051725.6lgggz2ktbd35pqj@kamzik>

On Fri, Aug 19, 2022, Andrew Jones wrote:
> On Thu, Aug 18, 2022 at 11:29:11PM +0000, Sean Christopherson wrote:
> > On Thu, Aug 18, 2022, Andrew Jones wrote:
> Dropping the only once-used uc_pool_idx() and adding the comment looks
> better, but I don't think there was a bug because uc == uc->hva.

uc == uc->hva for the host, but not for the guest.  From the guest's perspective,
"hva" is an opaque pointer that has no direct relation to "uc".

> 1) Doing ucall_init() at VM create time may be too early for Arm. Arm
> probes for an unmapped address for the MMIO address it needs, so it's
> best to do that after all mapping.

Argh.  I really hate the MMIO probing.  Is there really no arbitrary address that
selftests can carve out and simply say "thou shalt not create a memslot here"?

Or can we just say that it's always immediate after memslot0?  That would allow
us to delete the searching code in ARM's ucall_arch_init().

> 2) We'll need to change the sanity checks in Arm's get_ucall() to not
> check that the MMIO address == ucall_exit_mmio_addr since there's no
> guarantee that the exiting guest's address matches whatever is lingering
> in the host's version. We can either drop the sanity check altogether
> or try to come up with something else.

Ah, right.  This one at least is easy to handle.  If the address is per-VM, just
track the address.  If it's hardcoded (as a fix for #1) then, it's even simpler.

diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h
index 8623c1568f97..74167540815b 100644
--- a/tools/testing/selftests/kvm/include/kvm_util_base.h
+++ b/tools/testing/selftests/kvm/include/kvm_util_base.h
@@ -94,7 +94,8 @@ struct kvm_vm {
        vm_paddr_t pgd;
        vm_vaddr_t gdt;
        vm_vaddr_t tss;
-       vm_vaddr_t idt;
+       vm_paddr_t pgd;
+       vm_vaddr_t ucall_addr;
        vm_vaddr_t handlers;
        uint32_t dirty_ring_size;
        struct vm_memcrypt memcrypt;
diff --git a/tools/testing/selftests/kvm/lib/aarch64/ucall.c b/tools/testing/selftests/kvm/lib/aarch64/ucall.c
index b5d904f074b6..7f1d50dab0df 100644
--- a/tools/testing/selftests/kvm/lib/aarch64/ucall.c
+++ b/tools/testing/selftests/kvm/lib/aarch64/ucall.c
@@ -14,6 +14,8 @@ static vm_vaddr_t *ucall_exit_mmio_addr;

 static void ucall_set_mmio_addr(struct kvm_vm *vm, vm_vaddr_t val)
 {
+       vm->ucall_addr = val;
+
        atomic_sync_global_pointer_to_guest(vm, ucall_exit_mmio_addr, val);
 }

@@ -87,7 +89,7 @@ void *ucall_arch_get_ucall(struct kvm_vcpu *vcpu)
        struct kvm_run *run = vcpu->run;

        if (run->exit_reason == KVM_EXIT_MMIO &&
-           run->mmio.phys_addr == (uint64_t)ucall_exit_mmio_addr) {
+           run->mmio.phys_addr == vcpu->vm->ucall_addr) {
                TEST_ASSERT(run->mmio.is_write && run->mmio.len == sizeof(uint64_t),
                            "Unexpected ucall exit mmio address access");
                return (void *)(*((uint64_t *)run->mmio.data));


  reply	other threads:[~2022-08-19 18:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-10 15:20 [V3 00/11] KVM: selftests: Add simple SEV test Peter Gonda
2022-08-10 15:20 ` [V3 01/11] KVM: selftests: move vm_phy_pages_alloc() earlier in file Peter Gonda
2022-08-10 15:20 ` [V3 02/11] KVM: selftests: sparsebit: add const where appropriate Peter Gonda
2022-08-10 15:20 ` [V3 03/11] KVM: selftests: add hooks for managing encrypted guest memory Peter Gonda
2022-08-10 15:20 ` [V3 04/11] KVM: selftests: handle encryption bits in page tables Peter Gonda
2022-08-10 15:20 ` [V3 05/11] KVM: selftests: add support for encrypted vm_vaddr_* allocations Peter Gonda
2022-08-10 15:20 ` [V3 06/11] KVM: selftests: Consolidate common code for popuplating Peter Gonda
2022-08-16 15:26   ` Andrew Jones
2022-08-10 15:20 ` [V3 07/11] KVM: selftests: Consolidate boilerplate code in get_ucall() Peter Gonda
2022-08-16 15:32   ` Andrew Jones
2022-08-10 15:20 ` [V3 08/11] KVM: selftests: add library for creating/interacting with SEV guests Peter Gonda
2022-08-18  0:33   ` Sean Christopherson
2022-08-29 15:45     ` Peter Gonda
2022-08-10 15:20 ` [V3 09/11] tools: Add atomic_test_and_set_bit() Peter Gonda
2022-08-16 14:26   ` Sean Christopherson
2022-08-10 15:20 ` [V3 10/11] KVM: selftests: Add ucall pool based implementation Peter Gonda
2022-08-16 16:13   ` Andrew Jones
2022-08-18 16:00     ` Sean Christopherson
2022-08-18 19:05       ` Andrew Jones
2022-08-18 23:29         ` Sean Christopherson
2022-08-19  5:17           ` Andrew Jones
2022-08-19 18:02             ` Sean Christopherson [this message]
2022-08-19 20:51               ` Sean Christopherson
2022-08-19 19:27   ` Vishal Annapurve
2022-08-19 19:37     ` Sean Christopherson
2022-08-22 23:55       ` Vishal Annapurve
2022-08-10 15:20 ` [V3 11/11] KVM: selftests: Add simple sev vm testing Peter Gonda
2022-08-18  0:22   ` Sean Christopherson
2022-08-29 15:38     ` Peter Gonda
2022-08-18 18:43   ` 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=Yv/QPxeKczzmxR9H@google.com \
    --to=seanjc@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcorr@google.com \
    --cc=michael.roth@amd.com \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.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