From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT Date: Mon, 22 Sep 2014 09:53:57 +0100 Message-ID: <541FFFC50200007800036C28@mail.emea.novell.com> References: <541FB087.4080008@intel.com> <541FB7C3.9080608@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <541FB7C3.9080608@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 Z Zhang , Kevin , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>> On 22.09.14 at 07:46, wrote: >> >> It should suffice to give 3 Gb (or event slightly less) of memory to >> >> the DomU (if your Dom0 can hopefully tolerate running with just 1Gb). >> > >> > Yes. So I can't produce that real case of conflict with those existing >> > RMRR in my platform. >> >> When you pass 3Gb to the guest, its memory map should extend to >> about 0xC0000000, well beyond the range the RMRRs reference. So > > Yes. So I set memory size as 2816M which also cover all RMRR ranges in > my platform. > >> you ought to be able to see the collision (or if you don't you ought to >> have ways to find out why they're not happening, as that would be a >> sign of something else being bogus). >> > > Then I can see that work as we expect: > > # xl cr hvm.cfg > Parsing config from hvm.cfg > libxl: error: libxl_pci.c:949:do_pci_add: xc_assign_device failed: > Operation not permitted > libxl: error: libxl_create.c:1329:domcreate_attach_pci: > libxl_device_pci_add failed: -3 > > And > > # xl dmesg > ... > (XEN) [VT-D]iommu.c:1589: d0:PCI: unmap 0000:00:02.0 > (XEN) [VT-D]iommu.c:1452: d1:PCI: map 0000:00:02.0 > (XEN) Cannot identity map d1:ad000, already mapped to 115d51. > (XEN) [VT-D]iommu.c:2296: IOMMU: mapping reserved region failed > (XEN) XEN_DOMCTL_assign_device: assign 0000:00:02.0 to dom1 failed (-1) > (XEN) [VT-D]iommu.c:1589: d1:PCI: unmap 0000:00:02.0 > (XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:02.0 > ... So after all device assignment fails in that case, which is what I was expecting to happen. Which gets me back to the question: What's the value of the two patches for you if with them you can't pass through anymore the device you want passed through for the actual work you're doing? Jan