https://bugzilla.kernel.org/show_bug.cgi?id=78331
Bug ID: 78331
Summary: Qemu crash in x86
Product: Virtualization
Version: unspecified
Kernel Version: 2.6.32
Hardware: All
OS: Linux
Tree: Mainline
On Wed, Jun 18, 2014 at 08:12:05PM -0300, mtosa...@redhat.com wrote:
> Allow vcpus to pin spte translations by:
>
> 1) Creating a per-vcpu list of pinned ranges.
What if memory slot containing pinned range is going away?
> 2) On mmu reload request:
> - Fault ranges.
> - Mark sptes wit
On 06/19/2014 02:12 AM, mtosa...@redhat.com wrote:
Allow vcpus to pin spte translations by:
1) Creating a per-vcpu list of pinned ranges.
2) On mmu reload request:
- Fault ranges.
- Mark sptes with a pinned bit.
- Mark shadow pages as pinned.
3) Then modify the followin
On Wed, Jun 18, 2014 at 01:48:15PM -0700, Andrew Morton wrote:
> On Mon, 16 Jun 2014 14:40:46 +0900 Joonsoo Kim wrote:
>
> > PPC KVM's CMA area management requires arbitrary bitmap granularity,
> > since they want to reserve very large memory and manage this region
> > with bitmap that one bit fo
On Wed, Jun 18, 2014 at 08:12:07PM -0300, mtosa...@redhat.com wrote:
> Reload remote vcpus MMU from GET_DIRTY_LOG codepath, before
> deleting a pinned spte.
>
> Signed-off-by: Marcelo Tosatti
>
> ---
> arch/x86/kvm/mmu.c |3 +++
> 1 file changed, 3 insertions(+)
>
> Index: kvm.pinned-sptes
On 06/18/2014 05:01 PM, Andreas Färber wrote:
late onto this thread: SUSE Security team has just recently
done a thorough review of QEMU ivshmem code because a customer has
requested this be supported in SLES12. Multiple security-related
patches were submitted by Stefan Hajnoczi and Sebastian Kra
Add the necessary documentation to support GICv3.
Cc: Thomas Gleixner
Cc: Mark Rutland
Cc: Jason Cooper
Acked-by: Catalin Marinas
Acked-by: Rob Herring
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
Documentation/devicetree/bindings/arm/gic-v3.txt | 79
The Generic Interrupt Controller (version 3) offers services that are
similar to GICv2, with a number of additional features:
- Affinity routing based on the CPU MPIDR (ARE)
- System register for the CPU interfaces (SRE)
- Support for more that 8 CPUs
- Locality-specific Peripheral Interrupts (LPIs
Move the GICH_ELRSR access to its own functions, and add them to
the vgic_ops structure.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 2 ++
virt/kvm/arm/vgic.c| 38 +-
2 files changed,
So far, irqchip_in_kernel() was implemented by testing the value of
vctrl_base, which worked fine with GICv2.
With GICv3, this field is useless, as we're using system registers
instead of a emmory mapped interface. To solve this, add a boolean
flag indicating if the we're using a vgic or not.
Rev
Introduce the support code for emulating a GICv2 on top of GICv3
hardware.
Acked-by: Catalin Marinas
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_asm.h | 2 +
arch/arm64/kvm/vgic-v3-switch.S | 29 +
include/kvm/arm_vgic.h | 28 +
virt/kvm/arm/vgic-v3.c
Move the code dealing with enabling the VGIC on to vgic_ops.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/vgic.c| 29 +
2 files changed, 22 insertions(+), 8 deletions(-)
diff
Move all the data specific to a given GIC implementation into its own
little structure.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 11
virt/kvm/arm/vgic.c| 70 --
Instead of directly messing with with the GICH_VMCR bits for the CPU
interface save/restore code, add accessors that encode/decode the
entire set of registers exposed by VMCR.
Not the most efficient thing, but given that this code is only used
by the save/restore code, performance is far from bein
Move the GICv2 world switch code into its own file, and add the
necessary indirection to the arm64 switch code.
Also introduce a new type field to the vgic_params structure.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
arch/arm/include/asm/kvm_host.h
GICv3 requires the IMO and FMO bits to be tightly coupled with some
of the interrupt controller's register switch.
In order to have similar code paths, move the manipulation of these
bits to the GICv2 switch code.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngi
We already have __hyp_text_{start,end} to express the boundaries
of the HYP text section, and __kvm_hyp_code_{start,end} are getting
in the way of a more modular world switch code.
Just turn __kvm_hyp_code_{start,end} into #defines mapping the
linker-emited symbols.
Acked-by: Catalin Marinas
Rev
Brutally hack the innocent vgic code, and move the GICv2 specific code
to its own file, using vgic_ops and vgic_params as a way to pass
information between the two blocks.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/Makefile | 1 +
a
Introduce the GICv3 world switch code and helper functions, enabling
GICv2 emulation on GICv3 hardware.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_asm.h | 2 +
arch/arm64/include/asm/kvm_host.h | 7 ++
arch/arm64/kern
CCing Marcelo,
On Wed, Jun 18, 2014 at 02:50:44PM +0800, Tang Chen wrote:
> Hi Gleb,
>
> Thanks for the quick reply. Please see below.
>
> On 06/18/2014 02:12 PM, Gleb Natapov wrote:
> >On Wed, Jun 18, 2014 at 01:50:00PM +0800, Tang Chen wrote:
> >>[Questions]
> >>And by the way, would you guys
In order to split the various register manipulation from the main vgic
code, introduce a vgic_ops structure, and start by abstracting the
LR manipulation code with a couple of accessors.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 18 ++
virt/kvm/
The GIC CPU interface is always 4k aligned. If the host is using
64k pages, it is critical to place the guest's GICC interface at the
same relative alignment as the host's GICV. Failure to do so results
in an impossibility for the guest to deal with interrupts.
Add a KVM_DEV_ARM_VGIC_GRP_ADDR_OFFS
Move the GICH_EISR access to its own function.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/vgic.c| 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/kvm/arm_v
Linux has some requirements that must be satisfied in order to boot
on a system built with a GICv3.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
Documentation/arm64/booting.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/arm64/booting.txt b/Documentatio
So far, the VGIC data structures have been statically sized, meaning
that we always have to support more interrupts than we actually want,
and more CPU interfaces than we should. This is a waste of resource,
and is the kind of things that should be tuneable.
This series addresses that issue by cha
In order to make the number of interrupt configurable, use the new
fancy device management API to add KVM_DEV_ARM_VGIC_GRP_NR_IRQS as
a VGIC configurable attribute.
Userspace can now specify the exact size of the GIC (by increments
of 32 interrupts).
Signed-off-by: Marc Zyngier
---
arch/arm/inc
It is now quite easy to delay the allocation of the vgic tables
until we actually require it to be up and running (when the first
starting to kick around).
This allow us to allocate memory for the exact number of CPUs we
have. As nobody configures the number of interrupts just yet,
use a fallback
We now have the information about the number of CPU interfaces in
the distributor itself. Let's get rid of VGIC_MAX_CPUS, and just
rely on KVM_MAX_VCPUS where we don't have the choice. Yet.
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/arm.c | 2 +-
include/kvm/arm_vgic.h | 3 +--
virt/kvm/ar
Move the code dealing with LR underflow handling to its own functions,
and make them accessible through vgic_ops.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 2 ++
virt/kvm/arm/vgic.c| 28 +---
2
A few GICv2 low-level function are actually very useful to GICv3,
and it makes some sense to share them across the two drivers.
They end-up in their own file, with an additional parameter used
to ensure an optional synchronization (unused on GICv2).
Cc: Thomas Gleixner
Cc: Jason Cooper
Acked-by:
In order to make way for the GICv3 registers, move the v2-specific
registers to their own structure.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
arch/arm/kernel/asm-offsets.c | 14 +--
arch/arm/kvm/interrupts_head.S | 26 +-
So far, all the VGIC data structures are statically defined by the
*maximum* number of vcpus and interrupts it supports. It means that
we always have to oversize it to cater for the worse case.
Start by changing the data structures to be dynamically sizeable,
and allocate them at runtime.
The siz
As it stands, nothing prevents userspace from injecting an interrupt
before the guest's GIC is actually initialized.
This goes unnoticed so far (as everything is pretty much statically
allocated), but ends up exploding in a spectacular way once we switch
to a more dynamic allocation (the GIC data
Instead of directly dealing with the GICH_MISR bits, move the code to
its own function and use a couple of public flags to represent the
actual state.
Acked-by: Catalin Marinas
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 4
virt/kvm/arm/vgic.c
Nuke VGIC_NR_IRQS entierly, now that the distributor instance
contains the number of IRQ allocated to this GIC.
Also add VGIC_NR_IRQS_LEGACY to preserve the current API.
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/arm.c | 2 +-
include/kvm/arm_vgic.h | 6 +++---
virt/kvm/arm/vgic.c|
Having a dynamic number of supported interrupts means that we
cannot relly on VGIC_NR_SHARED_IRQS being fixed anymore.
Instead, make it take the distributor structure as a parameter,
so it can return the right value.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 1 -
virt/kvm/arm/vg
GICv3 is the base for a new generation of interrupt controllers
designed to overcome some of the most glaring limitations of GICv2.
Some of the features are:
- Support for more than 8 CPUs (a lot more...)
- System registers for CPU interface access (instead of the memory
mapped GICC, GICV, GICH)
Now that we can (almost) dynamically size the number of interrupts,
we're facing an interesting issue:
We have to evaluate at runtime whether or not an access hits a valid
register, based on the sizing of this particular instance of the
distributor. Furthermore, the GIC spec says that accessing a
Il 18/06/2014 21:55, Eduardo Habkost ha scritto:
TCG doesn't support VMX, and nested VMX is not enabled by default on the
KVM kernel module.
So, there's no reason to have VMX enabled by default on the core2duo and
coreduo CPU models, today. Even the newer Intel CPU model definitions
don't have i
Il 18/06/2014 18:59, Valentine Sinitsyn ha scritto:
I also noticed that setting PAT MSR from the nested hypervisor leaves
high word unassigned, i.e. the code like this:
mov $0x70106, %rax
mov %rax, %rdx
mov $0x0277, %rcx
wrmsr
rdmsr
yields %rax = 0, %rdx = 0x70106.
This should be t
https://bugzilla.kernel.org/show_bug.cgi?id=78331
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Il 18/06/2014 19:51, Nadav Amit ha scritto:
If you fix it, please fix both VMREAD and VMWRITE. If not, I would resubmit.
Yes, I'm fixing it myself.
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
ICC_SRE_EL1 is a system register allowing msr/mrs accesses to the
GIC CPU interface for EL1 (guests). Currently we force it to 0, but
for proper GICv3 support we have to allow guests to use it (depending
on their selected virtual GIC model).
So add ICC_SRE_EL1 to the list of saved/restored register
While the injection of a (virtual) inter-processor interrupt (SGI)
on a GICv2 works by writing to a MMIO register, GICv3 uses system
registers to trigger them.
Trap the appropriate registers both on ARM and ARM64 machines and
call the SGI handler function in the vGICv3 emulation code.
Signed-off-b
With everything separated and prepared, we implement a model of a
GICv3 distributor and redistributors by using the existing framework
to provide handler functions for each register group.
Currently we limit the emulation to a model enforcing a single
security state, with SRE==1 (forcing system reg
Currently we only have one virtual GIC model supported, so all guests
use the same emulation code. With the addition of another model we
end up with different guests using potentially different vGIC models,
so we have to split up some functions to be per VM.
Introduce a vgic_vm_ops struct to hold f
vgic.c is currently a mixture of generic vGIC emulation code and
functions specific to emulating a GICv2. To ease the addition of
GICv3, split off strictly v2 specific parts into a new file
vgic-v2-emul.c.
A new header file vgic.h is introduced to allow separation and later
sharing of functions.
S
Currently we only need to deal with one MMIO region for the GIC
emulation, but we soon need to extend this. Refactor the existing
code to allow easier addition of different ranges without code
duplication.
Signed-off-by: Andre Przywara
---
virt/kvm/arm/vgic.c | 72 +
With the introduction of a second emulated GIC model we need to let
userspace specify the GIC model to use for each VM. Pass the
userspace provided value down into the vGIC code to differentiate
later.
Signed-off-by: Andre Przywara
---
arch/arm/kvm/arm.c |2 +-
include/kvm/arm_vgic.h |
Currently the maximum number of vCPUs supported is a global value
limited by the used GIC model. GICv3 will lift this limit, but we
still need to observe it for guests using GICv2.
So the maximum number of vCPUs is per-VM value, depending on the
GIC model the guest uses.
Store and check the value i
The MMIO accessors for GICD_I[CS]ENABLER, GICD_I[CS]PENDR and
GICD_ICFGR behave very similiar in GICv3, although the way the
affected vCPU is determined differs.
Factor out a generic, backend-facing implementation and use small
wrappers in the current GICv2 emulation to ease code sharing later.
Si
With everything in place we allow userland to request the kernel
using a virtual GICv3 in the guest, which finally lifts the 8 vCPU
limit for a guest.
Also we provide the necessary support for guests setting the memory
addresses for the virtual distributor and redistributors.
This requires some use
GICv3 is the ARM generic interrupt controller designed to overcome
some limits of the prevalent GICv2. Most notably it lifts the 8-CPU
limit. Though with recent patches from Marc there is support for
hosts to use a GICv3, the CPU limitation still applies to KVM guests,
since the current code emulat
For a GICv2 there is always only one (v)CPU involved: the one that
does the access. On a GICv3 the access to a CPU redistributor is
memory-mapped, but not banked, so the (v)CPU affected is determined by
looking at the MMIO address region being accessed.
To allow passing the affected CPU into the ac
With all the necessary GICv3 emulation code in place, we can now
connect the code to the GICv3 backend in the kernel.
The LR register handling is different depending on the emulated GIC
model, so provide different implementations for each.
Also allow non-v2-compatible GICv3 implementations (which d
Some GICv3 registers can and will be accessed as 64 bit registers.
Currently the register handling code can only deal with 32 bit
accesses, so we do two consecutive calls to cover this.
Signed-off-by: Andre Przywara
---
virt/kvm/arm/vgic.c | 48 +---
The virtual MPIDR registers (containing topology information) for the
guest are currently mapped linearily to the vcpu_id. Improve this
mapping for arm64 by using three levels to not artificially limit the
number of vCPUs. Also add an accessor to later allow easier access to
a vCPU with a given MPI
On Wed, Jun 18, 2014 at 02:46:01PM -0400, Gabriel L. Somlo wrote:
> On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
> > On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
> > > mwait and monitor are currently handled as nop. Considering this
> > > behavior, they
> > > should still b
>From 6010e24da995d4161cb879e98fda989e3cdb41c4 Mon Sep 17 00:00:00 2001
From: Xiaoming Gao
Date: Thu, 19 Jun 2014 17:46:05 +0800
Subject: [PATCH] kvm: fix hyperv tsc page clear wrong address
tsc page addr need clear the low HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT bits
before kvm_write_guest write
Otherwise, the next test breaks with "vmxon failed".
Signed-off-by: Paolo Bonzini
---
x86/vmx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/x86/vmx.c b/x86/vmx.c
index 5bb5969..2d601cc 100644
--- a/x86/vmx.c
+++ b/x86/vmx.c
@@ -868,7 +868,7 @@ static int test_run(struct
This is more concisely
>From 6ddeb18347f9dda0fe37702e0d067a4129a89b54 Mon Sep 17 00:00:00 2001
From: Xiaoming Gao
Date: Thu, 19 Jun 2014 19:14:57 +0800
Subject: [PATCH] kvm: fix hyperv tsc page clear wrong address
tsc page addr need clear the low HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT bits
befor
Il 19/06/2014 13:17, "newtongao(??)" ha scritto:
This is more concisely
From 6ddeb18347f9dda0fe37702e0d067a4129a89b54 Mon Sep 17 00:00:00 2001
From: Xiaoming Gao
Date: Thu, 19 Jun 2014 19:14:57 +0800
Subject: [PATCH] kvm: fix hyperv tsc page clear wrong address
tsc page addr need clear the
On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
>
> On Jun 19, 2014, at 1:18 PM, Michael S. Tsirkin wrote:
>
> > On Wed, Jun 18, 2014 at 02:46:01PM -0400, Gabriel L. Somlo wrote:
> >> On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
> >>> On Wed, Jun 18, 2014 at 7:19 AM,
Il 18/06/2014 19:59, Eric Northup ha scritto:
On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
mwait and monitor are currently handled as nop. Considering this behavior, they
should still be handled correctly, i.e., check execution conditions and generate
exceptions when required. mwait and m
Il 09/06/2014 23:04, Bandan Das ha scritto:
A couple more updates to test_vmxon, test_vmptrld
and test_vmclear based on kvm commits -
3573e22cfecaac83f82ef4f6847d90e466fc8e10
KVM: nVMX: additional checks on vmxon region
96ec146330d18a938b4773be8d6dd1f93399507c
KVM: nVMX: fail on invalid vmclear
On 6/19/14, 2:23 PM, Gleb Natapov wrote:
On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
On Jun 19, 2014, at 1:18 PM, Michael S. Tsirkin wrote:
On Wed, Jun 18, 2014 at 02:46:01PM -0400, Gabriel L. Somlo wrote:
On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
On Wed
On Thu, Jun 19, 2014 at 02:52:20PM +0300, Nadav Amit wrote:
> On 6/19/14, 2:23 PM, Gleb Natapov wrote:
> >On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
> >>
> >>On Jun 19, 2014, at 1:18 PM, Michael S. Tsirkin wrote:
> >>
> >>>On Wed, Jun 18, 2014 at 02:46:01PM -0400, Gabriel L. Somlo
On Thu, Jun 19, 2014 at 02:52:20PM +0300, Nadav Amit wrote:
> On 6/19/14, 2:23 PM, Gleb Natapov wrote:
> >On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
> >>
> >>On Jun 19, 2014, at 1:18 PM, Michael S. Tsirkin wrote:
> >>
> >>>On Wed, Jun 18, 2014 at 02:46:01PM -0400, Gabriel L. Somlo
On 6/19/14, 3:07 PM, Gleb Natapov wrote:
On Thu, Jun 19, 2014 at 02:52:20PM +0300, Nadav Amit wrote:
On 6/19/14, 2:23 PM, Gleb Natapov wrote:
On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
On Jun 19, 2014, at 1:18 PM, Michael S. Tsirkin wrote:
On Wed, Jun 18, 2014 at 02:46:01P
On Thu, Jun 19, 2014 at 03:10:21PM +0300, Nadav Amit wrote:
> On 6/19/14, 3:07 PM, Gleb Natapov wrote:
> >On Thu, Jun 19, 2014 at 02:52:20PM +0300, Nadav Amit wrote:
> >>On 6/19/14, 2:23 PM, Gleb Natapov wrote:
> >>>On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
>
> On Jun 19,
On Thu, Jun 19, 2014 at 03:10:21PM +0300, Nadav Amit wrote:
> On 6/19/14, 3:07 PM, Gleb Natapov wrote:
> >On Thu, Jun 19, 2014 at 02:52:20PM +0300, Nadav Amit wrote:
> >>On 6/19/14, 2:23 PM, Gleb Natapov wrote:
> >>>On Thu, Jun 19, 2014 at 01:53:36PM +0300, Nadav Amit wrote:
>
> On Jun 19,
On 6/19/14, 3:17 PM, Michael S. Tsirkin wrote:
On Thu, Jun 19, 2014 at 03:10:21PM +0300, Nadav Amit wrote:
On 6/19/14, 3:07 PM, Gleb Natapov wrote:
On Thu, Jun 19, 2014 at 02:52:20PM +0300, Nadav Amit wrote:
On 6/19/14, 2:23 PM, Gleb Natapov wrote:
On Thu, Jun 19, 2014 at 01:53:36PM +0300, Na
The code currently is assuming fixed sized memory regions for the
distributor and CPU interface. GICv3 needs a dynamic allocation of
it's redistributor region, since it's size depends on the number of
vCPUs.
Also add the necessary code to create a GICv3 IRQ chip instance.
Signed-off-by: Andre Przy
Extend the vGIC handling code to deal with different IRQ chip devices
instead of hard-coding the GICv2 in.
Signed-off-by: Andre Przywara
---
tools/kvm/arm/aarch64/arm-cpu.c|2 +-
tools/kvm/arm/gic.c| 59
tools/kvm/arm/include/arm
Add the command line parameter "--gicv3" to request GICv3 emulation
in the kernel. Connect that to the already existing GICv3 code.
Signed-off-by: Andre Przywara
---
tools/kvm/arm/aarch64/arm-cpu.c|5 -
.../kvm/arm/aarch64/include/kvm/kvm-config-arch.h |4 +++-
t
This is a first version of the kvmtool changes needed for GICv3
emulation. Allows testing of the GICv3 emulation code and allows
creating guests with more than 8 VCPUs (given that in the host
CONFIG_KVM_ARM_MAX_VCPUS and in the guest CONFIG_NR_CPUS have been
raised accordingly).
Use --gicv3 to crea
This pulls the necessary defines for the GICv3 constants from the
Linux tree into kvmtool for now. Should be obsolete as soon as
the vGICv3 patches are upstream and kvmtool is rebased on top of
it.
Signed-off-by: Andre Przywara
---
arch/arm64/include/uapi/asm/kvm.h |6 ++
include/uapi/li
This reverts commit 87c00572ba05aa8c9db118da75c608f47eb10b9e.
OS X <= 10.7.* are the only known guests which realistically required
this functionality. As it turns out, OS X can be told to forego using
monitor/mwait by passing it "idlehalt=0" as a kernel argument, so we're
better off removing this
Hi Marc,
On Thu, Jun 19, 2014 at 10:19:27AM +0100, Marc Zyngier wrote:
> Linux has some requirements that must be satisfied in order to boot
> on a system built with a GICv3.
>
> Acked-by: Christoffer Dall
> Signed-off-by: Marc Zyngier
> ---
> Documentation/arm64/booting.txt | 6 ++
> 1 fi
Hi,
If I am not wrong I did not get any reply to this question. Can anyone
share his/her experience/knowledge on this gsi routing/irqfd use case?
Thank you in advance
Best Regards
Eric
On 06/17/2014 01:39 PM, Eric Auger wrote:
> Hello,
>
> I have a question related to KVM_IRQFD and KVM_SET_GS
> >+ * Failure to instantiate pages will abort guest entry.
> >+ *
> >+ * Page frames should be pinned with get_page in advance.
> >+ *
> >+ * Pinning is not guaranteed while executing as L2 guest.
>
> Does this undermine security?
It should not. In the worst case it'll randomly lose PEBS records
Hi all,
I'm currently adding VFIO support for kvmtool, so I'm interested in this
patch series (although actually from a PCI perspective).
Eric: can you CC me on future versions of this series please? Once things
start to stabilise, I can help with testing.
On Thu, Jun 05, 2014 at 03:39:50PM +010
Il 10/06/2014 23:06, Marcelo Tosatti ha scritto:
> BTW how about general PMU migration? As far as I can tell there
> is no code to save/restore the state for that currently, right?
Paolo wrote support for it, recently. Paolo?
Yes, on the KVM side all that is needed is to special case MSR reads
Il 02/06/2014 21:57, Andi Kleen ha scritto:
> It would be a bigger concern if we expected virtual PMU migration to
> work, but I think it would be nice to update kvm_pmu_cpuid_update() to
> notice the presence/absence of the new CPUID bits, and then store that
> into per-VM kvm_pmu->pebs_allowed
On 06/19/2014 04:13 PM, Will Deacon wrote:
> Hi all,
>
> I'm currently adding VFIO support for kvmtool, so I'm interested in this
> patch series (although actually from a PCI perspective).
>
> Eric: can you CC me on future versions of this series please? Once things
> start to stabilise, I can he
Hi,
I was hitting a BUG while running a couple of qemu 2.0 on a 3.15.0 kernel. KSM
was running. This box uses NUMA with two E5 6-core Xeons.
Linux toaster 3.15.0 #1 SMP PREEMPT Thu Jun 12 14:05:12 CEST 2014 x86_64
Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz GenuineIntel GNU/Linux
Jun 17 16:59:47
On Thu, Jun 19, 2014 at 06:30:38PM +0200, Ortwin Glück wrote:
> Hi,
>
> I was hitting a BUG while running a couple of qemu 2.0 on a 3.15.0 kernel.
> KSM was running. This box uses NUMA with two E5 6-core Xeons.
>
> Linux toaster 3.15.0 #1 SMP PREEMPT Thu Jun 12 14:05:12 CEST 2014 x86_64
> Intel
On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
> In KVM mode the bootrom is loaded and executed from the last 1MB of
> DRAM.
What is the reason for that? I am not opposed to that, but if it is
really needed, it means that loading a bootloader into the flash area
(for example YAMON) w
On Wed, Jun 18, 2014 at 05:00:47PM +0200, Paolo Bonzini wrote:
> Il 18/06/2014 00:10, James Hogan ha scritto:
> >The patchset depends on v4 of "target-mips: implement UserLocal
> >Register". I'm aiming for QEMU 2.1, hopefully it isn't too late to get
> >some final review.
> >
> >Thanks to everybody
> Userspace then can read/write these MSRs, and add them to the migration
> stream. QEMU has code for that.
Thanks. The PEBS setup always redoes its state, can be arbitarily often redone.
So the only change needed would be to add the MSRs to some list in qemu?
-Andi
--
a...@linux.intel.com --
Andi Kleen writes:
>>
>>> Signed-off-by: Kan Liang
>>
>> And here I thought that Andi was of the opinion that if you set CPUID to
>> indicate a particular CPU you had better also handle all its MSRs.
>
> Yes, philosophically that would be the right way,
> but we needed a short term fix to sto
Hi Mark,
On 19/06/14 15:01, Mark Rutland wrote:
> Hi Marc,
>
> On Thu, Jun 19, 2014 at 10:19:27AM +0100, Marc Zyngier wrote:
>> Linux has some requirements that must be satisfied in order to boot
>> on a system built with a GICv3.
>>
>> Acked-by: Christoffer Dall
>> Signed-off-by: Marc Zyngier
On Thu, Jun 19, 2014 at 11:17:19AM +0300, Gleb Natapov wrote:
> On Wed, Jun 18, 2014 at 08:12:07PM -0300, mtosa...@redhat.com wrote:
> > Reload remote vcpus MMU from GET_DIRTY_LOG codepath, before
> > deleting a pinned spte.
> >
> > Signed-off-by: Marcelo Tosatti
> >
> > ---
> > arch/x86/kvm/mm
On Thu, Jun 19, 2014 at 11:01:06AM +0300, Avi Kivity wrote:
>
> On 06/19/2014 02:12 AM, mtosa...@redhat.com wrote:
> >Allow vcpus to pin spte translations by:
> >
> >1) Creating a per-vcpu list of pinned ranges.
> >2) On mmu reload request:
> > - Fault ranges.
> > - Mark sptes with a pinne
On Thu, Jun 19, 2014 at 12:20:32PM +0300, Gleb Natapov wrote:
> CCing Marcelo,
>
> On Wed, Jun 18, 2014 at 02:50:44PM +0800, Tang Chen wrote:
> > Hi Gleb,
> >
> > Thanks for the quick reply. Please see below.
> >
> > On 06/18/2014 02:12 PM, Gleb Natapov wrote:
> > >On Wed, Jun 18, 2014 at 01:50:
On Thu, Jun 19, 2014 at 09:48:50AM +0300, Gleb Natapov wrote:
> On Wed, Jun 18, 2014 at 08:12:06PM -0300, mtosa...@redhat.com wrote:
> > Request KVM_REQ_MMU_RELOAD when deleting sptes from MMU notifiers.
> >
> > Keep pinned sptes intact if page aging.
> >
> > Signed-off-by: Marcelo Tosatti
> >
On Thu, Jun 19, 2014 at 10:21:16AM +0300, Gleb Natapov wrote:
> On Wed, Jun 18, 2014 at 08:12:05PM -0300, mtosa...@redhat.com wrote:
> > Allow vcpus to pin spte translations by:
> >
> > 1) Creating a per-vcpu list of pinned ranges.
> What if memory slot containing pinned range is going away?
->pa
On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote:
> On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
>> In KVM mode the bootrom is loaded and executed from the last 1MB of
>> DRAM.
>
> What is the reason for that? I am not opposed to that, but if it is
> really needed, it means tha
> > Userspace then can read/write these MSRs, and add them to the migration
> > stream. QEMU has code for that.
>
> Thanks. The PEBS setup always redoes its state, can be arbitarily often
> redone.
>
> So the only change needed would be to add the MSRs to some list in qemu?
Yes, and also adding
-Original Message-
From: kvmarm-boun...@lists.cs.columbia.edu
[mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Andre Przywara
Sent: Thursday, June 19, 2014 2:46 AM
To: linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
kvm@vger.kernel.org
Cc: christoffer.d...@
1 - 100 of 109 matches
Mail list logo
