[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current



On Tue, Dec 13, 2016 at 5:50 AM, Julien Grall <julien.grall@xxxxxxx> 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.grall@xxxxxxx>
>> wrote:
>>>
>>> On 12/12/2016 19:41, Tamas K Lengyel wrote:
>>>>
>>>> On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall <julien.grall@xxxxxxx>
>>>> wrote:
>>>>>
>>>>> On 12/12/16 18:42, Tamas K Lengyel wrote:
>>>>>>
>>>>>> On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall <julien.grall@xxxxxxx>
>>>>>> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.