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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.09.14 at 10:30, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/9/19 16:06, Jan Beulich wrote:
>>>>> On 19.09.14 at 09:40, <tiejun.chen@xxxxxxxxx> wrote:
>>> On 2014/9/19 15:10, Jan Beulich wrote:
>>>>>>> On 19.09.14 at 08:50, <tiejun.chen@xxxxxxxxx> wrote:
>>>>> On 2014/9/19 14:26, Jan Beulich wrote:
>>>>>>>>> On 19.09.14 at 03:20, <tiejun.chen@xxxxxxxxx> 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.

When you pass 3Gb to the guest, its memory map should extend to
about 0xC0000000, well beyond the range the RMRRs reference. So
you ought to be able to see the collision (or if you don't you ought to
have ways to find out why they're not happening, as that would be a
sign of something else being bogus).

Jan


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