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 11:36:56 +0100 Message-ID: <542017E80200007800036D1E@mail.emea.novell.com> References: <541FB087.4080008@intel.com> <541FB7C3.9080608@intel.com> <541FFFC50200007800036C28@mail.emea.novell.com> <541FE65A.8070803@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <541FE65A.8070803@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 11:05, wrote: > On 2014/9/22 16:53, Jan Beulich wrote: >>>>> 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? > > I don't understand what you mean again. This is true we already known > previously because this is just a part of the whole solution, right? So > I can't understand why we can't apply them now unless you're saying > they're wrong. You want these two patches applied despite having acknowledged that even for you they cause a regression (at the very least an apparent one). Jan