Re: [PATCH 3/3] Provide control over unmapped pages
* KAMEZAWA Hiroyuki [2010-12-02 11:50:36]: > On Thu, 2 Dec 2010 10:22:16 +0900 (JST) > KOSAKI Motohiro wrote: > > > > On Tue, 30 Nov 2010, Andrew Morton wrote: > > > > > > > > +#define UNMAPPED_PAGE_RATIO 16 > > > > > > > > Well. Giving 16 a name didn't really clarify anything. Attentive > > > > readers will want to know what this does, why 16 was chosen and what > > > > the effects of changing it will be. > > > > > > The meaning is analoguous to the other zone reclaim ratio. But yes it > > > should be justified and defined. > > > > > > > > Reviewed-by: Christoph Lameter > > > > > > > > So you're OK with shoving all this flotsam into 100,000,000 cellphones? > > > > This was a pretty outrageous patchset! > > > > > > This is a feature that has been requested over and over for years. Using > > > /proc/vm/drop_caches for fixing situations where one simply has too many > > > page cache pages is not so much fun in the long run. > > > > I'm not against page cache limitation feature at all. But, this is > > too ugly and too destructive fast path. I hope this patch reduce negative > > impact more. > > > > And I think min_mapped_unmapped_pages is ugly. It should be > "unmapped_pagecache_limit" or some because it's for limitation feature. > The feature will now be enabled with a CONFIG and boot parameter, I find changing the naming convention now - it is already in use and well known is not a good idea. THe name of the boot parameter can be changed of-course. -- Three Cheers, Balbir -- 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
buildbot failure in kvm on ppc64
The Buildbot has detected a new failure of ppc64 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/ppc64/builds/20 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on s390
The Buildbot has detected a new failure of s390 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/s390/builds/16 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on ia64
The Buildbot has detected a new failure of ia64 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/ia64/builds/21 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on ppc44x
The Buildbot has detected a new failure of ppc44x on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/ppc44x/builds/23 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on default_i386_out_of_tree
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/612 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on default_i386_debian_5_0
The Buildbot has detected a new failure of default_i386_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/675 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on default_x86_64_out_of_tree
The Buildbot has detected a new failure of default_x86_64_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/614 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on default_x86_64_debian_5_0
The Buildbot has detected a new failure of default_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/673 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_i386_out_of_tree
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/612 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_x86_64_out_of_tree
The Buildbot has detected a new failure of disable_kvm_x86_64_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_out_of_tree/builds/612 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_i386_debian_5_0
The Buildbot has detected a new failure of disable_kvm_i386_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/664 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_x86_64_debian_5_0
The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/663 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Joerg Roedel ,Roedel, Joerg BUILD FAILED: failed git sincerely, -The Buildbot -- 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
Re: [PATCH v4 1/3] KVM: MMU: rename 'no_apf' to 'prefault'
On Thu, Dec 02, 2010 at 05:44:43PM +0800, Xiao Guangrong wrote: > It's the speculative path if 'no_apf = 1' and we will specially handle this > speculative path in the later patch, so 'prefault' is better to fit the sense > > Signed-off-by: Xiao Guangrong > --- > arch/x86/include/asm/kvm_host.h |3 ++- > arch/x86/kvm/mmu.c | 18 +- > arch/x86/kvm/paging_tmpl.h |4 ++-- > 3 files changed, 13 insertions(+), 12 deletions(-) Looks good to me. Avi, Gleb? -- 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
Re: [PATCH 1/2] vhost test module
On Thu, Dec 02, 2010 at 03:56:56PM -0800, Paul E. McKenney wrote:
> On Fri, Dec 03, 2010 at 01:18:18AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 02, 2010 at 03:13:03PM -0800, Paul E. McKenney wrote:
> > > On Thu, Dec 02, 2010 at 09:47:09PM +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Dec 02, 2010 at 11:26:16AM -0800, Paul E. McKenney wrote:
> > > > > On Thu, Dec 02, 2010 at 09:11:30PM +0200, Michael S. Tsirkin wrote:
> > > > > > On Thu, Dec 02, 2010 at 11:00:37AM -0800, Paul E. McKenney wrote:
> > > > > > > On Mon, Nov 29, 2010 at 07:09:01PM +0200, Michael S. Tsirkin
> > > > > > > wrote:
> > > > > > > > This adds a test module for vhost infrastructure.
> > > > > > > > Intentionally not tied to kbuild to prevent people
> > > > > > > > from installing and loading it accidentally.
> > > > > > > >
> > > > > > > > Signed-off-by: Michael S. Tsirkin
> > > > > > >
> > > > > > > On question below.
> > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
> > > > > > > > new file mode 100644
> > > > > > > > index 000..099f302
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/drivers/vhost/test.c
> > > > > > > > @@ -0,0 +1,320 @@
> > > > > > > > +/* Copyright (C) 2009 Red Hat, Inc.
> > > > > > > > + * Author: Michael S. Tsirkin
> > > > > > > > + *
> > > > > > > > + * This work is licensed under the terms of the GNU GPL,
> > > > > > > > version 2.
> > > > > > > > + *
> > > > > > > > + * test virtio server in host kernel.
> > > > > > > > + */
> > > > > > > > +
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > > +
> > > > > > > > +#include "test.h"
> > > > > > > > +#include "vhost.c"
> > > > > > > > +
> > > > > > > > +/* Max number of bytes transferred before requeueing the job.
> > > > > > > > + * Using this limit prevents one virtqueue from starving
> > > > > > > > others. */
> > > > > > > > +#define VHOST_TEST_WEIGHT 0x8
> > > > > > > > +
> > > > > > > > +enum {
> > > > > > > > + VHOST_TEST_VQ = 0,
> > > > > > > > + VHOST_TEST_VQ_MAX = 1,
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +struct vhost_test {
> > > > > > > > + struct vhost_dev dev;
> > > > > > > > + struct vhost_virtqueue vqs[VHOST_TEST_VQ_MAX];
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +/* Expects to be always run from workqueue - which acts as
> > > > > > > > + * read-size critical section for our kind of RCU. */
> > > > > > > > +static void handle_vq(struct vhost_test *n)
> > > > > > > > +{
> > > > > > > > + struct vhost_virtqueue *vq = &n->dev.vqs[VHOST_TEST_VQ];
> > > > > > > > + unsigned out, in;
> > > > > > > > + int head;
> > > > > > > > + size_t len, total_len = 0;
> > > > > > > > + void *private;
> > > > > > > > +
> > > > > > > > + private = rcu_dereference_check(vq->private_data, 1);
> > > > > > >
> > > > > > > Any chance of a check for running in a workqueue? If I remember
> > > > > > > correctly,
> > > > > > > the ->lockdep_map field in the work_struct structure allows you
> > > > > > > to create
> > > > > > > the required lockdep expression.
> > > > > >
> > > > > > We moved away from using the workqueue to a custom kernel thread
> > > > > > implementation though.
> > > > >
> > > > > OK, then could you please add a check for "current ==
> > > > > custom_kernel_thread"
> > > > > or some such?
> > > > >
> > > > > Thanx, Paul
> > > >
> > > > It's a bit tricky. The way we flush out things is by an analog of
> > > > flush_work. So just checking that we run from workqueue isn't
> > > > right need to check that we are running from one of the specific work
> > > > structures that we are careful to flush.
> > > >
> > > > I can do this by passing the work structure pointer on to relevant
> > > > functions but I think this will add (very minor) overhead even when rcu
> > > > checks are disabled. Does it matter? Thoughts?
> > >
> > > Would it be possible to set up separate lockdep maps, in effect passing
> > > the needed information via lockdep rather than via the function arguments?
> >
> > Possibly, I don't know enough about this but will check.
> > Any examples to look at?
>
> I would suggest the workqueue example in include/linux/workqueue.h and
> kernel/workqueue.c. You will need a struct lockdep_map for each of the
> specific work structures, sort of like the one in struct workqueue_struct.
>
> You can then use lock_map_acquire() and lock_map_release() to flag the
> fact that your kernel thread is running and not, and then you can pass
> lock_is_held() to rcu_dereference_check(). Each of lock_map_acquire(),
> lock_map_release(), and lock_is_held() takes a struct lockdep_map as
>
Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices
On Sat, 4 Dec 2010, Jan Kiszka wrote: > Am 04.12.2010 15:41, Thomas Gleixner wrote: > > Also there is a pretty simple solution for this: The core code knows, > > that there is an ONESHOT interrupt in flight, so it simply can call > > It doesn't synchronize the tail part against the masking in the > handler(s), that's driver business. Right, but the core knows from the irq state, that the line is masked and due to the ONESHOT or whatever feature it knows that it needs to call the handler. The other way round shared -> exclusive does not matter at all. > > the primary handler of that device with the appropriate flag set > > (maybe an additional one to indicate the transition) and let that deal > > with it. Needs some thought vs. locking and races, but that shouldn't > > be hard. > > Yes, I thought about this kind of transition (re-invoking the existing > handler) already. We do need notification of the switch (at least for > exclusive->shared) as only the driver can migrate the masking for > in-flight interrupts. Right. It needs to set the device level mask in that case. As the interrupt handler already has the code to do that it's the most obvious function to call. Thanks, tglx -- 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
Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices
Am 04.12.2010 15:41, Thomas Gleixner wrote: > Jan, > > On Sat, 4 Dec 2010, Jan Kiszka wrote: > >> Am 04.12.2010 11:37, Thomas Gleixner wrote: >>> On Sat, 4 Dec 2010, Jan Kiszka wrote: >>> If interrupt is shared, then you want to keep the current behaviour: >>> >>>disable at line level (IRQF_ONESHOT) >>>run handler thread (PCI level masking) >>>reenable at line level in irq_finalize_oneshot() >>>reenable at PCI level when guest is done >> >> If the interrupt is shared, we must mask at PCI level inside the primary >> handler as we also have to support non-threaded users of the same line. >> So we always have a transition line-level -> device-level >> masking in a primary handler. > > Sorry that left out the hard irq part. Of course it needs to do the > PCI level masking in the primary one. > >> reduce the latency. So both threaded and non-threaded cases should be >> addressable by any approach. > > The oneshot magic should work on non threaded cases as well. Needs > some modifications, but nothing complex. > >>> If interrupts are in flight accross request/free then this change >>> takes effect when the next interrupt comes in. >> >> For registration, that might be too late. We need to synchronize on >> in-flight interrupts for that line and then ensure that it gets enabled >> independently of the registered user. That user may have applied >> outdated information, thus would block the line for too long if user >> space decides to do something else. > > No, that's really just a corner case when going from one to two > handlers and I don't think it matters much. If you setup a new driver > it's not really important whether that first thing comes in a few ms > later. The worst case remains infinite (user space never signals end of interrupt). > > Also there is a pretty simple solution for this: The core code knows, > that there is an ONESHOT interrupt in flight, so it simply can call It doesn't synchronize the tail part against the masking in the handler(s), that's driver business. > the primary handler of that device with the appropriate flag set > (maybe an additional one to indicate the transition) and let that deal > with it. Needs some thought vs. locking and races, but that shouldn't > be hard. Yes, I thought about this kind of transition (re-invoking the existing handler) already. We do need notification of the switch (at least for exclusive->shared) as only the driver can migrate the masking for in-flight interrupts. Jan signature.asc Description: OpenPGP digital signature
[PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v4)
In certain use-cases, we want to allocate guests fixed time slices where idle
guest cycles leave the machine idling. There are many approaches to achieve
this but the most direct is to simply avoid trapping the HLT instruction which
lets the guest directly execute the instruction putting the processor to sleep.
Introduce this as a module-level option for kvm-vmx.ko since if you do this
for one guest, you probably want to do it for all.
Signed-off-by: Anthony Liguori
---
v4 -> v3
- Clear HLT on all interrupt/exception injection and set EIP to next
instruction
v3 -> v2
- Clear HLT activity state on exception injection to fix issue with async PF
v1 -> v2
- Rename parameter to yield_on_hlt
- Remove __read_mostly
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 42d9590..9642c22 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -297,6 +297,12 @@ enum vmcs_field {
#define GUEST_INTR_STATE_SMI 0x0004
#define GUEST_INTR_STATE_NMI 0x0008
+/* GUEST_ACTIVITY_STATE flags */
+#define GUEST_ACTIVITY_ACTIVE 0
+#define GUEST_ACTIVITY_HLT 1
+#define GUEST_ACTIVITY_SHUTDOWN2
+#define GUEST_ACTIVITY_WAIT_SIPI 3
+
/*
* Exit Qualifications for MOV for Control Register Access
*/
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index caa967e..4d84f0e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -69,6 +69,9 @@ module_param(emulate_invalid_guest_state, bool, S_IRUGO);
static int __read_mostly vmm_exclusive = 1;
module_param(vmm_exclusive, bool, S_IRUGO);
+static int yield_on_hlt = 1;
+module_param(yield_on_hlt, bool, S_IRUGO);
+
#define KVM_GUEST_CR0_MASK_UNRESTRICTED_GUEST \
(X86_CR0_WP | X86_CR0_NE | X86_CR0_NW | X86_CR0_CD)
#define KVM_GUEST_CR0_MASK \
@@ -1009,6 +1012,18 @@ static void skip_emulated_instruction(struct kvm_vcpu
*vcpu)
vmx_set_interrupt_shadow(vcpu, 0);
}
+static void vmx_clear_hlt(struct kvm_vcpu *vcpu)
+{
+ /* Ensure that we clear the HLT state in the VMCS and skip the
+* instruction if we inject an event that would end HLT. */
+ if (!yield_on_hlt &&
+ vmcs_read32(GUEST_ACTIVITY_STATE) == GUEST_ACTIVITY_HLT) {
+ vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE);
+ emulate_instruction(vcpu, 0, 0, EMULTYPE_SKIP);
+ vcpu->arch.halt_request = 0;
+ }
+}
+
static void vmx_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
bool has_error_code, u32 error_code,
bool reinject)
@@ -1035,6 +1050,7 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu,
unsigned nr,
intr_info |= INTR_TYPE_HARD_EXCEPTION;
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
+ vmx_clear_hlt(vcpu);
}
static bool vmx_rdtscp_supported(void)
@@ -1419,7 +1435,7 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf)
&_pin_based_exec_control) < 0)
return -EIO;
- min = CPU_BASED_HLT_EXITING |
+ min =
#ifdef CONFIG_X86_64
CPU_BASED_CR8_LOAD_EXITING |
CPU_BASED_CR8_STORE_EXITING |
@@ -1432,6 +1448,10 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf)
CPU_BASED_MWAIT_EXITING |
CPU_BASED_MONITOR_EXITING |
CPU_BASED_INVLPG_EXITING;
+
+ if (yield_on_hlt)
+ min |= CPU_BASED_HLT_EXITING;
+
opt = CPU_BASED_TPR_SHADOW |
CPU_BASED_USE_MSR_BITMAPS |
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
@@ -2728,7 +2748,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
vmcs_writel(GUEST_IDTR_BASE, 0);
vmcs_write32(GUEST_IDTR_LIMIT, 0x);
- vmcs_write32(GUEST_ACTIVITY_STATE, 0);
+ vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE);
vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, 0);
vmcs_write32(GUEST_PENDING_DBG_EXCEPTIONS, 0);
@@ -2821,6 +2841,7 @@ static void vmx_inject_irq(struct kvm_vcpu *vcpu)
} else
intr |= INTR_TYPE_EXT_INTR;
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr);
+ vmx_clear_hlt(vcpu);
}
static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
@@ -2848,6 +2869,7 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
}
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK | NMI_VECTOR);
+ vmx_clear_hlt(vcpu);
}
static int vmx_nmi_allowed(struct kvm_vcpu *vcpu)
--
1.7.0.4
--
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
Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices
Jan, On Sat, 4 Dec 2010, Jan Kiszka wrote: > Am 04.12.2010 11:37, Thomas Gleixner wrote: > > On Sat, 4 Dec 2010, Jan Kiszka wrote: > > If interrupt is shared, then you want to keep the current behaviour: > > > >disable at line level (IRQF_ONESHOT) > >run handler thread (PCI level masking) > >reenable at line level in irq_finalize_oneshot() > >reenable at PCI level when guest is done > > If the interrupt is shared, we must mask at PCI level inside the primary > handler as we also have to support non-threaded users of the same line. > So we always have a transition line-level -> device-level > masking in a primary handler. Sorry that left out the hard irq part. Of course it needs to do the PCI level masking in the primary one. > reduce the latency. So both threaded and non-threaded cases should be > addressable by any approach. The oneshot magic should work on non threaded cases as well. Needs some modifications, but nothing complex. > > If interrupts are in flight accross request/free then this change > > takes effect when the next interrupt comes in. > > For registration, that might be too late. We need to synchronize on > in-flight interrupts for that line and then ensure that it gets enabled > independently of the registered user. That user may have applied > outdated information, thus would block the line for too long if user > space decides to do something else. No, that's really just a corner case when going from one to two handlers and I don't think it matters much. If you setup a new driver it's not really important whether that first thing comes in a few ms later. Also there is a pretty simple solution for this: The core code knows, that there is an ONESHOT interrupt in flight, so it simply can call the primary handler of that device with the appropriate flag set (maybe an additional one to indicate the transition) and let that deal with it. Needs some thought vs. locking and races, but that shouldn't be hard. > Pulling the effect of disable_irq_nosync into genirq also for threaded > handling would remove the need for re-registering handlers. That's good. > But we need to think about the hand-over scenarios again. Maybe > solvable, but non-trivial. See above. Thanks, tglx -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)
On 12/04/2010 02:16 AM, Avi Kivity wrote: On 12/04/2010 12:42 AM, Anthony Liguori wrote: In v3, I set the activity state to ACTIVE if the state is currently HLT when injecting an exception into a guest. The effect is that after the exception is handled, if iret is executed, the hlt instruction will be restarted. The seems like the correct semantics to me. No, an interrupt causes the HLT to be executed, and rip advanced past it. You need to preserve this (both for interrupts and for the apf completion exception). Yeah, I see in the architecture manual it specifically calls out the rip advancing after NMI. It doesn't say anything about debug exceptions though. It's not clear to me if some exceptions cause hlt to be skipped and others not. But then again, skipping hlt seems to be the most conservative thing to do for all exceptions because it's always going to be run in a loop. Regards, Anthony Liguori -- 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
Re: [PATCH 2/2] Do not register kvmclock savevm section if kvmclock is disabled.
On 12/03/2010 11:49 AM, Glauber Costa wrote:
+/* This has to happen after vcpu setup*/
+void kvmclock_register_savevm(void)
+{
+#ifdef KVM_CAP_ADJUST_CLOCK
+if (kvmclock_enabled&& kvm_check_extension(kvm_state,
KVM_CAP_ADJUST_CLOCK)) {
+printf("registering kvmclock savevm section\n");
+vmstate_register(NULL, 0,&vmstate_kvmclock,&kvmclock_data);
+}
+#endif
+}
+
You should use a state change notifier for patch 1. Even better, if you
put this patch first adding the state change notifier will be very clean.
Paolo
--
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
Re: [PATCH 2/2] Do not register kvmclock savevm section if kvmclock is disabled.
On 12/03/2010 11:49 AM, Glauber Costa wrote:
+/* This has to happen after vcpu setup*/
+void kvmclock_register_savevm(void)
+{
+#ifdef KVM_CAP_ADJUST_CLOCK
+if (kvmclock_enabled&& kvm_check_extension(kvm_state,
KVM_CAP_ADJUST_CLOCK)) {
+printf("registering kvmclock savevm section\n");
+vmstate_register(NULL, 0,&vmstate_kvmclock,&kvmclock_data);
+}
+#endif
+}
+
You should use a state change notifier for patch 1. Even better, if you
put this patch first adding the state change notifier will be very clean.
Paolo
--
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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)
On 12/04/2010 02:13 AM, Avi Kivity wrote: On 12/04/2010 12:45 AM, Anthony Liguori wrote: hlt exiting doesn't leave vcpu in the halted state (since hlt has not been executed). So currently we never see a vcpu in halted state. Right, you mean the guest activity state being halt. My understanding is that it just needs to be cleared on exception injection. Would could clear it at every vmentry but that would introduce a vmcs_read() to the fast path which is undesirable. Also need to skip the hlt instruction (by calling the emulator for example). I wasn't sure about this. Don't you want EIP to point to the beginning of the instruction such that the exception will cause the instruction to restart? Regards, Anthony Liguori -- 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
Re: [RFC PATCH 2/3] sched: add yield_to function
On 12/03/2010 04:23 PM, Peter Zijlstra wrote: On Fri, 2010-12-03 at 19:40 +0530, Srivatsa Vaddagiri wrote: On Fri, Dec 03, 2010 at 07:36:07PM +0530, Srivatsa Vaddagiri wrote: On Fri, Dec 03, 2010 at 03:03:30PM +0100, Peter Zijlstra wrote: No, because they do receive service (they spend some time spinning before being interrupted), so the respective vruntimes will increase, at some point they'll pass B0 and it'll get scheduled. Is that sufficient to ensure that B0 receives its fair share (1/3 cpu in this case)? Hmm perhaps yes, althought at cost of tons of context switches, which would be nice to minimize on? Don't care, as long as the guys calling yield_to() pay for that time its their problem. Also, the context switches are cheaper than spinning entire time slices on spinlocks we're not going to get (because the VCPU holding the lock is not running). -- All rights reversed -- 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
Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices
Am 04.12.2010 11:37, Thomas Gleixner wrote: > On Sat, 4 Dec 2010, Jan Kiszka wrote: > >> Besides 3 cleanup patches, this series consists of two major changes. >> The first introduces an interrupt sharing notifier to the genirq >> subsystem. It fires when an interrupt line is about to be use by more >> than one driver or the last but one user called free_irq. >> >> The second major change makes use of this interface in KVM's PCI pass- >> through subsystem. KVM has to keep the interrupt source disabled while >> calling into the guest to handle the event. This can be done at device >> or line level. The former is required to share the interrupt line, the >> latter is an order of magnitude faster (see patch 3 for details). >> >> Beside pass-through support of KVM, further users of the IRQ notifier >> could become VFIO (not yet mainline) and uio_pci_generic which have to >> resolve the same conflict. > > Hmm. You basically want to have the following functionality: > > If interrupt is shared, then you want to keep the current behaviour: > >disable at line level (IRQF_ONESHOT) >run handler thread (PCI level masking) >reenable at line level in irq_finalize_oneshot() >reenable at PCI level when guest is done If the interrupt is shared, we must mask at PCI level inside the primary handler as we also have to support non-threaded users of the same line. So we always have a transition line-level -> device-level masking in a primary handler. > > If interrupt is not shared: > >disable at line level (IRQF_ONESHOT) >run handler thread (no PCI level masking) >no reenable at line level >reenable at line level when guest is done We only use threaded handlers so far for hairy lock-dependency reasons and as certain injection complexity is too much guest-controllable. We hope to move most injection cases (ie. any IRQ directed to a single VCPU / user space task) directly into a primary handler in the future to reduce the latency. So both threaded and non-threaded cases should be addressable by any approach. > > I think the whole notifier approach including the extra irq handlers > plus the requirement to call disable_irq_nosync() from the non shared > handler is overkill. We can be more clever. Always welcome. > > The genirq code knows whether you have one or more handler > registered. So we can add IRQF_ONESHOT_UNMASK_SHARED and add a status > field to irq_data (which I was going to do anyway for other > reasons). In that status field you get a bit which says IRQ_MASK_DEVICE. > > So with IRQF_ONESHOT_UNMASK_SHARED == 0 we keep the current behaviour. > > If IRQF_ONESHOT_UNMASK_SHARED== 1 and IRQ_MASK_DEVICE == 1 we keep the > current behaviour. > > If IRQF_ONESHOT_UNMASK_SHARED== 1 and IRQ_MASK_DEVICE == 0 then then > irq_finalize_oneshot() simply marks the interrupt disabled (equivalent > to disable_irq_nosync()) and returns. That sounds good. > > Now in your primary irq handler you simply check the IRQ_MASK_DEVICE > status flag and decide whether you need to mask at PCI level or not. > > Your threaded handler gets the same information via IRQ_MASK_DEVICE so > it can issue the appropriate user space notification depending on that > flag. > > This works fully transparent across adding and removing handlers. On > request_irq/free_irq we update the IRQ_MASK_DEVICE flag with the > following logic: > > nr_actionsIRQF_ONESHOT_UNMASK_SHARED IRQ_MASK_DEVICE > 1 0 1 > 1 1 0 > >1don't care 1 > > If interrupts are in flight accross request/free then this change > takes effect when the next interrupt comes in. For registration, that might be too late. We need to synchronize on in-flight interrupts for that line and then ensure that it gets enabled independently of the registered user. That user may have applied outdated information, thus would block the line for too long if user space decides to do something else. I think this will be the trickier part of the otherwise nice & simple concept. > > No notifiers, no disable_irq_nosync() magic, less and simpler code. > > Thoughts ? Pulling the effect of disable_irq_nosync into genirq also for threaded handling would remove the need for re-registering handlers. That's good. But we need to think about the hand-over scenarios again. Maybe solvable, but non-trivial. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices
On Sat, 4 Dec 2010, Jan Kiszka wrote: > Besides 3 cleanup patches, this series consists of two major changes. > The first introduces an interrupt sharing notifier to the genirq > subsystem. It fires when an interrupt line is about to be use by more > than one driver or the last but one user called free_irq. > > The second major change makes use of this interface in KVM's PCI pass- > through subsystem. KVM has to keep the interrupt source disabled while > calling into the guest to handle the event. This can be done at device > or line level. The former is required to share the interrupt line, the > latter is an order of magnitude faster (see patch 3 for details). > > Beside pass-through support of KVM, further users of the IRQ notifier > could become VFIO (not yet mainline) and uio_pci_generic which have to > resolve the same conflict. Hmm. You basically want to have the following functionality: If interrupt is shared, then you want to keep the current behaviour: disable at line level (IRQF_ONESHOT) run handler thread (PCI level masking) reenable at line level in irq_finalize_oneshot() reenable at PCI level when guest is done If interrupt is not shared: disable at line level (IRQF_ONESHOT) run handler thread (no PCI level masking) no reenable at line level reenable at line level when guest is done I think the whole notifier approach including the extra irq handlers plus the requirement to call disable_irq_nosync() from the non shared handler is overkill. We can be more clever. The genirq code knows whether you have one or more handler registered. So we can add IRQF_ONESHOT_UNMASK_SHARED and add a status field to irq_data (which I was going to do anyway for other reasons). In that status field you get a bit which says IRQ_MASK_DEVICE. So with IRQF_ONESHOT_UNMASK_SHARED == 0 we keep the current behaviour. If IRQF_ONESHOT_UNMASK_SHARED== 1 and IRQ_MASK_DEVICE == 1 we keep the current behaviour. If IRQF_ONESHOT_UNMASK_SHARED== 1 and IRQ_MASK_DEVICE == 0 then then irq_finalize_oneshot() simply marks the interrupt disabled (equivalent to disable_irq_nosync()) and returns. Now in your primary irq handler you simply check the IRQ_MASK_DEVICE status flag and decide whether you need to mask at PCI level or not. Your threaded handler gets the same information via IRQ_MASK_DEVICE so it can issue the appropriate user space notification depending on that flag. This works fully transparent across adding and removing handlers. On request_irq/free_irq we update the IRQ_MASK_DEVICE flag with the following logic: nr_actions IRQF_ONESHOT_UNMASK_SHARED IRQ_MASK_DEVICE 1 0 1 1 1 0 >1 don't care 1 If interrupts are in flight accross request/free then this change takes effect when the next interrupt comes in. No notifiers, no disable_irq_nosync() magic, less and simpler code. Thoughts ? tglx -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v3)
On Fri, Dec 03, 2010 at 05:38:06PM -0600, Anthony Liguori wrote: > On 12/03/2010 05:32 PM, Joerg Roedel wrote: >> On Fri, Dec 03, 2010 at 04:39:22PM -0600, Anthony Liguori wrote: >> >>> + if (yield_on_hlt) >>> + min |= CPU_BASED_HLT_EXITING; >>> >> This approach won't work out on AMD because in HLT the CPU may enter >> C1e. In C1e the local apic timer interupt is not delivered anymore and >> when this is the current timer in use the cpu may miss timer ticks or >> never comes out of HLT again. The guest has no chance to work around >> this as the Linux idle routine does. >> > > And this doesn't break old software on bare metal? Yes it does. In fact, this behavior is documented as Erratum 400 for AMD CPUs. Linux has a workaround for it for quite some time. You can have a look at the c1e_idle routine for details. C1e can also be disabled by the OS. But there are BIOSes which re-enable it in SMI. So there is the chance that it gets re-enabled whithout an vmexit. Joerg -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)
On 12/03/2010 08:12 PM, Srivatsa Vaddagiri wrote: On Fri, Dec 03, 2010 at 12:07:15PM -0600, Anthony Liguori wrote: > My first reaction is that it's not terribly important to account the > non-idle time in the guest because of the use-case for this model. Agreed ...but I was considering the larger user-base who may be surprised to see their VMs being reported as 100% hogs when they had left it idle. The larger user base won't enable this option. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)
On 12/03/2010 07:33 PM, Srivatsa Vaddagiri wrote: On Fri, Dec 03, 2010 at 09:29:06AM -0800, Chris Wright wrote: > That's what Marcelo's suggestion does w/out a fill thread. Are we willing to add that to KVM sources? I'd rather avoid it. I was working under the constraints of not modifying the kernel (especially avoid adding short term hacks that become unnecessary in longer run, in this case when kernel-based hard limits goes in). Yes. Allowing the guest to execute HLT is fine, but adding scheduling smarts to kvm is something else. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)
On 12/04/2010 12:42 AM, Anthony Liguori wrote: In v3, I set the activity state to ACTIVE if the state is currently HLT when injecting an exception into a guest. The effect is that after the exception is handled, if iret is executed, the hlt instruction will be restarted. The seems like the correct semantics to me. No, an interrupt causes the HLT to be executed, and rip advanced past it. You need to preserve this (both for interrupts and for the apf completion exception). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)
On 12/04/2010 12:45 AM, Anthony Liguori wrote: hlt exiting doesn't leave vcpu in the halted state (since hlt has not been executed). So currently we never see a vcpu in halted state. Right, you mean the guest activity state being halt. My understanding is that it just needs to be cleared on exception injection. Would could clear it at every vmentry but that would introduce a vmcs_read() to the fast path which is undesirable. Also need to skip the hlt instruction (by calling the emulator for example). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [PATCH 07/15] ftrace: fix event alignment: kvm:kvm_hv_hypercall
On 12/04/2010 02:13 AM, David Sharp wrote: Signed-off-by: David Sharp --- arch/x86/kvm/trace.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h index a6544b8..ab41fb0 100644 --- a/arch/x86/kvm/trace.h +++ b/arch/x86/kvm/trace.h @@ -62,21 +62,21 @@ TRACE_EVENT(kvm_hv_hypercall, TP_ARGS(code, fast, rep_cnt, rep_idx, ingpa, outgpa), TP_STRUCT__entry( - __field(__u16, code) - __field(bool, fast) __field(__u16, rep_cnt ) __field(__u16, rep_idx ) __field(__u64, ingpa ) __field(__u64, outgpa ) + __field(__u16, code) + __field(bool, fast) ), Looks like a pessimisation. Before: 24 bytes After: 32 bytes (on a 64-bit machine, assuming no packing) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
