[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Next gen kvm api
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [RFC] Next gen kvm api |
Date: |
Sat, 18 Feb 2012 11:49:27 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 |
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.
- Re: [Qemu-devel] [RFC] Next gen kvm api, (continued)
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Scott Wood, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Scott Wood, 2012/02/17
- Re: [Qemu-devel] [RFC] Next gen kvm api,
Avi Kivity <=
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/18
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/18
- Re: [Qemu-devel] [RFC] Next gen kvm api, Scott Wood, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Takuya Yoshikawa, 2012/02/12
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Anthony Liguori, 2012/02/07
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/07
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alan Cox, 2012/02/08
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15