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: Thu, 24 Jul 2014 19:51:04 +0800 Message-ID: <53D0F328.80902@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140724113528.GD1821@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, JBeulich@suse.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 2014/7/24 19:35, Tim Deegan wrote: > At 19:25 +0800 on 24 Jul (1406226315), Chen, Tiejun wrote: >> On 2014/7/24 19:11, Tim Deegan wrote: >>> At 19:00 +0800 on 24 Jul (1406224818), Tiejun Chen wrote: >>>> intel_iommu_map_page() does nothing if VT-d shares EPT page table. >>>> So rmrr_identity_mapping() never create RMRR mapping but in some >>>> cases like some GFX drivers it still need to access RMRR. >>>> >>>> Here we will create those RMRR mappings even in shared EPT case. >>>> >>>> Signed-off-by: Tiejun Chen >>> >>> For the interaction with p2m code: >>> >>> Acked-by: Tim Deegn >> >> Thanks a lot. >> >>> >>> though I am still worried about what happens if this overwrites an >>> existing mapping. >>> >> >> As I understand RMRR should be specific. Its unlikely created for >> different mapping since this should be fixed in BIOS phase. And this is >> why that function is named as rmrr_identity_mapping(). > > But the BIOS only sets up _Xen's_ memory map. The toolstack sets up > the _VM's_ memory map, and unless it can avoid the RMRRs of all > devices in the system (and add them to guest E820s) it risks a clash > here. 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. > > If you can hot-plug one of these devices into a running guest, then > there's no way to be safe, as the guest might have been booted on > another system and migrated. I guess the original RMRR implementation don't consider live migration so current RMRR shouldn't support live migration, right? So this should be anther story we need to address. > > So I think it would be prudent to at least try to detect a clash here > and return an error. Or do you already have some better ways to do this? I'd like to code them in another thread. Tiejun > > (BTW, I think this patch can go in as-is, and the address-space clash > be fixed up separately.) > > Tim. > >