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

From: Julien Grall <julien.grall@arm.com>
To: Jan Beulich <JBeulich@suse.com>, sstabellini@kernel.org
Cc: Kaly.Xin@arm.com, nd@arm.com, xen-devel@lists.xen.org,
	Wei Chen <Wei.Chen@arm.com>,
	steve.capper@arm.com
Subject: Re: [PATCH v3] xen/arm: alternative: Register re-mapped Xen area as a temporary virtual region
Date: Fri, 31 Mar 2017 09:27:32 +0100	[thread overview]
Message-ID: <34bc2b04-806f-34a0-76dc-5476eb3cd1df@arm.com> (raw)
In-Reply-To: <58DE1786020000780014B02B@prv-mh.provo.novell.com>

On 03/31/2017 07:47 AM, Jan Beulich wrote:
>>>> On 29.03.17 at 16:23, <julien.grall@arm.com> wrote:
>> On 27/03/17 09:40, Wei Chen wrote:
>>> @@ -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.
>
> Hmm, this mostly addresses one of the two complaints I was going
> to make (pushing a patch which didn't go via xen-devel).

Actually, I was expected the patch to be fixed up on commit and not seen 
a separate commit. I am not sure why it has been done like that... and 
the commit title does not make that much sense.

Cheers,

-- 
Julien Grall

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