Hi, > From what I can see the guest OS will read this bitmap when it first > probes the virtio device, and never updates it. If so, then is it > actually a problem if we don't preserve the same map across save/ > restore/migrate ?
virtio-input config space size isn't fixed, instead it'll take up as many bytes as actually needed. So, when adding keys it can happen that the bitmap needed grows, therefore the config space grows. Not sure whenever live migration trips over that, needs checking. > If we added a key to the bitmap, we would potentially be sending > a key to the guest that we hadn't previously declared support for. > Either the guest OS will handle this normally, despite it not > being in the declared bitmap, or it will silently drop the event. > Neither behaviour seems problematic. Yes, in theory the guest drivers should be robust enough. We should check though whenever that is actually the case. > If we did need to preserve ABI for this bitmap, then it seems we're > going to create alot of work for ourselves, having to maintain > many historical copies of the keycode maps tables, adding a new > copy every time support for a new key is added in QEMU. That's why I've suggested to not touch that for now, and once the dust has settled and QKeyCode got all the keys still missing create a v2 of the device, so we don't end up with many different versions. cheers, Gerd