> This is the qemu part of kernel series "Let user space control the
> cpu states"
>
> Christian Borntraeger (1):
> update linux headers with with cpustate changes
>
> David Hildenbrand (4):
> s390x/kvm: introduce proper states for s390 cpus
> s3
> This is the qemu part of kernel series "Let user space control the
> cpu states"
>
> Christian Borntraeger (1):
> update linux headers with with cpustate changes
>
> David Hildenbrand (4):
> s390x/kvm: introduce proper states for s390 cpus
> s3
> > This is the qemu part of kernel series "Let user space control the
> > cpu states"
> >
> > Christian Borntraeger (1):
> > update linux headers with with cpustate changes
> >
> > David Hildenbrand (4):
> > s390x/kvm: introduce prop
>
> On 10.07.14 15:10, Christian Borntraeger wrote:
> > From: David Hildenbrand
> >
> > If a cpu is stopped, it must never be allowed to run and no interrupt may
> > wake it
> > up. A cpu also has to be unhalted if it is halted and has work to do - this
>
>
> On 28.07.2014, at 16:16, David Hildenbrand wrote:
>
> >>
> >> On 10.07.14 15:10, Christian Borntraeger wrote:
> >>> From: David Hildenbrand
> >>>
> >>> If a cpu is stopped, it must never be allowed to run and no interrupt m
> >
> > On 28.07.2014, at 16:16, David Hildenbrand wrote:
> >
> > >>
> > >> On 10.07.14 15:10, Christian Borntraeger wrote:
> > >>> From: David Hildenbrand
> > >>>
> > >>> If a cpu is stopped, it must neve
> Il 28/07/2014 17:03, David Hildenbrand ha scritto:
> > Well the difference is, that a STOPPED vcpu can be woken up by non-interrupt
> > like things (SIGP START) AND a special interrupt (SIGP RESTART - which is
> > like
> > a "SIPI"++ as it performs a psw ex
> > We have
> > - wait (wait bit in PSW)
> > - disabled wait (wait bit and interrupt fencing in PSW)
> > - STOPPED (not related to PSW, state change usually handled via service
> > processor or hypervisor)
> >
> > I think we have to differentiate between KVM/TCG. On KVM we always do in
> > kernel
> Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
> >> > The patch may be okay, but I'm worried that it might be hiding a bug in
> >> > QEMU.
> > On s390 we call "KVM_S390_INITIAL_RESET" from several reset functions, e.g.
> > during
> > CPU creation. This is the first hickup and the pid no
> Il 19/08/2014 13:28, David Hildenbrand ha scritto:
> > Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
> > the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
> > reasons
> > why kvm_cpu_synchronize_post_reset() doesn
> On 19/08/14 14:14, David Hildenbrand wrote:
> >> Il 19/08/2014 13:28, David Hildenbrand ha scritto:
> >>> Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
> >>> in
> >>> the vcpu thread (e.g. comming from cpu_synchro
> >> Hmm. We want to not only reduce, we want them be zero.
> >> In addition to a reworked MP_STATE patch set, we might be able to change
> >> the code to call "KVM_S390_INITIAL_RESET" only from the cpu thread itself.
> >> If that simplifies things, we could avoid doing KVM_S390_INITIAL_RESET on
> >>> Does anyone have an idea?
> >>> The request itself is completely filled with cc
> >>
> >> That is very weird, the 'rq' is got from hctx->tags, and rq should be
> >> valid, and rq->q shouldn't have been changed even though it was
> >> double free or double allocation.
> >>
> >>> I am currentl
> On Wed, 17 Sep 2014 14:00:34 +0200
> David Hildenbrand wrote:
>
> > > >>> Does anyone have an idea?
> > > >>> The request itself is completely filled with cc
> > > >>
> > > >> That is very weird, the 'rq' is
y or enough to check if hw_ctx/tag_sets are
> fully initialized if you mean all requests have been used one time.
>
> On Wed, Sep 17, 2014 at 10:11 PM, David Hildenbrand
> > I was playing with a simple patch that just sets cmd_flags and action_flags
> > to
>
> What is
request.
Also move the reset of cmd_flags for the initializing code to the point where a
request is freed. So we will never end up with pending flush request indicators
that might trigger dereferences of invalid pointers in blk_mq_timeout_check().
Cc: sta...@vger.kernel.org
Signed-off-by: David
This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249.
Test is still pending.
David Hildenbrand (1):
blk-mq: Avoid race condition with uninitialized requests
block/blk-mq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
1.8.5.5
--
To unsubscribe from
t that the VCPU thread is running and
therefore needs no yield. yield_to() checks whether the target thread is
running,
so let's use the inbuilt functionality to make it independent of PF_VCPU and
preemption.
Signed-off-by: David Hildenbrand
---
virt/kvm/kvm_main.c | 4
1 file chang
ule, yields will
not work as intended.
Signed-off-by: David Hildenbrand
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 18 ++
2 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index aa56894..f1fe655
we should optimize.
David Hildenbrand (2):
KVM: don't check for PF_VCPU when yielding
KVM: thread creating a vcpu is the owner of that vcpu
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 22 ++
2 files changed, 3 insertions(+), 20 deletions(-)
--
1.
> This change is a trade-off.
> PRO: This patch would improve the case of preemption on s390. This is
> probably a corner case as most distros have preemption off anyway.
> CON: The downside is that kvm_vcpu_yield_to is called also from
> kvm_vcpu_on_spin. Here we want to avoid the scheduler over
> On 11/28/2014 04:28 PM, Christian Borntraeger wrote:
> > Am 28.11.2014 um 11:08 schrieb Raghavendra KT:
> >> Was able to test the patch, here is the result: I have not tested with
> >> bigger VMs though. Results make it difficult to talk about any side
> >> effect of
> >> patch if any.
> >
> > Th
> same
> VCPU thread, so changing threads is not a scenario we should optimize.
>
>
> David Hildenbrand (2):
> KVM: don't check for PF_VCPU when yielding
> KVM: thread creating a vcpu is the owner of that vcpu
>
> include/linux/kvm_host.h | 1 +
> virt/k
>
>
> On 03/12/2014 13:12, David Hildenbrand wrote:
> >> This series improves yielding on architectures that cannot disable
> >> preemption
> >> while entering the guest and makes the creating thread of a VCPU the owning
> >> thread and therefor
->preempted))
> continue;
>
> so the check on PF_VCPU is superfluous in general, and this patch
> removes it.
>
> Signed-off-by: David Hildenbrand
> Signed-off-by: Paolo Bonzini
>
Perfect, thanks!
David
--
To unsubscribe from this list: send the line &q
>
> Any chance that you name this function differently? Otherwise we've got
> two functions that sound very similar and also have similar prototypes:
>
> - kvm_get_vcpu(struct kvm *kvm, int i)
> - kvm_lookup_vcpu(struct kvm *kvm, int id)
>
> I'm pretty sure this will cause confusion in the futur
> On 11/19/2015 02:13 PM, Paolo Bonzini wrote:
> >
> >
> > On 19/11/2015 13:55, David Hildenbrand wrote:
> >>>>
> >>>> I'm pretty sure this will cause confusion in the future!
> >>>> ==> Could you maybe name the new fun
> Bring into line with the commentary for the other structures and their
> KVM_EXIT_* cases.
s/commentary/comments/ in the subject and description. Unless you want to add a
lengthy discussion :)
>
> Signed-off-by: Alex Bennée
>
> ---
>
> v2
> - add comments for other exit types
>
> diff --
> This commit defines the API headers for guest debugging. There are two
> architecture specific debug structures:
>
> - kvm_guest_debug_arch, allows us to pass in HW debug registers
> - kvm_debug_exit_arch, signals the exact debug exit and pc
>
> The type of debugging being used is control b
> This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
> ioctl. Currently any operation flag will return EINVAL. Actual
Well it won't return -EINVAL if you push in KVM_GUESTDBG_ENABLE or 0.
"Any unsupported flag will return -EINVAL. For now, only KVM_GUESTDBG_ENABLE is
supported, a
> > Looks good to me!
>
> Is that a Reviewed-by?
Now it is :)
Reviewed-by: David Hildenbrand
David
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> This is a precursor for later patches which will need to do more to
> setup debug state before entering the hyp.S switch code. The existing
> functionality for setting mdcr_el2 has been moved out of hyp.S and now
> uses the value kept in vcpu->arch.mdcr_el2.
>
> This also moves the conditional s
> This adds support for SW breakpoints inserted by userspace.
>
> We do this by trapping all BKPT exceptions in the
> hypervisor (MDCR_EL2_TDE). The kvm_debug_exit_arch carries the address
> of the exception. If user-space doesn't know of the breakpoint then we
> have a guest inserted breakpoint a
> On Tue, Mar 31, 2015 at 04:08:02PM +0100, Alex Bennée wrote:
> > This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
> > ioctl. Currently any operation flag will return EINVAL. Actual
> > functionality will be added with further patches.
> >
> > Signed-off-by: Alex Bennée .
> >
> Am 15.09.2015 um 18:27 schrieb Paolo Bonzini:
> > This new statistic can help diagnosing VCPUs that, for any reason,
> > trigger bad behavior of halt_poll_ns autotuning.
> >
> > For example, say halt_poll_ns = 48, and wakeups are spaced exactly
> > like 479us, 481us, 479us, 481us. Then KVM a
We observed some performance degradation on s390x with dynamic
halt polling. Until we can provide a proper fix, let's enable
halt_poll_ns as default only for supported architectures.
Architectures are now free to set their own halt_poll_ns
default value.
Signed-off-by: David Hilden
36 matches
Mail list logo
