Re: [Xen-devel] altp2m: unexpected behavior

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/01/17 18:22, Tamas K Lengyel wrote:
> 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.

I'd argue that this is a bug.  Destroying a view should clean everything up.

~Andrew

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