All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Sergio Lopez" <slp@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	kvm <kvm@vger.kernel.org>,
	"Marcelo Tosatti" <mtosatti@redhat.com>
Subject: Re: [PATCH v4] x86: add etc/phys-bits fw_cfg file
Date: Fri, 7 Oct 2022 09:44:42 -0400	[thread overview]
Message-ID: <20221007094427-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220923062312.sibqhfhfznnc22km@sirius.home.kraxel.org>

On Fri, Sep 23, 2022 at 08:23:12AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > Given newer processors have more than 40 and for older ones we know
> > > the possible values for the two relevant x86 vendors we could do
> > > something along the lines of:
> > >
> > >    phys-bits >= 41                   -> valid
> > >    phys-bits == 40    + AuthenticAMD -> valid
> > >    phys-bits == 36,39 + GenuineIntel -> valid
> > >    everything else                   -> invalid
> > >
> > > Does that look sensible to you?
> > >
> > 
> > Yes, it does! Is phys-bits == 36 the same as invalid?
> 
> 'invalid' would continue to use the current guesswork codepath for
> phys-bits.  Which will end up with phys-bits = 36 for smaller VMs, but
> it can go beyond that in VMs with alot (32G or more) of memory.  That
> logic assumes that physical machines with enough RAM for 32G+ guests
> have a physical address space > 64G.
> 
> 'phys-bits = 36' would be a hard limit.
> 
> So, it's not exactly the same but small VMs wouldn't see a difference.
> 
> take care,
>   Gerd

I dropped the patch for now.

-- 
MST


  reply	other threads:[~2022-10-07 13:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22 10:14 [PATCH v4] x86: add etc/phys-bits fw_cfg file Gerd Hoffmann
2022-09-22 11:24 ` Daniel P. Berrangé
2022-09-22 11:56   ` Michael S. Tsirkin
2022-09-22 12:20   ` Gerd Hoffmann
2022-09-22 12:38     ` Paolo Bonzini
2022-09-22 14:16       ` Gerd Hoffmann
2022-09-22 17:13         ` Jim Mattson
2022-09-22 19:49           ` Paolo Bonzini
2022-09-22 20:33       ` Gerd Hoffmann
2022-09-23  6:00         ` Paolo Bonzini
2022-09-23  6:23           ` Gerd Hoffmann
2022-10-07 13:44             ` Michael S. Tsirkin [this message]
2022-10-10  7:30               ` Gerd Hoffmann

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=20221007094427-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=slp@redhat.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.