Hi Jan and Paolo,
I've tried to use preemption timer in KVM to trap vcpu regularly, but
there's something unexpected. I run a VM with 4 vcpus and give them
the same preemption timer value (e.g. 100) with all bits set
(activate/save bits), then reset the value in preemption time-out
handler.
The problem still the same.
Regards,
--
Carlos Rodrigues
Engenheiro de Software Sénior
Eurotux Informática, S.A. | www.eurotux.com
(t) +351 253 680 300 (m) +351 911 926 110
On Sáb, 2013-12-14 at 08:30 +1100, Vadim Rozenfeld wrote:
On Fri, 2013-12-13 at 14:35 +, Carlos Rodrigues
Hi,
Thank you all for your comments.
I'm sorry for taking this long to reply, I was away on vacation..
It was a good, long discussion, many issues were raised, which we'd like
to address with the following proposed roadmap for Elvis patches.
In general, we believe it would be best to start with
Il 16/12/2013 10:57, Jan Kiszka ha scritto:
See commit 47c1461a5.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
x86/emulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/x86/emulator.c b/x86/emulator.c
index 68d2b93..4e70e8f 100644
--- a/x86/emulator.c
+++
Il 16/12/2013 10:57, Jan Kiszka ha scritto:
Add missing include of desc.h for prototypes of setup_idt and
set_idt_entry and cast away the volatile of ipi_data - it's not volatile
while we run the IPI handler.
Why not?
Paolo
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Il 16/12/2013 10:57, Jan Kiszka ha scritto:
Add missing include of desc.h for prototypes of setup_idt and
set_idt_entry and cast away the volatile of ipi_data - it's not volatile
while we run the IPI handler.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
The right fix is to change the
x86/svm.c:534:18: warning: variable ‘data’ set but not used
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/svm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/x86/svm.c b/x86/svm.c
index d51e7ec..9d910ae 100644
--- a/x86/svm.c
+++ b/x86/svm.c
@@ -11,7 +11,7
On Sun, Dec 15, 2013 at 04:20:05PM +0800, Qingshu Chen wrote:
hi,I want to calculate the latencyof virtio in kvm, I read the document in
http://www.linux-kvm.org/page/Virtio/Block/Latency and met some problem.
1. when calculating latency in kvm, the document said kvm_pio and
kvm_set_irq can
On 2013-12-17 11:35, Paolo Bonzini wrote:
Il 16/12/2013 10:57, Jan Kiszka ha scritto:
Add missing include of desc.h for prototypes of setup_idt and
set_idt_entry and cast away the volatile of ipi_data - it's not volatile
while we run the IPI handler.
Signed-off-by: Jan Kiszka
Il 17/12/2013 10:32, Arthur Chunqi Li ha scritto:
Hi Jan and Paolo,
I've tried to use preemption timer in KVM to trap vcpu regularly, but
there's something unexpected. I run a VM with 4 vcpus and give them
the same preemption timer value (e.g. 100) with all bits set
(activate/save
On 13/12/13 20:35, Andre Przywara wrote:
On 12/13/2013 09:10 PM, Christoffer Dall wrote:
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this is per VCPU, we can use
Il 17/12/2013 07:11, Arthur Chunqi Li ha scritto:
Hi Paolo,
Since VCPU is managed the same as a process in kernel, how can I know
the status (running, sleeping etc.) of a vcpu in kernel? Is there a
variant in struct kvm_vcpu or something else indicate this?
waitqueue_active(vcpu-wq) means
On 2013-12-17 10:32, Arthur Chunqi Li wrote:
Hi Jan and Paolo,
I've tried to use preemption timer in KVM to trap vcpu regularly, but
there's something unexpected. I run a VM with 4 vcpus and give them
the same preemption timer value (e.g. 100) with all bits set
(activate/save bits),
Hi Jan,
On Tue, Dec 17, 2013 at 7:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-17 10:32, Arthur Chunqi Li wrote:
Hi Jan and Paolo,
I've tried to use preemption timer in KVM to trap vcpu regularly, but
there's something unexpected. I run a VM with 4 vcpus and give them
the same
Hi Paolo,
Thanks very much. And...(see below)
On Tue, Dec 17, 2013 at 7:21 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 17/12/2013 07:11, Arthur Chunqi Li ha scritto:
Hi Paolo,
Since VCPU is managed the same as a process in kernel, how can I know
the status (running, sleeping etc.) of a
Il 17/12/2013 12:43, Arthur Chunqi Li ha scritto:
Hi Paolo,
Thanks very much. And...(see below)
On Tue, Dec 17, 2013 at 7:21 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 17/12/2013 07:11, Arthur Chunqi Li ha scritto:
Hi Paolo,
Since VCPU is managed the same as a process in kernel,
On 2013-12-17 12:31, Arthur Chunqi Li wrote:
Hi Jan,
On Tue, Dec 17, 2013 at 7:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-17 10:32, Arthur Chunqi Li wrote:
Hi Jan and Paolo,
I've tried to use preemption timer in KVM to trap vcpu regularly, but
there's something unexpected.
On Tue, Dec 17, 2013 at 8:43 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-17 12:31, Arthur Chunqi Li wrote:
Hi Jan,
On Tue, Dec 17, 2013 at 7:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-17 10:32, Arthur Chunqi Li wrote:
Hi Jan and Paolo,
I've tried to use
Il 16/12/2013 10:32, Jan Kiszka ha scritto:
As long as we do not expose all the VMX related states to user space,
there is no way to properly reset a VCPU when VMX is enabled. Emulate
this for now by catching host-side clearings of the feature control MSR.
This allows to reboot a VM while it
On 2013-12-17 14:25, Paolo Bonzini wrote:
Il 16/12/2013 10:32, Jan Kiszka ha scritto:
As long as we do not expose all the VMX related states to user space,
there is no way to properly reset a VCPU when VMX is enabled. Emulate
this for now by catching host-side clearings of the feature control
Il 17/12/2013 15:40, Jan Kiszka ha scritto:
The final vmx_vcpu_reset is the only really ugly part, but it is
_really_ ugly... Can you modify QEMU to restore MSRs first, and reduce
vmx_reset_nested to just
if (is_guest_mode(vcpu))
nested_vmx_vmexit(vcpu);
On 2013-12-17 13:59, Arthur Chunqi Li wrote:
On Tue, Dec 17, 2013 at 8:43 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-17 12:31, Arthur Chunqi Li wrote:
Hi Jan,
On Tue, Dec 17, 2013 at 7:21 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-12-17 10:32, Arthur Chunqi Li wrote:
This patch series allows (but discourages) overriding the Generic Timer
frequency for device tree-based guest OSes, to work around systems with
broken secure firmware that fails to program CNTFRQ correctly.
Robin Murphy (2):
kvmtool: Support unsigned int options
kvmtool/arm: Add option to
Add support for unsigned int command-line options by implementing the
OPT_UINTEGER macro.
Signed-off-by: Robin Murphy robin.mur...@arm.com
Acked-by: Will Deacon will.dea...@arm.com
---
tools/kvm/include/kvm/parse-options.h |9 +
1 file changed, 9 insertions(+)
diff --git
If the guest is running in nested mode on system reset, clearing the
feature MSR signals the kernel to leave this mode. Recent kernels
processes this properly, but leave the VCPU state undefined behind. It
is the job of userspace to bring it to a proper shape. Therefore, write
this specific MSR
When userspace sets MSR_IA32_FEATURE_CONTROL to 0, make sure we leave
root and non-root mode, fully disabling VMX. The register state of the
VCPU is undefined after this step, so userspace has to set it to a
proper state afterward.
This enables to reboot a VM while it is running some hypervisor
Some platforms have secure firmware which does not correctly set the
CNTFRQ register on boot, preventing the use of the Generic Timer.
This patch allows mirroring the necessary host workaround by specifying
the clock-frequency property in the guest DT.
This should only be considered a means of
On Tue, Dec 17, 2013 at 11:20:20AM +, Marc Zyngier wrote:
On 13/12/13 20:35, Andre Przywara wrote:
On 12/13/2013 09:10 PM, Christoffer Dall wrote:
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
For migration to work we need to save (and later restore) the state of
On 17.12.2013, at 19:31, Robin Murphy robin.mur...@arm.com wrote:
Some platforms have secure firmware which does not correctly set the
CNTFRQ register on boot, preventing the use of the Generic Timer.
This patch allows mirroring the necessary host workaround by specifying
the clock-frequency
Hi,
You must adjust the preemption timer according to the eclipsed time
when the guest runs.
And register a hrtimer triggered when a guest exit.
The timer should be alarmed when the remaining time runs out,
2013/12/17 Jan Kiszka jan.kis...@siemens.com:
On 2013-12-17 13:59, Arthur Chunqi Li
The current KVM implementation of PSCI returns INVALID_PARAMETERS if the
waitqueue for the corresponding CPU is not active. This does not seem
correct, since KVM should not care what the specific thread is doing,
for example, user space may not have called KVM_RUN on this VCPU yet or
the thread
There is nothing technically or semantically wrong with calling
KVM_ARM_VCPU_INIT more than once, and even calling this on a VCPU after
the VCPU has been executed. It just happens that user space will need a
way to reset the VCPU or put the VCPU back in PSCI power-off mode after
the VM has run,
On 2013-12-18 04:27, R wrote:
Hi,
You must adjust the preemption timer according to the eclipsed time
when the guest runs.
And register a hrtimer triggered when a guest exit.
The timer should be alarmed when the remaining time runs out,
In fact, as we need to register an hrtimer anyway
Hi Alex,
Any update on this ? We need this to got into 3.13.
-aneesh
Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR
KVM mode when both HV and PR are enabled in the
Hi Alex,
Any update on this ? We need this to got into 3.13.
-aneesh
Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR
KVM mode when both HV and PR are enabled in the
35 matches
Mail list logo
