On 22/06/2015 18:05, Denis V. Lunev wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
Previous patches allowes userspace to setup Hyper-V crash ctl msr.
This msr should expose HV_X64_MSR_CRASH_CTL_NOTIFY value to Hyper-V
guest to allow to send crash data. Unfortunately Hyper-V guest
On 22/06/2015 18:05, Denis V. Lunev wrote:
+void qemu_system_guest_panicked(void)
+{
+qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, error_abort);
+vm_stop(RUN_STATE_GUEST_PANICKED);
+}
+
Please call this in pvpanic.c and target-s390x/kvm.c (replacing the
guest_panicked
On 22/06/15 19:33, Andreas Färber wrote:
Am 22.06.2015 um 18:27 schrieb Paolo Bonzini:
On the other hand, I wonder if current_cpu is available in
qemu_system_guest_panicked. If so, you could add the field to the
generic CPUState struct and migrate it as a subsection of
vmstate_cpu_common.
Hm,
Acked-by: Baptiste Reynal b.rey...@virtualopensystems.com
On Thu, Jun 18, 2015 at 8:06 PM, Alex Williamson
alex.william...@redhat.com wrote:
Add Baptiste Reynal as the VFIO platform driver sub-maintainer.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Baptiste Reynal
Another one...
On 22/06/2015 18:05, Denis V. Lunev wrote:
+case KVM_SYSTEM_EVENT_CRASH:
+if (run-system_event.flags KVM_SYSTEM_EVENT_FL_HV_CRASH) {
+kvm_arch_handle_hv_crash(cpu);
+}
+
Hi
Please, send any topic that you are interested in covering.
Call details:
By popular demand, a google calendar public entry with it
https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
(Let me know if you have any problems
Hi Eric,
On 18/06/15 18:40, Eric Auger wrote:
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry structure
that enables to encode that information on top of
This is a note to let you know that I have just added a patch titled
MIPS: KVM: Do not sign extend on unsigned MMIO load
to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree
which can be found at:
From: Andrey Smetanin asmeta...@virtuozzo.com
Added Hyper-V crash msrs HV_X64_MSR_CRASH* constants.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
From: Andrey Smetanin asmeta...@virtuozzo.com
vcpu_debug is a useful macro like kvm_debug and additionally
includes vcpu context into output.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb
From: Andrey Smetanin asmeta...@virtuozzo.com
Added KVM_REQ_HV_CRASH - vcpu request used for notify user space(QEMU)
about Hyper-v crash.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov
From: Andrey Smetanin asmeta...@virtuozzo.com
It's usually impossible to understand from Hyper-V
crash msr's that crash happened because ctl msr
always contains the same value HV_X64_MSR_CRASH_CTL_NOTIFY.
To solve it add a particalar value hv_crash_occurred
inside CPU state and migrate this value
From: Andrey Smetanin asmeta...@virtuozzo.com
Previous patches allowes userspace to setup Hyper-V crash ctl msr.
This msr should expose HV_X64_MSR_CRASH_CTL_NOTIFY value to Hyper-V
guest to allow to send crash data. Unfortunately Hyper-V guest notifies
hardware about crash by writing the same
From: Andrey Smetanin asmeta...@virtuozzo.com
Sending of notification is done by exiting vcpu to user space if
KVM_REQ_HV_CRASH is set for vcpu. kvm_run structure will contain
system_event with type equals to KVM_SYSTEM_EVENT_CRASH and flag
KVM_SYSTEM_EVENT_FL_HV_CRASH to clarify that the crash
From: Andrey Smetanin asmeta...@virtuozzo.com
This patch introduces Hyper-V related source code file - hyperv.c and
per vm and per vcpu hyperv context structures.
All Hyper-V MSR's and hypercall code moved into hyperv.c.
All hyper-v kvm/vcpu fields moved into appropriate hyperv context
From: Andrey Smetanin asmeta...@virtuozzo.com
Added hyper-v crash msr's(HV_X64_MSR_CRASH*) data and control
geters and setters.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov
From: Andrey Smetanin asmeta...@virtuozzo.com
Added kvm hyperv context hv crash variables as storage
of hyper-v crash msrs.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
From: Andrey Smetanin asmeta...@virtuozzo.com
KVM Hyper-V based guests can notify hypervisor about
occurred guest crash. This patch does handling of KVM crash event
by sending to libvirt guest panic event that allows to gather
guest crash dump by QEMU/LIBVIRT. Add support of
From: Andrey Smetanin asmeta...@virtuozzo.com
Hyper-V crash msr's a per VM, not per vcpu, so mark them
as partition wide.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
Windows 2012 guests can notify hypervisor about occurred guest crash
(Windows bugcheck(BSOD)) by writing specific Hyper-V msrs. This patch does
handling of this MSR's by KVM and sending notification to user space that
allows to gather Windows guest crash dump by QEMU/LIBVIRT.
The idea is to
On 22/06/2015 18:23, Andreas Färber wrote:
@@ -679,6 +679,7 @@ static const VMStateDescription
vmstate_msr_hyperv_crash = {
VMSTATE_UINT64(env.msr_hv_crash_ctl, X86CPU),
VMSTATE_UINT64_ARRAY(env.msr_hv_crash_prm,
X86CPU,
Am 22.06.2015 um 18:05 schrieb Denis V. Lunev:
From: Andrey Smetanin asmeta...@virtuozzo.com
It's usually impossible to understand from Hyper-V
crash msr's that crash happened because ctl msr
always contains the same value HV_X64_MSR_CRASH_CTL_NOTIFY.
To solve it add a particalar value
Am 22.06.2015 um 18:27 schrieb Paolo Bonzini:
On the other hand, I wonder if current_cpu is available in
qemu_system_guest_panicked. If so, you could add the field to the
generic CPUState struct and migrate it as a subsection of
vmstate_cpu_common.
Hm, not sure whether it is.
Would that
On 22/06/2015 18:33, Andreas Färber wrote:
On the other hand, I wonder if current_cpu is available in
qemu_system_guest_panicked. If so, you could add the field to the
generic CPUState struct and migrate it as a subsection of
vmstate_cpu_common.
Hm, not sure whether it is.
It should
John Nielsen li...@jnielsen.net writes:
On Jun 17, 2014, at 10:48 AM, John Nielsen li...@jnielsen.net wrote:
On Jun 17, 2014, at 12:05 AM, Gleb Natapov g...@kernel.org wrote:
On Tue, Jun 17, 2014 at 06:21:23AM +0200, Paolo Bonzini wrote:
Il 16/06/2014 18:47, John Nielsen ha scritto:
On
On Mon, Jun 22, 2015 at 9:05 AM, Denis V. Lunev d...@openvz.org wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
Previous patches allowes userspace to setup Hyper-V crash ctl msr.
This msr should expose HV_X64_MSR_CRASH_CTL_NOTIFY value to Hyper-V
guest to allow to send crash data.
On Jun 22, 2015, at 3:48 PM, Bandan Das b...@redhat.com wrote:
John Nielsen li...@jnielsen.net writes:
On Jun 17, 2014, at 10:48 AM, John Nielsen li...@jnielsen.net wrote:
On Jun 17, 2014, at 12:05 AM, Gleb Natapov g...@kernel.org wrote:
On Tue, Jun 17, 2014 at 06:21:23AM +0200, Paolo
On Mon, Jun 22, 2015 at 9:05 AM, Denis V. Lunev d...@openvz.org wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
Added hyper-v crash msr's(HV_X64_MSR_CRASH*) data and control
geters and setters.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev
On Fri, 19 Jun 2015 18:33:39 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jun 19, 2015 at 06:26:27PM +0200, Paolo Bonzini wrote:
On 19/06/2015 18:20, Michael S. Tsirkin wrote:
We could, but I/O is just an example. It can be I/O, a network ring,
whatever. We cannot
On Fri, 19 Jun 2015 21:31:27 +0100
Timur Tabi ti...@codeaurora.org wrote:
On 06/17/2015 04:00 AM, Suzuki K. Poulose wrote:
genericv8_target_table);
kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
As we're about to trap a bunch of CP14 registers, let's rework
the CP15 handling so it can be generalized and work with multiple
tables.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/coproc.c | 176 ++---
We now have multiple tables for the various system registers
we trap. Make sure we check the order of all of them, as it is
critical that we get the order right (been there, done that...).
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/coproc.c | 26
Add handlers for all the 32-bit debug registers.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/include/asm/kvm_asm.h | 12
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/kernel/asm-offsets.c | 1 +
arch/arm/kvm/coproc.c | 122
This patch series adds debug support, a key feature missing from the
KVM/armv7 port.
The main idea is borrowed from ARM64, which is to keep track of whether
the debug registers are dirty (changed by the guest) or not. In this
case, perform the usual save/restore dance, for one run only. It
pm_fake doesn't quite describe what the handler does (ignoring writes
and returning 0 for reads).
As we're about to use it (a lot) in a different context, rename it
with a (admitedly cryptic) name that make sense for all users.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
Reviewed-by:
Add #ifndef __ASSEMBLY__ in hw_breakpoint.h, in order to use
the ARM_DSCR_MDBGEN macro from KVM assembly code.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
Reviewed-by: Alex Bennee alex.ben...@linaro.org
---
arch/arm/include/asm/hw_breakpoint.h | 54 +++-
Implement switching of the debug registers. While the number
of registers is massive, CPUs usually don't implement them all
(A15 has 6 breakpoints and 4 watchpoints, which gives us a total
of 22 registers only).
Notice that, for ARMv7, if the CONFIG_HAVE_HW_BREAKPOINT is set in
the guest, debug
Add handlers for all the 64-bit debug registers.
There is an overlap between 32 and 64bit registers. Make sure that
64-bit registers preceding 32-bit ones.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/coproc.c | 12
1 file changed, 12 insertions(+)
diff
The trapping code keeps track of the state of the debug registers,
allowing for the switch code to implement a lazy switching strategy.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/include/asm/kvm_asm.h | 3 +++
arch/arm/include/asm/kvm_host.h | 3 +++
On Fri, Jun 19, 2015 at 05:28:53PM -0500, Timur Tabi wrote:
On 06/15/2015 05:59 AM, Catalin Marinas wrote:
I think this patch together with the second one could go through the kvm
tree. For the core arm64 part:
Acked-by: Catalin Marinascatalin.mari...@arm.com
Suzuki Poulose posted a patch
On 17/06/2015 18:11, Paolo Bonzini wrote:
Also, this loop looks weird. Is this what you wanted?
list_for_each_entry(tmp, mtrr_state-head, node)
if (cur-base = tmp-base)
break;
list_add_tail(cur-node, tmp-node);
If so, can you
Hardware debugging in guests is not intercepted currently, it means
that a malicious guest can bring down the entire machine by writing
to the debug registers.
This patch enable trapping of all debug registers, preventing the guests
to access the debug registers.
This patch also disable the
On 19/06/2015 20:57, Hu Yaohui wrote:
One more thing, for the standard guest VM which uses EPT, What's the
usage of gfn field in the struct kvm_mmu_page? Since it uses EPT,
a single shadow page should has no relation with any of the guest
physical page, right?
The gfn is the same value
On 22/06/2015 09:10, Igor Mammedov wrote:
So far HVA is unusable even if we will make this assumption and let guest
crash.
virt_net doesn't work with it anyway,
translation of GPA to HVA for descriptors works as expected (correctly)
but vhost+HVA hack backed virtio still can't
On 22/06/2015 02:09, Paul Mackerras wrote:
On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote:
Tested-by: Laurent Vivier lviv...@redhat.com
Performance is better, but Paul could you explain why it is better if I
disable dynamic micro-threading ?
Did I miss something ?
My
On 22/06/2015 02:09, Paul Mackerras wrote:
On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote:
Tested-by: Laurent Vivier lviv...@redhat.com
Performance is better, but Paul could you explain why it is better if I
disable dynamic micro-threading ?
Did I miss something ?
My
There are too many cp15 traps, so we don't reuse the cp15 trace event
but add a new trace event to trace the access of debug registers.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/coproc.c | 14 ++
arch/arm/kvm/trace.h | 30 ++
Enable trapping of the debug registers, allowing guests to use
the debug infrastructure.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/interrupts_head.S | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/interrupts_head.S
From: Jens Freimann jf...@linux.vnet.ibm.com
commit 6d3da24141 (KVM: s390: deliver floating interrupts in order
of priority) introduced a regression for the reset handling.
We don't clear the bitmap of pending floating interrupts
and interrupt parameters. This could result in stale interrupts
Paolo,
here is a small fixup for KVM on s390. It is also necessary for
4.1 which I am a bit late for - so cc stable.
No pull request as it is only one patch.
Jens Freimann (1):
KVM: s390: clear floating interrupt bitmap and parameters
arch/s390/kvm/interrupt.c | 3 +++
1 file changed, 3
Hi Pavel,
On 06/19/2015 08:37 AM, Pavel Fedin wrote:
Hello!
The series therefore allows and mandates the usage of KVM_SET_GSI_ROUTING
ioctl along with KVM_IRQFD. If the userspace does not define any routing
table, no irqfd injection can happen. The user-space can use
KVM_CAP_IRQ_ROUTING to
Hi Eric,
I briefly looked over the series, the patches itself look good overall.
I have one or two comments on the actual code, but want to discuss the
general approach first (more a dump of some first thoughts):
On 18/06/15 18:40, Eric Auger wrote:
With the advent of GICv3 ITS in-kernel
On 17 June 2015 at 10:00, Suzuki K. Poulose suzuki.poul...@arm.com wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch adds a generic ARM v8 KVM target cpu type for use
by the new CPUs which eventualy ends up using the common sys_reg
table. For backward compatibility the existing
On 06/22/2015 10:40 AM, Andre Przywara wrote:
Hi Eric,
I briefly looked over the series, the patches itself look good overall.
I have one or two comments on the actual code, but want to discuss the
general approach first (more a dump of some first thoughts):
On 18/06/15 18:40, Eric Auger
Am 22.06.2015 um 18:36 schrieb Paolo Bonzini:
On 22/06/2015 18:33, Andreas Färber wrote:
On the other hand, I wonder if current_cpu is available in
qemu_system_guest_panicked. If so, you could add the field to the
generic CPUState struct and migrate it as a subsection of
vmstate_cpu_common.
On Jun 17, 2014, at 10:48 AM, John Nielsen li...@jnielsen.net wrote:
On Jun 17, 2014, at 12:05 AM, Gleb Natapov g...@kernel.org wrote:
On Tue, Jun 17, 2014 at 06:21:23AM +0200, Paolo Bonzini wrote:
Il 16/06/2014 18:47, John Nielsen ha scritto:
On Jun 16, 2014, at 10:39 AM, Paolo Bonzini
On 6/22/15 1:38 AM, Jan Kiszka wrote:
On 2015-06-18 22:21, Eduardo Habkost wrote:
On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
ARAT signals that the APIC timer does not stop in power saving states.
As our APICs are emulated, it's fine
On 06/22/2015 07:24 PM, Paolo Bonzini wrote:
On 17/06/2015 18:11, Paolo Bonzini wrote:
Also, this loop looks weird. Is this what you wanted?
list_for_each_entry(tmp, mtrr_state-head, node)
if (cur-base = tmp-base)
break;
On 2015-06-23 04:50, Wanpeng Li wrote:
On 6/22/15 1:38 AM, Jan Kiszka wrote:
On 2015-06-18 22:21, Eduardo Habkost wrote:
On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
ARAT signals that the APIC timer does not stop in power saving
Catalin Marinas wrote:
So if the second patch is no longer needed, what's using this patch? I
would defer merging it until actually required in some part of the
kernel.
Fair enough.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member
On 22/06/2015 15:28, Hu Yaohui wrote:
*/2504 pseudo_gfn = base_addr PAGE_SHIFT;
2505 sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
2506 iterator.level - 1,
2507 1, ACC_ALL, iterator.sptep);/*
2508
61 matches
Mail list logo
