Re: [PATCH V2] Documentation/kvm: Update cpuid documentation for steal time and pv eoi
On Wed, Sep 04, 2013 at 02:18:46PM +0530, Raghavendra K T wrote: > Signed-off-by: Raghavendra K T > --- > Changes in V2: > Correction in the description of steal time and added msr info (Michael S > Tsirkin) Thanks. Some comments below: > Documentation/virtual/kvm/cpuid.txt | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/virtual/kvm/cpuid.txt > b/Documentation/virtual/kvm/cpuid.txt > index 22ff659..6c4fb20 100644 > --- a/Documentation/virtual/kvm/cpuid.txt > +++ b/Documentation/virtual/kvm/cpuid.txt > @@ -43,6 +43,16 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock > available at msrs > KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by > || || writing to msr 0x4b564d02 > > -- > +KVM_FEATURE_STEAL_TIME || 5 || Steal time available at msr > + || || 0x4b564d03. The feature is > enabled > + || || by guest when host has > schedstat > + || || or task delay accounting > support. Well I think we really should be documenting the host/guest interface here. After all it starts out A guest running on a kvm host, can check some of its features using cpuid. And guests really should not try to guess whether host has schedstat or task delay accounting support based on this bit. So I would just say: "steal time can be enabled by writing to msr 0x4b564d02" just like async pf. > +-- > +KVM_FEATURE_PV_EOI || 6 || overrides the generic EOI > + || || implementation with a > + || || paravirtualized version. > Available > + || || at msr 0x4b564d04. Actually there's no override: guest can still use the standard EOI even if PV EOI MSR is enabled. There's a detailed explanation of PV EOI in Documentation/virtual/kvm/msr.txt I think the following would be enough: "paravirtualized end of interrupt handler can be enabled by writing to msr 0x4b564d04" > +-- > KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit > || || before enabling > paravirtualized > || || spinlock support. > -- > 1.7.11.7 -- 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
[PATCH] KVM: IRQFD: equip irqfd and resamplefd with polarity
Nowadays, irqfd can emulate trigger mode, but it can not emulate
trigger polarity. While in some cases, ioapic ioredtbl[x] expects
_low_ active. So equipping irqfd with the ability. Correspondingly,
resamplefd will have the same polarity as irqfd.
Signed-off-by: Liu Ping Fan
---
This helps to step around making the interrupt component re-entrance
in qemu
---
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 2 ++
virt/kvm/eventfd.c | 32 ++--
3 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a63d83e..0b8c3b1 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -678,6 +678,7 @@ bool kvm_is_mmio_pfn(pfn_t pfn);
struct kvm_irq_ack_notifier {
struct hlist_node link;
unsigned gsi;
+ int polarity; /* 0 high active */
void (*irq_acked)(struct kvm_irq_ack_notifier *kian);
};
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index acccd08..bba3a1b 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -740,6 +740,8 @@ struct kvm_xen_hvm_config {
* emlation. See Documentation/virtual/kvm/api.txt.
*/
#define KVM_IRQFD_FLAG_RESAMPLE (1 << 1)
+/* 0: high-active */
+#define KVM_IRQFD_FLAG_POLARITY (1<<2)
struct kvm_irqfd {
__u32 fd;
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 1550637..865c656 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -77,6 +77,7 @@ struct _irqfd {
struct kvm_kernel_irq_routing_entry __rcu *irq_entry;
/* Used for level IRQ fast-path */
int gsi;
+ int polarity; /* 0 high active */
struct work_struct inject;
/* The resampler used by this irqfd (resampler-only) */
struct _irqfd_resampler *resampler;
@@ -100,13 +101,13 @@ irqfd_inject(struct work_struct *work)
struct kvm *kvm = irqfd->kvm;
if (!irqfd->resampler) {
- kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
- false);
- kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
- false);
+ kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi,
+ !irqfd->polarity, false);
+ kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi,
+ !!irqfd->polarity, false);
} else
kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
- irqfd->gsi, 1, false);
+ irqfd->gsi, !irqfd->polarity, false);
}
/*
@@ -123,7 +124,8 @@ irqfd_resampler_ack(struct kvm_irq_ack_notifier *kian)
resampler = container_of(kian, struct _irqfd_resampler, notifier);
kvm_set_irq(resampler->kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
- resampler->notifier.gsi, 0, false);
+ resampler->notifier.gsi,
+ !!resampler->notifier.polarity, false);
rcu_read_lock();
@@ -148,7 +150,7 @@ irqfd_resampler_shutdown(struct _irqfd *irqfd)
list_del(&resampler->link);
kvm_unregister_irq_ack_notifier(kvm, &resampler->notifier);
kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
- resampler->notifier.gsi, 0, false);
+ resampler->notifier.gsi, !!irqfd->polarity, false);
kfree(resampler);
}
@@ -302,6 +304,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
irqfd->kvm = kvm;
irqfd->gsi = args->gsi;
+ irqfd->polarity = !!(args->flags & KVM_IRQFD_FLAG_POLARITY);
INIT_LIST_HEAD(&irqfd->list);
INIT_WORK(&irqfd->inject, irqfd_inject);
INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
@@ -337,8 +340,15 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
list_for_each_entry(resampler,
&kvm->irqfds.resampler_list, link) {
if (resampler->notifier.gsi == irqfd->gsi) {
- irqfd->resampler = resampler;
- break;
+ if (likely(resampler->notifier.polarity ==
+ irqfd->polarity)) {
+ irqfd->resampler = resampler;
+ break;
+ } else {
+ ret = -EBUSY;
+
mutex_unlock(&kvm->irqfds.resampler_lock);
+ goto fail;
+ }
}
}
@@ -353,6 +363,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
resampler->kvm = kvm;
INIT_LIST_HEAD(&resampler->list);
Re: [PATCH V2] Documentation/kvm: Update cpuid documentation for steal time and pv eoi
On 09/04/2013 02:18 PM, Raghavendra K T wrote: Signed-off-by: Raghavendra K T --- Changes in V2: Correction in the description of steal time and added msr info (Michael S Tsirkin) Documentation/virtual/kvm/cpuid.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 22ff659..6c4fb20 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -43,6 +43,16 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by || || writing to msr 0x4b564d02 -- +KVM_FEATURE_STEAL_TIME || 5 || Steal time available at msr + || || 0x4b564d03. The feature is enabled + || || by guest when host has schedstat + || || or task delay accounting support. +-- +KVM_FEATURE_PV_EOI || 6 || overrides the generic EOI + || || implementation with a + || || paravirtualized version. Available + || || at msr 0x4b564d04. +-- KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit || || before enabling paravirtualized || || spinlock support. Michael, Are you okay with the above patch. Please let me know. -- 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] ARM: kvm: rename cpu_reset to avoid name clash
On Wed, Sep 11, 2013 at 03:39:26PM -0700, Olof Johansson wrote: > On Wed, Sep 11, 2013 at 3:27 PM, Olof Johansson wrote: > > cpu_reset is already #defined in as processor.reset, > > so it expands here and causes problems. > > > > Signed-off-by: Olof Johansson > > I just noticed this is broken on 3.10 too, so if/when applying feel free to > add: > > Cc: # 3.10+ > Thanks for the fix, applied. -Christoffer -- 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] ARM: kvm: rename cpu_reset to avoid name clash
On Wed, Sep 11, 2013 at 3:27 PM, Olof Johansson wrote: > cpu_reset is already #defined in as processor.reset, > so it expands here and causes problems. > > Signed-off-by: Olof Johansson I just noticed this is broken on 3.10 too, so if/when applying feel free to add: Cc: # 3.10+ -Olof -- 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
[PATCH] ARM: kvm: rename cpu_reset to avoid name clash
cpu_reset is already #defined in as processor.reset,
so it expands here and causes problems.
Signed-off-by: Olof Johansson
---
arch/arm/kvm/reset.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index 71e08ba..c02ba4a 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -58,14 +58,14 @@ static const struct kvm_irq_level a15_vtimer_irq = {
*/
int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
- struct kvm_regs *cpu_reset;
+ struct kvm_regs *reset_regs;
const struct kvm_irq_level *cpu_vtimer_irq;
switch (vcpu->arch.target) {
case KVM_ARM_TARGET_CORTEX_A15:
if (vcpu->vcpu_id > a15_max_cpu_idx)
return -EINVAL;
- cpu_reset = &a15_regs_reset;
+ reset_regs = &a15_regs_reset;
vcpu->arch.midr = read_cpuid_id();
cpu_vtimer_irq = &a15_vtimer_irq;
break;
@@ -74,7 +74,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
}
/* Reset core registers */
- memcpy(&vcpu->arch.regs, cpu_reset, sizeof(vcpu->arch.regs));
+ memcpy(&vcpu->arch.regs, reset_regs, sizeof(vcpu->arch.regs));
/* Reset CP15 registers */
kvm_reset_coprocs(vcpu);
--
1.7.10.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: [libvirt-users] Questions on how to reset ID numbers for virt Guests.
On 09/11/2013 01:59 AM, Daniel P. Berrange wrote: > On Wed, Sep 11, 2013 at 09:47:07AM +0200, Paolo Bonzini wrote: >> Il 11/09/2013 00:27, James Sparenberg ha scritto: >>> I'm doing some experimenting in our Development lab and as a result >>> I'm kickstarting over and over Virtual guests. This is of course >>> causing the guest Id to increment by one with each test. I've >>> googled around and tried searching the list but have not found out >>> how (if at all) it would be possible to reset the ID number back to 1 >>> more than is in use. Also is there a limit where I run out of ID's? >>> (for example does it only go up to 99?) >> >> No, there is no limit. > > Well, 'int' will wrap eventually, but you'd need to have created > a hell of alot of guests for that to be a problem :-) 2**31 (~2 billion), to be exact, since we store it as a signed int, and I'm not sure if all the code paths handle a negative number gracefully (see src/datatypes.h:_virDomain). (Maybe we should have picked a 64-bit type, so that wraparound would not be possible within our lifetimes even with a process spawning guests as fast as possible on current computers - but even with a 32-bit number, it's going to take a lot of hammering to hit wraparound) -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [libvirt-users] Questions on how to reset ID numbers for virt Guests.
Ok. and trust me right now it feels like my experiments will hit the wrap number ;). As for the other part. Thanks, now when my boss takes a look and panics I've got an answer. ;) I really appreciate the help. James Sparenberg Sys Admin III Linux Vudu Inc a Walmart Company On 09/11/2013 12:59 AM, Daniel P. Berrange wrote: On Wed, Sep 11, 2013 at 09:47:07AM +0200, Paolo Bonzini wrote: Il 11/09/2013 00:27, James Sparenberg ha scritto: I'm doing some experimenting in our Development lab and as a result I'm kickstarting over and over Virtual guests. This is of course causing the guest Id to increment by one with each test. I've googled around and tried searching the list but have not found out how (if at all) it would be possible to reset the ID number back to 1 more than is in use. Also is there a limit where I run out of ID's? (for example does it only go up to 99?) No, there is no limit. Well, 'int' will wrap eventually, but you'd need to have created a hell of alot of guests for that to be a problem :-) I don't know the answer to your other question, so I'm adding the libvirt-users mailing list. If you restart libvirtd, it reset itself to start allocating IDs at the max current used ID of any running guest. Daniel
[PATCH v3 2/3] kvm tools: remove periodic tick in favour of a polling thread
Currently the only use of the periodic timer tick in kvmtool is to
handle reading from stdin. Though functional, this periodic tick can be
problematic on slow (eg FPGA) platforms and can cause low interactivity or
even stop the execution from progressing at all.
This patch removes the periodic tick in favour of a dedicated thread blocked
waiting for input from the console. In order to reflect the new behaviour,
the old 'kvm__arch_periodic_tick' function is renamed to 'kvm__arch_read_term'.
In making this change it is necessary to actively flush the emulated serial
console's output buffer after the guest writes to it, as otherwise flushing
only happens with terminal input. Similarly, it is no longer necessary to
flush the buffer when we process input.
Signed-off-by: Jonathan Austin
Acked-by: Marc Zyngier
---
tools/kvm/arm/kvm.c |2 +-
tools/kvm/builtin-run.c | 13 ---
tools/kvm/hw/serial.c | 10 +
tools/kvm/include/kvm/kvm.h |2 +-
tools/kvm/kvm.c | 50 ---
tools/kvm/powerpc/kvm.c |2 +-
tools/kvm/term.c| 31 +++
tools/kvm/x86/kvm.c |2 +-
8 files changed, 36 insertions(+), 76 deletions(-)
diff --git a/tools/kvm/arm/kvm.c b/tools/kvm/arm/kvm.c
index 27e6cf4..008b7fe 100644
--- a/tools/kvm/arm/kvm.c
+++ b/tools/kvm/arm/kvm.c
@@ -46,7 +46,7 @@ void kvm__arch_delete_ram(struct kvm *kvm)
munmap(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size);
}
-void kvm__arch_periodic_poll(struct kvm *kvm)
+void kvm__arch_read_term(struct kvm *kvm)
{
if (term_readable(0)) {
serial8250__update_consoles(kvm);
diff --git a/tools/kvm/builtin-run.c b/tools/kvm/builtin-run.c
index 4d7fbf9d..da95d71 100644
--- a/tools/kvm/builtin-run.c
+++ b/tools/kvm/builtin-run.c
@@ -165,13 +165,6 @@ void kvm_run_set_wrapper_sandbox(void)
OPT_END() \
};
-static void handle_sigalrm(int sig, siginfo_t *si, void *uc)
-{
- struct kvm *kvm = si->si_value.sival_ptr;
-
- kvm__arch_periodic_poll(kvm);
-}
-
static void *kvm_cpu_thread(void *arg)
{
char name[16];
@@ -487,17 +480,11 @@ static struct kvm *kvm_cmd_run_init(int argc, const char
**argv)
{
static char real_cmdline[2048], default_name[20];
unsigned int nr_online_cpus;
- struct sigaction sa;
struct kvm *kvm = kvm__new();
if (IS_ERR(kvm))
return kvm;
- sa.sa_flags = SA_SIGINFO;
- sa.sa_sigaction = handle_sigalrm;
- sigemptyset(&sa.sa_mask);
- sigaction(SIGALRM, &sa, NULL);
-
nr_online_cpus = sysconf(_SC_NPROCESSORS_ONLN);
kvm->cfg.custom_rootfs_name = "default";
diff --git a/tools/kvm/hw/serial.c b/tools/kvm/hw/serial.c
index 931067f..3b5540c 100644
--- a/tools/kvm/hw/serial.c
+++ b/tools/kvm/hw/serial.c
@@ -169,15 +169,6 @@ static void serial8250__receive(struct kvm *kvm, struct
serial8250_device *dev,
{
int c;
- /*
-* If the guest transmitted a full fifo, we clear the
-* TEMT/THRE bits to let the kernel escape from the 8250
-* interrupt handler. We come here only once a ms, so that
-* should give the kernel the desired pause. That also flushes
-* the tx fifo to the terminal.
-*/
- serial8250_flush_tx(kvm, dev);
-
if (dev->mcr & UART_MCR_LOOP)
return;
@@ -260,6 +251,7 @@ static bool serial8250_out(struct ioport *ioport, struct
kvm *kvm, u16 port,
dev->lsr &= ~UART_LSR_TEMT;
if (dev->txcnt == FIFO_LEN / 2)
dev->lsr &= ~UART_LSR_THRE;
+ serial8250_flush_tx(kvm, dev);
} else {
/* Should never happpen */
dev->lsr &= ~(UART_LSR_TEMT | UART_LSR_THRE);
diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index ad53ca7..d05b936 100644
--- a/tools/kvm/include/kvm/kvm.h
+++ b/tools/kvm/include/kvm/kvm.h
@@ -103,7 +103,7 @@ void kvm__arch_delete_ram(struct kvm *kvm);
int kvm__arch_setup_firmware(struct kvm *kvm);
int kvm__arch_free_firmware(struct kvm *kvm);
bool kvm__arch_cpu_supports_vm(void);
-void kvm__arch_periodic_poll(struct kvm *kvm);
+void kvm__arch_read_term(struct kvm *kvm);
void *guest_flat_to_host(struct kvm *kvm, u64 offset);
u64 host_to_guest_flat(struct kvm *kvm, void *ptr);
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index cfd30dd..d7d2e84 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -393,56 +393,6 @@ found_kernel:
return ret;
}
-#define TIMER_INTERVAL_NS 100 /* 1 msec */
-
-/*
- * This function sets up a timer that's used to inject interrupts from the
- * userspace hypervisor into the guest at periodical intervals. Please note
- * that clock interrupt, for example, is not handled he
[PATCH v3 3/3] kvm tools: stop virtio console doing unnecessary input handling
The asynchronous nature of the virtio input handling (using a job queue)
can result in unnecessary jobs being created if there is some delay in
handing input (the original function to handle the input returns immediately
without the file having been read, and hence poll returns immediately
informing us of data to read).
This patch adds synchronisation to the threads so that we don't start
polling input files again until we've read from the console.
Signed-off-by: Jonathan Austin
Acked-by: Marc Zyngier
---
tools/kvm/virtio/console.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index 83c58bf..f982dab7 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -36,12 +36,17 @@ struct con_dev {
struct virtio_console_configconfig;
u32 features;
+ pthread_cond_t poll_cond;
+ int vq_ready;
+
struct thread_pool__job jobs[VIRTIO_CONSOLE_NUM_QUEUES];
};
static struct con_dev cdev = {
.mutex = MUTEX_INITIALIZER,
+ .vq_ready = 0,
+
.config = {
.cols = 80,
.rows = 24,
@@ -69,6 +74,9 @@ static void virtio_console__inject_interrupt_callback(struct
kvm *kvm, void *par
vq = param;
+ if (!cdev.vq_ready)
+ pthread_cond_wait(&cdev.poll_cond, &cdev.mutex.mutex);
+
if (term_readable(0) && virt_queue__available(vq)) {
head = virt_queue__get_iov(vq, iov, &out, &in, kvm);
len = term_getc_iov(kvm, iov, in, 0);
@@ -81,7 +89,8 @@ static void virtio_console__inject_interrupt_callback(struct
kvm *kvm, void *par
void virtio_console__inject_interrupt(struct kvm *kvm)
{
- thread_pool__do_job(&cdev.jobs[VIRTIO_CONSOLE_RX_QUEUE]);
+ virtio_console__inject_interrupt_callback(kvm,
+ &cdev.vqs[VIRTIO_CONSOLE_RX_QUEUE]);
}
static void virtio_console_handle_callback(struct kvm *kvm, void *param)
@@ -141,10 +150,16 @@ static int init_vq(struct kvm *kvm, void *dev, u32 vq,
u32 page_size, u32 align,
vring_init(&queue->vring, VIRTIO_CONSOLE_QUEUE_SIZE, p, align);
- if (vq == VIRTIO_CONSOLE_TX_QUEUE)
+ if (vq == VIRTIO_CONSOLE_TX_QUEUE) {
thread_pool__init_job(&cdev.jobs[vq], kvm,
virtio_console_handle_callback, queue);
- else if (vq == VIRTIO_CONSOLE_RX_QUEUE)
+ } else if (vq == VIRTIO_CONSOLE_RX_QUEUE) {
thread_pool__init_job(&cdev.jobs[vq], kvm,
virtio_console__inject_interrupt_callback, queue);
+ /* Tell the waiting poll thread that we're ready to go */
+ mutex_lock(&cdev.mutex);
+ cdev.vq_ready = 1;
+ pthread_cond_signal(&cdev.poll_cond);
+ mutex_unlock(&cdev.mutex);
+ }
return 0;
}
@@ -192,6 +207,8 @@ int virtio_console__init(struct kvm *kvm)
if (kvm->cfg.active_console != CONSOLE_VIRTIO)
return 0;
+ pthread_cond_init(&cdev.poll_cond, NULL);
+
virtio_init(kvm, &cdev, &cdev.vdev, &con_dev_virtio_ops,
VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_CONSOLE,
VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
--
1.7.9.5
--
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
[PATCH v3 1/3] kvm tools: use #define for maximum number of terminal devices
Though there may be no near-term plans to change the number of terminal
devices in the future, using TERM_MAX_DEVS instead of '4' makes reading
some of the loops over terminal devices clearer.
This patch makes the this substitution where required.
Signed-off-by: Jonathan Austin
Acked-by: Marc Zyngier
---
tools/kvm/term.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/term.c b/tools/kvm/term.c
index fa85e4a..ac9c7cc 100644
--- a/tools/kvm/term.c
+++ b/tools/kvm/term.c
@@ -16,13 +16,14 @@
#define TERM_FD_IN 0
#define TERM_FD_OUT 1
+#define TERM_MAX_DEVS 4
static struct termios orig_term;
int term_escape_char = 0x01; /* ctrl-a is used for escape */
bool term_got_escape = false;
-int term_fds[4][2];
+int term_fds[TERM_MAX_DEVS][2];
int term_getc(struct kvm *kvm, int term)
{
@@ -94,7 +95,7 @@ static void term_cleanup(void)
{
int i;
- for (i = 0; i < 4; i++)
+ for (i = 0; i < TERM_MAX_DEVS; i++)
tcsetattr(term_fds[i][TERM_FD_IN], TCSANOW, &orig_term);
}
@@ -140,7 +141,7 @@ int term_init(struct kvm *kvm)
struct termios term;
int i, r;
- for (i = 0; i < 4; i++)
+ for (i = 0; i < TERM_MAX_DEVS; i++)
if (term_fds[i][TERM_FD_IN] == 0) {
term_fds[i][TERM_FD_IN] = STDIN_FILENO;
term_fds[i][TERM_FD_OUT] = STDOUT_FILENO;
--
1.7.9.5
--
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
[PATCH v3 0/3] kvm tools: remove periodic tick
This patch series removes kvm tool's periodic tick function in favour of a thread that blocks waiting for input. The paths used for handling input are the same as when using a periodic tick, but they're not called unless there is actually input to be processed. On extremely slow platforms (eg FPGAs) the overhead involved in handling the timer tick means it is possible to make progress at all inside the VM! This patch addresses this problem. In doing this there are a number of small tidyups/cleanups that made sense, too: - Use a #define for maximum number of term devices - Refactor the method by which the virtio console handles input in order not to - handle input too early - handle input multiple times if the worker thread didn't immediately start work. - Rename the periodic_poll function to reflect the functional change --- Changes since V1: - s/kvm__arm_read_term/kvm__arch_read_term/ in patch2's coverletter - make term_poll_thread static - Added Marc's ack Changes since V2: - force the flushing of the tx queue for serial console emulation - test that this doesn't degrade performance considerably Jonathan Austin (3): kvm tools: use #define for maximum number of terminal devices kvm tools: remove periodic tick in favour of a polling thread kvm tools: stop virtio console doing unnecessary input handling tools/kvm/arm/kvm.c |2 +- tools/kvm/builtin-run.c | 13 --- tools/kvm/hw/serial.c | 10 + tools/kvm/include/kvm/kvm.h |2 +- tools/kvm/kvm.c | 50 --- tools/kvm/powerpc/kvm.c |2 +- tools/kvm/term.c| 38 +--- tools/kvm/virtio/console.c | 23 +--- tools/kvm/x86/kvm.c |2 +- 9 files changed, 60 insertions(+), 82 deletions(-) -- 1.7.9.5 -- 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: 2nd level lockups using VMX nesting on 3.11 based host kernel
Il 10/09/2013 09:52, Stefan Bader ha scritto: > On 03.09.2013 20:13, Gleb Natapov wrote: >> On Tue, Sep 03, 2013 at 03:19:27PM +0200, Stefan Bader wrote: >>> With current 3.11 kernels we got reports of nested qemu failing >>> in weird ways. I believe 3.10 also had issues before. Not sure >>> whether those were the same. With 3.8 based kernels (close to >>> current stable) I found no such issues. >> Try to bisect it. > > It took a while to bisect. Though I am not sure this helps much. > Starting from v3.9, the first broken commit is: > > commit 5f3d5799974b89100268ba813cec8db7bd0693fb KVM: nVMX: Rework > event injection and recovery > > This sounds reasonable as this changes event injection between > nested levels. However starting with this patch I am unable to > start any second level guest. Very soon after the second level > guest starts, the first (and by that the second level as well) lock > up completely without any visible messages. > > This goes on until > > commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6 KVM: nVMX: Skip PF > interception check when queuing during nested run I'm not sure I'm seeing the same issue as you, but it is similar enough to point out. Nested virtualization is completely broken with shadow paging on the host even before commit 5f3d5799974b89100268ba813cec8db7bd0693fb. Whether it works probably depends on the combination of host and guest kernels; I am constantly using 3.10 in the guest. It is very reproducible, my testcase is x86/realmode.flat from kvm-unit-tests. There are several problems, some of which were fixed along the way. I bisected while doing this: - apply patch 63fbf59 (nVMX: reset rflags register cache during nested vmentry., 2013-07-28) - use the emulate_invalid_guest_state=0 argument to kvm-intel. This is fixed somewhere between commit 5f3d579 and commit 205befd (KVM: nVMX: correctly set tr base on nested vmexit emulation, 2013-08-04); I haven't bisected it fully, but it should not be necessary. The resulting faulty patch is the same as yours. The symptoms are the same for all three cases: - commit 5f3d579 + patch 63fbf59 + emulate_invalid_guest_state=0 - commit 205befd + emulate_invalid_guest_state=0 - commit 205befd + emulate_invalid_guest_state=1 My first impression is that a pagefault is injected erroneously, will look more at it tomorrow. Paolo > In between there was also a period where first level did not lock > up but would either seem not to schedule the second level guest or > displayed internal error messages from starting the second level. > > Given that it sounds like the current double faults in second level > might be one of the issues introduced by the injection rework that > remains until now while other issues were fixed from the second > commit on. > > I am not really deeply familiar with the nVMX code, just trying to > make sense of observations. The double fault always seems to > originate from the cmos_interrupt function in the second level > guest. It is not immediate and sometimes took several repeated runs > to trigger (during bisect I would require 10 successful test runs > before marking it good). So could it maybe be some event / > interrupt (cmos related?) that accidentally gets injected into the > wrong guest level? Or maybe the same event taking place at the same > time for more than one level and messing up things? > > -Stefan > -- 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: How to recreate MOV-SS blocking vmentry fail
On Wed, Sep 11, 2013 at 09:04:26PM +0800, Arthur Chunqi Li wrote: > On Wed, Sep 11, 2013 at 9:03 PM, Gleb Natapov wrote: > > On Wed, Sep 11, 2013 at 03:01:07PM +0200, Paolo Bonzini wrote: > >> Il 11/09/2013 14:53, Gleb Natapov ha scritto: > >> >> > I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, > >> >> > 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 > >> >> > also describe it. I got confused how this scenario can be recreated. > >> >> > Do you have any ideas? > >> >> > > >> > mov $0, %ss > >> > vmlaunch > >> > >> Probably better to save %ss somewhere around these instructions... :) > >> > > Details, details :) It can be: > > mov %ss, tmp > > mov tmp, $ss > > vmlaunch > Well, this seems hard to test this in our framework ;( vmlaunch is > surrounded with many instructions and we cannot add vmlaunch in exit > handler. > Well, we can put moves always there, or write special test for it, but it is nice to have test, but not very important. -- 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: How to recreate MOV-SS blocking vmentry fail
On Wed, Sep 11, 2013 at 9:03 PM, Gleb Natapov wrote: > On Wed, Sep 11, 2013 at 03:01:07PM +0200, Paolo Bonzini wrote: >> Il 11/09/2013 14:53, Gleb Natapov ha scritto: >> >> > I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, >> >> > 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 >> >> > also describe it. I got confused how this scenario can be recreated. >> >> > Do you have any ideas? >> >> > >> > mov $0, %ss >> > vmlaunch >> >> Probably better to save %ss somewhere around these instructions... :) >> > Details, details :) It can be: > mov %ss, tmp > mov tmp, $ss > vmlaunch Well, this seems hard to test this in our framework ;( vmlaunch is surrounded with many instructions and we cannot add vmlaunch in exit handler. Thanks, Arthur > > -- > 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: How to recreate MOV-SS blocking vmentry fail
On Wed, Sep 11, 2013 at 03:01:07PM +0200, Paolo Bonzini wrote: > Il 11/09/2013 14:53, Gleb Natapov ha scritto: > >> > I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, > >> > 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 > >> > also describe it. I got confused how this scenario can be recreated. > >> > Do you have any ideas? > >> > > > mov $0, %ss > > vmlaunch > > Probably better to save %ss somewhere around these instructions... :) > Details, details :) It can be: mov %ss, tmp mov tmp, $ss vmlaunch -- 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: How to recreate MOV-SS blocking vmentry fail
Il 11/09/2013 14:53, Gleb Natapov ha scritto: >> > I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, >> > 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 >> > also describe it. I got confused how this scenario can be recreated. >> > Do you have any ideas? >> > > mov $0, %ss > vmlaunch Probably better to save %ss somewhere around these instructions... :) 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: How to recreate MOV-SS blocking vmentry fail
On Wed, Sep 11, 2013 at 08:55:41PM +0800, Arthur Chunqi Li wrote: > On Wed, Sep 11, 2013 at 8:53 PM, Gleb Natapov wrote: > > On Wed, Sep 11, 2013 at 08:49:28PM +0800, Arthur Chunqi Li wrote: > >> Hi Gleb, Paolo and related folks, > >> > >> I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, > >> 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 > >> also describe it. I got confused how this scenario can be recreated. > >> Do you have any ideas? > >> > > mov $0, %ss > > vmlaunch > Should these two instructions execute sequentially? > One immediately after another in the order above. -- 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: How to recreate MOV-SS blocking vmentry fail
On Wed, Sep 11, 2013 at 8:53 PM, Gleb Natapov wrote: > On Wed, Sep 11, 2013 at 08:49:28PM +0800, Arthur Chunqi Li wrote: >> Hi Gleb, Paolo and related folks, >> >> I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, >> 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 >> also describe it. I got confused how this scenario can be recreated. >> Do you have any ideas? >> > mov $0, %ss > vmlaunch Should these two instructions execute sequentially? Thanks, Arthur > > -- > 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: How to recreate MOV-SS blocking vmentry fail
On Wed, Sep 11, 2013 at 08:49:28PM +0800, Arthur Chunqi Li wrote: > Hi Gleb, Paolo and related folks, > > I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, > 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 > also describe it. I got confused how this scenario can be recreated. > Do you have any ideas? > mov $0, %ss vmlaunch -- 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
How to recreate MOV-SS blocking vmentry fail
Hi Gleb, Paolo and related folks, I was trying to recreate MOV-SS blocking vmentry fail (Intel SDM 26.1, 5. a). Here the manual refers to Table 24-3, but later in 26.3.1.5 also describe it. I got confused how this scenario can be recreated. Do you have any ideas? Thanks, Arthur -- Arthur Chunqi Li Department of Computer Science School of EECS Peking University Beijing, China -- 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 00/11] HV KVM improvements in preparation for POWER8 support
On Fri, Sep 06, 2013 at 01:10:03PM +1000, Paul Mackerras wrote: > This series of patches is based on Alex Graf's kvm-ppc-queue branch. > It fixes some bugs, makes some more registers accessible through the > one_reg interface, and implements some missing features such as > support for the compatibility modes in recent POWER cpus and support > for the guest having a different timebase origin from the host. > These patches are all useful on POWER7 and will be needed for good > POWER8 support. > > Please apply. Alex, Any comment on these patches? Some of them define new one_reg register identifiers, and I'm keen to get those nailed down so that we can start submitting the corresponding QEMU patches. Thanks, Paul. -- 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: [libvirt-users] Questions on how to reset ID numbers for virt Guests.
On Wed, Sep 11, 2013 at 09:47:07AM +0200, Paolo Bonzini wrote: > Il 11/09/2013 00:27, James Sparenberg ha scritto: > > I'm doing some experimenting in our Development lab and as a result > > I'm kickstarting over and over Virtual guests. This is of course > > causing the guest Id to increment by one with each test. I've > > googled around and tried searching the list but have not found out > > how (if at all) it would be possible to reset the ID number back to 1 > > more than is in use. Also is there a limit where I run out of ID's? > > (for example does it only go up to 99?) > > No, there is no limit. Well, 'int' will wrap eventually, but you'd need to have created a hell of alot of guests for that to be a problem :-) > I don't know the answer to your other question, so I'm adding the > libvirt-users mailing list. If you restart libvirtd, it reset itself to start allocating IDs at the max current used ID of any running guest. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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: Questions on how to reset ID numbers for virt Guests.
Il 11/09/2013 00:27, James Sparenberg ha scritto: > I'm doing some experimenting in our Development lab and as a result > I'm kickstarting over and over Virtual guests. This is of course > causing the guest Id to increment by one with each test. I've > googled around and tried searching the list but have not found out > how (if at all) it would be possible to reset the ID number back to 1 > more than is in use. Also is there a limit where I run out of ID's? > (for example does it only go up to 99?) No, there is no limit. I don't know the answer to your other question, so I'm adding the libvirt-users mailing list. 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-unit-tests: VMX: Fix two minor bugs
Il 11/09/2013 05:15, Arthur Chunqi Li ha scritto: > Hi Paolo, > > Sorry but I should trouble you merging these two minor changes to vmx branch. > > Until now, all the commits in vmx branch seems fine (if others have no > comments). Because I have some patches to commit based on vmx branch, > should we merge this branch to master or I just commit patches based > on vmx? Please send patches based on vmx, otherwise review becomes very very hard. When everything is ready, we'll squash the fixes and merge to master. Until then, vmx will _not_ be rebased so you can use it for development. 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
