Re: [Xen-devel] [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_rmrr()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.02.17 at 10:44, <JBeulich@xxxxxxxx> wrote:
>>>> On 31.01.17 at 18:00, <venu.busireddy@xxxxxxxxxx> wrote:
>> That brings up this question. Do we want to disable VT-d if the PCIe
>> device specified via ACPI cannot be detected? We do so if the address
>> range is incorrectly specified. If the answer is yes, then returning
>> -EINVAL may be acceptable, and that will be the only change needed. If
>> not, we will have to make changes to acpi_parse_dmar() also to deal
>> with the non-zero return value from register_one_rmrr() for failure to
>> detect the device.
> 
> Part of the issue is that you appear to think only in terms of a single
> device. The logic, however, is such that initialization failure is being
> avoided as long as at least one of the (possibly many) listed devices
> can be successfully probed.

Actually I was wrong here (one of the rare cases where replying
without looking at the code another time would have been better):
An RMRR is being ignored when none of the devices can be
successfully probed; normal processing results if at least one
device can be confirmed to be there. The conclusion, though, is
the same - we don't want such (apparently) pointless RMRRs
result in VT-d initialization failure, since as long as the RMRR
really is there for no reason, nothing will break by us using the
IOMMU(s).

Jan


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