On 2012-05-23 23:00, Jan Kiszka wrote: > On 2012-05-23 22:29, TeLeMan wrote: >> On Thu, May 24, 2012 at 1:36 AM, Jan Kiszka <jan.kis...@siemens.com> wrote: >>> On 2012-05-23 13:02, Jan Kiszka wrote: >>>> On 2012-05-23 11:11, TeLeMan wrote: >>>>> On Wed, May 23, 2012 at 7:22 PM, Jan Kiszka <jan.kis...@siemens.com> >>>>> wrote: >>>>>> On 2012-05-23 04:09, TeLeMan wrote: >>>>>>> On Wed, May 23, 2012 at 11:41 AM, Andreas Färber <afaer...@suse.de> >>>>>>> wrote: >>>>>>>> Am 18.05.2012 11:49, schrieb TeLeMan: >>>>>>>>> This breakage was introduced by the commit "memory: make >>>>>>>>> phys_page_find() return an unadjusted". >>>>>>>> >>>>>>>> You seem to have found the origin of your problem. If you also mention >>>>>>>> the commit hash in your commit message then certain frontends (gitk, >>>>>>>> repo.or.cz) will display it as a handy hyperlink to that commit. >>>>>>>> >>>>>>>>> >>>>>>>>> Signed-off-by: TeLeMan <gele...@gmail.com> >>>>>>>> >>>>>>>> Signed-off-by is a legal statement of origin and must not be a >>>>>>>> pseudonym. >>>>>>> Ok, please ignore this patch. I won't submit any patch just report bugs. >>>>>> >>>>>> Then please describe this bug in more details, e.g. how to reproduce. >>>>> I think its evident. cpu_get_phys_page_debug(env, pc) is not the >>>>> physical address of pc but the physical page base address of pc. >>>> >>>> ...so this bites us if the instruction spans two pages as >>>> tb_invalidate_phys_addr requests invalidation on a page granularity. >>> >>> In fact, this is irrelevant. We only need to flush the address at which >>> the instruction starts, and that is achieved by flushing all TB that >>> relate to that page as the current code does. >> >> But the instruction start is wrong and its TB may not be found. For example, >> the pc is 0x1234 and its physical address is 0x1234. The correct >> "start" and "end" of tb_invalidate_phys_page_range() is 0x1234 and >> 0x1235. But now the "start" and "end" is 0x1000 and 0x1001. >> If 0x1000 is not translated yet, the real TB won't be invalidated. > > The tb containing 0x1234 would be linked to the list of TBs that are > related to the 0x1000 page. As we declare that page invalid, all > affected TBs are dropped, not just the one containing the breakpoint. > See tb_invalidate_phys_page_range.
Oops, too fast: in fact the introductory comment of tb_invalidate_phys_page_range is misleading, there is a sub-page-level range check. And now my test also actually triggers. Was probably running the wrong qemu version before. Jan
signature.asc
Description: OpenPGP digital signature
