Il 29/08/2014 02:13, Andy Lutomirski ha scritto:
Hmm. Then, assuming that someone manages to allocate a
cross-hypervisor MSR number for this, what am I supposed to do in the
KVM code? Just make it available unconditionally? I don't see why
that wouldn't work reliably, but it seems like an
Hi, all
I start a VM with virtio-serial (default ports number: 31), and found that
virtio-blk performance degradation happened, about 25%, this problem can be
reproduced 100%.
without virtio-serial:
4k-read-random 1186 IOPS
with virtio-serial:
4k-read-random 871 IOPS
but if use max_ports=2
Il 28/08/2014 20:02, Eduardo Habkost ha scritto:
Change the kvm-unit-tests x86 code to always check CPUID level/xlevel before
looking at CPUID data. Otherwise, the test code will be looking at bogus data.
Eduardo Habkost (3):
x86: apic: Look up MAXPHYADDR on CPUID correctly
x86: vmx:
Il 28/08/2014 23:10, David Matlack ha scritto:
Paolo,
It seems like this patch ([PATCH 2/2] kvm: x86: fix stale mmio cache)
is ready to go. Is there anything blocking it from being merged?
(It should be fine to merge this on its own, independent of the fix
discussed in [PATCH 1/2] KVM: fix
Modern IBM POWERPC systems support multiple IOMMU tables per PE
so we need a more reliable way (compared to container_of()) to get
a PE pointer from the iommu_table struct pointer used in IOMMU functions.
At the moment IOMMU group data points to an iommu_table struct. This
introduces a
This defines and implements VFIO IOMMU API which lets the userspace
create and remove DMA windows.
This updates VFIO_IOMMU_SPAPR_TCE_GET_INFO to return the number of
available windows and page mask.
This adds VFIO_IOMMU_SPAPR_TCE_CREATE and VFIO_IOMMU_SPAPR_TCE_REMOVE
to allow the user space to
There moves locked pages accounting to helpers.
Later they will be reused for Dynamic DMA windows (DDW).
While we are here, update the comment explaining why RLIMIT_MEMLOCK
might be required to be bigger than the guest RAM.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
This makes use of the it_page_size from the iommu_table struct
as page size can differ.
This replaces missing IOMMU_PAGE_SHIFT macro in commented debug code
as recently introduced IOMMU_PAGE_XXX macros do not include
IOMMU_PAGE_SHIFT.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
SPAPR defines an interface to create additional DMA windows dynamically.
Dynamically means that the window is not allocated before the guest
even started, the guest can request it later. In practice, existing linux
guests check for the capability and if it is there, they create and map
a DMA
This adds missing locks in iommu_take_ownership()/
iommu_release_ownership().
This marks all pages busy in iommu_table::it_map in order to catch
errors if there is an attempt to use this table while ownership over it
is taken.
This only clears TCE content if there is no page marked busy in
The previous patch introduced iommu_table_ops::exchange() callback
which effectively disabled VFIO on pseries. This implements exchange()
for pseries/lpar so VFIO can work in nested guests.
Since exchaange() callback returns an old TCE, it has to call H_GET_TCE
for every TCE being put to the
This adds a iommu_table_ops struct and puts pointer to it into
the iommu_table struct. This moves tce_build/tce_free/tce_get/tce_flush
callbacks from ppc_md to the new struct where they really belong to.
This adds an extra @ops parameter to iommu_init_table() to make sure
that we do not leave any
Normally a bitmap from the iommu_table is used to track what TCE entry
is in use. Since we are going to use iommu_table without its locks and
do xchg() instead, it becomes essential not to put bits which are not
implied in the direction flag.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
At the moment the iommu_table struct has a set_bypass() which enables/
disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
which calls this callback when external IOMMU users such as VFIO are
about to get over a PHB.
Since the set_bypass() is not really an iommu_table function
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such
At the moment pnv_pci_ioda_tce_invalidate() gets the PE pointer via
container_of(tbl). Since we are going to have to add Dynamic DMA windows
and that means having 2 IOMMU tables per PE, this is not going to work.
This implements pnv_pci_ioda(1|2)_tce_invalidate as a pnv_ioda_pe callback.
This
This checks that the TCE table page size is not bigger that the size of
a page we just pinned and going to put its physical address to the table.
Otherwise the hardware gets unwanted access to physical memory between
the end of the actual page and the end of the aligned up TCE page.
This enables PAPR defined feature called Dynamic DMA windows (DDW).
Each Partitionable Endpoint (IOMMU group) has a separate DMA window on
a PCI bus where devices are allows to perform DMA. By default there is
1 or 2GB window allocated at the host boot time and these windows are
used when an
Hi Anup,
On 26/08/14 10:22, Anup Patel wrote:
Instead, of trying out each and every target type we should
use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type
for KVM ARM/ARM64.
If KVM_ARM_PREFERRED_TARGET vm ioctl fails then we fallback to
old method of trying all known target
Unlike VMCALL, the instructions VMXOFF, VMLAUNCH and VMRESUME should cause a UD
exception in real-mode or vm86. However, the emulator considers all these
instructions the same for the matter of mode checks, and emulation upon exit
due to #UD exception.
As a result, the hypervisor behaves
Il 29/08/2014 10:26, Nadav Amit ha scritto:
Unlike VMCALL, the instructions VMXOFF, VMLAUNCH and VMRESUME should cause a
UD
exception in real-mode or vm86. However, the emulator considers all these
instructions the same for the matter of mode checks, and emulation upon exit
due to #UD
On Aug 29, 2014, at 11:36 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/08/2014 10:26, Nadav Amit ha scritto:
Unlike VMCALL, the instructions VMXOFF, VMLAUNCH and VMRESUME should cause a
UD
exception in real-mode or vm86. However, the emulator considers all these
instructions the
Il 29/08/2014 10:52, Nadav Amit ha scritto:
Patch looks good, but where is the check that MOD == 3 in the case
RMExt? Am I just not seeing it?
This seems to be part of the “case GroupDual”.
GroupDual handles it, but the EXT() macro you're using is exactly what
you want:
#define RMExt
(resent, that was the wrong account before ...)
Hi Anup,
On 26/08/14 10:22, Anup Patel wrote:
Instead, of trying out each and every target type we should
use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type
for KVM ARM/ARM64.
If KVM_ARM_PREFERRED_TARGET vm ioctl fails then we
Hi Anup,
On 26/08/14 10:22, Anup Patel wrote:
If in-kernel KVM support PSCI-0.2 emulation then we should set
KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also
provide arm,psci-0.2,arm,psci as PSCI compatible string.
This patch updates kvm_cpu__arch_init() and setup_fdt() as
per
On Aug 29, 2014, at 11:57 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/08/2014 10:52, Nadav Amit ha scritto:
Patch looks good, but where is the check that MOD == 3 in the case
RMExt? Am I just not seeing it?
This seems to be part of the “case GroupDual”.
GroupDual handles it, but
Il 29/08/2014 11:12, Nadav Amit ha scritto:
I don’t know. I am looking at Intel SDM table A-6 (Opcode Extensions
for One- and Two-byte Opcodes by Group Number). According to the
table, only group 7 needs RMExt, and in this case the “case
GroupDual” makes the required checks, in the iteration
From: Pranavkumar Sawargaonkar pranavku...@linaro.org
X-Gene u-boot runs in EL2 mode with MMU enabled hence we might
have stale EL2 tlb enteris when we enable EL2 MMU on each host CPU.
This can happen on any ARM/ARM64 board running bootloader in
Hyp-mode (or EL2-mode) with MMU enabled.
This
Hi Paolo and Gleb,
The following changes since commit 30d1e0e806e5b2fadc297ba78f2d7afd6ba309cf:
virt/kvm/assigned-dev.c: Set 'dev-irq_source_id' to '-1' after free it
(2014-08-19 15:12:28 +0200)
are available in the git repository at:
The architecture specifies that when the processor wakes up from a WFE
or WFI instruction, the instruction is considered complete, however we
currrently return to EL1 (or EL0) at the WFI/WFE instruction itself.
While most guests may not be affected by this because their local
exception handler
On Tue, Aug 26 2014 at 7:35:21 pm BST, Joel Schopp joel.sch...@amd.com wrote:
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..73f6ff6 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -166,6 +166,18 @@ static
Il 29/08/2014 11:59, Christoffer Dall ha scritto:
Hi Paolo and Gleb,
The following changes since commit 30d1e0e806e5b2fadc297ba78f2d7afd6ba309cf:
virt/kvm/assigned-dev.c: Set 'dev-irq_source_id' to '-1' after free it
(2014-08-19 15:12:28 +0200)
are available in the git repository at:
From: David Matlack dmatl...@google.com
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
the SPTE write-execute-noread
The next patch will give a meaning (a la seqcount) to the low bit of the
generation number. Ensure that it matches between kvm-memslots-generation
and kvm_current_mmio_generation().
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/mmu.c | 7 +--
From: David Matlack dmatl...@google.com
vcpu exits and memslot mutations can run concurrently as long as the
vcpu does not aquire the slots mutex. Thus it is theoretically possible
for memslots to change underneath a vcpu that is handling an exit.
If we increment the memslot generation number
David and Xiao, here's my take on the MMIO generation patches. Now
with documentation, too. :) Please review!
David Matlack (2):
kvm: fix potentially corrupt mmio cache
kvm: x86: fix stale mmio cache bug
Paolo Bonzini (1):
KVM: do not bias the generation number in
Opaque KVM structs are useful for prototypes in asm/kvm_host.h, to avoid
'struct foo' declared inside parameter list warnings (and consequent
breakage due to conflicting types).
Move them from individual files to a generic place in linux/kvm_types.h.
Signed-off-by: Paolo Bonzini
After its publication about 10 months ago, the Jailhouse partitioning
hypervisor for Linux [1] reached an important first milestone: all major
features required to use Jailhouse on Intel x86 CPUs are now available.
We are marking this point with a first release tag, v0.1.
This release
2014-08-29 14:01+0200, Paolo Bonzini:
Opaque KVM structs are useful for prototypes in asm/kvm_host.h, to avoid
'struct foo' declared inside parameter list warnings (and consequent
breakage due to conflicting types).
Move them from individual files to a generic place in linux/kvm_types.h.
These are not explicitly aligned, and do not require alignment on AVX.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/emulate.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index
Il 11/07/2014 19:56, Alex Williamson ha scritto:
Windows 8.1 guest with NVIDIA driver and GPU fails to boot with an
emulation failure. The KVM spew suggests the fault is with lack of
movntdq emulation (courtesy of Paolo):
Code=02 00 00 b8 08 00 00 00 f3 0f 6f 44 0a f0 f3 0f 6f 4c 0a e0 66
The kernel now exposes register accessor macros in the uapi/ headers
for arm and arm64, so use those instead (and avoid the compile failure
from the duplicate definitions).
Signed-off-by: Will Deacon will.dea...@arm.com
---
Pekka -- please take this as a fix, since merging the 3.16 sources has
On 29/08/14 14:01, Paolo Bonzini wrote:
Opaque KVM structs are useful for prototypes in asm/kvm_host.h, to avoid
'struct foo' declared inside parameter list warnings (and consequent
breakage due to conflicting types).
Move them from individual files to a generic place in linux/kvm_types.h.
Il 29/08/2014 14:46, Radim Krčmář ha scritto:
2014-08-29 14:01+0200, Paolo Bonzini:
Opaque KVM structs are useful for prototypes in asm/kvm_host.h, to avoid
'struct foo' declared inside parameter list warnings (and consequent
breakage due to conflicting types).
Move them from individual
On (Fri) 29 Aug 2014 [15:45:30], Zhang Haoyu wrote:
Hi, all
I start a VM with virtio-serial (default ports number: 31), and found that
virtio-blk performance degradation happened, about 25%, this problem can be
reproduced 100%.
without virtio-serial:
4k-read-random 1186 IOPS
with
On Fri, Aug 29, 2014 at 10:10:52AM +0100, Andre Przywara wrote:
(resent, that was the wrong account before ...)
Aha, and now your true identity has been revealed to all! Nice try Andre...
or should I say, Rienhard?
Will
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On 29/08/14 17:17, Will Deacon wrote:
On Fri, Aug 29, 2014 at 10:10:52AM +0100, Andre Przywara wrote:
(resent, that was the wrong account before ...)
Aha, and now your true identity has been revealed to all! Nice try Andre...
or should I say, Rienhard?
Psst, don't give Google funny ideas
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
Section 11.11.2.3 of the SDM mentions All other bits in the
IA32_MTRR_PHYSBASEn
and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
general-protection exception(#GP) if software attempts to write to them.
This
patch do it
On 2014-08-29 18:47, Paolo Bonzini wrote:
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
Section 11.11.2.3 of the SDM mentions All other bits in the
IA32_MTRR_PHYSBASEn
and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
general-protection exception(#GP) if software
ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.
The e6500 core shares TLBs between hardware threads. Without tlb write
conditional instruction, the Linux kernel uses per core
Now that AltiVec and hardware threading support are in place enable e6500 core.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
arch/powerpc/kvm/e500mc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index
On 08/27/2014 05:05 PM, Paolo Bonzini wrote:
- Messaggio originale -
Da: Chris J Arges chris.j.ar...@canonical.com
A: Paolo Bonzini pbonz...@redhat.com, kvm@vger.kernel.org
Inviato: Mercoledì, 27 agosto 2014 23:24:14
Oggetto: kvm-unit-test failures (was: [PATCH 1/2 v3] add check
On 25 May 2014 19:18, Christoffer Dall christoffer.d...@linaro.org wrote:
From: Anup Patel anup.pa...@linaro.org
Currently, we don't have an exit reason to notify user space about
a system-level event (for e.g. system reset or shutdown) triggered
by the VCPU. This patch adds exit reason
On Fri, Aug 29, 2014 at 12:58 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/08/2014 23:10, David Matlack ha scritto:
Paolo,
It seems like this patch ([PATCH 2/2] kvm: x86: fix stale mmio cache)
is ready to go. Is there anything blocking it from being merged?
(It should be fine to merge
On 08/29/2014 12:36 PM, Chris J Arges wrote:
On 08/27/2014 05:05 PM, Paolo Bonzini wrote:
- Messaggio originale -
Da: Chris J Arges chris.j.ar...@canonical.com
A: Paolo Bonzini pbonz...@redhat.com, kvm@vger.kernel.org
Inviato: Mercoledì, 27 agosto 2014 23:24:14
Oggetto:
Il 29/08/2014 19:36, Chris J Arges ha scritto:
I still get failures with the following test, I actually tested on
multiple machines with identical hardware and the same failure occurred.
In v3.13/v3.16 series kernels this passes. I'll look into which commit
changed this result for me. I
On 08/29/2014 04:08 PM, Paolo Bonzini wrote:
Il 29/08/2014 19:36, Chris J Arges ha scritto:
I still get failures with the following test, I actually tested on
multiple machines with identical hardware and the same failure occurred.
In v3.13/v3.16 series kernels this passes. I'll look into
Hi Andre,
On 29 August 2014 14:40, Andre Przywara andre.przyw...@arm.com wrote:
(resent, that was the wrong account before ...)
Hi Anup,
On 26/08/14 10:22, Anup Patel wrote:
Instead, of trying out each and every target type we should
use KVM_ARM_PREFERRED_TARGET vm ioctl to determine
Hi Andre,
On 29 August 2014 14:41, Andre Przywara andre.przyw...@arm.com wrote:
Hi Anup,
On 26/08/14 10:22, Anup Patel wrote:
If in-kernel KVM support PSCI-0.2 emulation then we should set
KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also
provide arm,psci-0.2,arm,psci as PSCI
Now that AltiVec and hardware threading support are in place enable e6500 core.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
arch/powerpc/kvm/e500mc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index
60 matches
Mail list logo
