From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v4 RFC 6/6] x86/MSI: properly track guest masking requests Date: Thu, 25 Jun 2015 15:49:26 +0100 Message-ID: <558C31160200007800089BBE@mail.emea.novell.com> References: <558839ED02000078000879FE@mail.emea.novell.com> <55883D290200007800087A67@mail.emea.novell.com> <558AE7DD.6090908@citrix.com> <558BD23A0200007800089597@mail.emea.novell.com> <558C0FA8.7060303@citrix.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 1Z88T3-0002Ir-Pc for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 14:49:29 +0000 In-Reply-To: <558C0FA8.7060303@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 25.06.15 at 16:26, wrote: > 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. I don't see how it could get on such a patch - it's an intercept of a guest (Dom0) operation. If we were to introduce hypercall based PCI config space writes, then that would be a physdev op imo. Jan