On Mon, May 18, 2009 at 05:46:09PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>>> If it generates the interrupt after masking it in the msi-x entry,
>>> we'll see it. If it generates the interrupt before masking it, it
>>> may or may not receive the interrupt, even on real hardware.
>>>
>>
>> Yes but in the later case, real hardware must re-send the pending
>> interrupt after it is unmasked (that's the spec). We would just lose it.
>>
>
> That's a different matter. We need to buffer the interrupt pending bit,
> and a way for userspace to either query that buffer or have a
> conditional injection (inject_if_pending).
Here's the race as I see it: we discussed the possibility
of making kernel and user share and actual memory page,
and using that for MSI-X tables.
host kernel want to send msi x message
host kernel test mask bit: unmasked
guest sets mask bit
guest does read to flash msi writes
guest does sync irq and makes sure there are no
outstanging interrupts
---> at this stage guest expects not to get interrupts
guest starts editing msix entry
host kernel never saw mask so it sends message to the old address
or even a corrupted address which the guest is in
the middle of editing
bad things happen
This race is not easy to solve, except by catching writes to msix table,
and syncronising them with interrupt delivery.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
