Re: [qemu-s390x] [PATCH v2 1/3] hw/s390x/ipl: Fix alignment problems of S390IPLState members

[Thomas Huth]

On 2018-09-26 11:55, Cornelia Huck wrote:
> On Wed, 26 Sep 2018 11:46:22 +0200
> Thomas Huth <address@hidden> wrote:
> 
>> On 2018-09-26 11:42, Cornelia Huck wrote:
>>> On Wed, 26 Sep 2018 09:38:45 +0200
>>> Thomas Huth <address@hidden> wrote:
>>>   
>>>> The IplParameterBlock and QemuIplParameters structures are declared
>>>> with QEMU_PACKED, so the compiler assumes that the structures do not
>>>> need to be aligned in memory. Since the are listed after a "bool"
>>>> within the S390IPLState, the IplParameterBlock and QemuIplParameters
>>>> are also indeed mis-aligned in memory. This causes problems on Sparc
>>>> during migration, since we use VMSTATE_UINT16 in vmstate_iplb to access
>>>> the devno member for example, and the corresponding migration functions
>>>> (like qemu_get_be16s) then try to access a 16-bit value from a mis-
>>>> aligned memory address.
>>>> The easiest solution to fix this problem is to move the packed structures
>>>> to the beginning of the S390IPLState. Also add some additional comments
>>>> here to prevent that this problem will be introduced again in the future.
>>>>
>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>> ---
>>>>  hw/s390x/ipl.h | 5 +++--
>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
>>>> index 4e87b89..b3a07a1 100644
>>>> --- a/hw/s390x/ipl.h
>>>> +++ b/hw/s390x/ipl.h
>>>> @@ -132,15 +132,15 @@ typedef struct QemuIplParameters QemuIplParameters;
>>>>  struct S390IPLState {
>>>>      /*< private >*/
>>>>      DeviceState parent_obj;
>>>> +    IplParameterBlock iplb;
>>>> +    QemuIplParameters qipl;  
>>>
>>> Hm... this is not quite the beginning of the structure; what am I
>>> missing?  
>>
>> DeviceState of course has to stay first for QOM reasons. But since it is
>> a non-packed struct, we can be sure that it will be padded to the
>> correct alignment at the end. If not, the QEMU_BUILD_BUG_MSG in this
>> patch will tell us.
> 
> What about adding that explanation to the commit message?
> 
> [I can do that.]

Sure, if you could do that, that would be great!

 Thanks,
  Thomas