Re: [Xen-devel] [PATCH v2 14/25] arm/altp2m: Make get_page_from_gva ready for altp2m.

[Julien Grall <julien.grall@xxxxxxx>]

On 06/08/2016 11:38, Sergej Proskurin wrote:
> Hi Julien,
Hello Serge,

> On 08/04/2016 01:59 PM, Julien Grall wrote:
> > Hello Sergej,
> >
> > On 01/08/16 18:10, Sergej Proskurin wrote:
> > > The function get_page_from_gva uses ARM's hardware support to translate
> > > gva's to machine addresses. This function is used, among others, for
> > > memory regulation purposes, e.g, within the context of memory
> > > ballooning.
> > > To ensure correct behavior while altp2m is in use, we use the host's p2m
> > > table for the associated gva to ma translation. This is required at this
> > > point, as altp2m lazily copies pages from the host's p2m and even might
> > > be flushed because of changes to the host's p2m (as it is done within
> > > the context of memory ballooning).
> > I was expecting to see some change in
> > p2m_mem_access_check_and_get_page. Is there any reason to not fix it?
> I did not yet encounter any issues with
> p2m_mem_access_check_and_get_page. According to ARM ARM, ATS1C** (see
> gva_to_ipa_par) translates VA to IPA in non-secure privilege levels (as
> it is the the case here). Thus, the 2nd level translation represented by
> the (alt)p2m is not really considered at this point and hence make an
> extension obsolete.
>
> Or did you have anything else in mind?
The stage-1 page tables are living in the guest memory. So every time 
you access an entry in the page table, you have to translate the IPA 
(guest physical address) into a PA.
However, the underlying memory of those page table may have restriction 
permission or does not exist in the altp2m at all. So the translation 
will fail.
Regards,

--
Julien Grall

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