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

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

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