From: Maxim Levitsky <mlevitsk@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, Li Qiang <liq3ea@gmail.com>
Cc: Qemu Developers <qemu-devel@nongnu.org>,
Avi Kivity <avi.kivity@gmail.com>
Subject: Re: Questions about the real mode in kvm/qemu
Date: Thu, 26 Sep 2019 12:41:07 +0300 [thread overview]
Message-ID: <f8a138f8c00df4886045d6771415336a7e43b887.camel@redhat.com> (raw)
In-Reply-To: <4ed0f9ca-6cd1-fd8e-9abd-4098f85c7f9d@redhat.com>
On Thu, 2019-09-26 at 11:33 +0200, Paolo Bonzini wrote:
> On 26/09/19 11:24, Maxim Levitsky wrote:
> > On Thu, 2019-09-26 at 11:18 +0200, Paolo Bonzini wrote:
> > > On 26/09/19 10:59, Maxim Levitsky wrote:
> > > > If you mean to ask if there is a way to let guest access use no
> > > > paging at all, that is access host physical addresses directly, then
> > > > indeed there is no way, since regular non 'unrestricted guest' mode
> > > > required both protected mode and paging, and 'unrestricted guest'
> > > > requires EPT. Academically speaking it is of course possible to
> > > > create paging tables that are 1:1...
> > >
> > > Not so academically, it's exactly what KVM does.
> >
> > You mean KVM uses 1:1 EPT pages and no guest paging,
> > to allow guest to access host physical address space?
>
> No, it uses the usual HVA->GPA EPT pages and 1:1 GPA->GVA pages when EPT
> is enabled and guest CR0.PG=0. This lets KVM work around the CR0.PG=1
> requirement when unrestricted guest mode.
I understand now.
>
> Thinking more about it, I suppose that saves memory (the same EPT page
> tables can now be used independent of guest CR0.PG), at the cost of
> making TLB misses a little slower.
Don't really understand what you mean.
Isn't this always the case that EPT and guest paging
are independent (at least when no nesting is involved)?
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2019-09-26 9:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-26 7:52 Questions about the real mode in kvm/qemu Li Qiang
2019-09-26 8:31 ` Maxim Levitsky
2019-09-26 8:52 ` Li Qiang
2019-09-26 8:59 ` Maxim Levitsky
2019-09-26 9:18 ` Paolo Bonzini
2019-09-26 9:24 ` Maxim Levitsky
2019-09-26 9:33 ` Paolo Bonzini
2019-09-26 9:41 ` Maxim Levitsky [this message]
2019-09-26 10:00 ` Paolo Bonzini
2019-09-26 10:03 ` Maxim Levitsky
2019-09-28 22:10 ` Avi Kivity
2019-09-29 7:39 ` Li Qiang
2019-09-26 9:15 ` Paolo Bonzini
2019-09-26 9:35 ` Maxim Levitsky
2019-09-26 9:35 ` Li Qiang
2019-09-26 9:53 ` Paolo Bonzini
2019-09-26 11:47 ` Li Qiang
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=f8a138f8c00df4886045d6771415336a7e43b887.camel@redhat.com \
--to=mlevitsk@redhat.com \
--cc=avi.kivity@gmail.com \
--cc=liq3ea@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).