(+xen-devel, juergen, boris)
On 08/05/2019 10:25, Andrii Anisov wrote:
Hello Julien,
On 03.05.19 13:19, Julien Grall wrote:
Could you be a bit more specific about the failure? Do you see "Failed to walk
page-table"?
Sorry for a delayed answer.
Yes, I see еру following, also with your patch (and replacing dprintk with
printk, 'cause it is more convenient to me to issue a non-debug build):
(XEN) d1v3 par 0x809
(XEN) d1v1 par 0x809
(XEN) d1v2 par 0x809
(XEN) d1v0 par 0x809
(XEN) d1v3: Failed to walk page-table va 0xffff80002ff7e348
(XEN) d1v1: Failed to walk page-table va 0xffff80002ff4e348
(XEN) d1v2: Failed to walk page-table va 0xffff80002ff66348
(XEN) d1v0: Failed to walk page-table va 0xffff80002ff36348
As I understand ARM ARM, EL1_PAR says it is the "translation fault level" (as
per "ISS encoding for an exception from a Data Abort", DFSC bits).
That's a translation fault level 0 on a stage-1 page-table walk. To confirm you
have kpti disabled, right? Does it always fail, or only time to time? Could you
dump the guest register when this happen?
Even with kpti disabled, you are still potentially facing issue using virtual
address (although they may be more difficult to trigger). Indeed, you are
relying on the guest OS to unmap the regions or touch the page-tables entries
used for the walk.
Unfortunately we can't prevent a guest playing with its page-table. So at best
we can only workaround it.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
