Re: [Xen-devel] [PATCH v2 0/2] Introduce runstate area registration with phys address

[Julien Grall <julien.grall@xxxxxxx>]

(+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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel