| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] EPT: Flush running cpus, add mask to flush
|
To: |
Jan Beulich <JBeulich@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: [PATCH] EPT: Flush running cpus, add mask to flush when scheduled in |
|
From: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
|
Date: |
Tue, 22 Sep 2009 09:33:25 +0100 |
|
Cc: |
Xiaohui Xin <Xiaohui.xin@xxxxxxxxx>, Xin Li <xin.b.li@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Delivery-date: |
Tue, 22 Sep 2009 01:33:55 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4AB8A5B802000078000162E2@xxxxxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
Aco7XgcFmkC5jLNwRYG6jqnnp9bgbAAAVLl2 |
|
Thread-topic: |
[Xen-devel] Re: [PATCH] EPT: Flush running cpus, add mask to flush when scheduled in |
|
User-agent: |
Microsoft-Entourage/12.20.0.090605 |
On 22/09/2009 09:23, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> I don't see how that is possible, as domain_dirty_cpumask can have changed
>> arbitrarily since the previous invocation of ept_sync_domain(), as can the
>> EPT tables. We have to assume every CPU has potentially stale cached
>> mappings.
>
> Why? It ought to be possible to know which CPUs the guest has run on
> for any period of time. Any CPU it hasn't run on wouldn't need flushing,
> would it?
Probably not, as long as VMCLEAR is sufficient to stop a particular EPTP's
entries being cached? We'd need to maintain an extra cpumask to track this
however, and it's not clear it's worth it. This is really just about
optimising large numbers of almost back-to-back invocations of
ept_sync_domain(), where the # flushes of not-currently-active cpus will
probably collapse to 1 with the current logic in the patch. The time between
batches of calls should be large enough that the extra flushes caused by not
tracking VCPU movements between the batches really shouldn't matter very
much.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home