Skip to content
Snippets Groups Projects
  1. Jan 20, 2024
    • Paolo Bonzini's avatar
      target/i386: pcrel: store low bits of physical address in data[0] · c46f68bd
      Paolo Bonzini authored
      For PC-relative translation blocks, env->eip changes during the
      execution of a translation block, Therefore, QEMU must be able to
      recover an instruction's PC just from the TranslationBlock struct and
      the instruction data with.  Because a TB will not span two pages, QEMU
      stores all the low bits of EIP in the instruction data and replaces them
      in x86_restore_state_to_opc.  Bits 12 and higher (which may vary between
      executions of a PCREL TB, since these only use the physical address in
      the hash key) are kept unmodified from env->eip.  The assumption is that
      these bits of EIP, unlike bits 0-11, will not change as the translation
      block executes.
      
      Unfortunately, this is incorrect when the CS base is not aligned to a page.
      Then the linear address of the instructions (i.e. the one with the
      CS base addred) indeed will never span two pages, but bits 12+ of EIP
      can actually change.  For example, if CS base is 0x80262200 and EIP =
      0x6FF4, the first instruction in the translation block will be at linear
      address 0x802691F4.  Even a very small TB will cross to EIP = 0x7xxx,
      while the linear addresses will remain comfortably within a single page.
      
      The fix is simply to use the low bits of the linear address for data[0],
      since those don't change.  Then x86_restore_state_to_opc uses tb->cs_base
      to compute a temporary linear address (referring to some unknown
      instruction in the TB, but with the correct values of bits 12 and higher);
      the low bits are replaced with data[0], and EIP is obtained by subtracting
      again the CS base.
      
      Huge thanks to Mark Cave-Ayland for the image and initial debugging,
      and to Gitlab user @kjliew for help with bisecting another occurrence
      of (hopefully!) the same bug.
      
      It should be relatively easy to write a testcase that performs MMIO on
      an EIP with different bits 12+ than the first instruction of the translation
      block; any help is welcome.
      
      Fixes: e3a79e0e ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11)
      Cc: qemu-stable@nongnu.org
      Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
      Cc: Richard Henderson <richard.henderson@linaro.org>
      Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759
      Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964
      Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012
      
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      (cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      c46f68bd
    • guoguangyao's avatar
      target/i386: fix incorrect EIP in PC-relative translation blocks · 652c34cb
      guoguangyao authored
      
      The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case.
      Using s->pc in func gen_update_eip_next() solves the problem.
      
      Cc: qemu-stable@nongnu.org
      Fixes: b5e0d5d2 ("target/i386: Fix 32-bit wrapping of pc/eip computation")
      Signed-off-by: default avatarguoguangyao <guoguangyao18@mails.ucas.ac.cn>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      (cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      652c34cb
    • Richard Henderson's avatar
      target/i386: Do not re-compute new pc with CF_PCREL · 6e8e580e
      Richard Henderson authored
      
      With PCREL, we have a page-relative view of EIP, and an
      approximation of PC = EIP+CSBASE that is good enough to
      detect page crossings.  If we try to recompute PC after
      masking EIP, we will mess up that approximation and write
      a corrupt value to EIP.
      
      We already handled masking properly for PCREL, so the
      fix in b5e0d5d2 was only needed for the !PCREL path.
      
      Cc: qemu-stable@nongnu.org
      Fixes: b5e0d5d2 ("target/i386: Fix 32-bit wrapping of pc/eip computation")
      Reported-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      (cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      6e8e580e
  2. Jan 19, 2024
  3. Jan 17, 2024
  4. Jan 13, 2024
  5. Jan 12, 2024
  6. Jan 11, 2024
  7. Jan 08, 2024
  8. Jan 05, 2024
  9. Dec 26, 2023
  10. Dec 22, 2023
    • Kevin Wolf's avatar
      iotests: Basic tests for internal snapshots · 11b0730d
      Kevin Wolf authored
      
      We have a few test cases that include tests for corner case aspects of
      internal snapshots, but nothing that tests that they actually function
      as snapshots or that involves deleting a snapshot. Add a test for this
      kind of basic internal snapshot functionality.
      
      The error cases include a regression test for the crash we just fixed
      with snapshot operations on inactive images.
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-ID: <20231201142520.32255-4-kwolf@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      (cherry picked from commit bb6e2511eb48539b7dcbcb5f47772e156b9c45d1)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      11b0730d
Loading