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: Tue, 23 Sep 2014 09:56:39 +0800 Message-ID: <5420D357.1060202@intel.com> References: <541FB087.4080008@intel.com> <541FB7C3.9080608@intel.com> <541FFFC50200007800036C28@mail.emea.novell.com> <541FE65A.8070803@intel.com> <542017E80200007800036D1E@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: <542017E80200007800036D1E@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 18:36, Jan Beulich wrote: >>>> 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). > Why did you say this is a regression? Without these two patches, any assigned device with RMRR dependency can't work at all since RMRR table never be created. But if we apply these two patches, RMRR table can be created safely, right? Then the assigned device can work based on them. Thanks Tiejun