[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [qemu-s390x] [PATCH 1/6] accel/tcg: add size paremeter in
Re: [Qemu-arm] [qemu-s390x] [PATCH 1/6] accel/tcg: add size paremeter in tlb_fill()
Wed, 10 Jan 2018 10:47:28 -0800
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
On 01/10/2018 05:42 AM, Laurent Vivier wrote:
> Le 10/01/2018 à 09:43, David Hildenbrand a écrit :
>> On 09.01.2018 00:10, Laurent Vivier wrote:
>>> The MC68040 MMU provides the size of the access that
>>> triggers the page fault.
>>> This size is set in the Special Status Word which
>>> is written in the stack frame of the access fault
>>> So we need the size in m68k_cpu_unassigned_access() and
>>> To be able to do that, this patch modifies the prototype of
>>> handle_mmu_fault handler, tlb_fill() and probe_write().
>>> do_unassigned_access() already includes a size parameter.
>>> This patch also updates handle_mmu_fault handlers and
>>> tlb_fill() of all targets (only parameter, no code change).
>> There are a couple of places where you use "1" (when no other size is
>> available). e.g. in get_page_addr_code().
>> Wonder if that's the right thing to do - are there any architectures
>> that e.g. always fetch at least 2 bytes in these conditions?
> It's a good question.
> "1" is passed to probe_write() and tlb_fill() and handle_mmu_fault().
> probe_write() calls tlb_fill(), and tlb_fill() calls machine
> handle_mmu_fault handler.
> As no existing handle_mmu_fault takes care of the access size, I think
> passing 1 and ignoring it doesn't change the existing behavior.
> probe_write() is used to check if a page is writable, and none of the
> callers is guessing the write can cross a page boundary, so 1 is the
> good value in this case.
> get_page_addr_code() is the only user of tlb_fill() with 1. and callers
> of get_page_addr_code() never guess the code address can run across a
> page boundary. Some of them calls get_page_addr_code() a second time to
> check this case. So I think using 1 is good solution, but perhaps the
> code could be improved by adding the size parameter to get_page_addr_code().
> My purpose was not to change the functions behavior, only to add the new
> parameter. So using "1" when the size is not obvious is a good solution
> to me.
I guess I don't really have a problem with "1".
I do wonder if "0" might be a better value for "I don't know", because it is
not mistakable with a real access of 1 byte.