[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 3/4] xen/arm: switch ARM to use generic implementation of bug.h



On 28/02/2023 17:21, Oleksii wrote:
Hi Julien,

Hi Oleksii,

On Sat, 2023-02-25 at 17:05 +0000, Julien Grall wrote:


On 25/02/2023 16:49, Julien Grall wrote:
Hi Oleksii,

On 24/02/2023 11:31, Oleksii Kurochko wrote:
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM

I have asked in patch #1 but will ask it again because I think this
should be recorded in the commit message. Can you outline why it is
not
possible to completely switch to the generic version?

I have just tried to remove it on arm64 and it seems to work. This
was
only tested with GCC 10 though. But given the generic version is not
not
using the %c modifier, then I wouldn't expect any issue.

Cheers,


I tried to switch ARM to generic implementation.

Here is the patch: [1]

This is similar to the patch I wrote to test with generic implementation on Arm (see my other reply).

[...]

(it will be merged with patch 3 if it is OK )

And looks like we can switch ARM to generic implementation as all tests
passed:
https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/791549396

Thanks for checking with the gitlab CI!


The only issue is with yocto-arm:
https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/791549396/failures
But I am not sure that it is because of my patch

This looks unrelated to me. This is happening because there is a data abort before PSCI (used to reboot the platform) is properly setup. I think we should consider to only print once the error rather than every few iterations (not a request for you).

That said, I am a bit puzzled why this issue is only happening in the Yocto test (the Debian one pass). Do you know if the test is passing in the normal CI?

If yes, what other modifications did you do?

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.