qemu-devel
[Top][All Lists]
Advanced

[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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]