mirror of
https://chromium.googlesource.com/crosvm/crosvm
synced 2025-02-06 02:25:23 +00:00
b3d382c942
VirtioPciCap omits the `cap_vndr` and `cap_next` fields from it's definition, deferring the instantiation of these bytes to the add_capability method in PCI configuration. There is even a comment on add_capability that mentions this omission. Unfortunately, comments tend not to be read, and mismatches between the linux headers and crosvm structures can result in some subtle and tricky to debug bugs, especially when implementing other types of virtio capabilties that subsume VirtioPciCap. Case in point, when implementing the VirtioPciShmCap (used by virtio-fs), this subtle mismatch resulted in a bug where an additional 2 bytes of padding were inserted between the `cap` member and the `offset_hi` member (see CL:1493014 for the exact struct). Since the cap_len field was instantiated using mem::sizeof Self, the additional padding just-so-happened to be the perfect ammount to sneak past the sanity checks in add_capabilities. The bug manifested itself by shifting over the length_hi field by 16 bits, resulting in much larger than expected cache sizes. This CL brings the VirtioPciCap structures in-line with their linux/virtio_pci.h counterparts, marking the structures as repr(C) (as opposed to repr(packed)) and leaving the cap_vndr and cap_next members in the struct, noting that they will be automatically populated in add_capability. BUG=chromium:936567 TEST=cargo test -p devices, boot vm Change-Id: Ia360e532b58070372a52346e85dd4e30e81ace7a Reviewed-on: https://chromium-review.googlesource.com/1540397 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||