All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Emilio G. Cota" <cota@braap.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Stephen Checkoway <stephen.checkoway@oberlin.edu>,
	Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] x86 segment limits enforcement with TCG
Date: Wed, 6 Mar 2019 20:49:22 -0500	[thread overview]
Message-ID: <20190307014922.GA15870@flamenco> (raw)
In-Reply-To: <a244b0af-9b69-3760-0663-dbf9a0315789@linaro.org>

On Thu, Feb 28, 2019 at 10:05:02 -0800, Richard Henderson wrote:
> On 2/28/19 9:18 AM, Stephen Checkoway wrote:
> > I wonder if it would make sense to maintain a small cache of TLBs. The
> > majority of cases are likely to involving setting segment registers to one
> > of a handful of segments (e.g., setting es to ds or ss). So it might be nice
> > to avoid the flushes entirely.
> Hmm.
> 
> The straight-forward approach to this would change the mapping between segment
> and mmu index, which would need to force a new translation (since mmu indexes
> are built into the generated code as constants).  It would be easy for this
> scheme to generate too many translations and slow down the system as a whole.
> 
> However, since the change to dynamic tlbs, the actual tlb is now a pointer.  So
> it might not be out of the question to simply swap TLB contents around when
> changing segment registers.  All you would need is N+1 tlbs to support the
> (easy?) case of es swapping.
> 
> With some additional work in cputlb, it might even be possible to have
> different mmu indexes share the same backing tlb.  This would be tricky to
> manage during a tlb resize, but perhaps not impossible.
> 
> Emilio, do you have any thoughts here?

I like the approach you propose. If I understood correctly, we could:

- Let target code manipulate the pointer in TLB[mmu_idx]. This way the
  target can keep for each idx a set of tables, indexed by segment register
  value. The target would detect changes to segment registers and
  update the pointer in TLB[mmu_idx].

- Add a hook from cputlb to target-specific code, so that the latter
  is notified of flushes and can therefore flush the set of tables.
  Note that resizes only occur during flushes, which makes things
  simpler.

Seems like a reasonable amount of work and won't affect much the
common path (i.e. no segmentation) -- at worst it will add the overhead
of using helpers for a small number of instructions.

Thanks,

		Emilio

      reply	other threads:[~2019-03-07  1:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-24 19:36 [Qemu-devel] x86 segment limits enforcement with TCG Stephen Checkoway
2019-02-24 19:46 ` Peter Maydell
2019-02-24 20:21   ` Stephen Checkoway
2019-02-26  0:32     ` Stephen Checkoway
2019-02-26 16:56       ` Richard Henderson
2019-02-28 15:01         ` Stephen Checkoway
2019-02-28 16:11           ` Richard Henderson
2019-02-28 17:18             ` Stephen Checkoway
2019-02-28 18:05               ` Richard Henderson
2019-03-07  1:49                 ` Emilio G. Cota [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190307014922.GA15870@flamenco \
    --to=cota@braap.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stephen.checkoway@oberlin.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.