WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] domain_page tlb flushing problem?

To: <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] domain_page tlb flushing problem?
From: "Michael A Fetterman" <Michael.Fetterman@xxxxxxxxxxxx>
Date: Fri, 15 Oct 2004 19:03:47 +0100
Delivery-date: Sat, 16 Oct 2004 05:52:41 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcSy4VE5HftRhPfJTomlryzMr4RZxg==
I think I've noticed a tlb flushing bug in xen's domain_page.c stuff.
Most of this code was based on the Linux PKMAP code (as noted in the
comment at the top of domain_page.c), but that code does not have
the following tlb flushing bug.

The bug is basically that flush_all_ready_maps() doesn't cause all
processors to flush their tlb's.  Or at least, I can't see anything
that would cause them to.

Here's the problem:
flush_all_ready_maps() can cause a map cache entry to get zero'ed
(i.e. permissions to that virtual address are reduced/removed),
but it only ever notifies the local processor's TLB.  However,
all the processors share the map cache, and so there's no guarantee
that a reduction in privilege in the page tables will be observed
by any other processor (since their TLBs are explicitly flushed).

map_domain_mem() tries to protect itself against this somewhat
by trying to detect if the shadow_map_idx[processor_id()] is greater
than the current map_idx (i.e. some other processor caused map_idx
to wrap around), but that's not sufficient.  Another processor may
have caused over 1024 map_domain_mem() calls quite easily (validating
a bunch of new PTEs, for example).

Theoretically, a processor shouldn't have touched any memory in the
map cache area "above" its current shadow_map_idx, and so ideally,
this test in map_domain_mem() might be thought to be sufficient, but
it isn't.  Processors (starting with the P6, and certainly true with
P4) can create arbitrary speculative accesses to any cachable memory,
and cause TLB loads for such speculative addresses.  So arguing about
whatever
memory is actually touched by the code path executed by a processor
isn't sufficient.  It's all about what might have been speculatively
touched.

I am quite new to the Xen source base, and if I'm missed something
fundamental, I'd be most appreciative if someone could help point me
in the right direction.  But so far, this just looks busted to me.

Comments?

Michael Fetterman



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>