All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yahya Sohail <ysohail@cs.utexas.edu>
Cc: kvm@vger.kernel.org
Subject: Re: VM Memory Map
Date: Fri, 11 Aug 2023 11:07:30 -0700	[thread overview]
Message-ID: <ZNZ44ti0twIoXQqg@google.com> (raw)
In-Reply-To: <12a72fb7-4125-c705-6dd6-733ec23de80e@cs.utexas.edu>

On Fri, Aug 11, 2023, Yahya Sohail wrote:
> Hi,
> 
> Accesses to certain memory addresses by the guest trigger a KVM_EXIT_MMIO. I
> can't seem to find a memory map in the documentation or source that
> describes exactly which addresses are real memory and which addresses are
> MMIO addresses (on x86, if that matters). Is there any such documentation or
> a listing in the source?
> 
> Is there any way to configure which addresses are MMIO? I hoped that mapping
> memory to MMIO address regions with the KVM_SET_USER_MEMORY_REGION ioctl
> would allow me to use them as memory, but that didn't work. The only ioctls
> that seem relevant to MMIO are KVM_(UN)REGISTER_COALESCED_MMIO, but those
> only allow coalescing MMIO exits, not changing which addresses cause them.

KVM_EXIT_MMIO is for *emulated* MMIO, and is triggered by a guest access to
non-existent memory from the guest's (and KVM's) perspective.  Specifically, if
the guest accesses a GPA that is not covered by a memslot.

Mapping a "real" host MMIO address into a guest via KVM_SET_USER_MEMORY_REGION
will not generate KVM_EXIT_MMIO, as KVM will simply map the "real" MMIO directly
into the guest.

There is no KVM documentation of a memory map or real vs. emulated addresses because
what is real and what is emulated is completely userspace defined (except for the
local APIC and/or I/O APIC if userspace enables KVM's "in-kernel" APIC emulation).

      reply	other threads:[~2023-08-11 18:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11 17:04 VM Memory Map Yahya Sohail
2023-08-11 18:07 ` 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=ZNZ44ti0twIoXQqg@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=ysohail@cs.utexas.edu \
    /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.