From: Fabien Chouteau <chouteau@adacore.com>
To: Alexander Graf <agraf@suse.de>
Cc: Scott Wood <scottwood@freescale.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op
Date: Fri, 01 Jul 2011 17:39:49 +0200 [thread overview]
Message-ID: <4E0DEA45.1020607@adacore.com> (raw)
In-Reply-To: <E933A339-E1B2-4036-B903-A56C0DC9A9CC@suse.de>
On 01/07/2011 17:05, Alexander Graf wrote:
>
> On 01.07.2011, at 16:59, Fabien Chouteau wrote:
>
>> On 01/07/2011 00:38, Alexander Graf wrote:
>>>
>>> On 01.07.2011, at 00:32, Scott Wood wrote:
>>>
>>>> On Fri, 1 Jul 2011 00:28:19 +0200
>>>> Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>>
>>>>> On 01.07.2011, at 00:23, Scott Wood wrote:
>>>>>
>>>>>> On Fri, 1 Jul 2011 00:18:22 +0200
>>>>>> Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>>>
>>>>>>> On 01.07.2011, at 00:11, Scott Wood wrote:
>>>>>>>
>>>>>>>> Almost, but what if we have write permission but not read?
>>>>>>>
>>>>>>> How would you write back data from a cache line when you haven't read it earlier?
>>>>>>
>>>>>> The CPU can read it. The program can't.
>>>>>
>>>>> Hrm. We can always just call the check manually and trigger the respective interrupt :).
>>>>
>>>> Yep. A little trickier, but doable.
>>>>
>>>>>>>> but what about a race with DMA from the I/O thread?
>>>>>>>
>>>>>>> That'd simply be broken, but I don't quite see how it wouldn't with real hardware either :).
>>>>>>
>>>>>> Real hardware doesn't generate a load/store sequence that the program didn't
>>>>>> ask for -- where's the breakage?
>>>>>
>>>>> Real hardware flushes whatever contents are in that cache line to RAM, no? So it would collide with the DMA just as much. Or am I missing something?
>>>>
>>>> If the DMA happens after the cache line is fetched, it'll be flushed,
>>>> whether locked or not. But that's different from losing some of what the
>>>> device wrote.
>>>
>>> Ah, so DMA flushes even locked cache lines? Then it makes sense. Well, I guess the best choice here really is to merely do a manual storage protection check and be done with it.
>>>
>>
>> Well, this is far beyond the scope of my knowledge of e500 and the current
>> patch is sufficient for me, so I will let you implement this if you want to...
>
> Well, all it needs is to call mmubooke206_get_physical_address on the address (or each page of the destination) with access_type set to write and check for the result. If it's protected, inject a DSI (see cpu_ppc_handle_mmu_fault).
>
> But yeah, I can try and see if I get around to implementing it. No promises though. Do you have a test case I can verify this against?
No, I just implemented these no-oped instructions to get rid of an illegal
instruction exception while running u-boot on my emulated p2010.
--
Fabien Chouteau
next prev parent reply other threads:[~2011-07-01 15:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-27 13:15 [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op Fabien Chouteau
2011-06-27 16:28 ` Scott Wood
2011-06-28 8:17 ` Fabien Chouteau
2011-06-28 16:20 ` Scott Wood
2011-06-30 8:25 ` Fabien Chouteau
2011-06-30 16:17 ` Scott Wood
2011-06-30 21:34 ` Alexander Graf
2011-06-30 21:46 ` Scott Wood
2011-06-30 21:56 ` Alexander Graf
2011-06-30 22:11 ` Scott Wood
2011-06-30 22:18 ` Alexander Graf
2011-06-30 22:23 ` Scott Wood
2011-06-30 22:28 ` Alexander Graf
2011-06-30 22:32 ` Scott Wood
2011-06-30 22:38 ` Alexander Graf
2011-07-01 14:59 ` Fabien Chouteau
2011-07-01 15:05 ` Alexander Graf
2011-07-01 15:39 ` Fabien Chouteau [this message]
2011-07-01 16:00 ` Scott Wood
2011-07-01 16:21 ` Fabien Chouteau
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=4E0DEA45.1020607@adacore.com \
--to=chouteau@adacore.com \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=scottwood@freescale.com \
/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.