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
next prev parent 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.