All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xin Li <xin@zytor.com>
Cc: kvm@vger.kernel.org
Subject: Re: Run user level code in guest in a new KVM selftest
Date: Thu, 26 Oct 2023 17:54:54 -0700	[thread overview]
Message-ID: <ZTsKXmXXr4lIi5If@google.com> (raw)
In-Reply-To: <a65e6d23-791b-4866-8cb8-543d8f1942a6@zytor.com>

On Thu, Oct 26, 2023, Xin Li wrote:
> Hi Sean,
> 
> I'm adding a nested exception selftest for FRED, which needs to run
> user level code in guest.  I have to add the following hack for that:
> 
> diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c
> b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> index d8288374078e..72928c07ccbe 100644
> --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c
> +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> @@ -159,6 +159,7 @@ static uint64_t *virt_create_upper_pte(struct kvm_vm
> *vm,
> 
>         if (!(*pte & PTE_PRESENT_MASK)) {
>                 *pte = PTE_PRESENT_MASK | PTE_WRITABLE_MASK;
> +               *pte |= PTE_USER_MASK;
>                 if (current_level == target_level)
>                         *pte |= PTE_LARGE_MASK | (paddr &
> PHYSICAL_PAGE_MASK);
>                 else
> @@ -222,6 +223,7 @@ void __virt_pg_map(struct kvm_vm *vm, uint64_t vaddr,
> uint64_t paddr, int level)
>         TEST_ASSERT(!(*pte & PTE_PRESENT_MASK),
>                     "PTE already present for 4k page at vaddr: 0x%lx\n",
> vaddr);
>         *pte = PTE_PRESENT_MASK | PTE_WRITABLE_MASK | (paddr &
> PHYSICAL_PAGE_MASK);
> +       *pte |= PTE_USER_MASK;
>  }
> 
>  void virt_arch_pg_map(struct kvm_vm *vm, uint64_t vaddr, uint64_t paddr)
> 
> 
> Is there an exiting selftest running user level code in guest?

Nope, not that I know of.

> It seems there is none as the USER bit in PTEs is never set, what have I
> missed?

Nothing.

> If such a facility doesn't exist, we probably need to find a
> clean solution to add the USER bit in user level page table mappings
> (which seems not yet clearly defined yet).

Yes, being able to run usercode would be very nice indeed.  It should be a lot
simpler than KUT since we can stuff guest state directly.  The big hiccup is SMEP
and SMAP, e.g. we can't just set PTE_USER_MASK blindly :-(

My best off-the-top-of-my-head idea is to play games with "enum vm_guest_mode" so
that we know from time zero that the guest will be run in user mode, e.g. so that
loading the initial guest_code can map it for user.

      reply	other threads:[~2023-10-27  0:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26 17:59 Run user level code in guest in a new KVM selftest Xin Li
2023-10-27  0:54 ` Sean Christopherson [this message]

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=ZTsKXmXXr4lIi5If@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=xin@zytor.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.