On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/2019 18:59, Stefano Stabellini wrote:
> > On Thu, 13 Jun 2019, Julien Grall wrote: + * Return values:
> + * XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
> + * was empty, or allocating a new page
Hi Stefano,
On 13/06/2019 18:59, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote: + * Return values:
+ * XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
+ * was empty, or allocating a new page failed.
+ * XEN_TABLE_NORMAL_PAGE: next level
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:52 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > Currently, xen_pt_update_entry() is only able to update the region covered
> > > by xen_second (i.e 0 to 0x7fff).
> > >
> > > Because
Hi Stefano,
On 6/12/19 11:52 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying
On Tue, 14 May 2019, Julien Grall wrote:
> Currently, xen_pt_update_entry() is only able to update the region covered
> by xen_second (i.e 0 to 0x7fff).
>
> Because of the restriction we end to have multiple functions in mm.c
> modifying the page-tables differently.
>
> Furthermore, we never
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying the page-tables differently.
Furthermore, we never walked the page-tables fully. This means that any
