From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [RFC][PATCH 3/5] tools:libxc: remove mmio BAR out
	of RMRR mappings
Date: Tue, 12 Aug 2014 18:56:10 +0800
Message-ID: <53E9F2CA.7030309@intel.com>
References: <1407409371-31728-1-git-send-email-tiejun.chen@intel.com>
	<1407409371-31728-4-git-send-email-tiejun.chen@intel.com>
	<53E50D91020000780002AB44@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12602BF13@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12602BF13@SHSMSX101.ccr.corp.intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Tian, Kevin" <kevin.tian@intel.com>, Jan Beulich <JBeulich@suse.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, "ian.campbell@citrix.com" <ian.campbell@citrix.com>, "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

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
>
>