From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v4 RFC 6/6] x86/MSI: properly track guest masking requests Date: Thu, 25 Jun 2015 15:26:48 +0100 Message-ID: <558C0FA8.7060303@citrix.com> References: <558839ED02000078000879FE@mail.emea.novell.com> <55883D290200007800087A67@mail.emea.novell.com> <558AE7DD.6090908@citrix.com> <558BD23A0200007800089597@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 1Z887H-0000GK-SP for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 14:26:59 +0000 In-Reply-To: <558BD23A0200007800089597@mail.emea.novell.com> 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 Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 25/06/15 09:04, Jan Beulich wrote: >>>> On 24.06.15 at 19:24, wrote: >> On 22/06/15 15:51, Jan Beulich wrote: >>> --- a/xen/arch/x86/msi.c >>> +++ b/xen/arch/x86/msi.c >>> @@ -1308,6 +1308,39 @@ printk("%04x:%02x:%02x.%u: MSI-X %03x:%u >>> return 1; >>> } >>> >>> + entry = find_msi_entry(pdev, -1, PCI_CAP_ID_MSI); >>> + if ( entry && entry->msi_attrib.maskbit ) >>> + { >>> + uint16_t cntl; >>> + uint32_t unused; >>> + >>> + pos = entry->msi_attrib.pos; >>> + if ( reg < pos || reg >= entry->msi.mpos + 8 ) >>> + return 0; >>> +printk("%04x:%02x:%02x.%u: MSI %03x:%u->%04x\n", seg, bus, slot, func, reg, size, *data);//temp >>> + >>> + if ( reg == msi_control_reg(pos) ) >>> + return size == 2 ? 1 : -EACCES; >>> + if ( reg < entry->msi.mpos || reg >= entry->msi.mpos + 4 || size != 4 ) >>> + return -EACCES; >> Can we avoid using EACCES to avoid confusing it with a mismatched tools >> version? > What other suitable error code would you see here? I'm not sure > we want this error code to be reserved for exactly one purpose, > the more that here we're on a path that will never has this error > code returned to the guest (and even less so via a domctl/sysctl, > which would be the primary mismatched-tools-version candidates). If there is no chance that we will end up back on a domctl/sysctl error path then its use is fine. ~Andrew