From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT Date: Mon, 22 Sep 2014 17:05:30 +0800 Message-ID: <541FE65A.8070803@intel.com> References: <541FB087.4080008@intel.com> <541FB7C3.9080608@intel.com> <541FFFC50200007800036C28@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <541FFFC50200007800036C28@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: Yang Z Zhang , Kevin , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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. When we want to implement a bigger or complicated feature, I think its reasonable to phase that with multiple steps. Thanks Tiejun