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

Re: [Xen-devel] altp2m: unexpected behavior



On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos <matt@xxxxxxxxxx> wrote:
> Hello,
>
> In developing against the altp2m API, I've encountered something I
> wasn't expecting.
>
> Here's the scenario:
>
> 1. Create a new altp2m memory view. Assume we get view ID 1.
> 2. Change some MFN permissions in view 1.
> 3. Destroy view 1.
> 4. Create another altp2m view. Get view ID 1 again.
>
>
> Now, I was expecting that by destroying the view in step 3, all the MFNs
> in that view would revert back to XENMEM_access_default. However, after
> completing step 4, I still encounter #VEs based on the permissions I set
> in step 2.
>
> Is this a deliberate design decision?
>
> Thanks,
> Matt

Hi Matt,
I'm not sure whether that is deliberate design decision but I've also
encountered the issue you are seeing. Destroying the view doesn't
actually seem to free/clean the tables, so you should do a manual
reset to the default permission of all GFNs you modified before you
destroy it. That will ensure that the next time you create a table
with that ID that it will be clean.

Cheers,
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®.