On 2017/8/25 19:20, gengdongjiu wrote: >>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c >>> >> index 3d78ff6..def1ec1 100644 >>> >> --- a/hw/arm/virt-acpi-build.c >>> >> +++ b/hw/arm/virt-acpi-build.c >>> >> @@ -45,6 +45,7 @@ >>> >> #include "hw/arm/virt.h" >>> >> #include "sysemu/numa.h" >>> >> #include "kvm_arm.h" >>> >> +#include "hw/acpi/hest_ghes.h" >>> >> >>> >> #define ARM_SPI_BASE 32 >>> >> #define ACPI_POWER_BUTTON_DEVICE "PWRB" >>> >> @@ -771,6 +772,9 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables) >>> >> acpi_add_table(table_offsets, tables_blob); >>> >> build_spcr(tables_blob, tables->linker, vms); >>> >> >>> >> + acpi_add_table(table_offsets, tables_blob); >>> >> + ghes_build_acpi(tables_blob, tables->hardware_errors, tables->linker); >>> >> + >> > So we add this table unconditionally. Is there any bad impact if QEMU >> > runs on old kvm? Does it need to check whether KVM supports RAS? > this table is added before guest OS boot. so can not use KVM to check it. No, we can check the RAS capability when we create vcpus like you done in another patch ans can use that in table generation. > if the old kvm does not support RAS, it does not have bad impact. only waste table memory. > May be we can make it as device? if this device is enabled in the qemu > boot parameters, then we will add this table? > And you need to add a option to virt machine for (migration) compatibility. On new virt machine it's on by default while off for old ones. Thanks, -- Shannon -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
