qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 461bba: block/nvme: fix doorbell stride


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 461bba: block/nvme: fix doorbell stride
Date: Tue, 23 Jul 2019 02:50:52 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 461bba04bff0b3712a02fe49812b497c758e78da
      
https://github.com/qemu/qemu/commit/461bba04bff0b3712a02fe49812b497c758e78da
  Author: Maxim Levitsky <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M block/nvme.c

  Log Message:
  -----------
  block/nvme: fix doorbell stride

Fix the math involving non standard doorbell stride

Signed-off-by: Maxim Levitsky <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 118d1b6a81c7c22023ab1c3aad46d37184d1d838
      
https://github.com/qemu/qemu/commit/118d1b6a81c7c22023ab1c3aad46d37184d1d838
  Author: Maxim Levitsky <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M block/nvme.c

  Log Message:
  -----------
  block/nvme: support larger that 512 bytes sector devices

Currently the driver hardcodes the sector size to 512,
and doesn't check the underlying device. Fix that.

Also fail if underlying nvme device is formatted with metadata
as this needs special support.

Signed-off-by: Maxim Levitsky <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 258867d1dc32c300690cc32bfcf3e648ae12c4c9
      
https://github.com/qemu/qemu/commit/258867d1dc32c300690cc32bfcf3e648ae12c4c9
  Author: Maxim Levitsky <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M block/nvme.c

  Log Message:
  -----------
  block/nvme: don't touch the completion entries

Completion entries are meant to be only read by the host and written by the 
device.
The driver is supposed to scan the completions from the last point where it 
left,
and until it sees a completion with non flipped phase bit.

Signed-off-by: Maxim Levitsky <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 65181d63817b33b10ecb1c418eb96c99e7cf8842
      
https://github.com/qemu/qemu/commit/65181d63817b33b10ecb1c418eb96c99e7cf8842
  Author: Max Reitz <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block: Dec. drained_end_counter before bdrv_wakeup

Decrementing drained_end_counter after bdrv_dec_in_flight() (which in
turn invokes bdrv_wakeup() and thus aio_wait_kick()) is not very clever.
We should decrement it beforehand, so that any waiting aio_poll() that
is woken by bdrv_dec_in_flight() sees the decremented
drained_end_counter.

Because the time window between decrementing drained_end_counter and
aio_wait_kick() is very small, I cannot supply a reliable regression
test.  However, running e.g. the /bdrv-drain/blockjob/iothread/drain_all
test in test-bdrv-drain has a small chance of hanging without this
patch (about 1/200 or so; it gets to nearly 100 % if you add e.g. an
fputc(' ', stderr); after the bdrv_dec_in_flight()).

Fixes: e037c09c78520cbdb6da7cfc6ad0256d5870b814
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 43eaaaef0e18817bf78d8f135993f8579cad2cc6
      
https://github.com/qemu/qemu/commit/43eaaaef0e18817bf78d8f135993f8579cad2cc6
  Author: Max Reitz <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M block.c
    M include/block/block.h

  Log Message:
  -----------
  block: Only the main loop can change AioContexts

bdrv_set_aio_context_ignore() can only work in the main loop:
bdrv_drained_begin() only works in the main loop and the node's (old)
AioContext; and bdrv_drained_end() really only works in the main loop
and the node's (new) AioContext (contrary to its current comment, which
is just wrong).

Consequentially, bdrv_set_aio_context_ignore() must be called from the
main loop.  Luckily, assuming that we can make block graph changes only
from the main loop as well, all its callers do that already.

Note that changing a node's context in a sense is an operation that
changes the block graph, so it actually makes sense to require this
function to be called from the main loop.

Also, fix bdrv_drained_end()'s description.  You can only use it from
the main loop or the node's AioContext, and in the latter case, the
whole subtree must be in the same context.

Fixes: e037c09c78520cbdb6da7cfc6ad0256d5870b814
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: ecb199b177b3d94c1dfba2e7ba4595d368f780f7
      
https://github.com/qemu/qemu/commit/ecb199b177b3d94c1dfba2e7ba4595d368f780f7
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M block.c
    M block/io.c
    M block/nvme.c
    M include/block/block.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-07-22' 
into staging

Block patches for 4.1.0-rc2:
- NVMe block driver fixes
- Drain/AioContext fixes

# gpg: Signature made Mon 22 Jul 2019 17:44:45 BST
# gpg:                using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Max Reitz <address@hidden>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1  1829 F407 DB00 61D5 CF40

* remotes/maxreitz/tags/pull-block-2019-07-22:
  block: Only the main loop can change AioContexts
  block: Dec. drained_end_counter before bdrv_wakeup
  block/nvme: don't touch the completion entries
  block/nvme: support larger that 512 bytes sector devices
  block/nvme: fix doorbell stride

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/23da9e297b41...ecb199b177b3



reply via email to

[Prev in Thread] Current Thread [Next in Thread]