From: Eric DeVolder <eric.devolder@oracle.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: ehabkost@redhat.com, mst@redhat.com, konrad.wilk@oracle.com,
qemu-devel@nongnu.org, pbonzini@redhat.com,
boris.ostrovsky@oracle.com, rth@twiddle.net
Subject: Re: [PATCH v5 06/10] ACPI ERST: build the ACPI ERST table
Date: Mon, 26 Jul 2021 15:02:55 -0500 [thread overview]
Message-ID: <078e48aa-e6eb-44a8-c60f-7bc5a64c5e1c@oracle.com> (raw)
In-Reply-To: <20210726130040.2cb8f717@redhat.com>
On 7/26/21 6:00 AM, Igor Mammedov wrote:
> On Wed, 21 Jul 2021 11:12:41 -0500
> Eric DeVolder <eric.devolder@oracle.com> wrote:
>
>> On 7/20/21 8:16 AM, Igor Mammedov wrote:
>>> On Wed, 30 Jun 2021 15:07:17 -0400
>>> Eric DeVolder <eric.devolder@oracle.com> wrote:
>>>
>>>> This code is called from the machine code (if ACPI supported)
>>>> to generate the ACPI ERST table.
>>> should be along lines:
>>> This builds ACPI ERST table /spec ref/ to inform OSMP
>>> how to communicate with ... device.
>>
>> Like this?
>> This builds the ACPI ERST table to inform OSMP how to communicate
> ^ [1]
>> with the acpi-erst device.
>>
>
> 1) ACPI spec vX.Y, chapter foo
done
>
>>
>>>
>>>>
>>>> Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
>>>> ---
>>>> hw/acpi/erst.c | 214 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 214 insertions(+)
>>>>
>>>> diff --git a/hw/acpi/erst.c b/hw/acpi/erst.c
>>>> index 6e9bd2e..1f1dbbc 100644
>>>> --- a/hw/acpi/erst.c
>>>> +++ b/hw/acpi/erst.c
>>>> @@ -555,6 +555,220 @@ static const MemoryRegionOps erst_mem_ops = {
>>>> /*******************************************************************/
>>>> /*******************************************************************/
>>>>
>>>> +/* ACPI 4.0: 17.4.1.2 Serialization Instruction Entries */
>>>> +static void build_serialization_instruction_entry(GArray *table_data,
>>>> + uint8_t serialization_action,
>>>> + uint8_t instruction,
>>>> + uint8_t flags,
>>>> + uint8_t register_bit_width,
>>>> + uint64_t register_address,
>>>> + uint64_t value,
>>>> + uint64_t mask)
>>> like I mentioned in previous patch, It could be simplified
>>> a lot if it's possible to use fixed 64-bit access with every
>>> action and the same width mask.
>> See previous response.
> lets see if it's a guest OS issue first, and then decide what to do with it.
>
>>
>>>
>>>> +{
>>>> + /* ACPI 4.0: Table 17-18 Serialization Instruction Entry */
>>>> + struct AcpiGenericAddress gas;
>>>> +
>>>> + /* Serialization Action */
>>>> + build_append_int_noprefix(table_data, serialization_action, 1);
>>>> + /* Instruction */
>>>> + build_append_int_noprefix(table_data, instruction , 1);
>>>> + /* Flags */
>>>> + build_append_int_noprefix(table_data, flags , 1);
>>>> + /* Reserved */
>>>> + build_append_int_noprefix(table_data, 0 , 1);
>>>> + /* Register Region */
>>>> + gas.space_id = AML_SYSTEM_MEMORY;
>>>> + gas.bit_width = register_bit_width;
>>>> + gas.bit_offset = 0;
>>>> + switch (register_bit_width) {
>>>> + case 8:
>>>> + gas.access_width = 1;
>>>> + break;
>>>> + case 16:
>>>> + gas.access_width = 2;
>>>> + break;
>>>> + case 32:
>>>> + gas.access_width = 3;
>>>> + break;
>>>> + case 64:
>>>> + gas.access_width = 4;
>>>> + break;
>>>> + default:
>>>> + gas.access_width = 0;
>>>> + break;
>>>> + }
>>>> + gas.address = register_address;
>>>> + build_append_gas_from_struct(table_data, &gas);
>>>> + /* Value */
>>>> + build_append_int_noprefix(table_data, value , 8);
>>>> + /* Mask */
>>>> + build_append_int_noprefix(table_data, mask , 8);
>>>> +}
>>>> +
>>>> +/* ACPI 4.0: 17.4.1 Serialization Action Table */
>>>> +void build_erst(GArray *table_data, BIOSLinker *linker, Object *erst_dev,
>>>> + const char *oem_id, const char *oem_table_id)
>>>> +{
>>>> + ERSTDeviceState *s = ACPIERST(erst_dev);
>>>
>>> globals are not welcomed in new code,
>>> pass erst_dev as argument here (ex: find_vmgenid_dev)
>>>
>>>> + unsigned action;
>>>> + unsigned erst_start = table_data->len;
>>>> +
>>>
>>>> + s->bar0 = (hwaddr)pci_get_bar_addr(PCI_DEVICE(erst_dev), 0);
>>>> + trace_acpi_erst_pci_bar_0(s->bar0);
>>>> + s->bar1 = (hwaddr)pci_get_bar_addr(PCI_DEVICE(erst_dev), 1);
>>>
>>> just store pci_get_bar_addr(PCI_DEVICE(erst_dev), 0) in local variable,
>>> Bar 1 is not used in this function so you don't need it here.
>> Corrected
>>
>>>
>>>
>>>> + trace_acpi_erst_pci_bar_1(s->bar1);
>>>> +
>>>> + acpi_data_push(table_data, sizeof(AcpiTableHeader));
>>>> + /* serialization_header_length */
>>> comments documenting table entries should be verbatim copy from spec,
>>> see build_amd_iommu() as example of preferred style.
>> Corrected
>>
>>>
>>>> + build_append_int_noprefix(table_data, 48, 4);
>>>> + /* reserved */
>>>> + build_append_int_noprefix(table_data, 0, 4);
>>>> + /*
>>>> + * instruction_entry_count - changes to the number of serialization
>>>> + * instructions in the ACTIONs below must be reflected in this
>>>> + * pre-computed value.
>>>> + */
>>>> + build_append_int_noprefix(table_data, 29, 4);
>>> a bit fragile as it can easily diverge from actual number later on.
>>> maybe instead of building instruction entries in place, build it
>>> in separate array and when done, use actual count to fill instruction_entry_count.
>>> pseudo code could look like:
>>>
>>> /* prepare instructions in advance because ... */
>>> GArray table_instruction_data;
>>> build_serialization_instruction_entry(table_instruction_data,...);;
>>> ...
>>> build_serialization_instruction_entry(table_instruction_data,...);
>>> /* instructions count */
>>> build_append_int_noprefix(table_data, table_instruction_data.len/entry_size, 4);
>>> /* copy prepared in advance instructions */
>>> g_array_append_vals(table_data, table_instruction_data.data, table_instruction_data.len);
>> Corrected
>>
>>>
>>>
>>>> +
>>>> +#define MASK8 0x00000000000000FFUL
>>>> +#define MASK16 0x000000000000FFFFUL
>>>> +#define MASK32 0x00000000FFFFFFFFUL
>>>> +#define MASK64 0xFFFFFFFFFFFFFFFFUL
>>>> +
>>>> + for (action = 0; action < ACPI_ERST_MAX_ACTIONS; ++action) {
>>> I'd unroll this loop and just directly code entries in required order.
>>> also drop reserved and nop actions/instructions or explain why they are necessary.
>> Unrolled. Dropped the NOP.
>
> What about 'reserved"?
I dropped Reserved as it was composed of a NOP, and isn't needed either.
>
>>
>>>
>>>> + switch (action) {
>>>> + case ACPI_ERST_ACTION_BEGIN_WRITE_OPERATION:
>>> given these names will/should never be exposed outside of hw/acpi/erst.c
>>> I'd drop ACPI_ERST_ACTION_/ACPI_ERST_INST_ prefixes (i.e. use names as defined in spec)
>>> if it doesn't cause build issues.
>> These are in include/hw/acpi/erst.h which is included by hw/i386/acpi-build.c,
>> which includes many other hardware files.
>> Removing the prefix leaves a rather generic name.
>> I'd prefer to leave them as it uniquely differentiates.
> is there a reason to put them into erst.h and expose to outside world?
> If not then it might be better to move them into erst.c
I've moved them into erst.c
>
>>
>>
>>>
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_BEGIN_READ_OPERATION:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_BEGIN_CLEAR_OPERATION:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_END_OPERATION:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_SET_RECORD_OFFSET:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER , 0, 32,
>>>> + s->bar0 + ERST_CSR_VALUE , 0, MASK32);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_EXECUTE_OPERATION:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_VALUE , ERST_EXECUTE_OPERATION_MAGIC, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_CHECK_BUSY_STATUS:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER_VALUE , 0, 32,
>>>> + s->bar0 + ERST_CSR_VALUE, 0x01, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_COMMAND_STATUS:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 32,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_RECORD_IDENTIFIER:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 64,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK64);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_SET_RECORD_IDENTIFIER:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER , 0, 64,
>>>> + s->bar0 + ERST_CSR_VALUE , 0, MASK64);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_RECORD_COUNT:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 32,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK32);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_BEGIN_DUMMY_WRITE_OPERATION:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_RESERVED:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_ERROR_LOG_ADDRESS_RANGE:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 64,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK64);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_ERROR_LOG_ADDRESS_LENGTH:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 64,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK32);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_ERROR_LOG_ADDRESS_RANGE_ATTRIBUTES:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 32,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK32);
>>>> + break;
>>>> + case ACPI_ERST_ACTION_GET_EXECUTE_OPERATION_TIMINGS:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_WRITE_REGISTER_VALUE, 0, 32,
>>>> + s->bar0 + ERST_CSR_ACTION, action, MASK8);
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_READ_REGISTER , 0, 64,
>>>> + s->bar0 + ERST_CSR_VALUE, 0, MASK64);
>>>> + default:
>>>> + build_serialization_instruction_entry(table_data, action,
>>>> + ACPI_ERST_INST_NOOP, 0, 0, 0, action, 0);
>>>> + break;
>>>> + }
>>>> + }
>>>> + build_header(linker, table_data,
>>>> + (void *)(table_data->data + erst_start),
>>>> + "ERST", table_data->len - erst_start,
>>>> + 1, oem_id, oem_table_id);
>>>> +}
>>>> +
>>>> +/*******************************************************************/
>>>> +/*******************************************************************/
>>>> +
>>>> static const VMStateDescription erst_vmstate = {
>>>> .name = "acpi-erst",
>>>> .version_id = 1,
>>>
>>
>
next prev parent reply other threads:[~2021-07-26 20:05 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 19:07 [PATCH v5 00/10] acpi: Error Record Serialization Table, ERST, support for QEMU Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 01/10] ACPI ERST: bios-tables-test.c steps 1 and 2 Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 02/10] ACPI ERST: specification for ERST support Eric DeVolder
2021-06-30 19:26 ` Eric DeVolder
2021-07-19 15:02 ` Igor Mammedov
2021-07-21 15:42 ` Eric DeVolder
2021-07-26 10:06 ` Igor Mammedov
2021-07-26 19:52 ` Eric DeVolder
2021-07-27 11:45 ` Igor Mammedov
2021-07-28 15:16 ` Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 03/10] ACPI ERST: PCI device_id for ERST Eric DeVolder
2021-07-19 15:06 ` Igor Mammedov
2021-07-21 15:42 ` Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 04/10] ACPI ERST: header file " Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 05/10] ACPI ERST: support for ACPI ERST feature Eric DeVolder
2021-07-20 12:17 ` Igor Mammedov
2021-07-21 16:07 ` Eric DeVolder
2021-07-26 10:42 ` Igor Mammedov
2021-07-26 20:01 ` Eric DeVolder
2021-07-27 12:52 ` Igor Mammedov
2021-08-04 22:13 ` Eric DeVolder
2021-08-05 9:05 ` Igor Mammedov
2021-07-21 17:36 ` Eric DeVolder
2021-07-26 10:13 ` Igor Mammedov
2021-06-30 19:07 ` [PATCH v5 06/10] ACPI ERST: build the ACPI ERST table Eric DeVolder
2021-07-20 13:16 ` Igor Mammedov
2021-07-20 14:59 ` Igor Mammedov
2021-07-21 16:12 ` Eric DeVolder
2021-07-26 11:00 ` Igor Mammedov
2021-07-26 20:02 ` Eric DeVolder [this message]
2021-07-27 12:01 ` Igor Mammedov
2021-07-28 15:18 ` Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 07/10] ACPI ERST: trace support Eric DeVolder
2021-07-20 13:15 ` Igor Mammedov
2021-07-21 16:14 ` Eric DeVolder
2021-07-26 11:08 ` Igor Mammedov
2021-07-26 20:03 ` Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 08/10] ACPI ERST: create ACPI ERST table for pc/x86 machines Eric DeVolder
2021-07-20 13:19 ` Igor Mammedov
2021-07-21 16:16 ` Eric DeVolder
2021-07-26 11:30 ` Igor Mammedov
2021-07-26 20:03 ` Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 09/10] ACPI ERST: qtest for ERST Eric DeVolder
2021-07-20 13:38 ` Igor Mammedov
2021-07-21 16:18 ` Eric DeVolder
2021-07-26 11:45 ` Igor Mammedov
2021-07-26 20:06 ` Eric DeVolder
2021-06-30 19:07 ` [PATCH v5 10/10] ACPI ERST: step 6 of bios-tables-test.c Eric DeVolder
2021-07-20 13:24 ` Igor Mammedov
2021-07-21 16:19 ` Eric DeVolder
2021-07-13 20:38 ` [PATCH v5 00/10] acpi: Error Record Serialization Table, ERST, support for QEMU Michael S. Tsirkin
2021-07-21 15:23 ` Eric DeVolder
2021-07-20 14:57 ` Igor Mammedov
2021-07-21 15:26 ` Eric DeVolder
2021-07-23 16:26 ` Eric DeVolder
2021-07-27 12:55 ` Igor Mammedov
2021-07-28 15:19 ` Eric DeVolder
2021-07-29 8:07 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=078e48aa-e6eb-44a8-c60f-7bc5a64c5e1c@oracle.com \
--to=eric.devolder@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).