Hi,
On 11/13/2017 11:06 AM, Jan Beulich wrote:
On 13.11.17 at 11:34, wrote:
Our debug showed the concerned page->count_info was already(and
unexpectedly)
cleared in free_xenheap_pages(), and the call trace should be like this:
free_xenheap_pages()
^
|
>>> On 13.11.17 at 11:34, wrote:
> Our debug showed the concerned page->count_info was already(and
> unexpectedly)
> cleared in free_xenheap_pages(), and the call trace should be like this:
>
> free_xenheap_pages()
> ^
> |
> free_xen_pagetable()
> ^
>
On 11/13/2017 5:31 PM, Jan Beulich wrote:
On 10.11.17 at 15:05, wrote:
On 11/10/2017 5:49 PM, Jan Beulich wrote:
I'm not certain this is important enough a fix to consider for 4.10,
and you seem to think it's good enough if this gets applied only
after the tree
>>> On 10.11.17 at 15:05, wrote:
> On 11/10/2017 5:49 PM, Jan Beulich wrote:
>> I'm not certain this is important enough a fix to consider for 4.10,
>> and you seem to think it's good enough if this gets applied only
>> after the tree would be branched, as you didn't
On 11/10/2017 5:49 PM, Jan Beulich wrote:
On 10.11.17 at 08:18, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4844,9 +4844,19 @@ int map_pages_to_xen(
{
unsigned long base_mfn;
-pl1e =
>>> On 10.11.17 at 08:18, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4844,9 +4844,19 @@ int map_pages_to_xen(
> {
> unsigned long base_mfn;
>
> -pl1e = l2e_to_l1e(*pl2e);
> if (
From: Min He
In map_pages_to_xen(), a L2 page table entry may be reset to point to
a superpage, and its corresponding L1 page table need be freed in such
scenario, when these L1 page table entries are mapping to consecutive
page frames and having the same mapping flags.