- 09 7月, 2012 4 次提交
-
-
由 Markus Armbruster 提交于
To prepare move of guess_disk_lchs() into hw/, where it poking BlockDriverState member io_limits_enabled directly would be unclean. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Markus Armbruster 提交于
bdrv_get_floppy_geometry_hint() fails to store through its parameter drive when bs has a geometry hint. Makes fd_revalidate() assign random crap to drv->drive. Has been broken that way for ages. Harmless, because: * The only way to set a geometry hint is -drive if=none,cyls=... Since commit c219331e, probably unintentional. * The only use of drv->drive is as argument to another bdrv_get_floppy_geometry_hint(). Which doesn't use it, since the geometry hint is still there. Drop the broken code, ignore -drive parameter cyls, heads and secs for floppies even with if=none, just like before commit c219331e. Matches -help, which explains cyls, heads, secs as "hard disk physical geometry". Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
The new function can be made a bit nicer than bdrv_append. It swaps the whole contents, and then swaps back (using the usual t=a;a=b;b=t idiom) the fields that need to stay on top. Thus, it does not need explicit bdrv_detach_dev, bdrv_iostatus_disable, etc. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
While these should not be in use at the time a transaction is started, a command in the prepare phase of a transaction might have added them, so they need to be brought over. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 15 6月, 2012 8 次提交
-
-
由 Markus Armbruster 提交于
So callers don't need to know anything about maximum name length. Returning a pointer is safe, because the name string lives as long as the block driver it names, and block drivers don't die. Requested by Peter Maydell. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
Formats are entirely in charge of flushes for metadata writes. For guest-initiated writes, a writethrough cache is faked in the block layer. So we can always open in writeback mode. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
Because the guest will be able to flip enable_write_cache, the actual state may not match what is used to open the new snapshot. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
We want to make the formats handle their own flushes autonomously, while keeping for guests the ability to use a writethrough cache. Since formats will write metadata via bs->file, bdrv_co_do_writev is the only place where we need to add a flush. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Markus Armbruster 提交于
Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Kevin Wolf 提交于
The QED block driver already provides the functionality to not only detect inconsistencies in images, but also fix them. However, this functionality cannot be manually invoked with qemu-img, but the check happens only automatically during bdrv_open(). This adds a -r switch to qemu-img check that allows manual invocation of an image repair. Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 12 6月, 2012 3 次提交
-
-
由 Michael Tokarev 提交于
It now allows specifying offset within qiov to start from and amount of bytes to copy. Actual implementation is just a call to iov_to_buf(). Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
由 Michael Tokarev 提交于
qemu_iovec_concat() is currently a wrapper for qemu_iovec_copy(), use the former (with extra "0" arg) in a few places where it is used. Change skip argument of qemu_iovec_copy() from uint64_t to size_t, since size of qiov itself is size_t, so there's no way to skip larger sizes. Rename it to soffset, to make it clear that the offset is applied to src. Also change the only usage of uint64_t in hw/9pfs/virtio-9p.c, in v9fs_init_qiov_from_pdu() - all callers of it actually uses size_t too, not uint64_t. One added restriction: as for all other iovec-related functions, soffset must point inside src. Order of argumens is already good: qemu_iovec_memset(QEMUIOVector *qiov, size_t offset, int c, size_t bytes) vs: qemu_iovec_concat(QEMUIOVector *dst, QEMUIOVector *src, size_t soffset, size_t sbytes) (note soffset is after _src_ not dst, since it applies to src; for memset it applies to qiov). Note that in many places where this function is used, the previous call is qemu_iovec_reset(), which means many callers actually want copy (replacing dst content), not concat. So we may want to add a wrapper like qemu_iovec_copy() with the same arguments but which calls qemu_iovec_reset() before _concat(). Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
由 Michael Tokarev 提交于
Similar to qemu_iovec_memset(QEMUIOVector *qiov, size_t offset, int c, size_t bytes); the new prototype is: qemu_iovec_from_buf(QEMUIOVector *qiov, size_t offset, const void *buf, size_t bytes); The processing starts at offset bytes within qiov. This way, we may copy a bounce buffer directly to a middle of qiov. This is exactly the same function as iov_from_buf() from iov.c, so use the existing implementation and rename it to qemu_iovec_from_buf() to be shorter and to match the utility function. As with utility implementation, we now assert that the offset is inside actual iovec. Nothing changed for current callers, because `offset' parameter is new. While at it, stop using "bounce-qiov" in block/qcow2.c and copy decrypted data directly from cluster_data instead of recreating a temp qiov for doing that. Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
- 30 5月, 2012 2 次提交
-
-
由 Jim Meyering 提交于
In snapshot mode, bdrv_open creates an empty temporary file without checking for mkstemp or close failure, and ignoring the possibility of a buffer overrun given a surprisingly long $TMPDIR. Change the get_tmp_filename function to return int (not void), so that it can inform its two callers of those failures. Also avoid the risk of buffer overrun and do not ignore mkstemp or close failure. Update both callers (in block.c and vvfat.c) to propagate temp-file-creation failure to their callers. get_tmp_filename creates and closes an empty file, while its callers later open that presumed-existing file with O_CREAT. The problem was that a malicious user could provoke mkstemp failure and race to create a symlink with the selected temporary file name, thus causing the qemu process (usually root owned) to open through the symlink, overwriting an attacker-chosen file. This addresses CVE-2012-2652. http://bugzilla.redhat.com/CVE-2012-2652Signed-off-by: NJim Meyering <meyering@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Jim Meyering 提交于
In snapshot mode, bdrv_open creates an empty temporary file without checking for mkstemp or close failure, and ignoring the possibility of a buffer overrun given a surprisingly long $TMPDIR. Change the get_tmp_filename function to return int (not void), so that it can inform its two callers of those failures. Also avoid the risk of buffer overrun and do not ignore mkstemp or close failure. Update both callers (in block.c and vvfat.c) to propagate temp-file-creation failure to their callers. get_tmp_filename creates and closes an empty file, while its callers later open that presumed-existing file with O_CREAT. The problem was that a malicious user could provoke mkstemp failure and race to create a symlink with the selected temporary file name, thus causing the qemu process (usually root owned) to open through the symlink, overwriting an attacker-chosen file. This addresses CVE-2012-2652. http://bugzilla.redhat.com/CVE-2012-2652Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: NJim Meyering <meyering@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 10 5月, 2012 15 次提交
-
-
由 Paolo Bonzini 提交于
qemu-img info should use the same logic as qemu when printing the backing file path, or debugging becomes quite tricky. We can also simplify the output in case the backing file has an absolute path or a protocol. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
bdrv_close should leave fields in the same state as bdrv_new. It is not up to bdrv_open_common to fix the mess. Also, backing_format was not being re-initialized. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
path_has_protocol will erroneously return "true" if the colon is part of a filename. These names are common with stable device names produced by udev. We cannot fully protect against this in case the filename does not have a path component (e.g. if the current directory is /dev/disk/by-path), but in the common case there will be a slash before and path_has_protocol can easily detect that and return false. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
On Windows, all the logic is already in is_windows_drive and is_windows_drive_prefix. On POSIX, there is no need to look out for colons. The win32 code changes the behaviour in some cases, we could have something like "d:foo.img". The old code would treat it as relative path, the new one as absolute. Now the path is absolute, because to go from c:/program files/blah to d:foo.img you cannot say c:/program files/blah/d:foo.img. You have to say d:foo.img. But you could also say it's relative because (I think, at least it was like that in DOS 15 years ago) d:foo.img is relative to the current path of drive D. Considering how path_is_absolute is used by path_combine, I think it's better to treat it as absolute. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
The limitation on not having I/O after cancellation cannot really be kept. Even streaming has a very small race window where you could cancel a job and have it report completion. If this window is hit, bdrv_change_backing_file() will yield and possibly cause accesses to dangling pointers etc. So, let's just assume that we cannot know exactly what will happen after the coroutine has set busy to false. We can set a very lax condition: - if we cancel the job, the coroutine won't set it to false again (and hence will not call co_sleep_ns again). - block_job_cancel_sync will wait for the coroutine to exit, which pretty much ensures no race. Instead, we track the coroutine that executes the job and put very strict conditions on what to do while it is quiescent (busy = false). First of all, the coroutine must never set busy = false while the job has been cancelled. Second, the coroutine can be reentered arbitrarily while it is quiescent, so you cannot really do anything but co_sleep_ns at that time. This condition is obeyed by the block_job_sleep_ns function. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
This function abstracts the pretty complex semantics of the "busy" member of BlockJob. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
We are reusing bs->file across close/open, which may not cause any known bugs but is a recipe for trouble. Prefer bdrv_delete, and enjoy the new invariant in the implementation of bdrv_delete. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
This is another bug caused by not doing a full cleanup of the BDS across close/open. This was found with mirroring by Shaolong Hu, but it can probably be reproduced also with eject or change. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
bdrv_append must also copy open_flags to the top, because the snapshot has BDRV_O_NO_BACKING set. This causes interesting results if you later use drive-reopen (not upstream) to reopen the image, and lose the backing file in the process. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
QED's opaque data includes a pointer back to the BlockDriverState. This breaks when bdrv_append shuffles data between bs_new and bs_top. To avoid this, add a "rebind" function that tells the driver about the new relationship between the BlockDriverState and its opaque. The patch also adds rebind to VVFAT for completeness, even though it is not used with live snapshots. Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
Also reuse elsewhere the new constant for sizeof(unsigned long) * 8. The dirty bitmap is allocated in bits but declared as unsigned long. Thus, its memory block is accessed beyond its end unless the image is a multiple of 64 chunks (i.e. a multiple of 64 MB). Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
bdrv_img_create will temporarily open the backing file to probe its size. However, this could be done with a read-write open if the wrong flags are passed to bdrv_img_create. Since there is really no documentation on what flags can be passed, assume that bdrv_img_create receives the flags with which the new image will be opened; sanitize them when opening the backing file. Reported-by: NEric Blake <eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
These are needed to print "info block" output correctly. QCOW2 does this because it needs it to write the header, but QED does not, and common code is the right place to do it. Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Paolo Bonzini 提交于
This check applies to all drivers, but QED lacks it. Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Zhi Yong Wu 提交于
Signed-off-by: NZhi Yong Wu <wuzhy@linux.vnet.ibm.com> [ Iterate until all block devices have processed all requests, add comments. - Paolo ] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 08 5月, 2012 1 次提交
-
-
由 Zhi Yong Wu 提交于
The current qemu.git introduces failure with preallocation and some sizes: qemu-img create -f qcow2 new.img 976563K -o preallocation=metadata qemu-img: qemu-coroutine-lock.c:111: qemu_co_mutex_unlock: Assertion `mutex->locked == 1' failed. And lock needs to work in coroutine context. So to fix this issue, we need to make bdrv_create adopt coroutine at first. Signed-off-by: NZhi Yong Wu <wuzhy@linux.vnet.ibm.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 27 4月, 2012 4 次提交
-
-
由 Stefan Hajnoczi 提交于
Allow streaming operations to be started with an initial speed limit. This eliminates the window of time between starting streaming and issuing block-job-set-speed. Users should use the new optional 'speed' parameter instead so that speed limits are in effect immediately when the job starts. Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Acked-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
-
由 Stefan Hajnoczi 提交于
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Acked-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
-
由 Stefan Hajnoczi 提交于
There are at least two different errors that can occur in block_job_set_speed(): the job might not support setting speeds or the value might be invalid. Use the Error mechanism to report the error where it occurs. Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Acked-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
-
由 Stefan Hajnoczi 提交于
The block job API uses -errno return values internally and we convert these to Error in the QMP functions. This is ugly because the Error should be created at the point where we still have all the relevant information. More importantly, it is hard to add new error cases to this case since we quickly run out of -errno values without losing information. Go ahead and use Error directly and don't convert later. Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Acked-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
-
- 20 4月, 2012 2 次提交
-
-
由 Kevin Wolf 提交于
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Liu Yuan 提交于
The 'qemu-img convert -h' advertise that the default cache mode is 'writeback', while in fact it is 'unsafe'. This patch 1) fix the help manual and 2) let bdrv_close() call bdrv_flush() 2) is needed because some backend storage doesn't have a self-flush mechanism(for e.g., sheepdog), so we need to call bdrv_flush() to make sure the image is really writen to the storage instead of hanging around writeback cache forever. Signed-off-by: NLiu Yuan <tailai.ly@taobao.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 19 4月, 2012 1 次提交
-
-
由 Kevin Wolf 提交于
If an AIO request is in flight that refers to a BlockDriverState that has been closed and possibly even freed, more or less anything could happen. I have seen segfaults, -EBADF return values and qcow2 sometimes actually catches the situation in bdrv_close() and abort()s. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
-