From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: kvm device assignment and MSI-X masking Date: Tue, 14 Aug 2012 15:48:26 +0200 Message-ID: <502A572A.5040408@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm To: Alex Williamson Return-path: Received: from david.siemens.de ([192.35.17.14]:30916 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751663Ab2HNNs3 (ORCPT ); Tue, 14 Aug 2012 09:48:29 -0400 Sender: kvm-owner@vger.kernel.org List-ID: Hi Alex, you once wrote this comment in device-assignment.c, msix_mmio_write: if (!msix_masked(&orig) && msix_masked(entry)) { /* * Vector masked, disable it * * XXX It's not clear if we can or should actually attempt * to mask or disable the interrupt. KVM doesn't have * support for pending bits and kvm_assign_set_msix_entry * doesn't modify the device hardware mask. Interrupts * while masked are simply not injected to the guest, so * are lost. Can we get away with always injecting an * interrupt on unmask? */ I'm wondering what made you think that we won't inject if the vector is masked like this (ie. in the shadow MSI-X table). Can you recall the details? I'm trying to refactor this code to make the KVM interface a bit more encapsulating the kernel interface details, not fixing anything. Still, I would also like to avoid introducing regressions. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux