qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/3] VFIO: Clear INTx pending state o


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/3] VFIO: Clear INTx pending state on EEH reset
Date: Mon, 16 Mar 2015 15:05:32 +1100

On Mon, 2015-03-16 at 12:04 +1100, Gavin Shan wrote:
> 
> 
> (2) QEMU sends IOCTL commands to host to disable MSIx and enable INTx. At
> this stage the INTx is still masked. At later point, the guest is requesting
> unmasking INTx, which is captured by host. Host checks and founds pending
> INTx, which is sent to QEMU. In QEMU INTx handler (vfio_intx_interrupt()),
> the mmap'ed regions are disabled, "intx.pending" is set and a timer is started
> to reenable mmap'ed regions if "intx.pending" is cleared there. However,
> "intx.pending" is only cleared upon BAR access in slow path, which is never
> happing.
> 
> (3) After guest disables MSIx and issue EEH reset, the device driver starts
> to check its firmware state by reading MMIO register, which isn't completed
> by QEMU VFIO BAR slow path (Note: fast path supported by mmaped regions have
> been disabled). Eventually, the guest hangs on reading MMIO register. With
> this patch applied to QEMU, I didn't see the problem again. 

Note that it might be a good idea to disable INTx (and synchronize with a cfg
read of some sort) around resetting a device.

Otherwise, you may hit a known issue if the device is behind a switch and has
sent the INTx "assert" message, and not the "deassert" one before it gets reset.

That can cause the INTx to effectively be "stuck" in the switch preventing a
subsequent one from being delivered.

Cheers,
Ben.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]