From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [v7][PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr Date: Tue, 14 Jul 2015 10:19:52 +0100 Message-ID: <55A4F0580200007800090810@mail.emea.novell.com> References: <1436420047-25356-1-git-send-email-tiejun.chen@intel.com> <1436420047-25356-16-git-send-email-tiejun.chen@intel.com> <55A3DC29020000780009037A@mail.emea.novell.com> <55A468FE.1020100@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A468FE.1020100@intel.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: Tiejun Chen Cc: Yang Zhang , Kevin Tian , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >>> On 14.07.15 at 03:42, wrote: >> > + { >>> + printk(XENLOG_G_ERR VTDPREFIX >>> + " cannot assign %04x:%02x:%02x.%u" >>> + " with shared RMRR for Dom%d.\n", >>> + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >>> + d->domain_id); >>> + return -EPERM; >>> + } >>> + } >> >> Two if()-s like these should be folded into one. >> >> In your place I'd also consider also printing the RMRR base address >> for easier analysis of the issue. >> > > I agree but I think the whole range info should be better, > > " with shared RMRR [%"PRIx64",%"PRIx64"] for Dom%d.\n", Perhaps, albeit due to there not being overlapping RMRRs the base address is sufficient for uniquely identifying the one in question. Jan