Re: [Xen-devel] [v3][PATCH 1/1] xen:vtd: missing RMRR mapping while share EPT

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2014/7/24 20:16, Jan Beulich wrote:
> > > > On 24.07.14 at 13:51, <tiejun.chen@xxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel