[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/i386: Use unaligned store functions building
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] [PATCH] hw/i386: Use unaligned store functions building acpi tables |
Date: |
Thu, 13 Mar 2014 06:30:01 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
On 03/12/2014 04:26 PM, Peter Maydell wrote:
> On 12 March 2014 22:25, Richard Henderson <address@hidden> wrote:
>> Hosts that don't support native unaligned stores will SIGBUS
>> without additional help.
>>
>> Signed-off-by: Richard Henderson <address@hidden>
>> ---
>> hw/i386/acpi-build.c | 29 +++++++++++++++--------------
>> 1 file changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>> index b1a7ebb..d636115 100644
>> --- a/hw/i386/acpi-build.c
>> +++ b/hw/i386/acpi-build.c
>> @@ -886,22 +886,24 @@ static void build_pci_bus_end(PCIBus *bus, void
>> *bus_state)
>>
>> static void patch_pci_windows(PcPciInfo *pci, uint8_t *start, unsigned size)
>> {
>> - *ACPI_BUILD_PTR(start, size, acpi_pci32_start[0], uint32_t) =
>> - cpu_to_le32(pci->w32.begin);
>> + /* Note that these pointers are unaligned, so we must use routines
>> + that take care for unaligned stores on the host. */
>>
>> - *ACPI_BUILD_PTR(start, size, acpi_pci32_end[0], uint32_t) =
>> - cpu_to_le32(pci->w32.end - 1);
>> + stl_le_p(ACPI_BUILD_PTR(start, size, acpi_pci32_start[0], uint32_t),
>> + pci->w32.begin);
>> + stl_le_p(ACPI_BUILD_PTR(start, size, acpi_pci32_end[0], uint32_t),
>> + pci->w32.end - 1);
>
> See the mail thread on Michael's original patch -- he didn't like
> this because we end up writing the size of the store twice
> (once in the "l" suffix in the function name and once by passing
> a type to the ACP_BUILD_PTR function.
I missed the original thread somewhere.
> (That thread also has my personal preferred option in the comments,
> which uses stl_le_p and friends but via a wrapping macro.)
I'm in favour of any solution that doesn't duplicate the bswap logic, like the
version I responded to did.
r~
>
> Also you'll find this doesn't apply because a fix has already been
> committed on master...
>
>> - *(uint16_t *)(ssdt_ptr + *ssdt_isa_pest) =
>> - cpu_to_le16(misc->pvpanic_port);
>> + stw_le_p(ssdt_ptr + *ssdt_isa_pest, misc->pvpanic_port);
>
> Patch on list to fix this too I think.
>
> thanks
> -- PMM
>