- 21 6月, 2019 23 次提交
-
-
由 Lidong Chen 提交于
Due to an off-by-one error, the assert statements allow an out-of-bound array access. This doesn't happen in practice, but the static analyzer notices. Signed-off-by: NLidong Chen <lidong.chen@oracle.com> Reviewed-by: NLiam Merwick <liam.merwick@oracle.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NLi Qiang <liq3ea@gmail.com> Reviewed-by: NDarren Kenny <darren.kenny@oracle.com> Message-Id: <6b19cb7359a10a6bedc3ea0fce22fed3ef93c102.1560806687.git.lidong.chen@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Previous commits have added support for migration of nested virtualization workloads. This was done by utilising two new KVM capabilities: KVM_CAP_NESTED_STATE and KVM_CAP_EXCEPTION_PAYLOAD. Both which are required in order to correctly migrate such workloads. Therefore, change code to add a migration blocker for vCPUs exposed with Intel VMX or AMD SVM in case one of these kernel capabilities is missing. Signed-off-by: NLiran Alon <liran.alon@oracle.com> Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Message-Id: <20190619162140.133674-11-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Kernel commit c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD") introduced a new KVM capability which allows userspace to correctly distinguish between pending and injected exceptions. This distinguish is important in case of nested virtualization scenarios because a L2 pending exception can still be intercepted by the L1 hypervisor while a L2 injected exception cannot. Furthermore, when an exception is attempted to be injected by QEMU, QEMU should specify the exception payload (CR2 in case of #PF or DR6 in case of #DB) instead of having the payload already delivered in the respective vCPU register. Because in case exception is injected to L2 guest and is intercepted by L1 hypervisor, then payload needs to be reported to L1 intercept (VMExit handler) while still preserving respective vCPU register unchanged. This commit adds support for QEMU to properly utilise this new KVM capability (KVM_CAP_EXCEPTION_PAYLOAD). Reviewed-by: NNikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-10-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Kernel commit 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") introduced new IOCTLs to extract and restore vCPU state related to Intel VMX & AMD SVM. Utilize these IOCTLs to add support for migration of VMs which are running nested hypervisors. Reviewed-by: NNikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Tested-by: NMaran Wilson <maran.wilson@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-9-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Reviewed-by: NNikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190619162140.133674-8-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Improve the KVM_{GET,SET}_NESTED_STATE structs by detailing the format of VMX nested state data in a struct. In order to avoid changing the ioctl values of KVM_{GET,SET}_NESTED_STATE, there is a need to preserve sizeof(struct kvm_nested_state). This is done by defining the data struct as "data.vmx[0]". It was the most elegant way I found to preserve struct size while still keeping struct readable and easy to maintain. It does have a misfortunate side-effect that now it has to be accessed as "data.vmx[0]" rather than just "data.vmx". Because we are already modifying these structs, I also modified the following: * Define the "format" field values as macros. * Rename vmcs_pa to vmcs12_pa for better readability. Signed-off-by: NLiran Alon <liran.alon@oracle.com> Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Message-Id: <20190619162140.133674-7-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Commit d98f2607 ("target/i386: kvm: add VMX migration blocker") added a migration blocker for vCPU exposed with Intel VMX. However, migration should also be blocked for vCPU exposed with AMD SVM. Both cases should be blocked because QEMU should extract additional vCPU state from KVM that should be migrated as part of vCPU VMState. E.g. Whether vCPU is running in guest-mode or host-mode. Fixes: d98f2607 ("target/i386: kvm: add VMX migration blocker") Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-6-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
If userspace (QEMU) debug guest, when #DB is raised in guest and intercepted by KVM, KVM forwards information on #DB to userspace instead of injecting #DB to guest. While doing so, KVM don't update vCPU DR6 but instead report the #DB DR6 value to userspace for further handling. See KVM's handle_exception() DB_VECTOR handler. QEMU handler for this case is kvm_handle_debug(). This handler basically checks if #DB is related to one of user set hardware breakpoints and if not, it re-inject #DB into guest. The re-injection is done by setting env->exception_injected to #DB which will later be passed as events.exception.nr to KVM_SET_VCPU_EVENTS ioctl by kvm_put_vcpu_events(). However, in case userspace re-injects #DB, KVM expects userspace to set vCPU DR6 as reported to userspace when #DB was intercepted! Otherwise, KVM_REQ_EVENT handler will inject #DB with wrong DR6 to guest. Fix this issue by updating vCPU DR6 appropriately when re-inject #DB to guest. Reviewed-by: NNikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: NKrish Sadhukhan <krish.sadhukhan@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-5-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Reviewed-by: NNikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: NKrish Sadhukhan <krish.sadhukhan@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-4-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Simiar to how kvm_init_vcpu() calls kvm_arch_init_vcpu() to perform arch-dependent initialisation, introduce kvm_arch_destroy_vcpu() to be called from kvm_destroy_vcpu() to perform arch-dependent destruction. This was added because some architectures (Such as i386) currently do not free memory that it have allocated in kvm_arch_init_vcpu(). Suggested-by: NMaran Wilson <maran.wilson@oracle.com> Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Signed-off-by: NLiran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-3-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Liran Alon 提交于
Commit d98f2607 ("target/i386: kvm: add VMX migration blocker") added migration blocker for vCPU exposed with Intel VMX because QEMU doesn't yet contain code to support migration of nested virtualization workloads. However, that commit missed adding deletion of the migration blocker in case init of vCPU failed. Similar to invtsc_mig_blocker. This commit fix that issue. Fixes: d98f2607 ("target/i386: kvm: add VMX migration blocker") Signed-off-by: NLiran Alon <liran.alon@oracle.com> Reviewed-by: NMaran Wilson <maran.wilson@oracle.com> Message-Id: <20190619162140.133674-2-liran.alon@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Xiaoyao Li 提交于
MSR IA32_CORE_CAPABILITY is a feature-enumerating MSR, which only enumerates the feature split lock detection (via bit 5) by now. The existence of MSR IA32_CORE_CAPABILITY is enumerated by CPUID.7_0:EDX[30]. The latest kernel patches about them can be found here: https://lkml.org/lkml/2019/4/24/1909Signed-off-by: NXiaoyao Li <xiaoyao.li@linux.intel.com> Message-Id: <20190617153654.916-1-xiaoyao.li@linux.intel.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for an interrupt instead of VMBus message). This new capability is only announced in KVM_GET_SUPPORTED_HV_CPUID. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-10-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
Enlightened VMCS is enabled by writing to a field in VP assist page and these require virtual APIC. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-9-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
The corresponding hypercalls require using VP indexes. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-8-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
Synthetic timers operate in hv-time time and Windows won't use these without SynIC. Add .dependencies field to kvm_hyperv_properties[] and a generic mechanism to check dependencies between features. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-7-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
In many case we just want to give Windows guests all currently supported Hyper-V enlightenments and that's where this new mode may come handy. We pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID. hv_cpuid_check_and_set() is modified to also set cpu->hyperv_* flags as we may want to check them later (and we actually do for hv_runtime, hv_synic,...). 'hv-passthrough' is a development only feature, a migration blocker is added to prevent issues while migrating between hosts with different feature sets. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-6-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
Currently, there is no doc describing hv-* CPU flags, people are encouraged to get the information from Microsoft Hyper-V Top Level Functional specification (TLFS). There is, however, a bit of QEMU specifics. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-5-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
Let's consolidate Hyper-V features handling in hyperv_handle_properties(). The change is necessary to support 'hv-passthrough' mode as we'll be just copying CPUIDs from KVM instead of filling them in. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-4-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
KVM now supports reporting supported Hyper-V features through CPUID (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be the only way to announce new functionality and this has already happened with Direct Mode stimers. While we could just support KVM_GET_SUPPORTED_HV_CPUID for new features, it seems to be beneficial to use it for all Hyper-V enlightenments when possible. This way we can implement 'hv-all' pass-through mode giving the guest all supported Hyper-V features even when QEMU knows nothing about them. Implementation-wise we create a new kvm_hyperv_properties structure defining Hyper-V features, get_supported_hv_cpuid()/ get_supported_hv_cpuid_legacy() returning the supported CPUID set and a bit over-engineered hv_cpuid_check_and_set() which we will also be used to set cpu->hyperv_* properties for 'hv-all' mode. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-3-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Vitaly Kuznetsov 提交于
Representing Hyper-V properties as bits will allow us to check features and dependencies between them in a natural way. Suggested-by: NRoman Kagan <rkagan@virtuozzo.com> Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-2-vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Colin Xu 提交于
QEMU tracks whether a vcpu is halted using CPUState::halted. E.g., after initialization or reset, halted is 0 for the BSP (vcpu 0) and 1 for the APs (vcpu 1, 2, ...). A halted vcpu should not be handed to the hypervisor to run (e.g. hax_vcpu_run()). Under HAXM, Android Emulator sometimes boots into a "vcpu shutdown request" error while executing in SeaBIOS, with the HAXM driver logging a guest triple fault in vcpu 1, 2, ... at RIP 0x3. That is ultimately because the HAX accelerator asks HAXM to run those APs when they are still in the halted state. Normally, the vcpu thread for an AP will start by looping in qemu_wait_io_event(), until the BSP kicks it via a pair of IPIs (INIT followed by SIPI). But because the HAX accelerator does not honor cpu->halted, it allows the AP vcpu thread to proceed to hax_vcpu_run() as soon as it receives any kick, even if the kick does not come from the BSP. It turns out that emulator has a worker thread which periodically kicks every vcpu thread (possibly to collect CPU usage data), and if one of these kicks comes before those by the BSP, the AP will start execution from the wrong RIP, resulting in the aforementioned SMP boot failure. The solution is inspired by the KVM accelerator (credit to Chuanxiao Dong <chuanxiao.dong@intel.com> for the pointer): 1. Get rid of questionable logic that unconditionally resets cpu->halted before hax_vcpu_run(). Instead, only reset it at the right moments (there are only a few "unhalt" events). 2. Add a check for cpu->halted before hax_vcpu_run(). Note that although the non-Unrestricted Guest (!ug_platform) code path also forcibly resets cpu->halted, it is left untouched, because only the UG code path supports SMP guests. The patch is first merged to android emulator with Change-Id: I9c5752cc737fd305d7eace1768ea12a07309d716 Cc: Yu Ning <yu.ning@intel.com> Cc: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: NColin Xu <colin.xu@intel.com> Message-Id: <20190610021939.13669-1-colin.xu@intel.com>
-
由 Yury Kotov 提交于
Signed-off-by: NYury Kotov <yury-kotov@yandex-team.ru> Message-Id: <20190607090830.18807-1-yury-kotov@yandex-team.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 19 6月, 2019 1 次提交
-
-
由 Peter Maydell 提交于
Block layer patches: - block: Remove bs->job - block: Ignore loosening perm restrictions failures - block/null: Expose read-zeroes option in QAPI schema - iotests: Hide timestamps for skipped tests # gpg: Signature made Tue 18 Jun 2019 15:44:12 BST # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: block/null: Expose read-zeroes option in QAPI schema iotests: Test failure to loosen restrictions block: Ignore loosening perm restrictions failures block: Add *tighten_restrictions to *check*_perm() block: Fix order in bdrv_replace_child() block/commit: Drop bdrv_child_try_set_perm() block/mirror: Fix child permissions block: Add bdrv_child_refresh_perms() file-posix: Update open_flags in raw_set_perm() block: drop bs->job blockdev: blockdev_mark_auto_del: drop usage of bs->job block/block-backend: blk_iostatus_reset: drop usage of bs->job block/replication: drop usage of bs->job iotests: Hide timestamps for skipped tests Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 18 6月, 2019 16 次提交
-
-
由 Peter Maydell 提交于
Python queue, 2019-06-18 Use a different method to dump avocado job log, to work around timing-dependent issues in the arm test cases. # gpg: Signature made Tue 18 Jun 2019 15:39:31 BST # gpg: using RSA key 2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/python-next-pull-request: Travis: print acceptance tests logs in case of job failure Revert "travis: Make check-acceptance job more verbose" Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Kevin Wolf 提交于
Commit cd219eb1 added the read-zeroes option for the null-co and null-aio block driver, but forgot to add them to the QAPI schema. Therefore, this option wasn't available in -blockdev and blockdev-add until now. Add the missing option in the schema to make it available there, too. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
We generally assume that loosening permission restrictions can never fail. We have seen in the past that this assumption is wrong. This has led to crashes because we generally pass &error_abort when loosening permissions. However, a failure in such a case should actually be handled in quite the opposite way: It is very much not fatal, so qemu may report it, but still consider the operation successful. The only realistic problem is that qemu may then retain permissions and thus locks on images it actually does not require. But again, that is not fatal. To implement this behavior, we make all functions that change permissions and that pass &error_abort to the initiating function (bdrv_check_perm() or bdrv_child_check_perm()) evaluate the @loosen_restrictions value introduced in the previous patch. If it is true and an error did occur, we abort the permission update, discard the error, and instead report success to the caller. bdrv_child_try_set_perm() itself does not pass &error_abort, but it is the only public function to change permissions. As such, callers may pass &error_abort to it, expecting dropping permission restrictions to never fail. Signed-off-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
This patch makes three functions report whether the necessary permission change tightens restrictions or not. These functions are: - bdrv_check_perm() - bdrv_check_update_perm() - bdrv_child_check_perm() Callers can use this result to decide whether a failure is fatal or not (see the next patch). Signed-off-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
We have to start by applying the permission restrictions to new_bs before we can loosen them on old_bs. See the comment for the explanation. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
commit_top_bs never requests or unshares any permissions. There is no reason to make this so explicit here. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
We cannot use bdrv_child_try_set_perm() to give up all restrictions on the child edge, and still have bdrv_mirror_top_child_perm() request BLK_PERM_WRITE. Fix this by making bdrv_mirror_top_child_perm() return 0/BLK_PERM_ALL when we want to give up all permissions, and replacing bdrv_child_try_set_perm() by bdrv_child_refresh_perms(). The bdrv_child_try_set_perm() before removing the node with bdrv_replace_node() is then unnecessary. No permissions have changed since the previous invocation of bdrv_child_try_set_perm(). Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
If a block node uses bdrv_child_try_set_perm() to change the permission it takes on its child, the result may be very short-lived. If anything makes the block layer recalculate the permissions internally, it will invoke the node driver's .bdrv_child_perm() implementation. The permission/shared permissions masks that returns will then override the values previously passed to bdrv_child_try_set_perm(). If drivers want a child edge to have specific values for the permissions/shared permissions mask, it must return them in .bdrv_child_perm(). Consequentially, there is no need for them to pass the same values to bdrv_child_try_set_perm() then: It is better to have a function that invokes .bdrv_child_perm() and calls bdrv_child_try_set_perm() with the result. This patch adds such a function under the name of bdrv_child_refresh_perms(). Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
raw_check_perm() + raw_set_perm() can change the flags associated with the current FD. If so, we have to update BDRVRawState.open_flags accordingly. Otherwise, we may keep reopening the FD even though the current one already has the correct flags. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
Drop remaining users of bs->job: 1. assertions actually duplicated by assert(!bs->refcnt) 2. trace-point seems not enough reason to change stream_start to return BlockJob pointer 3. Restricting creation of two jobs based on same bs is bad idea, as 3.1 Some jobs creates filters to be their main node, so, this check don't actually prevent creating second job on same real node (which will create another filter node) (but I hope it is restricted by other mechanisms) 3.2 Even without bs->job we have two systems of permissions: op-blockers and BLK_PERM 3.3 We may want to run several jobs on one node one day And finally, drop bs->job pointer itself. Hurrah! Suggested-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
We are going to remove bs->job pointer. Drop it's usage in blockdev_mark_auto_del: instead of looking at bs->job let's check all jobs for references to bs. Suggested-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
We are going to remove bs->job pointer. Drop it's usage in blk_iostatus_reset. blk_iostatus_reset() has only two callers: 1. blk_attach_dev(). This doesn't have anything to do with jobs and attaching a new guest device won't solve any problem the job encountered, so no reason to reset the iostatus for the job. 2. qmp_cont(). This resets the iostatus for everything. We can just call block_job_iostatus_reset() for all block jobs instead of going through BlockBackend. Suggested-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
We are going to remove bs->job pointer. Drop it's usage in replication code. Additionally we have to return job pointer from some mirror APIs. Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
Currently, the "thistime" variable is not reinitialized on every loop iteration. This leads to tests that do not yield a run time (because they failed or were skipped) printing the run time of the previous test that did. Fix that by reinitializing "thistime" for every test. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Cleber Rosa 提交于
Because Travis doesn't allow us to keep files produced during tests (such as log files), let's print the complete job log to the "console" in case of job failures. This is a debugging aid, and given that there's been some timeouts happening on some tests, we absolutely needs the logs to have a proper action. Signed-off-by: NCleber Rosa <crosa@redhat.com> Message-Id: <20190607152223.9467-2-crosa@redhat.com> Reviewed-by: NWainer dos Santos Moschetta <wainersm@redhat.com> Acked-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-