From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malcolm Crossley Subject: Re: [PATCH v4] hw/passthrough: Prevent QEMU from mapping PCI option ROM at address 0 Date: Mon, 12 May 2014 16:59:33 +0100 Message-ID: <5370EFE5.9050504@citrix.com> References: <1399909019-5812-1-git-send-email-malcolm.crossley@citrix.com> <53710A6F02000078000118D0@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53710A6F02000078000118D0@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: Ian.Jackson@citrix.com, Paul.Durrant@citrix.com, Ian.Campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 12/05/14 16:52, Jan Beulich wrote: >>>> On 12.05.14 at 17:36, wrote: >> The PCI option ROM BAR uses the LSB to indicate if the BAR is enabled. >> The AMD graphics driver sets the address bit's of the BAR to 0 but leaves >> the >> LSB set to 1. Whilst this is not good practice, QEMU should be ignoring the >> non address parts of the BAR. > > All you say above only warrants the PCI defined bits to be masked > off, ... > But we've only got 4k mapping granularity with the IOMMU, so if we try to map to an address between 2k and 4k then we will overlap with the bottom 2k which is likely to cause problems. Malcolm >> This patch adds masking of the bits 0-11 (4k page) parts of the BAR >> before comparing the address to 0. > > ... i.e. 0-10 (2k). > > Jan >