Re: [Xen-devel] [PATCH 1/2] VT-d: check all of an RMRR for being E820-reserved

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.02.2020 13:20, Roger Pau Monné wrote:
> On Thu, Feb 06, 2020 at 02:31:03PM +0100, Jan Beulich wrote:
>> Checking just the first and last page is not sufficient (and redundant
>> for single-page regions). As we don't need to care about IA64 anymore,
>> use an x86-specific function to get this done without looping over each
>> individual page.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -29,6 +29,7 @@
>>  #include <xen/pci.h>
>>  #include <xen/pci_regs.h>
>>  #include <asm/atomic.h>
>> +#include <asm/e820.h>
>>  #include <asm/string.h>
>>  #include "dmar.h"
>>  #include "iommu.h"
>> @@ -632,14 +633,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_hea
>>       * not properly represented in the system memory map and
>>       * inform the user
>>       */
>> -    if ( (!page_is_ram_type(paddr_to_pfn(base_addr), RAM_TYPE_RESERVED)) ||
>> -         (!page_is_ram_type(paddr_to_pfn(end_addr), RAM_TYPE_RESERVED)) )
>> -    {
>> +    if ( !e820_all_mapped(base_addr, end_addr + 1, RAM_TYPE_RESERVED) )
> 
> Do you need to add one to the end?
> 
> The other user of e820_all_mapped seems to treat end as start + size
> - 1, which makes me think the parameters to the function are an
> inclusive range [start, end] and that's what's present in the RMRR
> ACPI entries?

Well, it's the implementation of the function which matters. This
one other caller is wrong afaict, and I've just sent a patch. The
non-inclusiveness is also in line with Linux'es variant of the
function (where we've got ours from originally, just that it has
been renamed and slightly extended since then).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel