From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wu, Feng" Subject: Re: [PATCH 1/2] x86/vMSI-X: honor all mask requests Date: Wed, 25 Mar 2015 05:49:14 +0000 Message-ID: References: <550C5065020000780006C27E@mail.emea.novell.com> <550C5881020000780006C2AE@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YaeBt-0001kO-LX for xen-devel@lists.xenproject.org; Wed, 25 Mar 2015 05:49:21 +0000 In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: Andrew Cooper , Keir Fraser , "Wu, Feng" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Wu, Feng > Sent: Wednesday, March 25, 2015 1:41 PM > To: Jan Beulich; xen-devel > Cc: Andrew Cooper; Keir Fraser; Wu, Feng > Subject: RE: [Xen-devel] [PATCH 1/2] x86/vMSI-X: honor all mask requests > > > > > -----Original Message----- > > From: xen-devel-bounces@lists.xen.org > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich > > Sent: Saturday, March 21, 2015 12:27 AM > > To: xen-devel > > Cc: Andrew Cooper; Keir Fraser > > Subject: [Xen-devel] [PATCH 1/2] x86/vMSI-X: honor all mask requests > > > > Commit 74fd0036de ("x86: properly handle MSI-X unmask operation from > > guests") didn't go far enough: it fixed an issue with unmasking, but > > left an issue with masking in place: Due to the (late) point in time > > when qemu requests the hypervisor to set up MSI-X interrupts (which is > > where the MMIO intercept gets put in place), the hypervisor doesn't > > see all guest writes, and hence shouldn't make assumptions on the state > > the virtual MSI-X resources are in. Bypassing the rest of the logic on > > a guest mask operation leads to > > > > [00:04.0] pci_msix_write: Error: Can't update msix entry 1 since MSI-X is > > already enabled. > > > > which surprisingly enough doesn't lead to the device not working > > anymore (I didn't dig in deep enough to figure out why that is). But it > > does prevent the IRQ to be migrated inside the guest, i.e. all > > interrupts will always arrive in vCPU 0. > > > > Signed-off-by: Jan Beulich > > > > --- a/xen/arch/x86/hvm/vmsi.c > > +++ b/xen/arch/x86/hvm/vmsi.c > > @@ -286,11 +286,11 @@ static int msixtbl_write(struct vcpu *v, > > goto out; > > } > > > > - /* exit to device model if address/data has been modified */ > > - if ( test_and_clear_bit(nr_entry, &entry->table_flags) ) > > + /* Exit to device model when unmasking and address/data got > modified. > > */ > > + if ( !(val & PCI_MSIX_VECTOR_BITMASK) && > > + test_and_clear_bit(nr_entry, &entry->table_flags) ) > > Is it more accurate as the follows? > > If ( (offset == PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET) && > !(val & PCI_MSIX_VECTOR_BITMASK) && > test_and_clear_bit(nr_entry, &entry->table_flags) ) Oh, just found "offset == PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET" is not needed here, it guarantees this when we get here. Thanks, Feng > > BTW, how can I reproduce this issue? > > Thanks, > Feng > > > { > > - if ( !(val & PCI_MSIX_VECTOR_BITMASK) ) > > - v->arch.hvm_vcpu.hvm_io.msix_unmask_address = address; > > + v->arch.hvm_vcpu.hvm_io.msix_unmask_address = address; > > goto out; > > } > > > > > >