aboutsummaryrefslogtreecommitdiffstats
path: root/xen/common
diff options
context:
space:
mode:
authorJoby Poriyath <joby.poriyath@citrix.com>2013-09-09 10:43:11 +0200
committerJan Beulich <jbeulich@suse.com>2013-09-09 10:43:11 +0200
commita35137373aa9042424565e5ee76dc0a3bb7642ae (patch)
tree048b5938c762b7df6cdfabffdd16c3636d278b93 /xen/common
parenta350f3f43bcfac9c1591e28d8e43c505fcb172a5 (diff)
downloadxen-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