On 02/16/2012 10:41 PM, Scott Wood wrote: > >>> Sharing the data structures is not need. Simply synchronize them before > >>> lookup, like we do for ordinary registers. > >> > >> Ordinary registers are a few bytes. We're talking of dozens of kbytes here. > > > > A TLB way is a few dozen bytes, no? > > I think you mean a TLB set... Yes, thanks. > but the TLB (or part of it) may be fully > associative. A fully associative TLB has to be very small. > On e500mc, it's 24 bytes for one TLB entry, and you'd need 4 entries for > a set of TLB0, and all 64 entries in TLB1. So 1632 bytes total. Syncing this every time you need a translation (for gdb or the monitor) is trivial in terms of performance. > Then we'd need to deal with tracking whether we synchronized one or more > specific sets, or everything (for migration or debug TLB dump). The > request to synchronize would have to come from within the QEMU MMU code, > since that's the point where we know what to ask for (unless we > duplicate the logic elsewhere). I'm not sure that reusing the standard > QEMU MMU code for individual debug address translation is really > simplifying things... > > And yes, we do have fancier hardware coming fairly soon for which this > breaks (TLB0 entries can be loaded without host involvement, as long as > there's a translation from guest physical to physical in a separate > hardware table). It'd be reasonable to ignore TLB0 for migration (treat > it as invalidated), but not for debug since that may be where the > translation we're interested in resides. > So with this new hardware, the always-sync API breaks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
