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+ AuthenticAM
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
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-b
Il gio 22 set 2022, 22:33 Gerd Hoffmann ha scritto:
> On Thu, Sep 22, 2022 at 02:38:02PM +0200, Paolo Bonzini wrote:
> > On Thu, Sep 22, 2022 at 2:21 PM Gerd Hoffmann wrote:
> > > No. This will basically inform the guest that host-phys-bits has been
> > > enabled (and pass the number of bits).
On Thu, Sep 22, 2022 at 02:38:02PM +0200, Paolo Bonzini wrote:
> On Thu, Sep 22, 2022 at 2:21 PM Gerd Hoffmann wrote:
> > No. This will basically inform the guest that host-phys-bits has been
> > enabled (and pass the number of bits). So the firmware can make use of
> > the available address spa
On Thu, Sep 22, 2022 at 7:13 PM Jim Mattson wrote:
> > Treating 40 as invalid and continue to use the current conservative
> > heuristic, otherwise treat phys-bits as valid might work. Obvious
> > corner case is that it'll not catch broken manual configurations
> > (host-phys-bits=off,phys-bits=)
On Thu, Sep 22, 2022 at 7:16 AM Gerd Hoffmann wrote:
>
> On Thu, Sep 22, 2022 at 02:38:02PM +0200, Paolo Bonzini wrote:
> > On Thu, Sep 22, 2022 at 2:21 PM Gerd Hoffmann wrote:
> > > No. This will basically inform the guest that host-phys-bits has been
> > > enabled (and pass the number of bits)
On Thu, Sep 22, 2022 at 02:38:02PM +0200, Paolo Bonzini wrote:
> On Thu, Sep 22, 2022 at 2:21 PM Gerd Hoffmann wrote:
> > No. This will basically inform the guest that host-phys-bits has been
> > enabled (and pass the number of bits). So the firmware can make use of
> > the available address spa
On Thu, Sep 22, 2022 at 2:21 PM Gerd Hoffmann wrote:
> No. This will basically inform the guest that host-phys-bits has been
> enabled (and pass the number of bits). So the firmware can make use of
> the available address space instead of trying to be as conservative as
> possible to avoid going
On Thu, Sep 22, 2022 at 12:24:09PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 12:14:54PM +0200, Gerd Hoffmann wrote:
> > In case phys bits are functional and can be used by the guest (aka
> > host-phys-bits=on) add a fw_cfg file carrying the value. This can
> > be used by the guest
On Thu, Sep 22, 2022 at 12:14:54PM +0200, Gerd Hoffmann wrote:
> In case phys bits are functional and can be used by the guest (aka
> host-phys-bits=on) add a fw_cfg file carrying the value. This can
> be used by the guest firmware for address space configuration.
>
> The value in the etc/phys-bi
On Thu, Sep 22, 2022 at 12:24:09PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 12:14:54PM +0200, Gerd Hoffmann wrote:
> > In case phys bits are functional and can be used by the guest (aka
> > host-phys-bits=on) add a fw_cfg file carrying the value. This can
> > be used by the guest
In case phys bits are functional and can be used by the guest (aka
host-phys-bits=on) add a fw_cfg file carrying the value. This can
be used by the guest firmware for address space configuration.
The value in the etc/phys-bits fw_cfg file should be identical to
the phys bits value published via c
13 matches
Mail list logo
