bb99b92a | 07-Mar-2025 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/i386/fw_cfg: Check ACPI availability with acpi_builtin()
Define acpi_tables / acpi_tables_len stubs, then replace the compile-time CONFIG_ACPI check in fw_cfg.c by a runtime one.
Signed-off-by:
hw/i386/fw_cfg: Check ACPI availability with acpi_builtin()
Define acpi_tables / acpi_tables_len stubs, then replace the compile-time CONFIG_ACPI check in fw_cfg.c by a runtime one.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20250307223949.54040-4-philmd@linaro.org>
show more ...
|
3634039b | 07-Jan-2025 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/acpi: Add vmclock device
The vmclock device addresses the problem of live migration with precision clocks. The tolerances of a hardware counter (e.g. TSC) are typically around ±50PPM. A guest wil
hw/acpi: Add vmclock device
The vmclock device addresses the problem of live migration with precision clocks. The tolerances of a hardware counter (e.g. TSC) are typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that counter against an external source of 'real' time, and track the precise frequency of the counter as it changes with environmental conditions.
When a guest is live migrated, anything it knows about the frequency of the underlying counter becomes invalid. It may move from a host where the counter running at -50PPM of its nominal frequency, to a host where it runs at +50PPM. There will also be a step change in the value of the counter, as the correctness of its absolute value at migration is limited by the accuracy of the source and destination host's time synchronization.
The device exposes a shared memory region to guests, which can be mapped all the way to userspace. In the first phase, this merely advertises a 'disruption_marker', which indicates that the guest should throw away any NTP synchronization it thinks it has, and start again.
Because the region can be exposed all the way to userspace, applications can still use time from a fast vDSO 'system call', and check the disruption marker to be sure that their timestamp is indeed truthful.
The structure also allows for the precise time, as known by the host, to be exposed directly to guests so that they don't have to wait for NTP to resync from scratch.
The values and fields are based on the nascent virtio-rtc specification, and the intent is that a version (hopefully precisely this version) of this structure will be included as an optional part of that spec. In the meantime, a simple ACPI device along the lines of VMGENID is perfectly sufficient and is compatible with what's being shipped in certain commercial hypervisors.
Linux guest support was merged into the 6.13-rc1 kernel: https://git.kernel.org/torvalds/c/205032724226
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <07fd5e2f529098ad4d7cab1423fe9f4a03a9cc14.camel@infradead.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
47935fc1 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: Change ghes fill logic to work with only one source
Extending to multiple sources require a BIOS pointer to the beginning of the HEST table, which in turn requires a backward-compatible c
acpi/ghes: Change ghes fill logic to work with only one source
Extending to multiple sources require a BIOS pointer to the beginning of the HEST table, which in turn requires a backward-compatible code.
So, the current code supports only one source. Ensure that and simplify the code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <66bddd42a64c8515ad98b9975d953b4a70ffcc6d.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
1cd59b89 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: move offset calculus to a separate function
Currently, CPER address location is calculated as an offset of the hardware_errors table. It is also badly named, as the offset actually used i
acpi/ghes: move offset calculus to a separate function
Currently, CPER address location is calculated as an offset of the hardware_errors table. It is also badly named, as the offset actually used is the address where the CPER data starts, and not the beginning of the error source.
Move the logic which calculates such offset to a separate function, in preparation for a patch that will be changing the logic to calculate it from the HEST table.
While here, properly name the variable which stores the cper address.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <60fdd1bf379ba1db3099710868802aa49a27febb.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
652f6d86 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: better name the offset of the hardware error firmware
The hardware error firmware is where HEST error structures are stored. Those can be GHESv2, but they can also be other types.
Better
acpi/ghes: better name the offset of the hardware error firmware
The hardware error firmware is where HEST error structures are stored. Those can be GHESv2, but they can also be other types.
Better name the location of the hardware error.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <ddbb94294bafee998f12fede3ba0b05dae5ee45f.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
4651745d | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: rename etc/hardware_error file macros
Now that we have also have a file to store HEST data location, which is part of GHES, better name the file where CPER records are stored.
No functio
acpi/ghes: rename etc/hardware_error file macros
Now that we have also have a file to store HEST data location, which is part of GHES, better name the file where CPER records are stored.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <e79a013bcd9f634b46ff6b34756d1b1403713af3.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
1acc8d4e | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: don't crash QEMU if ghes GED is not found
Make error handling within ghes_record_cper_errors() consistent, i.e. instead abort just print a error in case ghes GED is not found.
Reviewed-b
acpi/ghes: don't crash QEMU if ghes GED is not found
Make error handling within ghes_record_cper_errors() consistent, i.e. instead abort just print a error in case ghes GED is not found.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <c7e1665ba46df321f0ce161d60dfd681ab827535.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
d32028a5 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: better name GHES memory error function
The current function used to generate GHES data is specific for memory errors. Give a better name for it, as we now have a generic function as well.
acpi/ghes: better name GHES memory error function
The current function used to generate GHES data is specific for memory errors. Give a better name for it, as we now have a generic function as well.
Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Message-Id: <35b59121129d5e99cb5062cc3d775594bbb0905b.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
48b0dcdd | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: make the GHES record generation more generic
Split the code into separate functions to allow using the common CPER filling code by different error sources.
The generic code was moved to
acpi/ghes: make the GHES record generation more generic
Split the code into separate functions to allow using the common CPER filling code by different error sources.
The generic code was moved to ghes_record_cper_errors(), and ghes_gen_err_data_uncorrectable_recoverable() now contains only a logic to fill the Generic Error Data part of the record, as described at:
ACPI 6.2: 18.3.2.7.1 Generic Error Data
The remaining code to generate a memory error now belongs to acpi_ghes_record_errors() function.
A further patch will give it a better name.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <68d9f787d8c4fc8d1dbc227d6902fe801e42dea9.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
2e223c5e | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: don't check if physical_address is not zero
The 'physical_address' value is a faulty page. As such, 0 is as valid as any other value.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Si
acpi/ghes: don't check if physical_address is not zero
The 'physical_address' value is a faulty page. As such, 0 is as valid as any other value.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <da32536bf4962e5c03471e2a4e6e0ef92be4a1be.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
26e0893e | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: Change the type for source_id
As described at: ACPI 6.5 spec at: 18.3.2. ACPI Error Source
In particular at GHES/GHESv2 table: Table 18.10 Generic Hardware Error Source Structure
HEST
acpi/ghes: Change the type for source_id
As described at: ACPI 6.5 spec at: 18.3.2. ACPI Error Source
In particular at GHES/GHESv2 table: Table 18.10 Generic Hardware Error Source Structure
HEST source ID is actually a 16-bit value.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <0e83ba548c1aedd1299fe387b94db78986590a34.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
4ffedca3 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: Remove a duplicated out of bounds check
acpi_ghes_record_errors() has an assert() at the beginning to ensure that source_id will be lower than ACPI_GHES_ERROR_SOURCE_COUNT. Remove a dupli
acpi/ghes: Remove a duplicated out of bounds check
acpi_ghes_record_errors() has an assert() at the beginning to ensure that source_id will be lower than ACPI_GHES_ERROR_SOURCE_COUNT. Remove a duplicated check.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <df33b004d85b7b9aa388fb2ac530dcdea94b7edc.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
a85a3b72 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: better handle source_id and notification
GHES has two fields that are stored on HEST error source blocks associated with notifications:
- notification type, which is a number defined at
acpi/ghes: better handle source_id and notification
GHES has two fields that are stored on HEST error source blocks associated with notifications:
- notification type, which is a number defined at the ACPI spec containing several arch-specific synchronous and assynchronous types; - source id, which is a HW/FW defined number, used to distinguish between different implemented sources.
There could be several sources with the same notification type, which is dependent of the way each architecture maps notifications.
Right now, build_ghes_v2() hardcodes a 1:1 mapping between such fields. Move it to two independent parameters, allowing the caller function to fill both.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <133ff72ea1041fed7dbcf97b7a2b0f4dfacde31a.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
606a42c4 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: simplify the per-arch caller to build HEST table
The GHES driver requires not only a HEST table, but also a separate firmware file to store Error Structure records. It can't do one withou
acpi/ghes: simplify the per-arch caller to build HEST table
The GHES driver requires not only a HEST table, but also a separate firmware file to store Error Structure records. It can't do one without the other.
Simplify the caller logic for it to require one function.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <9584bb8953385e165681d5d185c503f8df8ef42f.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
872b69f2 | 15-Jan-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
acpi/ghes: simplify acpi_ghes_record_errors() code
Reduce the ident of the function and prepares it for the next changes.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawe
acpi/ghes: simplify acpi_ghes_record_errors() code
Reduce the ident of the function and prepares it for the next changes.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <19af4188535217213486d169e0501e592bc78a95.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|