Xen devel - Nov 2011 - performance regression from c/s 21647:cfba1560054a

Stefano, Gianluca,

in this c/s you did, besides the main purpose of the change, an
adjustment to check_for_early_unshadow() in that L2...L4 entries
would no longer be attempted to get unshadowed. Neither the
patch description nor the added comment really make clear why
this was done, and we now got a customer report regarding this
causing considerable slowdown in process creation/destruction
intensive workloads (e.g. shell scripts).

Would you explain that change, and whether it is reasonable to
revert that part of said c/s?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Jan,

On a personal note, thanks for asking me about shadow pagetables, I''ve
been missing this kind of fun and it''s a good way to celebrate my
return to Xen (and Citrix) after exactly two years... :-)
Stefano imported an old patch of mine, so I am the culprit for this.

On Thu, Nov 10, 2011 at 3:23 AM, Jan Beulich <JBeulich@suse.com>
wrote:
> in this c/s you did, besides the main purpose of the change, an
> adjustment to check_for_early_unshadow() in that L2...L4 entries
> would no longer be attempted to get unshadowed. Neither the
> patch description nor the added comment really make clear why
> this was done, and we now got a customer report regarding this
> causing considerable slowdown in process creation/destruction
> intensive workloads (e.g. shell scripts).
Unfortunately, I can''t clearly remember the reason for this. I assume
that your mentioning of shell scripts implies that this is running
under a Linux guest. Back in the day, this patch was tailored very
strictly against Windows guests, and that probably meant that doing so
had a performance improvement over the way Windows handled pagetables
and process distructions.

Perhaps (I need some time to catch up) the PV-HVM thing has made this
patch affect Linux as well, at the point that this has became a
problem.

Can you tell me in what guest OS this is experiencing a slow down?
What is the order of magnitude of the performance decrease?

I have no problem in reverting that part of the change, if it makes you happy.

Thanks,
Gianluca

-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 14:45, Gianluca Guida <glguida@gmail.com>
wrote:
> On a personal note, thanks for asking me about shadow pagetables,
I''ve
> been missing this kind of fun and it''s a good way to celebrate my
> return to Xen (and Citrix) after exactly two years... :-)
> Stefano imported an old patch of mine, so I am the culprit for this.
So welcome back, Gianluca! And thanks for the fast response.
> On Thu, Nov 10, 2011 at 3:23 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>> in this c/s you did, besides the main purpose of the change, an
>> adjustment to check_for_early_unshadow() in that L2...L4 entries
>> would no longer be attempted to get unshadowed. Neither the
>> patch description nor the added comment really make clear why
>> this was done, and we now got a customer report regarding this
>> causing considerable slowdown in process creation/destruction
>> intensive workloads (e.g. shell scripts).
> 
> Unfortunately, I can''t clearly remember the reason for this. I
assume
> that your mentioning of shell scripts implies that this is running
> under a Linux guest. Back in the day, this patch was tailored very
> strictly against Windows guests, and that probably meant that doing so
> had a performance improvement over the way Windows handled pagetables
> and process distructions.
> 
> Perhaps (I need some time to catch up) the PV-HVM thing has made this
> patch affect Linux as well, at the point that this has became a
> problem.
> 
> Can you tell me in what guest OS this is experiencing a slow down?
It''s SLE11 SP1 guests that suffered a regression after a maintenance
update (originally shipped with 4.0.0, while that patch got backported
later into 4.0.x).
> What is the order of magnitude of the performance decrease?
Factor 7...8 in their measurements.
> I have no problem in reverting that part of the change, if it makes you 
> happy.
It''s not so much about making me feel good, but about understanding
what the reasons for the change were (and hence whether perhaps
some heuristic would better be used to determine whether higher
level page tables are worth getting unshadowed earlier). After all I
also don''t want reverting this to result in a performance regression in
Windows guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 10 Nov 2011, Jan Beulich wrote:
> It''s SLE11 SP1 guests that suffered a regression after a
maintenance
> update (originally shipped with 4.0.0, while that patch got backported
> later into 4.0.x).
Is SLES11 SP1 using HVMOP_pagetable_dying (see
arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Nov 10, 2011 at 6:59 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 10 Nov 2011, Jan Beulich wrote:
>> It''s SLE11 SP1 guests that suffered a regression after a
maintenance
>> update (originally shipped with 4.0.0, while that patch got backported
>> later into 4.0.x).
>
> Is SLES11 SP1 using HVMOP_pagetable_dying (see
> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
Good question. In case it does not, just changing the ">l1" check
to
work only in case we used the hypercall might do the trick.

Gianluca

-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Nov 10, 2011 at 6:53 AM, Jan Beulich <JBeulich@suse.com>
wrote:
> It''s not so much about making me feel good, but about
understanding
> what the reasons for the change were (and hence whether perhaps
> some heuristic would better be used to determine whether higher
> level page tables are worth getting unshadowed earlier). After all I
> also don''t want reverting this to result in a performance
regression in
> Windows guests.
I will try to set up an environment to test the effects on Windows
guest. Unfortunately I forgot the details and lost the notes I took
when developing that patch. Sorry about this.

Gianluca

-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 10 Nov 2011, Jan Beulich wrote:
>> It''s SLE11 SP1 guests that suffered a regression after a
maintenance
>> update (originally shipped with 4.0.0, while that patch got backported
>> later into 4.0.x).
> 
> Is SLES11 SP1 using HVMOP_pagetable_dying (see
> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
No, it''s not.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 16:00, Gianluca Guida <glguida@gmail.com>
wrote:
> On Thu, Nov 10, 2011 at 6:59 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Thu, 10 Nov 2011, Jan Beulich wrote:
>>> It''s SLE11 SP1 guests that suffered a regression after a
maintenance
>>> update (originally shipped with 4.0.0, while that patch got
backported
>>> later into 4.0.x).
>>
>> Is SLES11 SP1 using HVMOP_pagetable_dying (see
>> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
> 
> Good question. In case it does not, just changing the ">l1"
check to
> work only in case we used the hypercall might do the trick.
Possibly, though I would argue that the difference between Linuxes
shouldn''t be that big (i.e. I would rather expect that pv-on-hvm
guests also see a performance penalty here).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 10 Nov 2011, Jan Beulich wrote:
> >>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> wrote:
> > On Thu, 10 Nov 2011, Jan Beulich wrote:
> >> It''s SLE11 SP1 guests that suffered a regression after a
maintenance
> >> update (originally shipped with 4.0.0, while that patch got
backported
> >> later into 4.0.x).
> > 
> > Is SLES11 SP1 using HVMOP_pagetable_dying (see
> > arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
> 
> No, it''s not.
 
well, it should, not to fix this problem but because it is a significant
performance improvement when running on shadow

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 16:16, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 10 Nov 2011, Jan Beulich wrote:
>> >>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>> wrote:
>> > On Thu, 10 Nov 2011, Jan Beulich wrote:
>> >> It''s SLE11 SP1 guests that suffered a regression
after a maintenance
>> >> update (originally shipped with 4.0.0, while that patch got
backported
>> >> later into 4.0.x).
>> > 
>> > Is SLES11 SP1 using HVMOP_pagetable_dying (see
>> > arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
>> 
>> No, it''s not.
>  
> well, it should, not to fix this problem but because it is a significant
> performance improvement when running on shadow
Well - if you have suggestions on how to do this (a) in 2.6.32.x, (b)
without turning on CONFIG_XEN, and (c) without massive patching,
them I''m all for it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 10 Nov 2011, Jan Beulich wrote:
> >>> On 10.11.11 at 16:16, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> wrote:
> > On Thu, 10 Nov 2011, Jan Beulich wrote:
> >> >>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> >> wrote:
> >> > On Thu, 10 Nov 2011, Jan Beulich wrote:
> >> >> It''s SLE11 SP1 guests that suffered a regression
after a maintenance
> >> >> update (originally shipped with 4.0.0, while that patch
got backported
> >> >> later into 4.0.x).
> >> > 
> >> > Is SLES11 SP1 using HVMOP_pagetable_dying (see
> >> > arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
> >> 
> >> No, it''s not.
> >  
> > well, it should, not to fix this problem but because it is a
significant
> > performance improvement when running on shadow
> 
> Well - if you have suggestions on how to do this (a) in 2.6.32.x, (b)
> without turning on CONFIG_XEN, and (c) without massive patching,
> them I''m all for it.
Can you issue hypercalls?
If so, it is just a matter of backporting:

commit 5915100106b8f14a38053ad6c03a664d208aeaa2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Thu Jun 17 14:22:52 2010 +0100

    x86: Call HVMOP_pagetable_dying on exit_mmap.
    
    When a pagetable is about to be destroyed, we notify Xen so that the
    hypervisor can clear the related shadow pagetable.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Nov 10, 2011 at 7:14 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>> On 10.11.11 at 16:00, Gianluca Guida <glguida@gmail.com>
wrote:
>> On Thu, Nov 10, 2011 at 6:59 AM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>> On Thu, 10 Nov 2011, Jan Beulich wrote:
>>>> It''s SLE11 SP1 guests that suffered a regression after
a maintenance
>>>> update (originally shipped with 4.0.0, while that patch got
backported
>>>> later into 4.0.x).
>>>
>>> Is SLES11 SP1 using HVMOP_pagetable_dying (see
>>> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
>>
>> Good question. In case it does not, just changing the
">l1" check to
>> work only in case we used the hypercall might do the trick.
>
> Possibly, though I would argue that the difference between Linuxes
> shouldn''t be that big (i.e. I would rather expect that pv-on-hvm
> guests also see a performance penalty here).
No, because what the patch does is to unshadow the user pagetables
(all levels) as soon as the hypercall is made (when the kernel is
destroying the process). check_for_early_unshadow(), when the
hypercall is used, is for removing the pagetables that maps some
process-specific non-user mappings.

Importing the hypercall is a good idea, but fixing the logic would
help linux guests not using the hypercall.

Gianluca

-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan,

On Thu, Nov 10, 2011 at 7:11 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> wrote:
>> On Thu, 10 Nov 2011, Jan Beulich wrote:
>>> It''s SLE11 SP1 guests that suffered a regression after a
maintenance
>>> update (originally shipped with 4.0.0, while that patch got
backported
>>> later into 4.0.x).
>>
>> Is SLES11 SP1 using HVMOP_pagetable_dying (see
>> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
>
> No, it''s not.
Can you please try the inline patch? Unfortunately I have no unstable
test machine or infrastructure at the moment, so I can;t really test
it.

I finally recalled a bit of details about this patch, so this check is
clearly a bug as-it-is: it was written with the assumption that all
the HVM guests would have been Windows guests with particular
PV-drivers, so I wasn''t particularly nice with the checks.

Thank you,
Gianluca

diff -r 068d3d55ce6e xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c    Tue Nov 01 19:03:38 2011 +0000
+++ b/xen/arch/x86/mm/shadow/multi.c    Thu Nov 10 16:46:50 2011 -0800
@@ -2723,8 +2723,9 @@
            || ( !v->domain->arch.paging.shadow.pagetable_dying_op
                 &&
v->arch.paging.shadow.last_emulated_mfn_for_unshadow == mfn_x(gmfn) )
)
          && sh_mfn_is_a_page_table(gmfn)
-         && !(mfn_to_page(gmfn)->shadow_flags
-              & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64)) )
+         && (!v->domain->arch.paging.shadow.pagetable_dying_op ||
+             !(mfn_to_page(gmfn)->shadow_flags
+               & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64))) )
     {
         perfc_incr(shadow_early_unshadow);
         sh_remove_shadows(v, gmfn, 1, 0 /* Fast, can fail to unshadow */ );

-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 16:22, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 10 Nov 2011, Jan Beulich wrote:
>> >>> On 10.11.11 at 16:16, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>> wrote:
>> > On Thu, 10 Nov 2011, Jan Beulich wrote:
>> >> >>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>> >> wrote:
>> >> > On Thu, 10 Nov 2011, Jan Beulich wrote:
>> >> >> It''s SLE11 SP1 guests that suffered a
regression after a maintenance
>> >> >> update (originally shipped with 4.0.0, while that
patch got backported
>> >> >> later into 4.0.x).
>> >> > 
>> >> > Is SLES11 SP1 using HVMOP_pagetable_dying (see
>> >> > arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
>> >> 
>> >> No, it''s not.
>> >  
>> > well, it should, not to fix this problem but because it is a
significant
>> > performance improvement when running on shadow
>> 
>> Well - if you have suggestions on how to do this (a) in 2.6.32.x, (b)
>> without turning on CONFIG_XEN, and (c) without massive patching,
>> them I''m all for it.
> 
> Can you issue hypercalls?
>From the pv drivers yes, from the rest of the kernel not easily. But
installing a hook from the pv drivers is pointless afaik, since the
paravirt patching would likely have eliminated the call site by that
time.
> If so, it is just a matter of backporting:
> 
> commit 5915100106b8f14a38053ad6c03a664d208aeaa2
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Thu Jun 17 14:22:52 2010 +0100
> 
>     x86: Call HVMOP_pagetable_dying on exit_mmap.
>     
>     When a pagetable is about to be destroyed, we notify Xen so that the
>     hypervisor can clear the related shadow pagetable.
>     
>     Signed-off-by: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>     Signed-off-by: Jeremy Fitzhardinge
<jeremy.fitzhardinge@citrix.com>
Hmm, I should have been saying CONFIG_PARAVIRT_MMU (we have
an extra patch that splits CONFIG_PARATVIRT into sub-pieces) rather
than CONFIG_XEN above - the patch relies on pv_mmu_ops, which our
SP1 non-Xen kernels don''t have enabled (in SP2 we don''t have
the
splitting patch anymore, and we do have CONFIG_PARAVIRT, but as
per the above doing this when the pv drivers load is likely too late).

Which leaves utilizing mmu_notifier_release() as long as
CONFIG_MMU_NOTIFIER is enabled, which fortunately KVM
selects for us.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 16:55, Gianluca Guida <glguida@gmail.com>
wrote:
> Jan,
> 
> On Thu, Nov 10, 2011 at 7:11 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>> wrote:
>>> On Thu, 10 Nov 2011, Jan Beulich wrote:
>>>> It''s SLE11 SP1 guests that suffered a regression after
a maintenance
>>>> update (originally shipped with 4.0.0, while that patch got
backported
>>>> later into 4.0.x).
>>>
>>> Is SLES11 SP1 using HVMOP_pagetable_dying (see
>>> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
>>
>> No, it''s not.
> 
> Can you please try the inline patch? Unfortunately I have no unstable
> test machine or infrastructure at the moment, so I can;t really test
> it.
I''ll have it tested, but on 4.0.x (where the problem was reported and
is reproducible by those who observed it). I''ll let you know as soon as
I know the outcome, but from the debugging we did so far (which
narrowed it to this part of the condition) it is pretty clear that it is
going to do the trick.

Jan
> I finally recalled a bit of details about this patch, so this check is
> clearly a bug as-it-is: it was written with the assumption that all
> the HVM guests would have been Windows guests with particular
> PV-drivers, so I wasn''t particularly nice with the checks.
> 
> Thank you,
> Gianluca
> 
> diff -r 068d3d55ce6e xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c    Tue Nov 01 19:03:38 2011 +0000
> +++ b/xen/arch/x86/mm/shadow/multi.c    Thu Nov 10 16:46:50 2011 -0800
> @@ -2723,8 +2723,9 @@
>             || ( !v->domain->arch.paging.shadow.pagetable_dying_op
>                  &&
> v->arch.paging.shadow.last_emulated_mfn_for_unshadow == mfn_x(gmfn) )
> )
>           && sh_mfn_is_a_page_table(gmfn)
> -         && !(mfn_to_page(gmfn)->shadow_flags
> -              & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64)) )
> +         &&
(!v->domain->arch.paging.shadow.pagetable_dying_op ||
> +             !(mfn_to_page(gmfn)->shadow_flags
> +               & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64))) )
>      {
>          perfc_incr(shadow_early_unshadow);
>          sh_remove_shadows(v, gmfn, 1, 0 /* Fast, can fail to unshadow */
);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 17:10, "Jan Beulich"
<JBeulich@suse.com> wrote:
> Which leaves utilizing mmu_notifier_release() as long as
> CONFIG_MMU_NOTIFIER is enabled, which fortunately KVM
> selects for us.
Of which I didn''t immediately recall that it''s per-mm. Making
it useless
for this purpose too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 10.11.11 at 16:55, Gianluca Guida <glguida@gmail.com>
wrote:
> On Thu, Nov 10, 2011 at 7:11 AM, Jan Beulich <JBeulich@suse.com>
wrote:
>>>>> On 10.11.11 at 15:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>> wrote:
>>> On Thu, 10 Nov 2011, Jan Beulich wrote:
>>>> It''s SLE11 SP1 guests that suffered a regression after
a maintenance
>>>> update (originally shipped with 4.0.0, while that patch got
backported
>>>> later into 4.0.x).
>>>
>>> Is SLES11 SP1 using HVMOP_pagetable_dying (see
>>> arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)?
>>
>> No, it''s not.
> 
> Can you please try the inline patch? Unfortunately I have no unstable
> test machine or infrastructure at the moment, so I can;t really test
> it.
The testing on the customer system (4.0.2 based) went fine, so
please formally submit the patch (indicating the need to backport
to 4.0-testing and 4.1-testing).

Thanks, Jan
> I finally recalled a bit of details about this patch, so this check is
> clearly a bug as-it-is: it was written with the assumption that all
> the HVM guests would have been Windows guests with particular
> PV-drivers, so I wasn''t particularly nice with the checks.
> 
> Thank you,
> Gianluca
> 
> diff -r 068d3d55ce6e xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c    Tue Nov 01 19:03:38 2011 +0000
> +++ b/xen/arch/x86/mm/shadow/multi.c    Thu Nov 10 16:46:50 2011 -0800
> @@ -2723,8 +2723,9 @@
>             || ( !v->domain->arch.paging.shadow.pagetable_dying_op
>                  &&
> v->arch.paging.shadow.last_emulated_mfn_for_unshadow == mfn_x(gmfn) )
> )
>           && sh_mfn_is_a_page_table(gmfn)
> -         && !(mfn_to_page(gmfn)->shadow_flags
> -              & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64)) )
> +         &&
(!v->domain->arch.paging.shadow.pagetable_dying_op ||
> +             !(mfn_to_page(gmfn)->shadow_flags
> +               & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64))) )
>      {
>          perfc_incr(shadow_early_unshadow);
>          sh_remove_shadows(v, gmfn, 1, 0 /* Fast, can fail to unshadow */
);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel