On Tue, Dec 13, 2016 at 5:50 AM, Julien Grall <julien.gr...@arm.com> wrote: > Hello Tamas, > > On 12/12/16 23:47, Tamas K Lengyel wrote: >> >> On Mon, Dec 12, 2016 at 2:28 PM, Julien Grall <julien.gr...@arm.com> >> wrote: >>> >>> On 12/12/2016 19:41, Tamas K Lengyel wrote: >>>> >>>> On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall <julien.gr...@arm.com> >>>> wrote: >>>>> >>>>> On 12/12/16 18:42, Tamas K Lengyel wrote: >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall <julien.gr...@arm.com> >>>>>> wrote: >>>> >>>> I see. So IMHO this is not a problem with mem_access in general, but a >>>> problem with a specific application of mem_access on ARM (ie. >>>> restricting read access to guest pagetables). It's a pitty that ARM >>>> doesn't report the IPA automatically during a stage-2 violation. >>> >>> >>> >>> I don't understand what you are asking for here. If you are not able to >>> access stage-1 page table how would you be able to find the IPA? >> >> >> I'm not asking for anything, I'm expressing how it's a pity that ARM >> CPUs are limited in this regard compared to x86. > > > Give a look at the ARM ARM before complaining. The IPA will be provided (see > HPFAR) on a stage-2 data/prefetch abort fault.
Yes, we are already using HPFAR_EL2 when the guest faults with mem_access. Here however Xen faults when it tries to do gvirt_to_maddr. For some reason I was under the impression this register is only valid when the violation originates from guest context - hence my comment. If that's not the case we could avoid using gva_to_ipa and determine if mem_access was the reason for the gvirt_to_maddr failure by nature of having hpfar_is_valid return true AFAICT. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
