On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 27/01/17 18:22, Tamas K Lengyel wrote: >> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos <m...@starlab.io> 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. > > I'd argue that this is a bug. Destroying a view should clean everything up. >
Yeap, but there is a workaround at least. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
