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 14:48:56 +0800 Message-ID: <53D1FDD8.7020002@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53D1154A0200007800025857@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 , Tim Deegan Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 2014/7/24 20:16, Jan Beulich wrote: >>>> On 24.07.14 at 13:51, wrote: >> 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: >>>>> 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. > > 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. > may be related to more than one device (at least in theory), and Are you saying one RMRR corresponds to multiple devfns? > 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? But if I'm wrong please correct me. > > As said in an earlier reply to Tim - I think this half baked solution > isn't worth checking in without the other issues with RMRRs > properly taken care of. > >>> 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? > > You didn't read Tim's reply properly: He was referring to the case > where a passed through device gets hotplugged into a guest for > the first time _after_ the guest was already live migrated at least > once. > Thanks for you explanation. Tiejun