Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT

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

On 2014/9/19 16:06, Jan Beulich wrote:
>>>> On 19.09.14 at 09:40, <tiejun.chen@intel.com> wrote:
>> On 2014/9/19 15:10, Jan Beulich wrote:
>>>>>> On 19.09.14 at 08:50, <tiejun.chen@intel.com> wrote:
>>>> On 2014/9/19 14:26, Jan Beulich wrote:
>>>>>>>> On 19.09.14 at 03:20, <tiejun.chen@intel.com> wrote:
>>>>>> (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
>>>>>> (XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:14.0
>>>>>> (XEN) [VT-D]dmar.c:676:   RMRR region: base_addr ab805000 end_address
>>>>>> ab818fff
>>>>>> (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
>>>>>> (XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
>>>>>> (XEN) [VT-D]dmar.c:676:   RMRR region: base_addr ad000000 end_address
>>>>>> af7fffff
>>>>>
>>>>> So how does passing through either of these work for a guest with
>>>>> 4Gb or more of memory assigned with just the original 2 patches
>>>>> (and with shared page tables)? There ought to be a collision detected
>>>>> when trying to do the identity mapping.
>>>>
>>>> Do you mean this point, mfn_valid(mfn)? If yes, I remember we made
>>>> agreement previously about how to cover three cases including this scenario:
>>>>
>>>> "
>>>> #1: !mfn_valid(mfn)
>>>>
>>>> We can create those mapping safely.
>>>>
>>>> #2: mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2m_access_rw
>>>>
>>>> We already have these matched mappings.
>>>>
>>>> #3: Others
>>>>
>>>> Return with that waring message: "Cannot identity map d%d:%lx, already
>>>> mapped to %lx but mismatch.\n"
>>>> "
>>>> And this is just as we did in patch #1:
>>>>
>>>> +
>>>> +    if ( !mfn_valid(mfn) )
>>>> +        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
>>>> p2m_mmio_direct,
>>>> +                            p2m_access_rw);
>>>> +    else if ( mfn_x(mfn) == gfn &&
>>>> +              p2mt == p2m_mmio_direct &&
>>>> +              a == p2m_access_rw )
>>>> +        ret = 0;
>>>> +    else
>>>> +        printk(XENLOG_G_WARNING
>>>> +               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
>>>> +               d->domain_id, gfn, mfn_x(mfn));
>>>
>>> Right, but the important point is that when the warning gets printed
>>> -EBUSY gets returned, i.e. in the end the device assignment is to fail.
>>> Are you seeing the warning when creating a large enough guest? If
>>
>> My platform just own 4G memory, so after I try to set 'memory=15360' in
>> domu.cfg, I can't boot such a VM:
>>
>> # xl cr domu.cfg
>> Parsing config from domu.cfg
>> libxl: error: libxl.c:4202:libxl_set_memory_target: new target 0 for
>> dom0 is below the minimum threshhold
>> ...
>> failed to free memory for the domain
>>
>>> not - can you explain why you don't see it (as I can't)?
>>
>> Do you know exactly how to test this case as you expect here? Then I can
>> take a further look to step on your question. Or I guess you are hinting
>> something wrong should be happened but I never realize that previously.
>
> It should suffice to give 3 Gb (or event slightly less) of memory to
> the DomU (if your Dom0 can hopefully tolerate running with just 1Gb).

Yes. So I can't produce that real case of conflict with those existing 
RMRR in my platform.

I will have to try seeking a appropriate machine.

Thanks
Tiejun

>
> Jan
>
>
>