;>
>> NB that this is not a security issue: The only time this codepath is
>> called is in cases where either nestedp2m or altp2m is enabled, and
>> neither of them are in security support.
>>
>> Reported-by: Matt Leinhos
>> Signed-off-by: George Dunlap
>&
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
--
Ma
Andrew,
Thank you for the tip. The crash does not happen when the "maxmem"
option in the config file is disabled. I still get funny behavior with
my driver, but I need to investigate that further.
Regards,
Matt
On 11/02/2016 08:23 AM, Andrew Cooper wrote:
> On 02/11/16 13:16, Matt
crash happens immediately. I've also seen a delayed host crash
with Xen 4.6, but I'm focusing on the 4.8 RC here.
I don't know exactly which step causes the crash. I'll continue my
investigation today.
I'll work on a sample driver to exercise the crash if that's helpf
ler in the xen code or through searches.
I am attempting to use the altp2m API from a domU and need to handle #VE.
Thank you,
Matt Leinhos
Star Lab, San Antonio, TX
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
