Re: [RFC][PATCH 3/5] tools:libxc: remove mmio BAR out of RMRR mappings

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

On 2014/8/9 5:33, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, August 08, 2014 8:49 AM
>>
>>>>> On 07.08.14 at 13:02, <tiejun.chen@intel.com> wrote:
>>> @@ -300,6 +302,30 @@ static int setup_guest(xc_interface *xch,
>>>           goto error_out;
>>>       }
>>>
>>> +    /* We need to move mmio range out of RMRR mapping. */
>>> +    rc = xc_get_rmrr_map(xch, map, E820MAX);
>>> +    if (rc < 0)
>>> +    {
>>> +        PERROR("Could not get RMRR info on domain");
>>> +    }
>>> +    else if ( rc )
>>> +    {
>>> +        for ( i = 0; i < rc; i++ )
>>> +        {
>>> +            rmrr_end = map[i].addr + map[i].size + 1;
>>> +            if ( rmrr_end > mmio_start )
>>> +            {
>>> +                mmio_start = rmrr_end;
>>> +            }
>>> +        }
>>
>> This seems way too simplistic - what if the RMRRs are referring to
>> memory regions extremely far apart?
>>
>>> +        mmio_size = (1ull << 32) - mmio_start;
>>
>> Limiting things to 4Gb?
>>
>>> +        if ( mmio_size <= 0 )
>>
>> mmio_size is an unsigned quantity, so this won't do what you intend.
>>
>
> and it's not only about the start of mmio, but also the confliction with normal
> guest memory pages, i.e. all the populate_physmap calls should check with

RMRR maps should be as reserved by Xen, right? So why will we still 
check this? I mean Xen should guarantee we don't allocate those reserved 
pages to guest.

Thanks
Tiejun

> RMRR ranges.
>
> Thanks
> Kevin
>
>