qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Pavel Dovgalyuk <dovgaluk@ispras.ru>
Cc: ehabkost@redhat.com, quintela@redhat.com, dgilbert@redhat.com,
	qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] i386: EFER vs 32-bit CPU
Date: Thu, 30 May 2019 17:00:28 +0800	[thread overview]
Message-ID: <20190530090028.GB28587@xz-x1> (raw)
In-Reply-To: <000901d516ac$2b1a7d80$814f7880$@ru>

On Thu, May 30, 2019 at 08:54:38AM +0300, Pavel Dovgalyuk wrote:
> > From: Peter Xu [mailto:peterx@redhat.com]
> > On Wed, May 29, 2019 at 02:26:39PM +0300, Pavel Dovgalyuk wrote:
> > > Hello!
> > >
> > >
> > >
> > > I found this while debugging the inconsistent saved/restored state of the virtual machine.
> > >
> > >
> > >
> > > i386 (32 bit) emulation uses this register (in wrmsr and in MMU fault processing).
> > 
> > Sorry if this question is elementary, but... why would a 32bit guest
> > use IA32_EFER?  From SDM I only see 4 bits defined in this MSR (SCE,
> > LME, LMA, NXE) but is there any of them that should be set in a 32bit
> > guest?
> 
> Ubuntu server 16.04 (32 bit) sets NXE while booting.
> NXE affects the MMU fault processing and exception generation.

But this is what I read from the spec (SDM 4.6.1):

Instruction fetches:

  - Access rights depend on the mode of the linear address, the paging
    mode, and the value of IA32_EFER.NXE:

    - For 32-bit paging or if IA32_EFER.NXE = 0, instructions may be
      fetched from any user-mode address.

    - For PAE paging or 4-level paging with IA32_EFER.NXE = 1,
      instructions may be fetched from any user-mode address with a
      translation for which the XD flag is 0 in every paging-structure
      entry controlling the translation.

    - Instructions may not be fetched from any supervisor-mode address.

I'm not an expert of x86 arch but it seems to me that no matter what
NXE bit should be meaningless on x86 32bit according to above.

Also, above spec seems to match with the kvm code too, since in
init_kvm_tdp_mmu() where kvm_mmu.nx is only set with either long mode
or PAE, but never 32bit.  So I'm a bit confused on why that should be
migrated for 32bit (or even, whether should EFER MSR be visible to
such a guest at all?).

Regards,

-- 
Peter Xu


  reply	other threads:[~2019-05-30  9:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 11:26 [Qemu-devel] i386: EFER vs 32-bit CPU Pavel Dovgalyuk
2019-05-29 11:30 ` Dr. David Alan Gilbert
2019-05-29 11:39   ` Paolo Bonzini
2019-05-29 11:53     ` Pavel Dovgalyuk
2019-05-29 12:36       ` Dr. David Alan Gilbert
2019-05-29 14:03         ` Pavel Dovgalyuk
2019-05-30  0:52 ` Peter Xu
2019-05-30  5:54   ` Pavel Dovgalyuk
2019-05-30  9:00     ` Peter Xu [this message]
2019-05-30  9:04       ` Peter Xu
2019-05-30 11:00 ` TeLeMan

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=20190530090028.GB28587@xz-x1 \
    --to=peterx@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=dovgaluk@ispras.ru \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    /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).