| Message ID | 20210729135210.16970-1-sidcha@amazon.de |
|---|---|
| State | New |
| Headers | show |
| Series | hyperv: Fix struct hv_message_header ordering | expand |
diff --git a/include/hw/hyperv/hyperv-proto.h b/include/hw/hyperv/hyperv-proto.h index 21dc28aee9..f578a60e78 100644 --- a/include/hw/hyperv/hyperv-proto.h +++ b/include/hw/hyperv/hyperv-proto.h @@ -101,9 +101,9 @@ struct hyperv_signal_event_input { */ struct hyperv_message_header { uint32_t message_type; - uint8_t payload_size; - uint8_t message_flags; /* HV_MESSAGE_FLAG_XX */ uint8_t _reserved[2]; + uint8_t message_flags; /* HV_MESSAGE_FLAG_XX */ + uint8_t payload_size; uint64_t sender; };
According to Hyper-V TLFS Version 6.0b, struct hv_message_header members should be defined in the order: message_type, _reserved, message_flags, payload_size but we have it defined in the order: message_type, payload_size, message_flags, _reserved that is, the payload_size and _reserved members swapped. Due to this mix up, we were inadvertently causing two issues: - The payload_size field has invalid data; it didn't cause an issue so far because we are delivering only timer messages which has fixed size payloads the guest probably did a sizeof(payload) instead relying on the value of payload_size member. - The message_flags was always delivered as 0 to the guest; fortunately, according to section 13.3.1 message_flags is also treated as a reserved field. Although this is not causing an issue now, it might in future (we are adding more message types in our VSM implementation) so fix it to reflect the specification. Signed-off-by: Siddharth Chandrasekaran <sidcha@amazon.de> --- include/hw/hyperv/hyperv-proto.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)