bwlp/qemu.git/block/raw_bsd.c, branch spice_video_codecs

block: Rename raw_bsd to raw-format.c

2017-01-09T12:30:52+00:00

Given that we have raw-win32.c and raw-posix.c, my initial guess at raw_bsd.c was that it was for dealing with raw files using code specific to the BSD operating system (beyond what raw-posix could do). Not so - this name was chosen back in commit e1c66c6 to distinguish that it was a BSD licensed file, in contrast to the then-existing raw.c with an unclear and potentially unusable license. But since it has been more than three years since the rewrite, it's time to pick a more useful name for this file to avoid this type of confusion to future contributors that don't know the backstory, as none of our other files are named solely by the license they use. In reality, this file deals with the raw format, which is useful with any number of protocols, while raw-{win32,posix} deal with the file protocol (and in turn, that protocol is not limited to use with the raw format). So rename raw_bsd to raw-format.c. We could have also used the shorter name raw.c, except that collides with the earlier use of that filename for a different license, and it's better to be safe than risk license pollution. The next patch will also rename raw-win32.c and raw-posix.c to further distinguish the difference in roles. It doesn't hurt that this gets rid of an underscore in the filename, thereby making tab-completion on 'ra' easier (now I don't have to type the shift key, which slows things down :) Suggested-by: Daniel P. Berrange Signed-off-by: Eric Blake Reviewed-by: Laszlo Ersek Reviewed-by: Stefan Hajnoczi Signed-off-by: Kevin Wolf

raw_bsd: don't check size alignment when only offset is set

2016-11-11T14:54:55+00:00

We make sure that the size is aligned to sector length to prevent any round ups. Otherwise we could end up reading/writing data outside the area specified by user. This is only needed when user supplies the size option to avoid any surprises. It is not necessary when only offset is set. More over, the check made it difficult to use the offset option without size option. The check puts unneeded restriction on the offset which had to be aligned too. Because bdrv_getlength() returns aligned value having unaligned offset would make the check fail. Signed-off-by: Tomáš Golembiovský Signed-off-by: Kevin Wolf

raw_bsd: move check to prevent overflow

2016-11-11T14:54:55+00:00

When only offset is specified but no size and the offset is greater than the real size of the containing device an overflow occurs when parsing the options. This overflow is harmless because we do check for this exact situation little bit later, but it leads to an error message with weird values. It is better to do the check is sooner and prevent the overflow. Signed-off-by: Tomáš Golembiovský Signed-off-by: Kevin Wolf

raw_bsd: add offset and size options

2016-10-31T15:52:39+00:00

Added two new options 'offset' and 'size'. This makes it possible to use only part of the file as a device. This can be used e.g. to limit the access only to single partition in a disk image or use a disk inside a tar archive (like OVA). When 'size' is specified we do our best to honour it. Signed-off-by: Tomáš Golembiovský Signed-off-by: Kevin Wolf

raw: Implement .bdrv_co_ioctl instead of .bdrv_aio_ioctl

2016-10-27T17:05:23+00:00

It's the simpler interface to use for the raw format driver. Apart from that, this removes the last user of the AIO emulation implemented by bdrv_aio_ioctl(). Signed-off-by: Kevin Wolf Reviewed-by: Eric Blake

raw_bsd: Convert to byte-based interface

2016-07-20T13:24:25+00:00

Since the raw format driver is just passing things through, we can do byte-based read and write if the underlying protocol does likewise. There's one tricky part - if we probed the image format, we document that we restrict operations on the initial sector. It's easiest to keep this guarantee by enforcing read-modify-write on sub-sector operations (yes, this partially reverts commit ad82be2f). Signed-off-by: Eric Blake Message-id: 1468624988-423-20-git-send-email-eblake@redhat.com Signed-off-by: Stefan Hajnoczi

raw_bsd: Switch .bdrv_co_discard() to byte-based

2016-07-20T13:24:25+00:00

Another step towards killing off sector-based block APIs. Signed-off-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id: 1468624988-423-16-git-send-email-eblake@redhat.com Signed-off-by: Stefan Hajnoczi

block: Convert bdrv_co_discard() to byte-based

2016-07-20T13:11:54+00:00

Another step towards byte-based interfaces everywhere. Replace the sector-based bdrv_co_discard() with a new byte-based bdrv_co_pdiscard(), which silently ignores any unaligned head or tail. Driver callbacks will be converted in followup patches. By calculating the alignment outside of the loop, and clamping the max discard to an aligned value, we can simplify the actions done within the loop. Signed-off-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id: 1468624988-423-2-git-send-email-eblake@redhat.com Signed-off-by: Stefan Hajnoczi

raw_bsd: Don't advertise flags not supported by protocol layer

2016-07-20T13:11:54+00:00

The raw format layer supports all flags via passthrough - but it only makes sense to pass through flags that the lower layer actually supports. The next patch gives stronger reasoning for why this is correct. At the moment, the raw format layer ignores the max_transfer limit of its protocol layer, and an attempt to do the qemu-io 'w -f 0 40m' to an NBD server that lacks FUA will pass the entire 40m request to the NBD driver, which then fragments the request itself into a 32m write, 8m write, and flush. But once the block layer starts honoring limits and fragmenting packets, the raw driver will hand the NBD driver two separate requests; if both requests have BDRV_REQ_FUA set, then this would result in a 32m write, flush, 8m write, and second flush. By having the raw layer no longer advertise FUA support when the protocol layer lacks it, we are back to a single flush at the block layer for the overall 40m request. Note that 'w -f -z 0 40m' does not currently exhibit the same problem, because there, the fragmentation does not occur until at the NBD layer (the raw layer has .bdrv_co_pwrite_zeroes, and the NBD layer doesn't advertise max_pwrite_zeroes to constrain things at the raw layer) - but the problem is latent and we would again have too many flushes without this patch once the NBD layer implements support for the new NBD_CMD_WRITE_ZEROES command, if it sets max_pwrite_zeroes to the same 32m limit as recommended by the NBD protocol. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng Reviewed-by: Stefan Hajnoczi Message-id: 1468607524-19021-3-git-send-email-eblake@redhat.com Signed-off-by: Stefan Hajnoczi

block: Convert bdrv_co_preadv/pwritev to BdrvChild

2016-07-05T14:46:27+00:00

This is the final patch for converting the common I/O path to take a BdrvChild parameter instead of BlockDriverState. The completion of this conversion means that all users that perform I/O on an image need to actually hold a reference (in the form of BdrvChild, possible as part of a BlockBackend) to that image. This also protects against inconsistent use of BlockBackend vs. BlockDriverState functions because direct use of a BlockDriverState isn't possible any more and blk->root is private for block-backends.c. In addition, we can now distinguish different users in the I/O path, and the future op blockers work is going to add assertions based on permissions stored in BdrvChild. Signed-off-by: Kevin Wolf Acked-by: Stefan Hajnoczi