Skip to content
Snippets Groups Projects
  1. May 25, 2022
    • Lev Kujawski's avatar
      ide_ioport_read: Return lower octet of data register instead of 0xFF · 758c925e
      Lev Kujawski authored
      
      Prior to this patch, the pre-GRUB Solaris x86 bootloader would fail to
      load on QEMU with the following screen output:
      
      SunOS Secondary Boot version 3.00
      
      prom_panic: Could not mount filesystem.
      Entering boot debugger:
      [136419]: _
      
      This occurs because the bootloader issues an ATA IDENTIFY DEVICE
      command, and then reads the resulting 256 words of parameter
      information using inb rather than the correct inw. As the previous
      behavior of QEMU was to return 0xFF and not advance the drive's sector
      buffer, DRQ would never be cleared and the bootloader would be blocked
      from selecting a secondary ATA device, such as an optical drive.
      
      Resolves:
      * [Bug 1639394] Unable to boot Solaris 8/9 x86 under Fedora 24
      
      Signed-off-by: default avatarLev Kujawski <lkujaw@member.fsf.org>
      Message-Id: <20220520235200.1138450-1-lkujaw@member.fsf.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      758c925e
  2. Mar 08, 2022
  3. Mar 07, 2022
    • Peter Maydell's avatar
      osdep: Move memalign-related functions to their own header · 5df022cf
      Peter Maydell authored
      
      Move the various memalign-related functions out of osdep.h and into
      their own header, which we include only where they are used.
      While we're doing this, add some brief documentation comments.
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-id: 20220226180723.1706285-10-peter.maydell@linaro.org
      5df022cf
    • Hanna Reitz's avatar
      ide: Increment BB in-flight counter for TRIM BH · 7e5cdb34
      Hanna Reitz authored
      When we still have an AIOCB registered for DMA operations, we try to
      settle the respective operation by draining the BlockBackend associated
      with the IDE device.
      
      However, this assumes that every DMA operation is associated with an
      increment of the BlockBackend’s in-flight counter (e.g. through some
      ongoing I/O operation), so that draining the BB until its in-flight
      counter reaches 0 will settle all DMA operations.  That is not the case:
      For TRIM, the guest can issue a zero-length operation that will not
      result in any I/O operation forwarded to the BlockBackend, and also not
      increment the in-flight counter in any other way.  In such a case,
      blk_drain() will be a no-op if no other operations are in flight.
      
      It is clear that if blk_drain() is a no-op, the value of
      s->bus->dma->aiocb will not change between checking it in the `if`
      condition and asserting that it is NULL after blk_drain().
      
      The particular problem is that ide_issue_trim() creates a BH
      (ide_trim_bh_cb()) to settle the TRIM request: iocb->common.cb() is
      ide_dma_cb(), which will either create a new request, or find the
      transfer to be done and call ide_set_inactive(), which clears
      s->bus->dma->aiocb.  Therefore, the blk_drain() must wait for
      ide_trim_bh_cb() to run, which currently it will not always do.
      
      To fix this issue, we increment the BlockBackend's in-flight counter
      when the TRIM operation begins (in ide_issue_trim(), when the
      ide_trim_bh_cb() BH is created) and decrement it when ide_trim_bh_cb()
      is done.
      
      Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2029980
      
      
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarHanna Reitz <hreitz@redhat.com>
      Message-Id: <20220120142259.120189-1-hreitz@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarJohn Snow <jsnow@redhat.com>
      Tested-by: default avatarJohn Snow <jsnow@redhat.com>
      7e5cdb34
  4. Feb 21, 2022
  5. Jan 18, 2022
  6. Dec 31, 2021
  7. Dec 30, 2021
  8. Nov 02, 2021
    • Samuel Thibault's avatar
      ide: Cap LBA28 capacity announcement to 2^28-1 · 46e018e9
      Samuel Thibault authored
      
      The LBA28 capacity (at offsets 60/61 of identification) is supposed to
      express the maximum size supported by LBA28 commands. If the device is
      larger than this, we have to cap it to 2^28-1.
      
      At least NetBSD happens to be using this value to determine whether to use
      LBA28 or LBA48 for its commands, using LBA28 for sectors that don't need
      LBA48. This commit thus fixes NetBSD access to disks larger than 128GiB.
      
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Message-Id: <20210824104344.3878849-1-samuel.thibault@ens-lyon.org>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      46e018e9
  9. Oct 17, 2021
  10. Sep 30, 2021
  11. Jul 20, 2021
  12. Jul 19, 2021
  13. Jun 02, 2021
  14. May 02, 2021
  15. Mar 18, 2021
  16. Mar 09, 2021
  17. Feb 15, 2021
  18. Jan 27, 2021
    • Kevin Wolf's avatar
      block: Separate blk_is_writable() and blk_supports_write_perm() · 86b1cf32
      Kevin Wolf authored
      Currently, blk_is_read_only() tells whether a given BlockBackend can
      only be used in read-only mode because its root node is read-only. Some
      callers actually try to answer a slightly different question: Is the
      BlockBackend configured to be writable, by taking write permissions on
      the root node?
      
      This can differ, for example, for CD-ROM devices which don't take write
      permissions, but may be backed by a writable image file. scsi-cd allows
      write requests to the drive if blk_is_read_only() returns false.
      However, the write request will immediately run into an assertion
      failure because the write permission is missing.
      
      This patch introduces separate functions for both questions.
      blk_supports_write_perm() answers the question whether the block
      node/image file can support writable devices, whereas blk_is_writable()
      tells whether the BlockBackend is currently configured to be writable.
      
      All calls of blk_is_read_only() are converted to one of the two new
      functions.
      
      Fixes: https://bugs.launchpad.net/bugs/1906693
      
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-Id: <20210118123448.307825-2-kwolf@redhat.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      86b1cf32
  19. Jan 23, 2021
  20. Jan 18, 2021
  21. Jan 08, 2021
  22. Dec 18, 2020
  23. Dec 01, 2020
    • Paolo Bonzini's avatar
      ide: atapi: assert that the buffer pointer is in range · 81321228
      Paolo Bonzini authored
      
      A case was reported where s->io_buffer_index can be out of range.
      The report skimped on the details but it seems to be triggered
      by s->lba == -1 on the READ/READ CD paths (e.g. by sending an
      ATAPI command with LBA = 0xFFFFFFFF).  For now paper over it
      with assertions.  The first one ensures that there is no overflow
      when incrementing s->io_buffer_index, the second checks for the
      buffer overrun.
      
      Note that the buffer overrun is only a read, so I am not sure
      if the assertion failure is actually less harmful than the overrun.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 20201201120926.56559-1-pbonzini@redhat.com
      Reviewed-by: default avatarKevin Wolf <kwolf@redhat.com>
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      81321228
  24. Nov 15, 2020
  25. Nov 02, 2020
    • Anthony PERARD's avatar
      xen: rework pci_piix3_xen_ide_unplug · 045b1d4d
      Anthony PERARD authored
      
      This is to allow IDE disks to be unplugged when adding to QEMU via:
          -drive file=/root/disk_file,if=none,id=ide-disk0,format=raw
          -device ide-hd,drive=ide-disk0,bus=ide.0,unit=0
      
      as the current code only works for disk added with:
          -drive file=/root/disk_file,if=ide,index=0,media=disk,format=raw
      
      Since the code already have the IDE controller as `dev`, we don't need
      to use the legacy DriveInfo to find all the drive we want to unplug.
      We can simply use `blk` from the controller, as it kind of was already
      assume to be the same, by setting it to NULL.
      
      Signed-off-by: default avatarAnthony PERARD <anthony.perard@citrix.com>
      
      Acked-by: default avatarJohn Snow <jsnow@redhat.com>
      Reviewed-by: default avatarPaul Durrant <paul@xen.org>
      Message-Id: <20201027154058.495112-1-anthony.perard@citrix.com>
      Signed-off-by: default avatarAnthony PERARD <anthony.perard@citrix.com>
      045b1d4d
  26. Oct 27, 2020
  27. Oct 09, 2020
  28. Oct 01, 2020
Loading