Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall <julien.grall@xxxxxxx>]

On 2/4/19 10:32 AM, Andrii Anisov wrote:
> Hello Julien,
Hi Andrii,

> On 01.02.19 12:51, Julien Grall wrote:
> > I don't consider polluting your log a real problem.
> Unless the system becomes an insane typewriter :)
>
> > I don't consider it as a critical issue because of the type of guest 
> > we currently support, so it is not in my queue for Xen 4.12 fixes.
> > Feel free to suggest it as a blocker if you think it is.
> Well, for us the situation is as following: Renesas requested XEN 4.12 
> for the next release of their virtualization package.
That's a good news! Let me try to address your concerns below one by one.

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

> 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. While you may want to deal with this in your case, I 
would like to avoid promoting bad behavior when using Xen upstream.
> and possible performance drops/irq latency raise due to specter 
> mitigation measures.
Can you remind me the cores you are using?

Also, when you mean possible, does it mean you haven't looked the 
performance regression?
> I'm not sure if this is sufficient a justification to make it the 
> release blocker, but we are up to this stuff.
Which one?

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel