Re: [Xen-devel] Re: [PATCH] EPT: Only sync pcpus on which a domain's vcpus might be running

[George Dunlap <dunlapg@xxxxxxxxx>]

Just making sure I understand the failure mode... the risk is that if
we change the p2m for this domain while a vcpu is not running on that
core, and it's scheduled there again, it may have stale mappings that
get used (tagged by the EPT base pointer).

Hmm... any idea the performance implications of flushing the EPT
mappings when switching out?  The main performance problem I need to
fix is the ballooning case.  Without this patch, on my 2x4x2 Nehalem
box, a single-vcpu guest ballooning from 16GiB down to 8GiB for an
initial boot takes 12-15 minutes; with the patch, it takes around 40
seconds.

Perhaps we could start with the flush-ept-on-context-switch-out, and
do some performance testing later to see if it's worth maintaining a
"might-need-an-ept-flush" mask.

 -George

On Fri, Sep 18, 2009 at 8:43 AM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> This is definitely not safe. See ARM Vol 3B Section 24.3.3. EPTP-tagged
> cached mappings (that is, partial mappings from guest-phys to host-phys
> addresses, tagged by the EPT base pointer value) only need be flushed when a
> suitable INVEPT instruction is executed. So a HVM VCPU can leave EPTP-tagged
> droppings lying around in other TLBs as it migrates from CPU to CPU -- the
> domain_dirty_cpumask does not track this!
>
> The way to fix this is to' if ( hap_enabled ) __invept(1,
> d->arch.hvm_domain.vmx.ept_control.eptp, 0)' in vmx_ctxt_switch_from(). That
> then makes your patch correct.
>
> Care to test this and spin another patch?
>
>  -- Keir
>
> On 17/09/2009 18:51, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:
>
>> ept_sync_domain() is called whenever the p2m changes.  The current
>> code calls sync on all cpus; this is extremely wasteful, especially
>> for a single-vcpu VM on a 16-way (2x4x2) box.
>>
>> This patch will only call sync on cpus where there may be dirty cpu
>> state.  I've done a basic test, but I'd appreciate someone from Intel
>> verifying that there shouldn't be any problems.
>>
>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

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