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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 23.09.14 at 03:56, <tiejun.chen@intel.com> wrote:
> On 2014/9/22 18:36, Jan Beulich wrote:
>>>>> On 22.09.14 at 11:05, <tiejun.chen@intel.com> wrote:
>>> On 2014/9/22 16:53, Jan Beulich wrote:
>>>>>>> On 22.09.14 at 07:46, <tiejun.chen@intel.com> wrote:
>>>>>>     >> 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
>>>>>
>>>>> Yes. So I set memory size as 2816M which also cover all RMRR ranges in
>>>>> my platform.
>>>>>
>>>>>> 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).
>>>>>>
>>>>>
>>>>> Then I can see that work as we expect:
>>>>>
>>>>> # xl cr hvm.cfg
>>>>> Parsing config from hvm.cfg
>>>>> libxl: error: libxl_pci.c:949:do_pci_add: xc_assign_device failed:
>>>>> Operation not permitted
>>>>> libxl: error: libxl_create.c:1329:domcreate_attach_pci:
>>>>> libxl_device_pci_add failed: -3
>>>>>
>>>>> And
>>>>>
>>>>> # xl dmesg
>>>>> ...
>>>>> (XEN) [VT-D]iommu.c:1589: d0:PCI: unmap 0000:00:02.0
>>>>> (XEN) [VT-D]iommu.c:1452: d1:PCI: map 0000:00:02.0
>>>>> (XEN) Cannot identity map d1:ad000, already mapped to 115d51.
>>>>> (XEN) [VT-D]iommu.c:2296: IOMMU: mapping reserved region failed
>>>>> (XEN) XEN_DOMCTL_assign_device: assign 0000:00:02.0 to dom1 failed (-1)
>>>>> (XEN) [VT-D]iommu.c:1589: d1:PCI: unmap 0000:00:02.0
>>>>> (XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:02.0
>>>>> ...
>>>>
>>>> So after all device assignment fails in that case, which is what I was
>>>> expecting to happen. Which gets me back to the question: What's
>>>> the value of the two patches for you if with them you can't pass
>>>> through anymore the device you want passed through for the actual
>>>> work you're doing?
>>>
>>> I don't understand what you mean again. This is true we already known
>>> previously because this is just a part of the whole solution, right? So
>>> I can't understand why we can't apply them now unless you're saying
>>> they're wrong.
>>
>> You want these two patches applied despite having acknowledged
>> that even for you they cause a regression (at the very least an
>> apparent one).
>>
> 
> Why did you say this is a regression?

Did things work for you _regardless_ of guest memory size?

> Without these two patches, any assigned device with RMRR dependency 
> can't work at all since RMRR table never be created.

Whether a device works without the RMRR being mapped is an
unknown without knowing the specifics of the device - see USB
devices which don't normally need these regions post boot.

> But if we apply 
> these two patches, RMRR table can be created safely, right? Then the 
> assigned device can work based on them.

As long as the guest has little enough memory. As said before, if
the RMRR specifies regions below 1Mb, I don't think you'll be able
to create any guest with a respective device passed through.

Jan