diff options
author | Joby Poriyath <joby.poriyath@citrix.com> | 2013-09-09 10:43:11 +0200 |
---|---|---|
committer | Jan Beulich <jbeulich@suse.com> | 2013-09-09 10:43:11 +0200 |
commit | a35137373aa9042424565e5ee76dc0a3bb7642ae (patch) | |
tree | 048b5938c762b7df6cdfabffdd16c3636d278b93 /xen/common | |
parent | a350f3f43bcfac9c1591e28d8e43c505fcb172a5 (diff) | |
download | xen-a35137373aa9042424565e5ee76dc0a3bb7642ae.tar.gz xen-a35137373aa9042424565e5ee76dc0a3bb7642ae.tar.bz2 xen-a35137373aa9042424565e5ee76dc0a3bb7642ae.zip |
x86: allow guest to set/clear MSI-X mask bit (try 2)
Guest needs the ability to enable and disable MSI-X interrupts
by setting the MSI-X control bit, for a passed-through device.
Guest is allowed to write MSI-X mask bit only if Xen *thinks*
that mask is clear (interrupts enabled). If the mask is set by
Xen (interrupts disabled), writes to mask bit by the guest is
ignored.
Currently, a write to MSI-X mask bit by the guest is silently
ignored.
A likely scenario is where we have a 82599 SR-IOV nic passed
through to a guest. From the guest if you do
ifconfig <ETH_DEV> down
ifconfig <ETH_DEV> up
the interrupts remain masked. On VF reset, the mask bit is set
by the controller. At this point, Xen is not aware that mask is set.
However, interrupts are enabled by VF driver by clearing the mask
bit by writing directly to BAR3 region containing the MSI-X table.
From dom0, we can verify that
interrupts are being masked using 'xl debug-keys M'.
Initially, guest was allowed to modify MSI-X bit.
Later this behaviour was changed.
See changeset 74c213c506afcd74a8556dd092995fd4dc38b225.
Signed-off-by: Joby Poriyath <joby.poriyath@citrix.com>
Diffstat (limited to 'xen/common')
0 files changed, 0 insertions, 0 deletions