xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Julien Grall <julien.grall@arm.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current
Date: Mon, 12 Dec 2016 12:41:18 -0700	[thread overview]
Message-ID: <CAErYnsgHfYLmftFFEc2xdn95dCpCdr4f7gFCUDFwOgoWbH0mKA@mail.gmail.com> (raw)
In-Reply-To: <73b6b6c0-8acd-6df2-3bdf-775342fffb01@arm.com>

On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi Tamas,
>
> On 12/12/16 18:42, Tamas K Lengyel wrote:
>>
>> On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall <julien.grall@arm.com>
>> wrote:
>>>
>>> The translation VA to IPA (guest physical address) is done using
>>> hardware.
>>> If the underlying memory of the stage-1 page table is protected, so the
>>> translation will fail. Given that this function is used in hypercall to
>>> retrieve the page associated to a buffer, it means that it will not be
>>> possible to do hypercall when the page table used to find the buffer IPA
>>> has
>>> not been touched.
>>
>>
>> This function specifically works around the case where the page of the
>> guest pagetable is not accessible due to mem_access, when the hardware
>> based lookup doesn't work.This function checks what the fault was,
>> checks the page type and the mem_access rights to determine whether
>> the fault was legit, or if it was due to mem_access. If it was
>> mem_access it gets the page without involving the hardware. I'm not
>> following what you describe afterwards regarding the buffer and what
>> you mean by "the buffer IPA has not been touched". Care to elaborate?
>
>
> I am afraid to say that the function does not do what you think and is still
> using the hardware to do the translation. For instance the function
> gva_to_ipa is using the hardware to translate a VA to IPA.
>
> This function is called when it is not possible to directly translate a VA
> to a PA. This may fail for various reason:
>         * The underlying memory of the buffer was restricted in stage-2
>         * The underlying memory of stage-1 page tables was restricted in
> stage-2
>
> Whilst the function is solving the former, the latter will not work due to
> the call to gva_to_ipa. This will fail because the stage-1 PT are not
> accessible.

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. A way
to work around this would require mem_access restrictions to be
complete removed, which cannot be done unless all other vCPUs of the
domain are paused to avoid a race-condition. With altp2m I could also
envision creating a temporary p2m for the vcpu at hand with the
restriction removed, so that it doesn't affect other vcpus. However,
without a use-case specifically requiring this to be implemented I
would not deem it critical. For now a comment in the header describing
this limitation would suffice from my perspective.

Thanks,
Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-12-12 19:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-09 19:59 [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current Tamas K Lengyel
2016-12-09 19:59 ` [PATCH v2 2/2] p2m: split mem_access into separate files Tamas K Lengyel
2017-01-03 15:31   ` Tamas K Lengyel
2017-01-11 16:33     ` Konrad Rzeszutek Wilk
2017-01-30 21:11   ` Stefano Stabellini
2016-12-12  7:42 ` [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current Jan Beulich
2016-12-12  7:47   ` Tamas K Lengyel
2016-12-12 11:46     ` Julien Grall
2016-12-12 18:42       ` Tamas K Lengyel
2016-12-12 19:11         ` Julien Grall
2016-12-12 19:41           ` Tamas K Lengyel [this message]
2016-12-12 21:28             ` Julien Grall
2016-12-12 23:47               ` Tamas K Lengyel
2016-12-13 12:50                 ` Julien Grall
2016-12-13 18:03                   ` Tamas K Lengyel
2016-12-13 18:39                   ` Tamas K Lengyel
2016-12-13 18:28                 ` Andrew Cooper
2016-12-13 18:41                   ` Julien Grall
2016-12-13 19:39                     ` Andrew Cooper
2016-12-14 12:05                       ` Julien Grall
2016-12-15  4:54                         ` George Dunlap
2016-12-15 16:16                           ` Julien Grall
2017-01-03 15:29 ` Tamas K Lengyel
2017-01-30 21:11 ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAErYnsgHfYLmftFFEc2xdn95dCpCdr4f7gFCUDFwOgoWbH0mKA@mail.gmail.com \
    --to=tamas.lengyel@zentific.com \
    --cc=JBeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).