Re: [Xen-devel] altp2m: unexpected behavior

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> 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.
>

Yeap, but there is a workaround at least.

Tamas

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