Re: [Xen-devel] [PATCH v3] xen/arm: alternative: Register re-mapped Xen area as a temporary virtual region

[Julien Grall <julien.grall@xxxxxxx>]

Hi Wei,

On 27/03/17 09:40, Wei Chen wrote:
> Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
Thank you for updating the commit message :). With the small change below:

Reviewed-by: Julien Grall <julien.grall@xxxxxxx>

> ---
> Notes:
> This bug will affect the staging, staging-4.8 and stable-4.8 source trees.
>
> ---
> v2->v3
> 1. Fix typos.
> 2. Explain this bug only happening when booting Xen in commit message.
>
> ---
>  xen/arch/arm/alternative.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> index 1d10f51..96859fc 100644
> --- a/xen/arch/arm/alternative.c
> +++ b/xen/arch/arm/alternative.c
> @@ -24,6 +24,7 @@
>  #include <xen/vmap.h>
>  #include <xen/smp.h>
>  #include <xen/stop_machine.h>
> +#include <xen/virtual_region.h>
>  #include <asm/alternative.h>
>  #include <asm/atomic.h>
>  #include <asm/byteorder.h>
> @@ -154,8 +155,12 @@ static int __apply_alternatives_multi_stop(void *unused)
>          int ret;
>          struct alt_region region;
>          mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
> -        unsigned int xen_order = get_order_from_bytes(_end - _start);
> +        unsigned int xen_size = _end - _start;
I didn't notice it on the previous reviews. xen_size should technically 
be paddr_t.
It is more for consistency than a real bug as the result _end - _start 
will unlikely ever be > 4GB. I think Stefano should be able to fix on 
commit. So no need to resend the patch.
Cheers,

--
Julien Grall

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