On 2012-05-24 20:56, Thomas Gleixner wrote: > On Thu, 24 May 2012, Alex Williamson wrote: > >> On Fri, 2012-05-25 at 01:01 +0200, Thomas Gleixner wrote: >>> So the proper fix is that qemu tells the guest that mask bit is >>> supported and catches the mask bit toggling before writing it out to >>> the hardware for those devices which do not support it. >> >> We can't necessarily do that, we have to work with the config space >> we're give. Using the smallest possible MSI capability always works. >> Adding mask bits may not fit in with the existing capabilities of the >> physical device. Thanks, > > I see what you mean. A random device driver of a random guest OS might > rely on that information. Unlikely, but .... > > So we need some logic to circumvent the masked/unmasked logic in case > that property is not set, right ? For MSI emulation in QEMU (including device assignment) it is quite simple: don't assume that the guest will always mask or even disable before fiddling with some MSI vector configuration. That is not required by the spec, so we can't rely on it. The patches I have in a semi-finished state will do precisely this. But there is still some use for a dev-assign fix based on the current code for qemu-kvm-1.1. BTW, along with the switch of device assignment to generic MSI support, we should also gain support for MSI vector masking - provided the underlying device comes with that feature as well. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
