3e7a95feb9
COR across nodes (that is, you have some filter node between the actually COR target and the node that performs the COR) cannot reliably work together with the permission system when there is no explicit COR node that can request the WRITE_UNCHANGED permission for its child. This is because COR (currently) sneaks its requests by the usual permission checks, so it can work without a WRITE* permission; but if there is a filter node in between, that will re-issue the request, which then passes through the usual check -- and if nobody has requested a WRITE_UNCHANGED permission, that check will fail. There is no real direct fix apart from hoping that there is someone who has requested that permission; in case of just the qemu-io HMP command (and no guest device), however, that is not the case. The real real fix is to implement the copy-on-read flag through an implicitly added COR node. Such a node can request the necessary permissions as shown in this test. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180421132929.21610-10-mreitz@redhat.com Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
29 lines
641 B
Plaintext
29 lines
641 B
Plaintext
|
|
=== Copy-on-read across nodes ===
|
|
|
|
--- Setting up images ---
|
|
|
|
wrote 1048576/1048576 bytes at offset 0
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
wrote 1048576/1048576 bytes at offset 1048576
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
|
--- Doing COR ---
|
|
|
|
{u'return': {}}
|
|
{u'return': u''}
|
|
|
|
--- Checking COR result ---
|
|
|
|
discard 67108864/67108864 bytes at offset 0
|
|
64 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|