qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: "<qemu-ppc@nongnu.org>" <qemu-ppc@nongnu.org>,
	"qemu-devel Developers" <qemu-devel@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH] PPC: booke206: Check for min/max TLB entry size
Date: Mon, 23 Jan 2012 11:28:30 -0600	[thread overview]
Message-ID: <4F1D98BE.2000308@freescale.com> (raw)
In-Reply-To: <4DD03C47-706E-451F-88E4-52CF12778C5A@suse.de>

On 01/20/2012 08:43 PM, Alexander Graf wrote:
> 
> 
> Am 20.01.2012 um 21:01 schrieb Scott Wood <scottwood@freescale.com>:
>> I'm not sure what happens when you write
>> an entry to TLB1 with an invalid TSIZE.
> 
> What it says, the ISA means it's implementation dependent. What e500mc actually implements is an different question. Which still needs to be answered.

AFAIK it's not documented what e500mc does for invalid sizes in TLB1, so
I think anything that complies with the architecture's statement of any
supported size is OK.

> However for now I think wde 're ok by not modeling every odd corner case.

Sure.  I was just curious about the architectural statement.

>>> +    /* XXX only applies for MAV 1.0 */
>>> +    size_tlb = (tlb->mas1 & MAS1_TSIZE_MASK) >> (MAS1_TSIZE_SHIFT + 1);
>>> +    size_min = (tlbncfg & TLBnCFG_MINSIZE) >> TLBnCFG_MINSIZE_SHIFT;
>>> +    size_max = (tlbncfg & TLBnCFG_MAXSIZE) >> TLBnCFG_MAXSIZE_SHIFT;
>>> +    if ((size_tlb > size_max) || (size_tlb < size_min)) {
>>> +        /* set to min size */
>>> +        tlb->mas1 &= ~MAS1_TSIZE_MASK;
>>> +        tlb->mas1 |= size_min << (MAS1_TSIZE_SHIFT + 1);
>>> +    }
>>
>> You could just implement a bitmap now, which will work for MAV 2.0 as well.
>>
>> Especially since we're using the MAV 2.0 definition of tsize already, so
>> min/max isn't an accurate way to describe what we support.
> 
> Not sure I follow. In MAV 1.0 the size constraints are defined in TLBnCFG, while for MAV 2.0 they are defned in their own bitmap registers (TLBnPS)
> 
> Would you like to have a function called that returns a bitmap of
> supported sizes for the TLB depending on its MAV value based on
> either TLBnCFG or TLBnPS? We could then check if that size value bit
> is set.

Yes, use a bitmap internally regardless of how the programming model
says we convey the information to the target code.

-Scott

  reply	other threads:[~2012-01-23 17:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-20  3:17 [Qemu-devel] [PATCH 0/6] Make -cpu e500mc useful in TCG Alexander Graf
2012-01-20  3:17 ` [Qemu-devel] [PATCH 1/6] PPC: Add IVOR 38-42 Alexander Graf
2012-01-20  7:54   ` Andreas Färber
2012-01-20  3:17 ` [Qemu-devel] [PATCH 2/6] PPC: e500mc: add missing IVORs to bitmap Alexander Graf
2012-01-20 19:16   ` Scott Wood
2012-01-21  4:05     ` Alexander Graf
2012-01-20  3:17 ` [Qemu-devel] [PATCH 3/6] PPC: e500: msync is 440 only, e500 has real sync Alexander Graf
2012-01-20 19:39   ` Scott Wood
2012-01-20  3:17 ` [Qemu-devel] [PATCH 4/6] PPC: booke206: allow NULL raddr in ppcmas_tlb_check Alexander Graf
2012-01-20  3:17 ` [Qemu-devel] [PATCH 5/6] PPC: booke206: Check for min/max TLB entry size Alexander Graf
2012-01-20  8:09   ` Paolo Bonzini
2012-01-20  8:09   ` Andreas Färber
2012-01-20 13:21     ` [Qemu-devel] [PATCH] " Alexander Graf
2012-01-20 20:01       ` Scott Wood
2012-01-21  2:43         ` Alexander Graf
2012-01-23 17:28           ` Scott Wood [this message]
2012-01-23 17:30             ` Alexander Graf
2012-01-20  3:17 ` [Qemu-devel] [PATCH 6/6] PPC: booke206: Implement tlbilx Alexander Graf
2012-01-20 20:40   ` Scott Wood
2012-01-21  2:57     ` Alexander Graf

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=4F1D98BE.2000308@freescale.com \
    --to=scottwood@freescale.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).