From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v3][PATCH 1/1] xen:vtd: missing RMRR mapping while share EPT Date: Fri, 25 Jul 2014 15:53:37 +0800 Message-ID: <53D20D01.2070806@intel.com> References: <1406199618-21574-1-git-send-email-tiejun.chen@intel.com> <20140724111143.GF1817@deinos.phlegethon.org> <53D0ED1B.80107@intel.com> <20140724113528.GD1821@deinos.phlegethon.org> <53D0F328.80902@intel.com> <53D1154A0200007800025857@mail.emea.novell.com> <53D1FDD8.7020002@intel.com> <53D21E4F0200007800025CD7@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: <53D21E4F0200007800025CD7@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, Tim Deegan , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 2014/7/25 15:07, Jan Beulich wrote: >>>> On 25.07.14 at 08:48, wrote: >> On 2014/7/24 20:16, Jan Beulich wrote: >>>>>> On 24.07.14 at 13:51, wrote: >>>> RMRR seems be used barely. Here in my case, just GFX passthrough needs >>>> this since some windows GFX drivers may access those stolen memory now. >>> >>> USB legacy emulation is another use case iirc, as seen on at least >>> one of the systems I have here. >>> >>> Furthermore an RMRR (as pointed out a couple of months ago) >> >> I'm poor in this problem, so could you point where I can get this >> discussion? I think I should take a look at that to know about more. > > http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg00824.html > (continued in March; the list server doesn't properly deal with > cross-month follow-ups, so you'll need to search for the same > subject in > http://lists.xenproject.org/archives/html/xen-devel/2014-03/threads.html) > >>> may be related to more than one device (at least in theory), and >> >> Are you saying one RMRR corresponds to multiple devfns? > > Yes, just look at acpi_parse_one_rmrr() and its helper > acpi_parse_dev_scope(): There's nothing there enforcing just > a single device per RMRR. > >>> in such case it is insecure to assign these devices to distinct >>> domains. >> >> But looks we always create one RMRR when an associated devfn is assigned >> to one given domain, so this mean its always insecure before I introduce >> this patch, right? > > If you meant "already" instead of "always", then yes. Your patch > is just widening the issue. > Jan, Such this kind of problem just happens in shared EPT case, right? In non-shared EPT case, we don't create these EPT tables to override other EPTs, so its okay? Tiejun