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 opti
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: vm
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] K
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 spapr_tce_i
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 c
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
---
drivers/vfio/vfio_iommu_spapr_t
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
---
drivers/vfio/vfio_io
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 wind
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 it_map
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 table
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
---
arch/powerpc/
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 a
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 add
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.
Signed-off-by
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 IOMMU
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 tar
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 incorrec
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 e
On Aug 29, 2014, at 11:36 AM, Paolo Bonzini 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 same for the m
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 R
(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
On Aug 29, 2014, at 11:57 AM, Paolo Bonzini 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 the
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 iteratio
From: Pranavkumar Sawargaonkar
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 patch ensures that we flus
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:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/k
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 per
On Tue, Aug 26 2014 at 7:35:21 pm BST, Joel Schopp 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 inline voi
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 reposi
From: David Matlack
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 so that future access
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
---
arch/x86/kvm/mmu.c | 7 +--
virt/kvm/kvm_main.
From: David Matlack
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 again after
synchroniz
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 kvm_current_mmio_generat
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
---
arch/arm/
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 particularly
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.
These are not explicitly aligned, and do not require alignment on AVX.
Signed-off-by: Paolo Bonzini
---
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 0892622f9258..20d91873d831 100644
--- a/a
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
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
---
Pekka -- please take this as a fix, since merging the 3.16 sources has
caused some
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_type
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 ind
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 bo
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 ide
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
> patc
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 soft
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 mech
Now that AltiVec and hardware threading support are in place enable e6500 core.
Signed-off-by: Mihai Caraman
---
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 bf8f99f..2fdc872 100644
--- a/arc
On 08/27/2014 05:05 PM, Paolo Bonzini wrote:
>
>
> - Messaggio originale -
>> Da: "Chris J Arges"
>> A: "Paolo Bonzini" , kvm@vger.kernel.org
>> Inviato: Mercoledì, 27 agosto 2014 23:24:14
>> Oggetto: kvm-unit-test failures (was: [PATCH 1/2 v3] add check parameter to
>> run_tests config
On 25 May 2014 19:18, Christoffer Dall wrote:
> From: Anup Patel
>
> 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 KVM_EXIT_SYSTEM_EVENT for
> this purpose. We can
On Fri, Aug 29, 2014 at 12:58 AM, Paolo Bonzini 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 this on
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"
>>> A: "Paolo Bonzini" , kvm@vger.kernel.org
>>> Inviato: Mercoledì, 27 agosto 2014 23:24:14
>>> Oggetto: kvm-unit-test failures (was: [PAT
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 sus
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 i
Hi Andre,
On 29 August 2014 14:40, Andre Przywara 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 target type
>> for
Hi Andre,
On 29 August 2014 14:41, Andre Przywara 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 compatible stri
58 matches
Mail list logo
