Hi Andrii,
On 2/4/19 3:19 PM, Andrii Anisov wrote:
On 04.02.19 13:36, Julien Grall wrote:
That's a good news! Let me try to address your concerns below one by one.
Lets do it:)
And they employ KPTI enabled kernel in the BSP.
KPTI is going to work on Xen. There are no known issue with Linux as
the virtual address is not going to be re-used for other purpose in
the virtual address space. The only inconvenience is the message in
debug build.
Just in case, I am not saying it should not be fixed :).
We have a decision to eliminate it.
That reveals another critical issue for us, in addition to Set/Way issue
From the discussion on the another thread and with other people, this
is not entirely the fault of Xen. This was a misuse of the
instructions by the driver.
Yep, but it is still on our team to solve.
While you may want to deal with this in your case, I would like to
avoid promoting bad behavior when using Xen upstream.
Ah, ok. Will say that in different words.
and possible performance drops/irq latency raise due to specter
mitigation measures.
Can you remind me the cores you are using?
A57+A53.
I see the following in my log:
(XEN) alternatives: Patching with alt table 00000000002c6608 ->
00000000002c6c80
(XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
Cortex-A53 should not be affected by spectre v2, so I imagine they are
only for A57?
It is going to be hard to disable the workarounds by default. But we can
consider to provide host-wide or per-guest option to disable them on
trusted environment.
Also, when you mean possible, does it mean you haven't looked the
performance regression?
We have a preliminary results about performance drop with
xen4.12-unstable comparing to a our system with 4.10.
A lot of patches have not been backported in Xen 4.10 (including
Spectre/Meltdown) that will definitely fix hole but may have an impact
on the performance. There were not backported because of performance
reason but because of the complexity of the port and seemly lack of
interest.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel