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: Fri, 19 Sep 2014 16:30:15 +0800 Message-ID: <541BE997.7080808@intel.com> References: <1406684186-12788-1-git-send-email-tiejun.chen@intel.com> <1406684186-12788-2-git-send-email-tiejun.chen@intel.com> <541ABD800200007800036113@mail.emea.novell.com> <541B84C1.4000403@intel.com> <541BE899020000780003668C@mail.emea.novell.com> <541BD249.3030204@intel.com> <541BF2EA02000078000366E6@mail.emea.novell.com> <541BDDEC.2070007@intel.com> <541C00210200007800036716@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: <541C00210200007800036716@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@intel.com, kevin.tian@intel.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 2014/9/19 16:06, Jan Beulich wrote: >>>> On 19.09.14 at 09:40, wrote: >> On 2014/9/19 15:10, Jan Beulich wrote: >>>>>> On 19.09.14 at 08:50, wrote: >>>> On 2014/9/19 14:26, Jan Beulich wrote: >>>>>>>> On 19.09.14 at 03:20, wrote: >>>>>> (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR: >>>>>> (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:14.0 >>>>>> (XEN) [VT-D]dmar.c:676: RMRR region: base_addr ab805000 end_address >>>>>> ab818fff >>>>>> (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR: >>>>>> (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:02.0 >>>>>> (XEN) [VT-D]dmar.c:676: RMRR region: base_addr ad000000 end_address >>>>>> af7fffff >>>>> >>>>> So how does passing through either of these work for a guest with >>>>> 4Gb or more of memory assigned with just the original 2 patches >>>>> (and with shared page tables)? There ought to be a collision detected >>>>> when trying to do the identity mapping. >>>> >>>> Do you mean this point, mfn_valid(mfn)? If yes, I remember we made >>>> agreement previously about how to cover three cases including this scenario: >>>> >>>> " >>>> #1: !mfn_valid(mfn) >>>> >>>> We can create those mapping safely. >>>> >>>> #2: mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2m_access_rw >>>> >>>> We already have these matched mappings. >>>> >>>> #3: Others >>>> >>>> Return with that waring message: "Cannot identity map d%d:%lx, already >>>> mapped to %lx but mismatch.\n" >>>> " >>>> And this is just as we did in patch #1: >>>> >>>> + >>>> + if ( !mfn_valid(mfn) ) >>>> + ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K, >>>> p2m_mmio_direct, >>>> + p2m_access_rw); >>>> + else if ( mfn_x(mfn) == gfn && >>>> + p2mt == p2m_mmio_direct && >>>> + a == p2m_access_rw ) >>>> + ret = 0; >>>> + else >>>> + printk(XENLOG_G_WARNING >>>> + "Cannot identity map d%d:%lx, already mapped to %lx.\n", >>>> + d->domain_id, gfn, mfn_x(mfn)); >>> >>> Right, but the important point is that when the warning gets printed >>> -EBUSY gets returned, i.e. in the end the device assignment is to fail. >>> Are you seeing the warning when creating a large enough guest? If >> >> My platform just own 4G memory, so after I try to set 'memory=15360' in >> domu.cfg, I can't boot such a VM: >> >> # xl cr domu.cfg >> Parsing config from domu.cfg >> libxl: error: libxl.c:4202:libxl_set_memory_target: new target 0 for >> dom0 is below the minimum threshhold >> ... >> failed to free memory for the domain >> >>> not - can you explain why you don't see it (as I can't)? >> >> Do you know exactly how to test this case as you expect here? Then I can >> take a further look to step on your question. Or I guess you are hinting >> something wrong should be happened but I never realize that previously. > > 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. I will have to try seeking a appropriate machine. Thanks Tiejun > > Jan > > >