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,
genericv8_target_table);
+
4.0-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire hof...@osadl.org
commit ed9244e6c534612d2b5ae47feab2f55a0d4b4ced upstream.
Fix possible unintended sign extension in unsigned MMIO loads by casting
to uint16_t in the case of
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 that adds generic support for ARMv8 KVM
targets. I want to
On Wed, Jun 03, 2015 at 11:38:21AM +0200, Paolo Bonzini wrote:
On 03/06/2015 01:51, Steve Rutherford wrote:
In order to enable userspace PIC support, the userspace PIC needs to
be able to inject local interrupt requests.
This adds the ioctl KVM_REQUEST_PIC_INJECTION and kvm exit
On Fri, 2015-06-19 at 17:21 +1000, Michael Ellerman wrote:
Now that we don't have the kernel header on hand, just define the
minimum set of hcall opcodes and return values we need in order to
build.
Hi Andre,
I hope you don't mind me jumping in here but I thought I should help out rather
than
On Fri, 2015-06-19 at 17:21 +1000, Michael Ellerman wrote:
Now that we don't have the kernel header on hand, just define the
minimum set of hcall opcodes and return values we need in order to
build.
Hi Andre,
I hope you don't mind me jumping in here but I thought I should help out rather
than
We have always built kvmtool as 64-bit on powerpc, but mainly just out
of habit. There's not AFAIK any reason we *can't* build 32-bit.
So fix up a few places where we were assuming 64-bit, and drop the
Makefile logic that forces 64-bit.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
Now that we don't have the kernel header on hand, just define the
minimum set of hcall opcodes and return values we need in order to
build.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
powerpc/spapr.h | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
We have always built kvmtool as 64-bit on powerpc, but mainly just out
of habit. There's not AFAIK any reason we *can't* build 32-bit.
So fix up a few places where we were assuming 64-bit, and drop the
Makefile logic that forces 64-bit.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
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 detect whether a routing table is needed.
Yesterday,
On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it.
On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will cause a
mmap(MAP_NORESERVE), which _does_ have the effect of making the hva go
away.
I guess one way to do
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap releases it.
Paolo
Confused. So can we call mmap(MAP_NORESERVE) in address_space_unmap
after we detect
On Fri, Jun 19, 2015 at 08:21:00AM +0100, Michael Ellerman wrote:
Now that we don't have the kernel header on hand, just define the
minimum set of hcall opcodes and return values we need in order to
build.
Thanks Michael!
I pushed both of these out.
Will
--
To unsubscribe from this list:
On 19/06/2015 12:28, Andrey Smetanin wrote:
On Wed, 2015-06-17 at 14:44 +0200, Paolo Bonzini wrote:
On 11/06/2015 15:18, Denis V. Lunev wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
Windows 2012 guests can notify hypervisor about occurred guest crash
(Windows bugcheck(BSOD)) by
Due to our kernel heritage we have code in kvmtool that relies on
the (still) implicit -std=gnu89 compiler switch.
It turns out that this just affects some structure initialization,
where we currently provide a cast to the type, which upsets GCC for
anything beyond -std=gnu89 (for instance gnu99
On 19/06/15 00:49, Mario Smarduch wrote:
On 06/18/2015 10:27 AM, Marc Zyngier wrote:
On 16/06/15 22:50, Mario Smarduch wrote:
After enhancing arm64 FP/SIMD exit handling, FP/SIMD exit branch is moved
to guest trap handling. This keeps exiting handling flow between both
architectures
This is a precursor for later patches which will need to do more to
setup debug state before entering the hyp.S switch code. The existing
functionality for setting mdcr_el2 has been moved out of hyp.S and now
uses the value kept in vcpu-arch.mdcr_el2.
As the assembler used to previously mask and
This introduces a level of indirection for the debug registers. Instead
of using the sys_regs[] directly we store registers in a structure in
the vcpu. As we are no longer tied to the layout of the sys_regs[] we
can make the copies size appropriate for control and value registers.
This also
Hi Paolo,
Thanks a lot!
On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 19/06/2015 03:52, Hu Yaohui wrote:
Hi All,
In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
the L1
This adds support for userspace to control the HW debug registers for
guest debug. In the debug ioctl we copy the IMPDEF defined number of
registers into a new register set called host_debug_state. There is now
a new vcpu parameter called debug_ptr which selects which register set
is to copied
Commit fd1d0ddf2ae9 (KVM: arm/arm64: check IRQ number on userland
injection) rightly limited the range of interrupts userspace can
inject in a guest, but failed to consider the (unlikely) case where
a guest is configured with 1024 interrupts.
In this case, interrupts ranging from 1020 to 1023 are
This includes trace points for:
kvm_arch_setup_guest_debug
kvm_arch_clear_guest_debug
I've also added some generic register setting trace events and also a
trace point to dump the array of hardware registers.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v3
- add trace event for
Back in the days, vgic.c used to have an intimate knowledge of
the actual GICv2. These days, this has been abstracted away into
hardware-specific backends.
Remove the now useless arm-gic.h #include directive, making it
clear that GICv2 specific code doesn't belong here.
Signed-off-by: Marc
Finally advertise the KVM capability for SET_GUEST_DEBUG. Once arm
support is added this check can be moved to the common
kvm_vm_ioctl_check_extension() code.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
Acked-by: Christoffer Dall christoffer.d...@linaro.org
---
v3:
- separated capability
The GIC Hypervisor Configuration Register is used to enable
the delivery of virtual interupts to a guest, as well as to
define in which conditions maintenance interrupts are delivered
to the host.
This register doesn't contain any information that we need to
read back (the EOIcount is utterly
From: Alex Bennée alex.ben...@linaro.org
The elr_el2 and spsr_el2 registers in fact contain the processor state
before entry into EL2. In the case of guest state it could be in either
el0 or el1.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.
On VM exit, we restore access, test if we did enable them before,
and save/restore the guest/host registers if necessary. In this
sequence, the FPEXC register is always accessed,
From: Lorenzo Pieralisi lorenzo.pieral...@arm.com
According to the PSCI specification and the SMC/HVC calling
convention, PSCI function_ids that are not implemented must
return NOT_SUPPORTED as return value.
Current KVM implementation takes an unhandled PSCI function_id
as an error and injects
From: Andre Przywara andre.przyw...@arm.com
Commit 47a98b15ba7c (arm/arm64: KVM: support for un-queuing active
IRQs) introduced handling of the GICD_I[SC]ACTIVER registers,
but only for the GICv2 emulation. For the sake of completeness and
as this is a pre-requisite for save/restore of the GICv3
From: Christoffer Dall christoffer.d...@linaro.org
Until now we have been calling kvm_guest_exit after re-enabling
interrupts when we come back from the guest, but this has the
unfortunate effect that CPU time accounting done in the context of timer
interrupts occurring while the guest is running
From: Tiejun Chen tiejun.c...@intel.com
We already check KVM_CAP_IRQFD in generic once enable CONFIG_HAVE_KVM_IRQFD,
kvm_vm_ioctl_check_extension_generic()
|
+ switch (arg) {
+ ...
+ #ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD:
+ #endif
+ ...
+
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap
On 12/06/2015 07:34, Wei Huang wrote:
This patch defines a new function pointer struct (kvm_pmu_ops) to
support vPMU for both Intel and AMD. The functions pointers defined in
this new struct will be linked with Intel and AMD functions later. In the
meanwhile the struct that maps from
This adds support for single-stepping the guest. To do this we need to
manipulate the guests PSTATE.SS and MDSCR_EL1.SS bits to trigger
stepping. We take care to preserve MDSCR_EL1 and trap access to it to
ensure we don't affect the apparent state of the guest.
As we have to enable trapping of
The elr_el2 and spsr_el2 registers in fact contain the processor state
before entry into the hypervisor code. In the case of guest state it
could be in either el0 or el1.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
arch/arm64/kvm/hyp.S | 8
1 file changed, 4 insertions(+), 4
This adds support for SW breakpoints inserted by userspace.
We do this by trapping all guest software debug exceptions to the
hypervisor (MDCR_EL2.TDE). The exit handler sets an exit reason of
KVM_EXIT_DEBUG with the kvm_debug_exit_arch structure holding the
exception syndrome information.
It
This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
ioctl. Any unsupported flag will return -EINVAL. For now, only
KVM_GUESTDBG_ENABLE is supported, although it won't have any effects.
Signed-off-by: Alex Bennée alex.ben...@linaro.org.
Reviewed-by: Christoffer Dall
This commit defines the API headers for guest debugging. There are two
architecture specific debug structures:
- kvm_guest_debug_arch, allows us to pass in HW debug registers
- kvm_debug_exit_arch, signals exception and possible faulting address
The type of debugging being used is controlled
Bring into line with the comments for the other structures and their
KVM_EXIT_* cases. Also update api.txt to reflect use in kvm_run
documentation.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: David Hildenbrand d...@linux.vnet.ibm.com
Reviewed-by: Andrew Jones drjo...@redhat.com
This is a pre-cursor to sharing the code with the guest debug support.
This replaces the big macro that fishes data out of a fixed location
with a more general helper macro to restore a set of debug registers. It
uses macro substitution so it can be re-used for debug control and value
registers.
On Fri, Jun 19, 2015 at 08:21:00AM +0100, Michael Ellerman wrote:
Now that we don't have the kernel header on hand, just define the
minimum set of hcall opcodes and return values we need in order to
build.
Thanks Michael!
I pushed both of these out.
Will
--
To unsubscribe from this list:
On 12/06/2015 07:34, Wei Huang wrote:
-static void trigger_pmi(struct irq_work *irq_work)
+static void kvm_pmi_trigger_fn(struct irq_work *irq_work)
{
- struct kvm_pmu *pmu = container_of(irq_work, struct kvm_pmu,
- irq_work);
- struct kvm_vcpu *vcpu =
From: Kim Phillips kim.phill...@linaro.org
The KVM-VFIO device is used by the QEMU VFIO device. It is used to
record the list of in-use VFIO groups so that KVM can manipulate
them.
Signed-off-by: Kim Phillips kim.phill...@linaro.org
Signed-off-by: Eric Auger eric.au...@linaro.org
Signed-off-by:
Paolo, Marcelo, Gleb,
This is the KVM/ARM pull request for 4.2. Not much this time, as what
we had planned for this merge window is taking longer that
expected. 4.3 should be a lot more significant.
Thanks,
M.
The following changes since commit 3520469d65f26a1cd2f610f5d5de976f78db74fe:
From: Firo Yang fir...@gmail.com
No need to cast the void pointer returned by kmalloc() in
arch/arm/kvm/mmu.c::kvm_alloc_stage2_pgd().
Signed-off-by: Firo Yang fir...@gmail.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/kvm/mmu.c |
If a GICv3-enabled guest tries to configure Group0, we print a
warning on the console (because we don't support Group0 interrupts).
This is fairly pointless, and would allow a guest to spam the
console. Let's just drop the warning.
Acked-by: Christoffer Dall christoffer.d...@linaro.org
Here is V6 of the KVM Guest Debug support for arm64.
The changes are even more minimal than the last round which is
hopefully a good indication the series is ready for merging:
API/ABI Changes:
- returned to using u64 for control registers
- renamed
On 19/06/2015 03:52, Hu Yaohui wrote:
Hi All,
In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
the L1 guest writes to the guest EPT(EPT12). How can the shadow
EPT(EPT02) be modified according?
Because
Now that we don't have the kernel header on hand, just define the
minimum set of hcall opcodes and return values we need in order to
build.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
powerpc/spapr.h | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
On Fri, Jun 19, 2015 at 09:57:22AM +0200, Paolo Bonzini wrote:
On 19/06/2015 09:56, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap releases
it.
Paolo
Hi Paolo,
On 19/06/15 10:59, Paolo Bonzini wrote:
On 18/06/2015 17:50, Andre Przywara wrote:
Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
for LD.
Allow people to override the compiler name by specifying it explicitly
on the command line or via the environment.
Hi Michael,
On 19/06/15 02:14, Michael Ellerman wrote:
On Thu, 2015-06-18 at 16:50 +0100, Andre Przywara wrote:
Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
for LD.
Allow people to override the compiler name by specifying it explicitly
on the command line or via the
Hi Michael,
On 19/06/15 02:14, Michael Ellerman wrote:
On Thu, 2015-06-18 at 16:50 +0100, Andre Przywara wrote:
Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
for LD.
Allow people to override the compiler name by specifying it explicitly
on the command line or via the
On 18/06/2015 17:50, Andre Przywara wrote:
Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
for LD.
Allow people to override the compiler name by specifying it explicitly
on the command line or via the environment.
Beside calling a certain compiler binary this allows to
On 18/06/2015 17:50, Andre Przywara wrote:
Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
for LD.
Allow people to override the compiler name by specifying it explicitly
on the command line or via the environment.
Beside calling a certain compiler binary this allows to
On Wed, 2015-06-17 at 14:44 +0200, Paolo Bonzini wrote:
On 11/06/2015 15:18, Denis V. Lunev wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
Windows 2012 guests can notify hypervisor about occurred guest crash
(Windows bugcheck(BSOD)) by writing specific Hyper-V msrs. This patch
On 19/06/2015 09:56, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will cause a
mmap(MAP_NORESERVE), which _does_ have the effect of making
On Tue, Jun 16, 2015 at 05:35:51PM -0700, Andy Lutomirski wrote:
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ([PATCH] paravirt: header
and stubs for paravirtualisation). AFAICT the only paravirt guest
implementation that ever
While the code looks great, the splitting of patches 1 and 2
left something to be desired. I've redone the split altogether
and I'll place it soon in kvm/queue because I needed to do it myself
to figure out some suggestions; and after 4 hours it would have been
pointless for you to do the work
On 19/06/2015 14:44, Hu Yaohui wrote:
Hi Paolo,
Thanks a lot!
On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 19/06/2015 03:52, Hu Yaohui wrote:
Hi All,
In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
nested EPT. The shadow EPT(EPT02) is
On 19/06/2015 14:53, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvm-arm-for-4.2
for you to fetch changes up to c62e631d4a8e41493c6341d8259e996ed5fc11e3:
KVM: arm/arm64: vgic: Remove useless arm-gic.h #include (2015-06-18
15:50:31
On 06/19/2015 06:30 AM, Paolo Bonzini wrote:
On 12/06/2015 07:34, Wei Huang wrote:
This patch defines a new function pointer struct (kvm_pmu_ops) to
support vPMU for both Intel and AMD. The functions pointers defined in
this new struct will be linked with Intel and AMD functions later.
I understand that the original patch2 was huge. Thanks for taking care
of it (and the tips). I reviewed the diff below and they are reasonable.
-Wei
On 06/19/2015 10:14 AM, Paolo Bonzini wrote:
While the code looks great, the splitting of patches 1 and 2
left something to be desired. I've
On 06/19/2015 06:31 AM, Paolo Bonzini wrote:
On 12/06/2015 07:34, Wei Huang wrote:
-static void trigger_pmi(struct irq_work *irq_work)
+static void kvm_pmi_trigger_fn(struct irq_work *irq_work)
{
-struct kvm_pmu *pmu = container_of(irq_work, struct kvm_pmu,
-
On 19/06/2015 15:34, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction
Hi Michael,
On 19/06/15 02:08, Michael Ellerman wrote:
On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote:
Hi,
On 06/17/2015 10:43 AM, Andre Przywara wrote:
For converting the guest/init binary into an object file, we call
the linker binary, setting the endianness to big endian
On Fri, Jun 19, 2015 at 8:32 AM, Borislav Petkov b...@suse.de wrote:
On Tue, Jun 16, 2015 at 05:35:51PM -0700, Andy Lutomirski wrote:
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ([PATCH] paravirt: header
and stubs for
On Fri, Jun 19, 2015 at 05:19:44PM +0200, Paolo Bonzini wrote:
On 19/06/2015 15:34, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +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 audit all address_space_map uses.
No need to audit them all: defer device_add using an hva range until
address_space_unmap drops using hvas in range
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap releases
it.
Paolo
On 19/06/2015 18:33, Michael S. Tsirkin 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 audit all address_space_map uses.
No
Hi Michael,
On 19/06/15 02:08, Michael Ellerman wrote:
On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote:
Hi,
On 06/17/2015 10:43 AM, Andre Przywara wrote:
For converting the guest/init binary into an object file, we call
the linker binary, setting the endianness to big endian
On 19/06/2015 18:45, Michael S. Tsirkin wrote:
user guest QEMU
start I/O
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 audit all address_space_map uses.
No need to audit them all: defer device_add
On Fri, Jun 19, 2015 at 09:14:14AM -0700, Andy Lutomirski wrote:
Want to fix up the commit message? It seems silly to re-send the
whole series for this.
Of couse, done.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list:
On Mon, Jun 08, 2015 at 09:33:50AM +0100, James Hogan wrote:
Hi stable folk,
On 08/05/15 15:16, James Hogan wrote:
On 07/05/15 13:47, Nicholas Mc Guire wrote:
Fix possible unintended sign extension in unsigned MMIO loads by casting
to uint16_t in the case of mmio_needed != 2.
Thanks a lot! It's much straightforward to me right now.
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? According to the
79 matches
Mail list logo
