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

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

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