Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1218193 > unrolled thread

[PATCH] xen/p2m: fix extra memory regions accounting

Back to article view | Back to linux.kernel

Contents

  [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monne <roger.pau@citrix.com> - 2015-09-03 14:10 +0200
    Re: [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monné <roger.pau@citrix.com> - 2015-09-03 14:20 +0200
      Re: [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-03 14:30 +0200
    Re: [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-03 14:30 +0200
      Re: [PATCH] xen/p2m: fix extra memory regions accounting David Vrabel <david.vrabel@citrix.com> - 2015-09-03 16:50 +0200
        Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting David Vrabel <david.vrabel@citrix.com> - 2015-09-03 17:00 +0200
          Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-03 17:00 +0200
            Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting David Vrabel <david.vrabel@citrix.com> - 2015-09-03 17:10 +0200
              Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-03 17:30 +0200
                Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monné <roger.pau@citrix.com> - 2015-09-03 17:40 +0200
                  Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-03 18:00 +0200
                  Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-04 07:10 +0200
                    Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monné <roger.pau@citrix.com> - 2015-09-04 09:40 +0200
                      Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-04 09:50 +0200
                        Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monné <roger.pau@citrix.com> - 2015-09-04 10:00 +0200
                          Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-04 10:10 +0200
      Re: [PATCH] xen/p2m: fix extra memory regions accounting Roger Pau Monné <roger.pau@citrix.com> - 2015-09-03 16:50 +0200
        Re: [PATCH] xen/p2m: fix extra memory regions accounting Juergen Gross <jgross@suse.com> - 2015-09-03 17:00 +0200

#1218193 — [PATCH] xen/p2m: fix extra memory regions accounting

On systems with memory maps with ranges that don't end at page boundaries,
like:

[...]
(XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
(XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
[...]

xen_add_extra_mem will create a protected range that ends up at 0xdfdf9c00,
but the function used to check if a memory address is inside of a protected
range works with pfns, which means that an attempt to map 0xdfdf9c00 will be
refused because the check is performed against 0xdfdf9000 instead of
0xdfdf9c00.

In order to fix this, make sure that the ranges that are added to the
xen_extra_mem array are aligned to page boundaries.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org
---
AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
---
 arch/x86/xen/setup.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 55f388e..dcf5865 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
 {
 	int i;
 
+	start = PAGE_ALIGN(start);
+	size &= PAGE_MASK;
+
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
 		/* Add new region. */
 		if (xen_extra_mem[i].size == 0) {
@@ -92,6 +95,9 @@ static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
 	int i;
 	phys_addr_t start_r, size_r;
 
+	start = PAGE_ALIGN(start);
+	size &= PAGE_MASK;
+
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
 		start_r = xen_extra_mem[i].start;
 		size_r = xen_extra_mem[i].size;
-- 
1.9.5 (Apple Git-50.3)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1218199

El 03/09/15 a les 14.05, Roger Pau Monne ha escrit:
> On systems with memory maps with ranges that don't end at page boundaries,
> like:
> 
> [...]
> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
> [...]
> 
> xen_add_extra_mem will create a protected range that ends up at 0xdfdf9c00,
> but the function used to check if a memory address is inside of a protected
> range works with pfns, which means that an attempt to map 0xdfdf9c00 will be
> refused because the check is performed against 0xdfdf9000 instead of
> 0xdfdf9c00.
> 
> In order to fix this, make sure that the ranges that are added to the
> xen_extra_mem array are aligned to page boundaries.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: xen-devel@lists.xenproject.org
> ---
> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
> ---
>  arch/x86/xen/setup.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 55f388e..dcf5865 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
>  {
>  	int i;
>  
> +	start = PAGE_ALIGN(start);

Sorry, I didn't remember to update the patch before sending it, but I
think this should instead be:

start = round_up(start, PAGE_SIZE);

Here and below.

> +	size &= PAGE_MASK;
> +
>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>  		/* Add new region. */
>  		if (xen_extra_mem[i].size == 0) {
> @@ -92,6 +95,9 @@ static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
>  	int i;
>  	phys_addr_t start_r, size_r;
>  
> +	start = PAGE_ALIGN(start);
> +	size &= PAGE_MASK;
> +
>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>  		start_r = xen_extra_mem[i].start;
>  		size_r = xen_extra_mem[i].size;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218219

On 09/03/2015 02:15 PM, Roger Pau Monné wrote:
> El 03/09/15 a les 14.05, Roger Pau Monne ha escrit:
>> On systems with memory maps with ranges that don't end at page boundaries,
>> like:
>>
>> [...]
>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>> [...]
>>
>> xen_add_extra_mem will create a protected range that ends up at 0xdfdf9c00,
>> but the function used to check if a memory address is inside of a protected
>> range works with pfns, which means that an attempt to map 0xdfdf9c00 will be
>> refused because the check is performed against 0xdfdf9000 instead of
>> 0xdfdf9c00.
>>
>> In order to fix this, make sure that the ranges that are added to the
>> xen_extra_mem array are aligned to page boundaries.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Cc: David Vrabel <david.vrabel@citrix.com>
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: xen-devel@lists.xenproject.org
>> ---
>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>> ---
>>   arch/x86/xen/setup.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 55f388e..dcf5865 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
>>   {
>>   	int i;
>>
>> +	start = PAGE_ALIGN(start);
>
> Sorry, I didn't remember to update the patch before sending it, but I
> think this should instead be:
>
> start = round_up(start, PAGE_SIZE);

No, PAGE_ALIGN() already does that.


Juergen

>
> Here and below.
>
>> +	size &= PAGE_MASK;
>> +
>>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>>   		/* Add new region. */
>>   		if (xen_extra_mem[i].size == 0) {
>> @@ -92,6 +95,9 @@ static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
>>   	int i;
>>   	phys_addr_t start_r, size_r;
>>
>> +	start = PAGE_ALIGN(start);
>> +	size &= PAGE_MASK;
>> +
>>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>>   		start_r = xen_extra_mem[i].start;
>>   		size_r = xen_extra_mem[i].size;
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218215

On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
> On systems with memory maps with ranges that don't end at page boundaries,
> like:
>
> [...]
> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
> [...]
>
> xen_add_extra_mem will create a protected range that ends up at 0xdfdf9c00,
> but the function used to check if a memory address is inside of a protected
> range works with pfns, which means that an attempt to map 0xdfdf9c00 will be
> refused because the check is performed against 0xdfdf9000 instead of
> 0xdfdf9c00.
>
> In order to fix this, make sure that the ranges that are added to the
> xen_extra_mem array are aligned to page boundaries.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: xen-devel@lists.xenproject.org
> ---
> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
> ---
>   arch/x86/xen/setup.c | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 55f388e..dcf5865 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
>   {
>   	int i;
>
> +	start = PAGE_ALIGN(start);
> +	size &= PAGE_MASK;

This is not correct. If start wasn't page aligned and size was, you'll
add one additional page to xen_extra_mem.

> +
>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>   		/* Add new region. */
>   		if (xen_extra_mem[i].size == 0) {
> @@ -92,6 +95,9 @@ static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
>   	int i;
>   	phys_addr_t start_r, size_r;
>
> +	start = PAGE_ALIGN(start);
> +	size &= PAGE_MASK;

Not really needed, as xen_del_extra_mem() is called with aligned values
only. OTOH it does no harm, as long as you correct size as above.

> +
>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>   		start_r = xen_extra_mem[i].start;
>   		size_r = xen_extra_mem[i].size;
>

Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218297

On 03/09/15 15:38, Roger Pau Monné wrote:
> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>> On systems with memory maps with ranges that don't end at page
>>> boundaries,
>>> like:
>>>
>>> [...]
>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>> [...]
>>>
>>> xen_add_extra_mem will create a protected range that ends up at
>>> 0xdfdf9c00,
>>> but the function used to check if a memory address is inside of a
>>> protected
>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>> will be
>>> refused because the check is performed against 0xdfdf9000 instead of
>>> 0xdfdf9c00.
>>>
>>> In order to fix this, make sure that the ranges that are added to the
>>> xen_extra_mem array are aligned to page boundaries.
>>>
>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: xen-devel@lists.xenproject.org
>>> ---
>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>> ---
>>>   arch/x86/xen/setup.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>> index 55f388e..dcf5865 100644
>>> --- a/arch/x86/xen/setup.c
>>> +++ b/arch/x86/xen/setup.c
>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>> start, phys_addr_t size)
>>>   {
>>>       int i;
>>>
>>> +    start = PAGE_ALIGN(start);
>>> +    size &= PAGE_MASK;
>>
>> This is not correct. If start wasn't page aligned and size was, you'll
>> add one additional page to xen_extra_mem.
> 
> I'm not understanding this, let's put an example:
> 
> start = 0x8c00
> size = 0x1000
> 
> After the fixup added above this would become:
> 
> start = 0x9000
> size = 0x1000
> 
> So if anything, I'm adding one page less (because 0x8000 was partly
> added, and with the fixup it is not added).

We expand the reserved (i.e., non-RAM) areas down so they're fully
covered with whole pages when we depopulate and 1:1 map them, we should
add extra memory regions that cover these same areas.

See the use of PFN_DOWN() and PFN_UP() in xen_set_identify_and_remap().

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218309 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 03/09/15 15:45, David Vrabel wrote:
> On 03/09/15 15:38, Roger Pau Monné wrote:
>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>> On systems with memory maps with ranges that don't end at page
>>>> boundaries,
>>>> like:
>>>>
>>>> [...]
>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>> [...]
>>>>
>>>> xen_add_extra_mem will create a protected range that ends up at
>>>> 0xdfdf9c00,
>>>> but the function used to check if a memory address is inside of a
>>>> protected
>>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>>> will be
>>>> refused because the check is performed against 0xdfdf9000 instead of
>>>> 0xdfdf9c00.
>>>>
>>>> In order to fix this, make sure that the ranges that are added to the
>>>> xen_extra_mem array are aligned to page boundaries.
>>>>
>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>> Cc: Juergen Gross <jgross@suse.com>
>>>> Cc: xen-devel@lists.xenproject.org
>>>> ---
>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>> ---
>>>>   arch/x86/xen/setup.c | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>> index 55f388e..dcf5865 100644
>>>> --- a/arch/x86/xen/setup.c
>>>> +++ b/arch/x86/xen/setup.c
>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>> start, phys_addr_t size)
>>>>   {
>>>>       int i;
>>>>
>>>> +    start = PAGE_ALIGN(start);
>>>> +    size &= PAGE_MASK;
>>>
>>> This is not correct. If start wasn't page aligned and size was, you'll
>>> add one additional page to xen_extra_mem.
>>
>> I'm not understanding this, let's put an example:
>>
>> start = 0x8c00
>> size = 0x1000
>>
>> After the fixup added above this would become:
>>
>> start = 0x9000
>> size = 0x1000
>>
>> So if anything, I'm adding one page less (because 0x8000 was partly
>> added, and with the fixup it is not added).
> 
> We expand the reserved (i.e., non-RAM) areas down so they're fully
> covered with whole pages when we depopulate and 1:1 map them, we should
> add extra memory regions that cover these same areas.

Ignore this.  This was nonsense.

We expand the reserved (i.e., non-RAM) areas so they're fully covered
with whole pages when we depopulate and 1:1 map them, we should add the
extra memory such that it does not overlap with with expanded regions.
i.e., round up the start and round down the end (like Roger's patch does).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218310 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 09/03/2015 04:52 PM, David Vrabel wrote:
> On 03/09/15 15:45, David Vrabel wrote:
>> On 03/09/15 15:38, Roger Pau Monné wrote:
>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>>> On systems with memory maps with ranges that don't end at page
>>>>> boundaries,
>>>>> like:
>>>>>
>>>>> [...]
>>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>>> [...]
>>>>>
>>>>> xen_add_extra_mem will create a protected range that ends up at
>>>>> 0xdfdf9c00,
>>>>> but the function used to check if a memory address is inside of a
>>>>> protected
>>>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>>>> will be
>>>>> refused because the check is performed against 0xdfdf9000 instead of
>>>>> 0xdfdf9c00.
>>>>>
>>>>> In order to fix this, make sure that the ranges that are added to the
>>>>> xen_extra_mem array are aligned to page boundaries.
>>>>>
>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>>> Cc: Juergen Gross <jgross@suse.com>
>>>>> Cc: xen-devel@lists.xenproject.org
>>>>> ---
>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>>> ---
>>>>>    arch/x86/xen/setup.c | 6 ++++++
>>>>>    1 file changed, 6 insertions(+)
>>>>>
>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>>> index 55f388e..dcf5865 100644
>>>>> --- a/arch/x86/xen/setup.c
>>>>> +++ b/arch/x86/xen/setup.c
>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>>> start, phys_addr_t size)
>>>>>    {
>>>>>        int i;
>>>>>
>>>>> +    start = PAGE_ALIGN(start);
>>>>> +    size &= PAGE_MASK;
>>>>
>>>> This is not correct. If start wasn't page aligned and size was, you'll
>>>> add one additional page to xen_extra_mem.
>>>
>>> I'm not understanding this, let's put an example:
>>>
>>> start = 0x8c00
>>> size = 0x1000
>>>
>>> After the fixup added above this would become:
>>>
>>> start = 0x9000
>>> size = 0x1000
>>>
>>> So if anything, I'm adding one page less (because 0x8000 was partly
>>> added, and with the fixup it is not added).
>>
>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>> covered with whole pages when we depopulate and 1:1 map them, we should
>> add extra memory regions that cover these same areas.
>
> Ignore this.  This was nonsense.
>
> We expand the reserved (i.e., non-RAM) areas so they're fully covered
> with whole pages when we depopulate and 1:1 map them, we should add the
> extra memory such that it does not overlap with with expanded regions.
> i.e., round up the start and round down the end (like Roger's patch does).

Nearly. Roger's patch rounds up start and rounds down the size. It might
add non-RAM partial pages to xen_extra_mem.


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218317 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 03/09/15 15:55, Juergen Gross wrote:
> On 09/03/2015 04:52 PM, David Vrabel wrote:
>> On 03/09/15 15:45, David Vrabel wrote:
>>> On 03/09/15 15:38, Roger Pau Monné wrote:
>>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>>>> On systems with memory maps with ranges that don't end at page
>>>>>> boundaries,
>>>>>> like:
>>>>>>
>>>>>> [...]
>>>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>>>> [...]
>>>>>>
>>>>>> xen_add_extra_mem will create a protected range that ends up at
>>>>>> 0xdfdf9c00,
>>>>>> but the function used to check if a memory address is inside of a
>>>>>> protected
>>>>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>>>>> will be
>>>>>> refused because the check is performed against 0xdfdf9000 instead of
>>>>>> 0xdfdf9c00.
>>>>>>
>>>>>> In order to fix this, make sure that the ranges that are added to the
>>>>>> xen_extra_mem array are aligned to page boundaries.
>>>>>>
>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>>>> Cc: Juergen Gross <jgross@suse.com>
>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>> ---
>>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>>>> ---
>>>>>>    arch/x86/xen/setup.c | 6 ++++++
>>>>>>    1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>>>> index 55f388e..dcf5865 100644
>>>>>> --- a/arch/x86/xen/setup.c
>>>>>> +++ b/arch/x86/xen/setup.c
>>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>>>> start, phys_addr_t size)
>>>>>>    {
>>>>>>        int i;
>>>>>>
>>>>>> +    start = PAGE_ALIGN(start);
>>>>>> +    size &= PAGE_MASK;
>>>>>
>>>>> This is not correct. If start wasn't page aligned and size was, you'll
>>>>> add one additional page to xen_extra_mem.
>>>>
>>>> I'm not understanding this, let's put an example:
>>>>
>>>> start = 0x8c00
>>>> size = 0x1000
>>>>
>>>> After the fixup added above this would become:
>>>>
>>>> start = 0x9000
>>>> size = 0x1000
>>>>
>>>> So if anything, I'm adding one page less (because 0x8000 was partly
>>>> added, and with the fixup it is not added).
>>>
>>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>>> covered with whole pages when we depopulate and 1:1 map them, we should
>>> add extra memory regions that cover these same areas.
>>
>> Ignore this.  This was nonsense.
>>
>> We expand the reserved (i.e., non-RAM) areas so they're fully covered
>> with whole pages when we depopulate and 1:1 map them, we should add the
>> extra memory such that it does not overlap with with expanded regions.
>> i.e., round up the start and round down the end (like Roger's patch
>> does).
> 
> Nearly. Roger's patch rounds up start and rounds down the size. It might
> add non-RAM partial pages to xen_extra_mem.

Yes.  You're right.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218361 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 09/03/2015 05:01 PM, David Vrabel wrote:
> On 03/09/15 15:55, Juergen Gross wrote:
>> On 09/03/2015 04:52 PM, David Vrabel wrote:
>>> On 03/09/15 15:45, David Vrabel wrote:
>>>> On 03/09/15 15:38, Roger Pau Monné wrote:
>>>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>>>>> On systems with memory maps with ranges that don't end at page
>>>>>>> boundaries,
>>>>>>> like:
>>>>>>>
>>>>>>> [...]
>>>>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>>>>> [...]
>>>>>>>
>>>>>>> xen_add_extra_mem will create a protected range that ends up at
>>>>>>> 0xdfdf9c00,
>>>>>>> but the function used to check if a memory address is inside of a
>>>>>>> protected
>>>>>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>>>>>> will be
>>>>>>> refused because the check is performed against 0xdfdf9000 instead of
>>>>>>> 0xdfdf9c00.
>>>>>>>
>>>>>>> In order to fix this, make sure that the ranges that are added to the
>>>>>>> xen_extra_mem array are aligned to page boundaries.
>>>>>>>
>>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>>>>> Cc: Juergen Gross <jgross@suse.com>
>>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>>> ---
>>>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>>>>> ---
>>>>>>>     arch/x86/xen/setup.c | 6 ++++++
>>>>>>>     1 file changed, 6 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>>>>> index 55f388e..dcf5865 100644
>>>>>>> --- a/arch/x86/xen/setup.c
>>>>>>> +++ b/arch/x86/xen/setup.c
>>>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>>>>> start, phys_addr_t size)
>>>>>>>     {
>>>>>>>         int i;
>>>>>>>
>>>>>>> +    start = PAGE_ALIGN(start);
>>>>>>> +    size &= PAGE_MASK;
>>>>>>
>>>>>> This is not correct. If start wasn't page aligned and size was, you'll
>>>>>> add one additional page to xen_extra_mem.
>>>>>
>>>>> I'm not understanding this, let's put an example:
>>>>>
>>>>> start = 0x8c00
>>>>> size = 0x1000
>>>>>
>>>>> After the fixup added above this would become:
>>>>>
>>>>> start = 0x9000
>>>>> size = 0x1000
>>>>>
>>>>> So if anything, I'm adding one page less (because 0x8000 was partly
>>>>> added, and with the fixup it is not added).
>>>>
>>>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>>>> covered with whole pages when we depopulate and 1:1 map them, we should
>>>> add extra memory regions that cover these same areas.
>>>
>>> Ignore this.  This was nonsense.
>>>
>>> We expand the reserved (i.e., non-RAM) areas so they're fully covered
>>> with whole pages when we depopulate and 1:1 map them, we should add the
>>> extra memory such that it does not overlap with with expanded regions.
>>> i.e., round up the start and round down the end (like Roger's patch
>>> does).
>>
>> Nearly. Roger's patch rounds up start and rounds down the size. It might
>> add non-RAM partial pages to xen_extra_mem.
>
> Yes.  You're right.

Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
pfns instead of physical addresses. This would make things much more
clear.

Roger, do you want to do the patch or should I?


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218378 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

El 03/09/15 a les 17.20, Juergen Gross ha escrit:
> On 09/03/2015 05:01 PM, David Vrabel wrote:
>> On 03/09/15 15:55, Juergen Gross wrote:
>>> On 09/03/2015 04:52 PM, David Vrabel wrote:
>>>> On 03/09/15 15:45, David Vrabel wrote:
>>>>> On 03/09/15 15:38, Roger Pau Monné wrote:
>>>>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>>>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>>>>>> On systems with memory maps with ranges that don't end at page
>>>>>>>> boundaries,
>>>>>>>> like:
>>>>>>>>
>>>>>>>> [...]
>>>>>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>>>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> xen_add_extra_mem will create a protected range that ends up at
>>>>>>>> 0xdfdf9c00,
>>>>>>>> but the function used to check if a memory address is inside of a
>>>>>>>> protected
>>>>>>>> range works with pfns, which means that an attempt to map
>>>>>>>> 0xdfdf9c00
>>>>>>>> will be
>>>>>>>> refused because the check is performed against 0xdfdf9000
>>>>>>>> instead of
>>>>>>>> 0xdfdf9c00.
>>>>>>>>
>>>>>>>> In order to fix this, make sure that the ranges that are added
>>>>>>>> to the
>>>>>>>> xen_extra_mem array are aligned to page boundaries.
>>>>>>>>
>>>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>>>>>> Cc: Juergen Gross <jgross@suse.com>
>>>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>>>> ---
>>>>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>>>>>> ---
>>>>>>>>     arch/x86/xen/setup.c | 6 ++++++
>>>>>>>>     1 file changed, 6 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>>>>>> index 55f388e..dcf5865 100644
>>>>>>>> --- a/arch/x86/xen/setup.c
>>>>>>>> +++ b/arch/x86/xen/setup.c
>>>>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>>>>>> start, phys_addr_t size)
>>>>>>>>     {
>>>>>>>>         int i;
>>>>>>>>
>>>>>>>> +    start = PAGE_ALIGN(start);
>>>>>>>> +    size &= PAGE_MASK;
>>>>>>>
>>>>>>> This is not correct. If start wasn't page aligned and size was,
>>>>>>> you'll
>>>>>>> add one additional page to xen_extra_mem.
>>>>>>
>>>>>> I'm not understanding this, let's put an example:
>>>>>>
>>>>>> start = 0x8c00
>>>>>> size = 0x1000
>>>>>>
>>>>>> After the fixup added above this would become:
>>>>>>
>>>>>> start = 0x9000
>>>>>> size = 0x1000
>>>>>>
>>>>>> So if anything, I'm adding one page less (because 0x8000 was partly
>>>>>> added, and with the fixup it is not added).
>>>>>
>>>>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>>>>> covered with whole pages when we depopulate and 1:1 map them, we
>>>>> should
>>>>> add extra memory regions that cover these same areas.
>>>>
>>>> Ignore this.  This was nonsense.
>>>>
>>>> We expand the reserved (i.e., non-RAM) areas so they're fully covered
>>>> with whole pages when we depopulate and 1:1 map them, we should add the
>>>> extra memory such that it does not overlap with with expanded regions.
>>>> i.e., round up the start and round down the end (like Roger's patch
>>>> does).
>>>
>>> Nearly. Roger's patch rounds up start and rounds down the size. It might
>>> add non-RAM partial pages to xen_extra_mem.
>>
>> Yes.  You're right.
> 
> Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
> pfns instead of physical addresses. This would make things much more
> clear.
> 
> Roger, do you want to do the patch or should I?

I can certainly take care of it if you are busy, otherwise I leave it to
you since you have more expertise on it :).

Roger.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218396 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 09/03/2015 05:39 PM, Roger Pau Monné wrote:
> El 03/09/15 a les 17.20, Juergen Gross ha escrit:
>> On 09/03/2015 05:01 PM, David Vrabel wrote:
>>> On 03/09/15 15:55, Juergen Gross wrote:
>>>> On 09/03/2015 04:52 PM, David Vrabel wrote:
>>>>> On 03/09/15 15:45, David Vrabel wrote:
>>>>>> On 03/09/15 15:38, Roger Pau Monné wrote:
>>>>>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>>>>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>>>>>>> On systems with memory maps with ranges that don't end at page
>>>>>>>>> boundaries,
>>>>>>>>> like:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>>>>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> xen_add_extra_mem will create a protected range that ends up at
>>>>>>>>> 0xdfdf9c00,
>>>>>>>>> but the function used to check if a memory address is inside of a
>>>>>>>>> protected
>>>>>>>>> range works with pfns, which means that an attempt to map
>>>>>>>>> 0xdfdf9c00
>>>>>>>>> will be
>>>>>>>>> refused because the check is performed against 0xdfdf9000
>>>>>>>>> instead of
>>>>>>>>> 0xdfdf9c00.
>>>>>>>>>
>>>>>>>>> In order to fix this, make sure that the ranges that are added
>>>>>>>>> to the
>>>>>>>>> xen_extra_mem array are aligned to page boundaries.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>>>>>>> Cc: Juergen Gross <jgross@suse.com>
>>>>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>>>>> ---
>>>>>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>>>>>>> ---
>>>>>>>>>      arch/x86/xen/setup.c | 6 ++++++
>>>>>>>>>      1 file changed, 6 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>>>>>>> index 55f388e..dcf5865 100644
>>>>>>>>> --- a/arch/x86/xen/setup.c
>>>>>>>>> +++ b/arch/x86/xen/setup.c
>>>>>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>>>>>>> start, phys_addr_t size)
>>>>>>>>>      {
>>>>>>>>>          int i;
>>>>>>>>>
>>>>>>>>> +    start = PAGE_ALIGN(start);
>>>>>>>>> +    size &= PAGE_MASK;
>>>>>>>>
>>>>>>>> This is not correct. If start wasn't page aligned and size was,
>>>>>>>> you'll
>>>>>>>> add one additional page to xen_extra_mem.
>>>>>>>
>>>>>>> I'm not understanding this, let's put an example:
>>>>>>>
>>>>>>> start = 0x8c00
>>>>>>> size = 0x1000
>>>>>>>
>>>>>>> After the fixup added above this would become:
>>>>>>>
>>>>>>> start = 0x9000
>>>>>>> size = 0x1000
>>>>>>>
>>>>>>> So if anything, I'm adding one page less (because 0x8000 was partly
>>>>>>> added, and with the fixup it is not added).
>>>>>>
>>>>>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>>>>>> covered with whole pages when we depopulate and 1:1 map them, we
>>>>>> should
>>>>>> add extra memory regions that cover these same areas.
>>>>>
>>>>> Ignore this.  This was nonsense.
>>>>>
>>>>> We expand the reserved (i.e., non-RAM) areas so they're fully covered
>>>>> with whole pages when we depopulate and 1:1 map them, we should add the
>>>>> extra memory such that it does not overlap with with expanded regions.
>>>>> i.e., round up the start and round down the end (like Roger's patch
>>>>> does).
>>>>
>>>> Nearly. Roger's patch rounds up start and rounds down the size. It might
>>>> add non-RAM partial pages to xen_extra_mem.
>>>
>>> Yes.  You're right.
>>
>> Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
>> pfns instead of physical addresses. This would make things much more
>> clear.
>>
>> Roger, do you want to do the patch or should I?
>
> I can certainly take care of it if you are busy, otherwise I leave it to
> you since you have more expertise on it :).

Okay, I can do it. Should be ready soon...


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218677 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[Multipart message — attachments visible in raw view] — view raw

Hi Roger,

On 09/03/2015 05:39 PM, Roger Pau Monné wrote:
> El 03/09/15 a les 17.20, Juergen Gross ha escrit:
>> On 09/03/2015 05:01 PM, David Vrabel wrote:
>>> On 03/09/15 15:55, Juergen Gross wrote:
>>>> On 09/03/2015 04:52 PM, David Vrabel wrote:
>>>>> On 03/09/15 15:45, David Vrabel wrote:
>>>>>> On 03/09/15 15:38, Roger Pau Monné wrote:
>>>>>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>>>>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>>>>>>>> On systems with memory maps with ranges that don't end at page
>>>>>>>>> boundaries,
>>>>>>>>> like:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>>>>>>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> xen_add_extra_mem will create a protected range that ends up at
>>>>>>>>> 0xdfdf9c00,
>>>>>>>>> but the function used to check if a memory address is inside of a
>>>>>>>>> protected
>>>>>>>>> range works with pfns, which means that an attempt to map
>>>>>>>>> 0xdfdf9c00
>>>>>>>>> will be
>>>>>>>>> refused because the check is performed against 0xdfdf9000
>>>>>>>>> instead of
>>>>>>>>> 0xdfdf9c00.
>>>>>>>>>
>>>>>>>>> In order to fix this, make sure that the ranges that are added
>>>>>>>>> to the
>>>>>>>>> xen_extra_mem array are aligned to page boundaries.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>>>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>>>>>>>> Cc: Juergen Gross <jgross@suse.com>
>>>>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>>>>> ---
>>>>>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>>>>>>>> ---
>>>>>>>>>      arch/x86/xen/setup.c | 6 ++++++
>>>>>>>>>      1 file changed, 6 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>>>>>>> index 55f388e..dcf5865 100644
>>>>>>>>> --- a/arch/x86/xen/setup.c
>>>>>>>>> +++ b/arch/x86/xen/setup.c
>>>>>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>>>>>>>> start, phys_addr_t size)
>>>>>>>>>      {
>>>>>>>>>          int i;
>>>>>>>>>
>>>>>>>>> +    start = PAGE_ALIGN(start);
>>>>>>>>> +    size &= PAGE_MASK;
>>>>>>>>
>>>>>>>> This is not correct. If start wasn't page aligned and size was,
>>>>>>>> you'll
>>>>>>>> add one additional page to xen_extra_mem.
>>>>>>>
>>>>>>> I'm not understanding this, let's put an example:
>>>>>>>
>>>>>>> start = 0x8c00
>>>>>>> size = 0x1000
>>>>>>>
>>>>>>> After the fixup added above this would become:
>>>>>>>
>>>>>>> start = 0x9000
>>>>>>> size = 0x1000
>>>>>>>
>>>>>>> So if anything, I'm adding one page less (because 0x8000 was partly
>>>>>>> added, and with the fixup it is not added).
>>>>>>
>>>>>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>>>>>> covered with whole pages when we depopulate and 1:1 map them, we
>>>>>> should
>>>>>> add extra memory regions that cover these same areas.
>>>>>
>>>>> Ignore this.  This was nonsense.
>>>>>
>>>>> We expand the reserved (i.e., non-RAM) areas so they're fully covered
>>>>> with whole pages when we depopulate and 1:1 map them, we should add the
>>>>> extra memory such that it does not overlap with with expanded regions.
>>>>> i.e., round up the start and round down the end (like Roger's patch
>>>>> does).
>>>>
>>>> Nearly. Roger's patch rounds up start and rounds down the size. It might
>>>> add non-RAM partial pages to xen_extra_mem.
>>>
>>> Yes.  You're right.
>>
>> Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
>> pfns instead of physical addresses. This would make things much more
>> clear.
>>
>> Roger, do you want to do the patch or should I?
>
> I can certainly take care of it if you are busy, otherwise I leave it to
> you since you have more expertise on it :).

Could you try the attached patch? It should do the job. It is booting
fine on my laptop, but I think you should try it on the machine with
the memory ranges not at page boundary.


Juergen

[toc] | [prev] | [next] | [standalone]

#1218707 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

Hello,

El 04/09/15 a les 7.07, Juergen Gross ha escrit:
> Could you try the attached patch? It should do the job. It is booting
> fine on my laptop, but I think you should try it on the machine with
> the memory ranges not at page boundary.
> 
> 
> Juergen
> 
> 
> extramem.patch
> 
> 
> commit 3d0f8aa4d1b4c9c16a81902a197b5d6a77e182a0
> Author: Juergen Gross <jgross@suse.com>
> Date:   Thu Sep 3 17:44:04 2015 +0200
> 
>     xen: switch extra memory accounting to use pfns
>     
>     Instead of using physical addresses for accounting of extra memory
>     areas available for ballooning switch to pfns as this is much less
>     error prone regarding partial pages.

Thanks for taking care of this! I've tested it on the box that has
non-page aligned memory ranges and it works fine, only a couple of
comments below.

>     Reported-by: Roger Pau Monné <roger.pau@citrix.com>
>     Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 7a5d566..aa58bc4 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -90,62 +90,65 @@ static void __init xen_parse_512gb(void)
>  	xen_512gb_limit = val;
>  }
>  
> -static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
> +static void __init xen_add_extra_mem(unsigned long start_pfn,
> +				     unsigned long n_pfns)

Not very important, but for type consistency this should probably be
xen_pfn_t instead of unsigned long here and below.

>  {
>  	int i;
>  
>  	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>  		/* Add new region. */
> -		if (xen_extra_mem[i].size == 0) {
> -			xen_extra_mem[i].start = start;
> -			xen_extra_mem[i].size  = size;
> +		if (xen_extra_mem[i].n_pfns == 0) {
> +			xen_extra_mem[i].start_pfn = start_pfn;
> +			xen_extra_mem[i].n_pfns = n_pfns;
>  			break;
>  		}
>  		/* Append to existing region. */
> -		if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) {
> -			xen_extra_mem[i].size += size;
> +		if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
> +		    start_pfn) {
> +			xen_extra_mem[i].n_pfns += n_pfns;
>  			break;
>  		}

I also noticed this with the original code, why isn't there a case to
prepend to an existing region:

if (start_pfn + n_pfns == xen_extra_mem[i].start_pfn) {
    xen_extra_mem[i].n_pfns += n_pfns;
    xen_extra_mem[i].start_pfn = start_pfn;
}

>  	}
>  	if (i == XEN_EXTRA_MEM_MAX_REGIONS)
>  		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>  
> -	memblock_reserve(start, size);
> +	memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
>  }

[...]

> @@ -831,9 +833,11 @@ char * __init xen_memory_setup(void)
>  				chunk_size = min(size, mem_end - addr);
>  			} else if (extra_pages) {
>  				chunk_size = min(size, PFN_PHYS(extra_pages));
> -				extra_pages -= PFN_DOWN(chunk_size);
> -				xen_add_extra_mem(addr, chunk_size);
> -				xen_max_p2m_pfn = PFN_DOWN(addr + chunk_size);
> +				pfn_s = PFN_UP(addr);
> +				n_pfns = PFN_DOWN(addr + chunk_size) - pfn_s;

Should xen_add_extra_mem check for empty ranges and bail out early, or
should the caller make sure it doesn't try to add empty ranges?

IMHO it's easier and cleaner to add the check to xen_add_extra_mem.

Roger.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218710 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 09/04/2015 09:37 AM, Roger Pau Monné wrote:
> Hello,
>
> El 04/09/15 a les 7.07, Juergen Gross ha escrit:
>> Could you try the attached patch? It should do the job. It is booting
>> fine on my laptop, but I think you should try it on the machine with
>> the memory ranges not at page boundary.
>>
>>
>> Juergen
>>
>>
>> extramem.patch
>>
>>
>> commit 3d0f8aa4d1b4c9c16a81902a197b5d6a77e182a0
>> Author: Juergen Gross <jgross@suse.com>
>> Date:   Thu Sep 3 17:44:04 2015 +0200
>>
>>      xen: switch extra memory accounting to use pfns
>>
>>      Instead of using physical addresses for accounting of extra memory
>>      areas available for ballooning switch to pfns as this is much less
>>      error prone regarding partial pages.
>
> Thanks for taking care of this! I've tested it on the box that has
> non-page aligned memory ranges and it works fine, only a couple of
> comments below.
>
>>      Reported-by: Roger Pau Monné <roger.pau@citrix.com>
>>      Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 7a5d566..aa58bc4 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -90,62 +90,65 @@ static void __init xen_parse_512gb(void)
>>   	xen_512gb_limit = val;
>>   }
>>
>> -static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
>> +static void __init xen_add_extra_mem(unsigned long start_pfn,
>> +				     unsigned long n_pfns)
>
> Not very important, but for type consistency this should probably be
> xen_pfn_t instead of unsigned long here and below.

All of the p2m code is using unsigned long for pfns. I wouldn't mind
changing this to use xen_pfn_t instead, but this should be done in a
separate patch. I'll put it on my list.

>
>>   {
>>   	int i;
>>
>>   	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>>   		/* Add new region. */
>> -		if (xen_extra_mem[i].size == 0) {
>> -			xen_extra_mem[i].start = start;
>> -			xen_extra_mem[i].size  = size;
>> +		if (xen_extra_mem[i].n_pfns == 0) {
>> +			xen_extra_mem[i].start_pfn = start_pfn;
>> +			xen_extra_mem[i].n_pfns = n_pfns;
>>   			break;
>>   		}
>>   		/* Append to existing region. */
>> -		if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) {
>> -			xen_extra_mem[i].size += size;
>> +		if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
>> +		    start_pfn) {
>> +			xen_extra_mem[i].n_pfns += n_pfns;
>>   			break;
>>   		}
>
> I also noticed this with the original code, why isn't there a case to
> prepend to an existing region:
>
> if (start_pfn + n_pfns == xen_extra_mem[i].start_pfn) {
>      xen_extra_mem[i].n_pfns += n_pfns;
>      xen_extra_mem[i].start_pfn = start_pfn;
> }

Processing of memory is done from low to high addresses. This case
should never happen. And even if it does, the only downside from
not handling this scenario is wasting an additional table entry.

>
>>   	}
>>   	if (i == XEN_EXTRA_MEM_MAX_REGIONS)
>>   		printk(KERN_WARNING "Warning: not enough extra memory regions\n");
>>
>> -	memblock_reserve(start, size);
>> +	memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
>>   }
>
> [...]
>
>> @@ -831,9 +833,11 @@ char * __init xen_memory_setup(void)
>>   				chunk_size = min(size, mem_end - addr);
>>   			} else if (extra_pages) {
>>   				chunk_size = min(size, PFN_PHYS(extra_pages));
>> -				extra_pages -= PFN_DOWN(chunk_size);
>> -				xen_add_extra_mem(addr, chunk_size);
>> -				xen_max_p2m_pfn = PFN_DOWN(addr + chunk_size);
>> +				pfn_s = PFN_UP(addr);
>> +				n_pfns = PFN_DOWN(addr + chunk_size) - pfn_s;
>
> Should xen_add_extra_mem check for empty ranges and bail out early, or
> should the caller make sure it doesn't try to add empty ranges?
>
> IMHO it's easier and cleaner to add the check to xen_add_extra_mem.

This isn't critical at all. Adding an empty range is a nop, as a table
entry is regarded to be not used when n_pfns is 0.


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218712 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

El 04/09/15 a les 9.47, Juergen Gross ha escrit:
> On 09/04/2015 09:37 AM, Roger Pau Monné wrote:
>> Hello,
>>
>> El 04/09/15 a les 7.07, Juergen Gross ha escrit:
>>> Could you try the attached patch? It should do the job. It is booting
>>> fine on my laptop, but I think you should try it on the machine with
>>> the memory ranges not at page boundary.
>>>
>>>
>>> Juergen
>>>
>>>
>>> extramem.patch
>>>
>>>
>>> commit 3d0f8aa4d1b4c9c16a81902a197b5d6a77e182a0
>>> Author: Juergen Gross <jgross@suse.com>
>>> Date:   Thu Sep 3 17:44:04 2015 +0200
>>>
>>>      xen: switch extra memory accounting to use pfns
>>>
>>>      Instead of using physical addresses for accounting of extra memory
>>>      areas available for ballooning switch to pfns as this is much less
>>>      error prone regarding partial pages.
>>
>> Thanks for taking care of this! I've tested it on the box that has
>> non-page aligned memory ranges and it works fine, only a couple of
>> comments below.
>>
>>>      Reported-by: Roger Pau Monné <roger.pau@citrix.com>
>>>      Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>> index 7a5d566..aa58bc4 100644
>>> --- a/arch/x86/xen/setup.c
>>> +++ b/arch/x86/xen/setup.c
>>> @@ -90,62 +90,65 @@ static void __init xen_parse_512gb(void)
>>>       xen_512gb_limit = val;
>>>   }
>>>
>>> -static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t
>>> size)
>>> +static void __init xen_add_extra_mem(unsigned long start_pfn,
>>> +                     unsigned long n_pfns)
>>
>> Not very important, but for type consistency this should probably be
>> xen_pfn_t instead of unsigned long here and below.
> 
> All of the p2m code is using unsigned long for pfns. I wouldn't mind
> changing this to use xen_pfn_t instead, but this should be done in a
> separate patch. I'll put it on my list.
> 
>>
>>>   {
>>>       int i;
>>>
>>>       for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>>>           /* Add new region. */
>>> -        if (xen_extra_mem[i].size == 0) {
>>> -            xen_extra_mem[i].start = start;
>>> -            xen_extra_mem[i].size  = size;
>>> +        if (xen_extra_mem[i].n_pfns == 0) {
>>> +            xen_extra_mem[i].start_pfn = start_pfn;
>>> +            xen_extra_mem[i].n_pfns = n_pfns;
>>>               break;
>>>           }
>>>           /* Append to existing region. */
>>> -        if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) {
>>> -            xen_extra_mem[i].size += size;
>>> +        if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
>>> +            start_pfn) {
>>> +            xen_extra_mem[i].n_pfns += n_pfns;
>>>               break;
>>>           }
>>
>> I also noticed this with the original code, why isn't there a case to
>> prepend to an existing region:
>>
>> if (start_pfn + n_pfns == xen_extra_mem[i].start_pfn) {
>>      xen_extra_mem[i].n_pfns += n_pfns;
>>      xen_extra_mem[i].start_pfn = start_pfn;
>> }
> 
> Processing of memory is done from low to high addresses. This case
> should never happen. And even if it does, the only downside from
> not handling this scenario is wasting an additional table entry.

Right, this case would only be useful for xen_del_extra_mem, and as you
say, the worst that can happen is that we end up using an extra slot.

>>
>>>       }
>>>       if (i == XEN_EXTRA_MEM_MAX_REGIONS)
>>>           printk(KERN_WARNING "Warning: not enough extra memory
>>> regions\n");
>>>
>>> -    memblock_reserve(start, size);
>>> +    memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
>>>   }
>>
>> [...]
>>
>>> @@ -831,9 +833,11 @@ char * __init xen_memory_setup(void)
>>>                   chunk_size = min(size, mem_end - addr);
>>>               } else if (extra_pages) {
>>>                   chunk_size = min(size, PFN_PHYS(extra_pages));
>>> -                extra_pages -= PFN_DOWN(chunk_size);
>>> -                xen_add_extra_mem(addr, chunk_size);
>>> -                xen_max_p2m_pfn = PFN_DOWN(addr + chunk_size);
>>> +                pfn_s = PFN_UP(addr);
>>> +                n_pfns = PFN_DOWN(addr + chunk_size) - pfn_s;
>>
>> Should xen_add_extra_mem check for empty ranges and bail out early, or
>> should the caller make sure it doesn't try to add empty ranges?
>>
>> IMHO it's easier and cleaner to add the check to xen_add_extra_mem.
> 
> This isn't critical at all. Adding an empty range is a nop, as a table
> entry is regarded to be not used when n_pfns is 0.

Yes, it's just so we can bail out earlier instead of iterating over the
whole xen_extra_mem for empty ranges. IMHO, I would add a check to
xen_add_extra_mem so we don't waste cycles.

Roger.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218725 — Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

On 09/04/2015 09:57 AM, Roger Pau Monné wrote:
> El 04/09/15 a les 9.47, Juergen Gross ha escrit:
>> On 09/04/2015 09:37 AM, Roger Pau Monné wrote:
>>> Hello,
>>>
>>> El 04/09/15 a les 7.07, Juergen Gross ha escrit:
>>>> Could you try the attached patch? It should do the job. It is booting
>>>> fine on my laptop, but I think you should try it on the machine with
>>>> the memory ranges not at page boundary.
>>>>
>>>>
>>>> Juergen
>>>>
>>>>
>>>> extramem.patch
>>>>
>>>>
>>>> commit 3d0f8aa4d1b4c9c16a81902a197b5d6a77e182a0
>>>> Author: Juergen Gross <jgross@suse.com>
>>>> Date:   Thu Sep 3 17:44:04 2015 +0200
>>>>
>>>>       xen: switch extra memory accounting to use pfns
>>>>
>>>>       Instead of using physical addresses for accounting of extra memory
>>>>       areas available for ballooning switch to pfns as this is much less
>>>>       error prone regarding partial pages.
>>>
>>> Thanks for taking care of this! I've tested it on the box that has
>>> non-page aligned memory ranges and it works fine, only a couple of
>>> comments below.
>>>
>>>>       Reported-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>       Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>
>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>>> index 7a5d566..aa58bc4 100644
>>>> --- a/arch/x86/xen/setup.c
>>>> +++ b/arch/x86/xen/setup.c
>>>> @@ -90,62 +90,65 @@ static void __init xen_parse_512gb(void)
>>>>        xen_512gb_limit = val;
>>>>    }
>>>>
>>>> -static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t
>>>> size)
>>>> +static void __init xen_add_extra_mem(unsigned long start_pfn,
>>>> +                     unsigned long n_pfns)
>>>
>>> Not very important, but for type consistency this should probably be
>>> xen_pfn_t instead of unsigned long here and below.
>>
>> All of the p2m code is using unsigned long for pfns. I wouldn't mind
>> changing this to use xen_pfn_t instead, but this should be done in a
>> separate patch. I'll put it on my list.
>>
>>>
>>>>    {
>>>>        int i;
>>>>
>>>>        for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
>>>>            /* Add new region. */
>>>> -        if (xen_extra_mem[i].size == 0) {
>>>> -            xen_extra_mem[i].start = start;
>>>> -            xen_extra_mem[i].size  = size;
>>>> +        if (xen_extra_mem[i].n_pfns == 0) {
>>>> +            xen_extra_mem[i].start_pfn = start_pfn;
>>>> +            xen_extra_mem[i].n_pfns = n_pfns;
>>>>                break;
>>>>            }
>>>>            /* Append to existing region. */
>>>> -        if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) {
>>>> -            xen_extra_mem[i].size += size;
>>>> +        if (xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns ==
>>>> +            start_pfn) {
>>>> +            xen_extra_mem[i].n_pfns += n_pfns;
>>>>                break;
>>>>            }
>>>
>>> I also noticed this with the original code, why isn't there a case to
>>> prepend to an existing region:
>>>
>>> if (start_pfn + n_pfns == xen_extra_mem[i].start_pfn) {
>>>       xen_extra_mem[i].n_pfns += n_pfns;
>>>       xen_extra_mem[i].start_pfn = start_pfn;
>>> }
>>
>> Processing of memory is done from low to high addresses. This case
>> should never happen. And even if it does, the only downside from
>> not handling this scenario is wasting an additional table entry.
>
> Right, this case would only be useful for xen_del_extra_mem, and as you
> say, the worst that can happen is that we end up using an extra slot.

Even this case should be impossible. It would require two adjacent
regions to be present in xen_extra_mem before calling xen_del_extra_mem
which is impossible as stated above.

>
>>>
>>>>        }
>>>>        if (i == XEN_EXTRA_MEM_MAX_REGIONS)
>>>>            printk(KERN_WARNING "Warning: not enough extra memory
>>>> regions\n");
>>>>
>>>> -    memblock_reserve(start, size);
>>>> +    memblock_reserve(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
>>>>    }
>>>
>>> [...]
>>>
>>>> @@ -831,9 +833,11 @@ char * __init xen_memory_setup(void)
>>>>                    chunk_size = min(size, mem_end - addr);
>>>>                } else if (extra_pages) {
>>>>                    chunk_size = min(size, PFN_PHYS(extra_pages));
>>>> -                extra_pages -= PFN_DOWN(chunk_size);
>>>> -                xen_add_extra_mem(addr, chunk_size);
>>>> -                xen_max_p2m_pfn = PFN_DOWN(addr + chunk_size);
>>>> +                pfn_s = PFN_UP(addr);
>>>> +                n_pfns = PFN_DOWN(addr + chunk_size) - pfn_s;
>>>
>>> Should xen_add_extra_mem check for empty ranges and bail out early, or
>>> should the caller make sure it doesn't try to add empty ranges?
>>>
>>> IMHO it's easier and cleaner to add the check to xen_add_extra_mem.
>>
>> This isn't critical at all. Adding an empty range is a nop, as a table
>> entry is regarded to be not used when n_pfns is 0.
>
> Yes, it's just so we can bail out earlier instead of iterating over the
> whole xen_extra_mem for empty ranges. IMHO, I would add a check to
> xen_add_extra_mem so we don't waste cycles.

The question is whether the additional check for each call wouldn't add
more cycles than the early bail out for the rare case would win.

A comment seems to be an appropriate measure. :-)


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218300

El 03/09/15 a les 14.25, Juergen Gross ha escrit:
> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>> On systems with memory maps with ranges that don't end at page
>> boundaries,
>> like:
>>
>> [...]
>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>> [...]
>>
>> xen_add_extra_mem will create a protected range that ends up at
>> 0xdfdf9c00,
>> but the function used to check if a memory address is inside of a
>> protected
>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>> will be
>> refused because the check is performed against 0xdfdf9000 instead of
>> 0xdfdf9c00.
>>
>> In order to fix this, make sure that the ranges that are added to the
>> xen_extra_mem array are aligned to page boundaries.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Cc: David Vrabel <david.vrabel@citrix.com>
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: xen-devel@lists.xenproject.org
>> ---
>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>> ---
>>   arch/x86/xen/setup.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 55f388e..dcf5865 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>> start, phys_addr_t size)
>>   {
>>       int i;
>>
>> +    start = PAGE_ALIGN(start);
>> +    size &= PAGE_MASK;
> 
> This is not correct. If start wasn't page aligned and size was, you'll
> add one additional page to xen_extra_mem.

I'm not understanding this, let's put an example:

start = 0x8c00
size = 0x1000

After the fixup added above this would become:

start = 0x9000
size = 0x1000

So if anything, I'm adding one page less (because 0x8000 was partly
added, and with the fixup it is not added).

Roger.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218315

On 09/03/2015 04:38 PM, Roger Pau Monné wrote:
> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>> On systems with memory maps with ranges that don't end at page
>>> boundaries,
>>> like:
>>>
>>> [...]
>>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>>> [...]
>>>
>>> xen_add_extra_mem will create a protected range that ends up at
>>> 0xdfdf9c00,
>>> but the function used to check if a memory address is inside of a
>>> protected
>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>> will be
>>> refused because the check is performed against 0xdfdf9000 instead of
>>> 0xdfdf9c00.
>>>
>>> In order to fix this, make sure that the ranges that are added to the
>>> xen_extra_mem array are aligned to page boundaries.
>>>
>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Cc: David Vrabel <david.vrabel@citrix.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: xen-devel@lists.xenproject.org
>>> ---
>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>> ---
>>>    arch/x86/xen/setup.c | 6 ++++++
>>>    1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>> index 55f388e..dcf5865 100644
>>> --- a/arch/x86/xen/setup.c
>>> +++ b/arch/x86/xen/setup.c
>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>> start, phys_addr_t size)
>>>    {
>>>        int i;
>>>
>>> +    start = PAGE_ALIGN(start);
>>> +    size &= PAGE_MASK;
>>
>> This is not correct. If start wasn't page aligned and size was, you'll
>> add one additional page to xen_extra_mem.
>
> I'm not understanding this, let's put an example:
>
> start = 0x8c00
> size = 0x1000
>
> After the fixup added above this would become:
>
> start = 0x9000
> size = 0x1000
>
> So if anything, I'm adding one page less (because 0x8000 was partly
> added, and with the fixup it is not added).

You'd add 9c00-9cff which shouldn't be added (in this example you
shouldn't add anything as no complete page is covered by the range).

You need something like:

end = (start + size) & PAGE_MASK;
start = PAGE_ALIGN(start);
size = end - start;
if (!size)
      return;


Juergen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web