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

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

[Roger Pau Monne]

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)

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

[Roger Pau Monné]

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


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

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

[Roger Pau Monné]

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

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

[Juergen Gross]

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


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

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

[Juergen Gross]

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

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

[Juergen Gross]

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

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

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

[Juergen Gross]

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

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

[Roger Pau Monné]

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.

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

[David Vrabel]

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

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

[David Vrabel]

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

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

[Juergen Gross]

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

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

[David Vrabel]

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

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

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

[David Vrabel]

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

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

[Juergen Gross]

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


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

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

[Juergen Gross]

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

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

[Roger Pau Monné]

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.

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

[Juergen Gross]

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

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

[Juergen Gross]

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


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

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

[Juergen Gross]

[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: extramem.patch --]
[-- Type: text/x-patch; name="extramem.patch", Size: 6874 bytes --]

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.

    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)
 {
 	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;
 		}
 	}
 	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));
 }

-static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
+static void __init xen_del_extra_mem(unsigned long start_pfn,
+				     unsigned long n_pfns)
 {
 	int i;
-	phys_addr_t start_r, size_r;
+	unsigned long start_r, size_r;

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

 		/* Start of region. */
-		if (start_r == start) {
-			BUG_ON(size > size_r);
-			xen_extra_mem[i].start += size;
-			xen_extra_mem[i].size -= size;
+		if (start_r == start_pfn) {
+			BUG_ON(n_pfns > size_r);
+			xen_extra_mem[i].start_pfn += n_pfns;
+			xen_extra_mem[i].n_pfns -= n_pfns;
 			break;
 		}
 		/* End of region. */
-		if (start_r + size_r == start + size) {
-			BUG_ON(size > size_r);
-			xen_extra_mem[i].size -= size;
+		if (start_r + size_r == start_pfn + n_pfns) {
+			BUG_ON(n_pfns > size_r);
+			xen_extra_mem[i].n_pfns -= n_pfns;
 			break;
 		}
 		/* Mid of region. */
-		if (start > start_r && start < start_r + size_r) {
-			BUG_ON(start + size > start_r + size_r);
-			xen_extra_mem[i].size = start - start_r;
+		if (start_pfn > start_r && start_pfn < start_r + size_r) {
+			BUG_ON(start_pfn + n_pfns > start_r + size_r);
+			xen_extra_mem[i].n_pfns = start_pfn - start_r;
 			/* Calling memblock_reserve() again is okay. */
-			xen_add_extra_mem(start + size, start_r + size_r -
-					  (start + size));
+			xen_add_extra_mem(start_pfn + n_pfns, start_r + size_r -
+					  (start_pfn + n_pfns));
 			break;
 		}
 	}
-	memblock_free(start, size);
+	memblock_free(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
 }

 /*
@@ -156,11 +159,10 @@ static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
 unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
 {
 	int i;
-	phys_addr_t addr = PFN_PHYS(pfn);

 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
-		if (addr >= xen_extra_mem[i].start &&
-		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+		if (pfn >= xen_extra_mem[i].start_pfn &&
+		    pfn < xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns)
 			return INVALID_P2M_ENTRY;
 	}

@@ -176,10 +178,10 @@ void __init xen_inv_extra_mem(void)
 	int i;

 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
-		if (!xen_extra_mem[i].size)
+		if (!xen_extra_mem[i].n_pfns)
 			continue;
-		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
-		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		pfn_s = xen_extra_mem[i].start_pfn;
+		pfn_e = pfn_s + xen_extra_mem[i].n_pfns;
 		for (pfn = pfn_s; pfn < pfn_e; pfn++)
 			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
@@ -507,7 +509,7 @@ void __init xen_remap_memory(void)
 		} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 			len += xen_remap_buf.size;
 		} else {
-			xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
+			xen_del_extra_mem(pfn_s, len);
 			pfn_s = xen_remap_buf.target_pfn;
 			len = xen_remap_buf.size;
 		}
@@ -517,7 +519,7 @@ void __init xen_remap_memory(void)
 	}

 	if (pfn_s != ~0UL && len)
-		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(pfn_s, len);

 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);

@@ -744,7 +746,7 @@ static void __init xen_reserve_xen_mfnlist(void)
  **/
 char * __init xen_memory_setup(void)
 {
-	unsigned long max_pfn;
+	unsigned long max_pfn, pfn_s, n_pfns;
 	phys_addr_t mem_end, addr, size, chunk_size;
 	u32 type;
 	int rc;
@@ -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;
+				extra_pages -= n_pfns;
+				xen_add_extra_mem(pfn_s, n_pfns);
+				xen_max_p2m_pfn = pfn_s + n_pfns;
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index bf4a23c..1fa633b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -638,9 +638,9 @@ static int __init balloon_init(void)
 	 * regions (see arch/x86/xen/setup.c).
 	 */
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++)
-		if (xen_extra_mem[i].size)
-			balloon_add_region(PFN_UP(xen_extra_mem[i].start),
-					   PFN_DOWN(xen_extra_mem[i].size));
+		if (xen_extra_mem[i].n_pfns)
+			balloon_add_region(xen_extra_mem[i].start_pfn,
+					   xen_extra_mem[i].n_pfns);

 	return 0;
 }
diff --git a/include/xen/page.h b/include/xen/page.h
index c5ed20b..a5983da 100644
--- a/include/xen/page.h
+++ b/include/xen/page.h
@@ -9,8 +9,8 @@ static inline unsigned long page_to_mfn(struct page *page)
 }

 struct xen_memory_region {
-	phys_addr_t start;
-	phys_addr_t size;
+	unsigned long start_pfn;
+	unsigned long n_pfns;
 };

 #define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

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

[Juergen Gross]

[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: extramem.patch --]
[-- Type: text/x-patch; name="extramem.patch", Size: 6689 bytes --]

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.
    
    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)
 {
 	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;
 		}
 	}
 	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));
 }
 
-static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
+static void __init xen_del_extra_mem(unsigned long start_pfn,
+				     unsigned long n_pfns)
 {
 	int i;
-	phys_addr_t start_r, size_r;
+	unsigned long start_r, size_r;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
-		start_r = xen_extra_mem[i].start;
-		size_r = xen_extra_mem[i].size;
+		start_r = xen_extra_mem[i].start_pfn;
+		size_r = xen_extra_mem[i].n_pfns;
 
 		/* Start of region. */
-		if (start_r == start) {
-			BUG_ON(size > size_r);
-			xen_extra_mem[i].start += size;
-			xen_extra_mem[i].size -= size;
+		if (start_r == start_pfn) {
+			BUG_ON(n_pfns > size_r);
+			xen_extra_mem[i].start_pfn += n_pfns;
+			xen_extra_mem[i].n_pfns -= n_pfns;
 			break;
 		}
 		/* End of region. */
-		if (start_r + size_r == start + size) {
-			BUG_ON(size > size_r);
-			xen_extra_mem[i].size -= size;
+		if (start_r + size_r == start_pfn + n_pfns) {
+			BUG_ON(n_pfns > size_r);
+			xen_extra_mem[i].n_pfns -= n_pfns;
 			break;
 		}
 		/* Mid of region. */
-		if (start > start_r && start < start_r + size_r) {
-			BUG_ON(start + size > start_r + size_r);
-			xen_extra_mem[i].size = start - start_r;
+		if (start_pfn > start_r && start_pfn < start_r + size_r) {
+			BUG_ON(start_pfn + n_pfns > start_r + size_r);
+			xen_extra_mem[i].n_pfns = start_pfn - start_r;
 			/* Calling memblock_reserve() again is okay. */
-			xen_add_extra_mem(start + size, start_r + size_r -
-					  (start + size));
+			xen_add_extra_mem(start_pfn + n_pfns, start_r + size_r -
+					  (start_pfn + n_pfns));
 			break;
 		}
 	}
-	memblock_free(start, size);
+	memblock_free(PFN_PHYS(start_pfn), PFN_PHYS(n_pfns));
 }
 
 /*
@@ -156,11 +159,10 @@ static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size)
 unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
 {
 	int i;
-	phys_addr_t addr = PFN_PHYS(pfn);
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
-		if (addr >= xen_extra_mem[i].start &&
-		    addr < xen_extra_mem[i].start + xen_extra_mem[i].size)
+		if (pfn >= xen_extra_mem[i].start_pfn &&
+		    pfn < xen_extra_mem[i].start_pfn + xen_extra_mem[i].n_pfns)
 			return INVALID_P2M_ENTRY;
 	}
 
@@ -176,10 +178,10 @@ void __init xen_inv_extra_mem(void)
 	int i;
 
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) {
-		if (!xen_extra_mem[i].size)
+		if (!xen_extra_mem[i].n_pfns)
 			continue;
-		pfn_s = PFN_DOWN(xen_extra_mem[i].start);
-		pfn_e = PFN_UP(xen_extra_mem[i].start + xen_extra_mem[i].size);
+		pfn_s = xen_extra_mem[i].start_pfn;
+		pfn_e = pfn_s + xen_extra_mem[i].n_pfns;
 		for (pfn = pfn_s; pfn < pfn_e; pfn++)
 			set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 	}
@@ -507,7 +509,7 @@ void __init xen_remap_memory(void)
 		} else if (pfn_s + len == xen_remap_buf.target_pfn) {
 			len += xen_remap_buf.size;
 		} else {
-			xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
+			xen_del_extra_mem(pfn_s, len);
 			pfn_s = xen_remap_buf.target_pfn;
 			len = xen_remap_buf.size;
 		}
@@ -517,7 +519,7 @@ void __init xen_remap_memory(void)
 	}
 
 	if (pfn_s != ~0UL && len)
-		xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len));
+		xen_del_extra_mem(pfn_s, len);
 
 	set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
 
@@ -744,7 +746,7 @@ static void __init xen_reserve_xen_mfnlist(void)
  **/
 char * __init xen_memory_setup(void)
 {
-	unsigned long max_pfn;
+	unsigned long max_pfn, pfn_s, n_pfns;
 	phys_addr_t mem_end, addr, size, chunk_size;
 	u32 type;
 	int rc;
@@ -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;
+				extra_pages -= n_pfns;
+				xen_add_extra_mem(pfn_s, n_pfns);
+				xen_max_p2m_pfn = pfn_s + n_pfns;
 			} else
 				type = E820_UNUSABLE;
 		}
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index bf4a23c..1fa633b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -638,9 +638,9 @@ static int __init balloon_init(void)
 	 * regions (see arch/x86/xen/setup.c).
 	 */
 	for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++)
-		if (xen_extra_mem[i].size)
-			balloon_add_region(PFN_UP(xen_extra_mem[i].start),
-					   PFN_DOWN(xen_extra_mem[i].size));
+		if (xen_extra_mem[i].n_pfns)
+			balloon_add_region(xen_extra_mem[i].start_pfn,
+					   xen_extra_mem[i].n_pfns);
 
 	return 0;
 }
diff --git a/include/xen/page.h b/include/xen/page.h
index c5ed20b..a5983da 100644
--- a/include/xen/page.h
+++ b/include/xen/page.h
@@ -9,8 +9,8 @@ static inline unsigned long page_to_mfn(struct page *page)
 }
 
 struct xen_memory_region {
-	phys_addr_t start;
-	phys_addr_t size;
+	unsigned long start_pfn;
+	unsigned long n_pfns;
 };
 
 #define XEN_EXTRA_MEM_MAX_REGIONS 128 /* == E820MAX */

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

[Roger Pau Monné]

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.

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

[Juergen Gross]

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

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

[Roger Pau Monné]

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.


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

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

[Roger Pau Monné]

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.

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

[Juergen Gross]

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

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

[Juergen Gross]

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


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

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

[Juergen Gross]

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


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

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

[Roger Pau Monné]

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.


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

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

[Roger Pau Monné]

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.


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

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

[Juergen Gross]

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


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

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

[David Vrabel]

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

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

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

[David Vrabel]

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

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

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

[Juergen Gross]

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

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

[Juergen Gross]

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


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

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

[Roger Pau Monné]

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.

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

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

[Roger Pau Monne]

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)


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

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

[Roger Pau Monne]

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