schedule_work() returns 'false' only when the work is already on the queue
and this can't happen as kvm_setup_async_pf() always allocates a new one.
Also, to avoid potential race, it makes sense to to schedule_work() at the
very end after we've added it to the queue.
While on it, do some minor cleanup. gfn_to_pfn_async() mentioned in a
comment does not currently exist and, moreover, we can check
kvm_is_error_hva() at the very beginning, before we try to allocate work so
'retry_sync' label can go away completely.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200610175532.779793-1-vkuznets@redhat.com>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The pointer s is being assigned a value that is never read, the
assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Message-Id: <20200609233121.1118683-1-colin.king@canonical.com>
Fixes: 7837699fa6 ("KVM: In kernel PIT model")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When userspace configures KVM_GUESTDBG_SINGLESTEP, KVM will manage the
presence of X86_EFLAGS_TF via kvm_set/get_rflags on vcpus. The actual
rflag bit is therefore hidden from callers.
That includes init_emulate_ctxt() which uses the value returned from
kvm_get_flags() to set ctxt->tf. As a result, x86_emulate_instruction()
will skip a single step, leaving singlestep_rip stale and not returning
to userspace.
This resolves the issue by observing the vcpu guest_debug configuration
alongside ctxt->tf in x86_emulate_instruction(), performing the single
step if set.
Cc: stable@vger.kernel.org
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Message-Id: <20200519081048.8204-1-felipe@nutanix.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM_CAP_HYPERV_ENLIGHTENED_VMCS will be reported as supported even when
nested VMX is not, fix evmcs_test/hyperv_cpuid tests to check for both.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200610135847.754289-3-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
state_test/smm_test use KVM_CAP_NESTED_STATE check as an indicator for
nested VMX/SVM presence and this is incorrect. Check for the required
features dirrectly.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200610135847.754289-2-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Using a topic branch so that stable branches can simply cherry-pick the
patch.
Reviewed-by: Oliver Upton <oupton@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There are too many wrapper functions at atomisp_compat_css20.c.
Get rid of another set of such wrappers.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When probe fails, it is possible that hmm_init() to not be
called. On such case, hmm_cleanup() will cause a WARN_ON().
Avoid it by adding an explicit check at hmm_cleanup() to
ensure that the hmm code was properly initialized.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is an abstraction layer there meant to convert to
the Linux standard error codes. As the driver now use
such errors everywhere. we can get rid of this.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp driver has its own error codes under the
ia_css_err.h file. On several places, those got already
replaced by standard error codes, but there are still a
lot more to be fixed.
Let's get rid of all of those, mapping them into
the already-existing set of Linux error codes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Run checkpatch --fix-inline again, in order to get rid
of some additional issues that got introduced (or that
checkpatch can now detect).
This should help preventing receiving random cleanups,
while keeping the code on a better shape.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are tons of code inside atomisp_compat_css20.c, but
several of them are just trivial wrappers to other functions.
Getting rid of all of them will take some time, but let's
start getting rid of some of the trivial ones.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use the variant which zeroes the memory when allocating,
instead of having an explicit memset.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Clang warns:
drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:1707:64:
warning: implicit conversion from enumeration type 'const enum
ia_css_frame_format' to different enumeration type 'enum
atomisp_input_format' [-Wenum-conversion]
binary_supports_input_format(xcandidate, req_in_info->format));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~^~~~~~
As it turns out, binary_supports_input_format only asserts that
xcandidate is not NULL and just returns true so this call is never
actually made.
There are other functions that are called that assert info is not NULL
so this function actually serves no purpose. Remove it. It can be
brought back if needed later.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Clang warns:
drivers/staging/media/atomisp/pci/isp/kernels/xnr/xnr_3.0/ia_css_xnr3.host.c:129:35:
warning: implicit conversion from 'unsigned long' to 'int32_t' (aka
'int') changes value from 18446744073709543424 to -8192
[-Wconstant-conversion]
return MAX(MIN(isp_strength, 0), -XNR_BLENDING_SCALE_FACTOR);
~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
XNR_BLENDING_SCALE_FACTOR is BIT(13), or 8192, which will easily fit
into a signed 32-bit integer. However, it is an unsigned long, which
means that negating it is the same as subtracting that value from
ULONG_MAX + 1, which causes it to be larger than a signed 32-bit
integer so it gets implicitly converted.
We can avoid this by using the variable isp_scale, which holds the value
of XNR_BLENDING_SCALE_FACTOR already, where the implicit conversion from
unsigned long to s32 already happened. If that were to ever overflow,
clang would warn: https://godbolt.org/z/EeSxLG
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Clang warns:
drivers/staging/media/atomisp/pci/atomisp_cmd.c:4278:17: warning:
address of 'config->info' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (!&config->info) {
~ ~~~~~~~~^~~~
config cannot be NULL because it comes from an ioctl, which ensures that
the user is not giving us an invalid pointer through copy_from_user. If
config is not NULL, info cannot be NULL. Remove this check.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Clang warns:
../drivers/staging/media/atomisp/pci/sh_css.c:8537:14: warning: address
of 'pipe->output_stage' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (&pipe->output_stage)
~~ ~~~~~~^~~~~~~~~~~~
../drivers/staging/media/atomisp/pci/sh_css.c:8545:14: warning: address
of 'pipe->vf_stage' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (&pipe->vf_stage)
~~ ~~~~~~^~~~~~~~
output_stage and vf_stage are pointers in the middle of a struct, their
addresses cannot be NULL if pipe is not NULL and pipe is already checked
for NULL in this function. Simplify this if block.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Clang warns:
../drivers/staging/media/atomisp/pci/atomisp_v4l2.c:1097:3: warning:
variable 'count' is incremented both in the loop header and in the loop
body [-Wfor-loop-analysis]
count++;
^
This was probably unintentional, remove it.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Clang warns:
../drivers/staging/media/atomisp/pci/sh_css_sp.c:1039:23: warning:
address of 'binary->in_frame_info' will always evaluate to 'true'
[-Wpointer-bool-conversion]
} else if (&binary->in_frame_info) {
~~ ~~~~~~~~^~~~~~~~~~~~~
in_frame_info is not a pointer so if binary is not NULL, in_frame_info's
address cannot be NULL. Change this to an else since it will always be
evaluated as one.
While we are here, clean up this if block. The contents of both if
blocks are the same but a check against "stage == 0" is added when
ISP2401 is defined. USE_INPUT_SYSTEM_VERSION_2401 is only defined when
isp2401_system_global.h is included, which only happens when ISP2401. In
other words, USE_INPUT_SYSTEM_VERSION_2401 always requires ISP2401 to be
defined so the '#ifndef ISP2401' makes no sense. Remove that part of the
block to simplify everything.
Link: https://github.com/ClangBuiltLinux/linux/issues/1036
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
stage->args->delay_frames array could point to NULL frames.
What's weird is that we didn't notice this behavior with the
Intel Aero Yocto code.
Handle it, while adding a notice at the code, as this could
be due to some broken pipeline setup.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The sh_css layer adds an abstraction for kvmalloc/kvcalloc.
Get rid of them. Most of the work here was done by this
small coccinelle script:
<cocci>
@@
expression size;
@@
- sh_css_malloc(size)
+ kvmalloc(size, GFP_KERNEL)
@@
expression n;
expression size;
@@
- sh_css_calloc(n, size)
+ kvcalloc(n, size, GFP_KERNEL)
</cocci>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The frame allocation logic happens differently for userptr
or normal mmap. On a quick look, this sounded to be unbalanced,
but the logic should actually work for both cases.
Add an extra comment to reflect it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If something gets wrong when enabling or disabling an IRQ,
we should know better about what happened.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The hmm code is still complex and has bugs. Add a debug print
when memory gets allocated, in order to help identifying what's
happening out there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of using a hacked version of an old copy of
get_user_pages(), use pin_user_pages().
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The hmm code is partially based on a fork from 3.10 code,
and has bugs.
Add debug there to help tracking what happens there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The kernel ABI was extended to allow pass tagged user pointers.
Untag the pointers in this function.
Fixes: d93445225c ("uaccess: add noop untagged_addr definition")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that we have everything in place, we can get rid of the
memory_access abstraction layer.
Now, everything related to heterogeneous memory management
(hmm) is under hmm.c & related pools.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The mmgr alloc code returns a different type than hmm, due to
some abstraction layer.
Change the driver to use just one type to represent the
hmm memory.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The code for it is commented out, probably because it is
broken or uneeded for the driver to work. So, let's get
rid of it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move the attrs handling into hmm, simplifying even further
what the ia_css_memory_access.c file does.
Yet, the returned type for ia_css_memory_access.c is an
integer, instead of a pointer.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Yet another memory abstraction layer. Getting rid of this
may be a little trickier, but let's reduce it to a minimal.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The code there is a wrapper for hmm/ wrapper. Simplify it,
and get rid of ION-specific code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several spelling mistakes in various messages and literal
strings. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Right now, the variables that define the max number of
delay frames is defined as:
#define VIDEO_FRAME_DELAY 2
#define MAX_NUM_VIDEO_DELAY_FRAMES (VIDEO_FRAME_DELAY + 1)
#define NUM_PREVIEW_DVS_FRAMES (2)
#define MAX_NUM_DELAY_FRAMES MAX(MAX_NUM_VIDEO_DELAY_FRAMES, NUM_PREVIEW_DVS_FRAMES)
In other words, we have:
MAX_NUM_VIDEO_DELAY_FRAMES = 3
MAX_NUM_DELAY_FRAMES = 2
The MAX_NUM_DELAY_FRAMES macro is used only only when allocating
memory. On all other parts, including looping over such array,
MAX_NUM_VIDEO_DELAY_FRAMES is used instead, like:
void sh_css_binary_args_reset(struct sh_css_binary_args *args)
{
unsigned int i;
...
for (i = 0; i < MAX_NUM_VIDEO_DELAY_FRAMES; i++)
args->delay_frames[i] = NULL;
Which will cause buffer overflows, with may override the next array
(tnr_frames[]).
In practice, this may not be causing real issues, as the code
checks for num_delay_frames on some parts (but not everywhere).
So, get rid of the smallest value.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some arguments for tnf and ref settings are meant to be const, but
they're defined without such annotation. Due to that, there's an
ugly cast at sh_css_sp.c.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The very same macros are defined as CSS_foo and IA_CSS_foo.
Remove this abstraction, as it just make things confusing,
for no good reason.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver has 3 different types of debug messages:
- dev_dbg()
- dbg_level
- ia_css_debug_trace_level
Which is crazy. Ideally, it shold just use dev_dbg()
everywhere, but for now let's unify the last two machanisms.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It sounds that someone once changed the debug level at compile
time for some testing, but forgot to remove the legacy code after
finishing debuging it.
Get rid of the dead code.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Let's reflect the current status at the TODO list, as other
developers can help addressing issues over there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Using DQBUF on non-blocking mode will return -EAGAIN
if nothing arrives. Printing it has no value, even for debug
purposes. So, only display real return codes.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several error conditions that don't print anything,
making harder to identify bugs at the code there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's no reason to copy isp_sink_fmt, as the driver
uses it for read-only purposes.
Linux stack is a precious resource. Let's avoid wasting it.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, when an EOF IRQ is received, it generates two messages:
[ 59.191893] atomisp-isp2 0000:00:03.0: irq:0x200000
[ 59.191913] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 142, asd 0
Flooding the dmesg with lots of messages per second. The same
pattern happens for all other IRQs.
Change the logic for printing just one message per IRQ and
rate-limit those, as, for debugging purposes, it is usually
interesting to know that IRQs are being received, but not
displaying every single one.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
