Hi,
> > I don't see a need for that. Live migration compatibility can be
> > handled just fine today using
> > 'host-phys-bits=on,host-phys-bits-limit='
> >
> > Which is simliar to 'phys-bits='.
>
> yes but what if user did not configure anything?
I expect that'll be less and less
On Fri, Sep 02, 2022 at 10:44:20AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I feel there are three major sources of controversy here
> >
> > 0. the cover letter and subject don't do such a good job
> >explaining that what we are doing is just telling guest
> >CPUID is not broken. we
Hi,
> I feel there are three major sources of controversy here
>
> 0. the cover letter and subject don't do such a good job
>explaining that what we are doing is just telling guest
>CPUID is not broken. we are not exposing anything new
>and not exposing host capability to guest,
On Fri, Sep 02, 2022 at 08:07:20AM +0200, Gerd Hoffmann wrote:
> On Fri, Sep 02, 2022 at 08:10:00AM +0800, Xiaoyao Li wrote:
> > On 9/2/2022 12:17 AM, Gerd Hoffmann wrote:
> > > On Thu, Sep 01, 2022 at 10:36:19PM +0800, Xiaoyao Li wrote:
> > > > On 9/1/2022 9:58 PM, Gerd Hoffmann wrote:
> > > >
>
On Fri, Sep 02, 2022 at 08:10:00AM +0800, Xiaoyao Li wrote:
> On 9/2/2022 12:17 AM, Gerd Hoffmann wrote:
> > On Thu, Sep 01, 2022 at 10:36:19PM +0800, Xiaoyao Li wrote:
> > > On 9/1/2022 9:58 PM, Gerd Hoffmann wrote:
> > >
> > > > > Anyway, IMO, guest including guest firmware, should always
On 9/2/2022 12:17 AM, Gerd Hoffmann wrote:
On Thu, Sep 01, 2022 at 10:36:19PM +0800, Xiaoyao Li wrote:
On 9/1/2022 9:58 PM, Gerd Hoffmann wrote:
Anyway, IMO, guest including guest firmware, should always consult from
CPUID leaf 0x8008 for physical address length.
It simply can't for the
On Thu, Sep 01, 2022 at 10:36:19PM +0800, Xiaoyao Li wrote:
> On 9/1/2022 9:58 PM, Gerd Hoffmann wrote:
>
> > > Anyway, IMO, guest including guest firmware, should always consult from
> > > CPUID leaf 0x8008 for physical address length.
> >
> > It simply can't for the reason outlined above.
On 9/1/22 08:07, Xiaoyao Li wrote:
> On 8/31/2022 8:50 PM, Gerd Hoffmann wrote:
>> When the guest (firmware specifically) knows how big
>> the address space actually is it can be used better.
>>
>> Some more background:
>>https://bugzilla.redhat.com/show_bug.cgi?id=2084533
>
> QEMU enables
On 9/1/2022 9:58 PM, Gerd Hoffmann wrote:
Anyway, IMO, guest including guest firmware, should always consult from
CPUID leaf 0x8008 for physical address length.
It simply can't for the reason outlined above. Even if we fix qemu
today that doesn't solve the problem for the firmware
Hi,
> I think the problem is for all the named CPU model, that they don't have
> phys_bits defined. Thus they all have "cpu->phys-bits == 0", which leads to
> cpu->phys_bits = TCG_PHYS_ADDR_BITS (36 for 32-bits build and 40 for 64-bits
> build)
Exactly. And if you run on hardware with
On 8/31/2022 8:50 PM, Gerd Hoffmann wrote:
When the guest (firmware specifically) knows how big
the address space actually is it can be used better.
Some more background:
https://bugzilla.redhat.com/show_bug.cgi?id=2084533
QEMU enables host-phys-bits for "-cpu host/max" in
When the guest (firmware specifically) knows how big
the address space actually is it can be used better.
Some more background:
https://bugzilla.redhat.com/show_bug.cgi?id=2084533
This is a RfC series exposes the information via cpuid.
take care,
Gerd
Gerd Hoffmann (2):
[hack] reserve
12 matches
Mail list logo
