Re: [Xen-devel] altp2m: unexpected behavior

2017-01-30 Thread George Dunlap
On Fri, Jan 27, 2017 at 7:10 PM, Tamas K Lengyel wrote: > On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper > wrote: >> On 27/01/17 18:22, Tamas K Lengyel wrote: >>> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote: Hello, In developing against the altp2m API, I've encountered so

Re: [Xen-devel] altp2m: unexpected behavior

2017-01-27 Thread Tamas K Lengyel
On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper wrote: > On 27/01/17 18:22, Tamas K Lengyel wrote: >> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote: >>> Hello, >>> >>> In developing against the altp2m API, I've encountered something I >>> wasn't expecting. >>> >>> Here's the scenario: >>> >

Re: [Xen-devel] altp2m: unexpected behavior

2017-01-27 Thread Andrew Cooper
On 27/01/17 18:22, Tamas K Lengyel wrote: > On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos 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. >>

Re: [Xen-devel] altp2m: unexpected behavior

2017-01-27 Thread Tamas K Lengyel
On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos 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. Destro

[Xen-devel] altp2m: unexpected behavior

2017-01-27 Thread Matt Leinhos
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