It is true that writes/reads of an MSI-X table are either 32 or 64 bits
long. However, we do check for this invariant in the `match` expression
just after the assertion. If the invariant is not held (the guest tried
to read/write with an invalid length) we just print an error and
continue. This branch of the `match` block is never reached due to the
assertion itself.

To simplify things, just remove the assertion and let the `match` block
logic handle invalid memory accesses. This should also help us better
fuzz the bus accesses.

Do add a check that the data access is up to 8 bytes long. These are
all MMIO or Port IO accesses and they can't be bigger than 8 bytes. So
this assertion should never fail in production (unless there's a KVM
bug or we try to run Firecracker in some architecture that allows more
than 64bit memory accesses).

Signed-off-by: Babis Chalios <[email protected]>

We were using a Hashmap to store the GSIs that were used by the vectors
of an MSI-X group. These vectors were always indexed starting by 0, so
we can just use a simple Vec.

Signed-off-by: Babis Chalios <[email protected]>

We are using a HashMap to track the interrupt routes we use in the
system. The index to the HashMap is the GSI of the interrupt route.
We know the maximum number of GSIs we have available so pre-allocate the
space for the HashMap to avoid reallocations at runtime.

Signed-off-by: Babis Chalios <[email protected]>

Fix a bug in the common VirtIO configuration for PCI transport where we
would use `queue_select` to read the queue's MSI vector without
validating it matches a valid queue. This could lead in panics when
accessing the `msix_queue` array. The spec states that in such cases we
should return `NO_VECTOR` (0xffff), so do that.

Signed-off-by: Babis Chalios <[email protected]>

We were shifting by the wrong number of bits for 2-byte accesses.

Signed-off-by: Babis Chalios <[email protected]>