Re: [Xen-devel] altp2m: unexpected behavior

[George Dunlap <dunlapg@xxxxxxxxx>]

On Fri, Jan 27, 2017 at 7:10 PM, Tamas K Lengyel
<tamas.lengyel@xxxxxxxxxxxx> wrote:
> 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.

Hmm, it seems the problem is that p2m_flush_table() assumes you're
calling it because you're running in nested virt mode, and will return
early if the table isn't a nested table.

Let me take a look.

 -George

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