On Wed, 23 Feb 2022 17:18:55 +0000 Joao Martins <joao.m.mart...@oracle.com> wrote:
> On 2/14/22 15:18, Joao Martins wrote: > > On 2/14/22 15:03, Igor Mammedov wrote: > >> On Mon, 7 Feb 2022 20:24:21 +0000 > >> Joao Martins <joao.m.mart...@oracle.com> wrote: > >> > >>> Default phys-bits on Qemu is TCG_PHYS_BITS (40) which is enough > >>> to address 1Tb (0xff ffff ffff). On AMD platforms, if a > >>> ram-above-4g relocation happens and the CPU wasn't configured > >>> with a big enough phys-bits, warn the user. There isn't a > >>> catastrophic failure exactly, the guest will still boot, but > >>> most likely won't be able to use more than ~4G of RAM. > >> > >> how 'unable to use" would manifest? > >> It might be better to prevent QEMU startup with broken setup (CLI) > >> rather then letting guest run and trying to figure out what's > >> going wrong when users start to complain. > >> > > Sounds better to be conservative here. > > > > I will change from warn_report() to error_report() > > and exit. > > > > I was running through x86_64 qtests prior to submission > and it seems that the inclusion of a pci_hole64_size in > the check added by this patch would break tests if we were > to error out. So far, I'm keeping it as a warning over > compatibility concerns, not limited these 5 test failures > below. Let me know otherwise if you disagree, or if you > prefer another way. can you check what exactly breaks tests? > Summary of Failures: > > 1/56 qemu:qtest+qtest-x86_64 / qtest-x86_64/qom-test ERROR > 0.07s > killed by signal 6 SIGABRT > 4/56 qemu:qtest+qtest-x86_64 / qtest-x86_64/test-hmp ERROR > 0.07s > killed by signal 6 SIGABRT > 7/56 qemu:qtest+qtest-x86_64 / qtest-x86_64/boot-serial-test ERROR > 0.07s > killed by signal 6 SIGABRT > 44/56 qemu:qtest+qtest-x86_64 / qtest-x86_64/test-x86-cpuid-compat ERROR > 0.09s > killed by signal 6 SIGABRT > 45/56 qemu:qtest+qtest-x86_64 / qtest-x86_64/numa-test ERROR > 0.17s > killed by signal 6 SIGABRT >