lkml.org 
[lkml]   [2012]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Qemu-devel] [RFC] Next gen kvm api
    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.



    \
     
     \ /
      Last update: 2012-02-18 10:53    [W:3.868 / U:0.548 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site