Il 19/08/2014 04:17, Wanpeng Li ha scritto:
-if (level == 1 || (level == 2 (spte (1ULL 7
{
+if (level == 1 || ((level == 3 || level == 2)
+ (spte (1ULL 7 {
This condition can be simplified by checking the
This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=61411
TPR shadow/threshold feature is important to speed up the Windows guest.
Besides, it is a must feature for certain VMM.
We map virtual APIC page address and TPR threshold from L1 VMCS. If
TPR_BELOW_THRESHOLD VM exit is
Il 19/08/2014 05:50, Xiao Guangrong ha scritto:
Note in the step *, my approach detects the invalid generation-number which
will invalidate the mmio spte properly .
You are right, in fact my mail included another part: Another
alternative could be to use the low bit to mark an in-progress
Il 19/08/2014 10:30, Wanpeng Li ha scritto:
+ if (vmx-nested.virtual_apic_page)
+ nested_release_page(vmx-nested.virtual_apic_page);
+ vmx-nested.virtual_apic_page =
+nested_get_page(vcpu, vmcs12-virtual_apic_page_addr);
+
That was just one example. There many other possibilities. Either
actually make the systems load all host CPUs equally, or divide
throughput by host CPU.
The polling patch adds this capability to vhost, reducing costly exit
overhead when the vm is loaded.
In order to load the vm I ran
On 07/08/14 15:40, Paolo Bonzini wrote:
Il 07/08/2014 11:59, Christian Borntraeger ha scritto:
Paolo,
are you willing to apply to kvm/queue?
I asked a question, but anyway... not until the end of the merge window
and my small vacation. :)
Paolo
Absolutely, was on vacation myself :-)
On 07/08/14 15:39, Paolo Bonzini wrote:
Il 05/08/2014 16:44, Christian Borntraeger ha scritto:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by
On 08/19/2014 04:28 PM, Paolo Bonzini wrote:
Il 19/08/2014 05:50, Xiao Guangrong ha scritto:
Note in the step *, my approach detects the invalid generation-number which
will invalidate the mmio spte properly .
You are right, in fact my mail included another part: Another
alternative could
On 08/13/2014 04:55 PM, Christoffer Dall wrote:
On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
a kvm_irqfd
On 08/13/2014 04:55 PM, Christoffer Dall wrote:
On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
a kvm_irqfd
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings reserved for
future functionality. However, the handler can't identify if
paging-structure entry of reserved bits
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings reserved for
future functionality. However, the handler can't
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 in kvm.
Signed-off-by: Wanpeng Li
The first entry in each pair(IA32_MTRR_PHYSBASEn) defines the base
address and memory type for the range; the second entry(IA32_MTRR_PHYSMASKn)
contains a mask used to determine the address range. The legal values
for the type field of IA32_MTRR_PHYSBASEn are 0,1,4,5, and 6. However,
Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
Okay, what confused me it that it seems that the single line patch
is ok to you. :)
No, it was late and I was confused. :)
Now, do we really need to care the case 2? like David said:
Sorry I didn't explain myself very well: Since we can get a
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
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset functions, e.g.
during
CPU creation. This is the first hickup and the pid now points to the main
On 19/08/14 11:27, Paolo Bonzini wrote:
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset functions, e.g.
during
CPU creation. This is the first
Il 18/08/2014 21:43, Nadav Amit ha scritto:
Currently, the TSC deadline test never runs, since TSC deadline is disabled
unless the host cpu parameter is used. This patch changes the apic test to use
the qemu host cpu parameter.
Better use
Signed-off-by: Nadav Amit na...@cs.technion.ac.il
---
Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
On 19/08/14 11:27, Paolo Bonzini wrote:
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be
hiding a bug in QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset
On 19/08/14 11:53, Paolo Bonzini wrote:
Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
On 19/08/14 11:27, Paolo Bonzini wrote:
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be
hiding a bug in QEMU.
On s390 we call
On Tue, Aug 19, 2014 at 10:53:16AM +0200, Eric Auger wrote:
On 08/13/2014 04:55 PM, Christoffer Dall wrote:
On Mon, Aug 04, 2014 at 02:08:22PM +0200, Eric Auger wrote:
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger.
Il 19/08/2014 11:59, Christian Borntraeger ha scritto:
Its only for the interrupts that are cpu local (like pending IPIs).
In addition, we would do that only for the reset case (with an
interface that can be used for migration). Right now
KVM_S390_INITIAL_RESET takes the vcpu_mutex, so this
Il 18/08/2014 21:43, Nadav Amit ha scritto:
Once the local-apic timer is configured to use TSC deadline, the deadline
should be cleared after the deadline passes. This patch adds a check of this
behavior.
Signed-off-by: Nadav Amit na...@cs.technion.ac.il
---
x86/apic.c | 1 +
1 file
On 19/08/14 12:03, Paolo Bonzini wrote:
Il 19/08/2014 11:59, Christian Borntraeger ha scritto:
Its only for the interrupts that are cpu local (like pending IPIs).
In addition, we would do that only for the reset case (with an
interface that can be used for migration). Right now
Juan Quintela quint...@redhat.com wrote:
Hi
Please, send any topic that you are interested in covering.
People have complained on the past that I don't cancel the call until
the very last minute. So, what do you think that deadline for
submitting topics is 23:00UTC on Monday?
As there are
Il 17/08/2014 21:34, Nadav Amit ha scritto:
Commit 5045b46803 added a check that cs.dpl equals cs.rpl during task-switch.
This is a wrong check, and this test introduces a test in which cs.dpl !=
cs.rpl. To do so, it configures tss.cs to be conforming with rpl=3 and dpl=0.
Since the cpl after
Il 19/08/2014 12:09, Christian Borntraeger ha scritto:
I'm not sure, this does seem like a workaround for another
limitation after all... Gleb?
Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes
from a time, when we had another userspace prototype for KVM on s390
(kuli).
Il 18/08/2014 23:03, Nadav Amit ha scritto:
Currently, recalculate_apic_map ignores vcpus whose lapic is software disabled
through the spurious interrupt vector. However, once it is re-enabled, the map
is not recalculated. Therefore, if the guest OS configured DFR while lapic is
Il 18/08/2014 21:42, Nadav Amit ha scritto:
Intel SDM 10.5.4.1 says When the timer generates an interrupt, it disarms
itself and clears the IA32_TSC_DEADLINE MSR.
This patch clears the MSR upon timer interrupt delivery which delivered on
deadline mode. Since the MSR may be reconfigured
On 19/08/14 12:31, Paolo Bonzini wrote:
Il 19/08/2014 12:09, Christian Borntraeger ha scritto:
I'm not sure, this does seem like a workaround for another
limitation after all... Gleb?
Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes
from a time, when we had another
Il 19/08/2014 12:48, Christian Borntraeger ha scritto:
But I understand your concern of touching generic KVM code only if
really necessary. Let me know if I should send a minimal pid==0
version. (I would prefer the full version, of course).
Yes, please do.
Paolo
--
To unsubscribe from this
On Tue, Aug 19, 2014 at 11:09:49AM +0200, Paolo Bonzini wrote:
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn-slot-base_gfn'
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
virt/kvm/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 0df7d4b..c02f9a3
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset functions, e.g.
during
CPU creation. This is the first hickup and the pid now points to the
To support read-only memory regions on arm and arm64, we have a need to
resolve a gfn to an hva given a pointer to a memslot to avoid looping
through the memslots twice and to reuse the hva error checking of
gfn_to_hva_prot(), add a new gfn_to_hva_memslot_prot() function and
refactor
When userspace loads code and data in a read-only memory regions, KVM
needs to be able to handle this on arm and arm64. Specifically this is
used when running code directly from a read-only flash device; the
common scenario is a UEFI blob loaded with the -bios option in QEMU.
Note that the MMIO
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any reasons
why kvm_cpu_synchronize_post_reset() doesn't do the same (e.g. called from
Il 19/08/2014 13:16, Wanpeng Li ha scritto:
On Tue, Aug 19, 2014 at 11:09:49AM +0200, Paolo Bonzini wrote:
Il 19/08/2014 11:04, Wanpeng Li ha scritto:
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
reasons
why kvm_cpu_synchronize_post_reset() doesn't do the same (e.g. called from
https://bugzilla.kernel.org/show_bug.cgi?id=82761
Bug ID: 82761
Summary: DMAR:[fault reason 06] PTE Read access is not set
Product: Virtualization
Version: unspecified
Kernel Version: 3.16.1
Hardware: All
OS: Linux
On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
#endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16e7994..70f0f02 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -521,6 +521,7 @@ int create_hyp_io_mappings(void *from, void
On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it seems like a good time to also set
things at run-time instead of compile time to accomodate more hardware.
This
https://bugzilla.kernel.org/show_bug.cgi?id=82761
Alex Williamson alex.william...@redhat.com changed:
What|Removed |Added
CC|
Il 19/08/2014 13:14, zhanghailiang ha scritto:
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn-slot-base_gfn'
This fixes a crash, doesn't it? Please mention it in the commit
message, because we have to assign a CVE for this kind of issue. It
will be CVE-2014-3601.
I
Commit 5045b46803 added a check that cs.dpl equals cs.rpl during task-switch.
This is a wrong check, and this patch introduces a test in which cs.dpl !=
cs.rpl. To do so, it configures tss.cs to be conforming with rpl=3 and dpl=0.
Since the cpl after calling is 3, it does not make any prints in
On Tue, Aug 19, 2014 at 11:51:05AM +0200, Paolo Bonzini wrote:
Il 18/08/2014 21:43, Nadav Amit ha scritto:
Currently, the TSC deadline test never runs, since TSC deadline is disabled
unless the host cpu parameter is used. This patch changes the apic test to
use
the qemu host cpu
Il 19/08/2014 15:18, Eduardo Habkost ha scritto:
On Tue, Aug 19, 2014 at 11:51:05AM +0200, Paolo Bonzini wrote:
Il 18/08/2014 21:43, Nadav Amit ha scritto:
Currently, the TSC deadline test never runs, since TSC deadline is disabled
unless the host cpu parameter is used. This patch changes the
Il 19/08/2014 15:04, Nadav Amit ha scritto:
Commit 5045b46803 added a check that cs.dpl equals cs.rpl during task-switch.
This is a wrong check, and this patch introduces a test in which cs.dpl !=
cs.rpl. To do so, it configures tss.cs to be conforming with rpl=3 and dpl=0.
Since the cpl after
On Aug 19, 2014, at 4:28 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 19/08/2014 15:04, Nadav Amit ha scritto:
+void test_conforming_switch(void)
+{
+/* test lcall with conforming segment, cs.dpl != cs.rpl */
+test_count = 0;
+set_intr_task_gate(0, user_tss);
No need to
Il 19/08/2014 15:34, Nadav Amit ha scritto:
I know, but all the other ‘call' tests did. If there is an error, at
least it should be consistent. ;-)
Right, let's fix it up:
diff --git a/x86/taskswitch2.c b/x86/taskswitch2.c
index fd9a404..3cfb467 100644
--- a/x86/taskswitch2.c
+++
On 18/08/14 07:02, Wanpeng Li wrote:
Hi Christian,
On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu
On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
reasons
why kvm_cpu_synchronize_post_reset()
On 08/19/2014 07:22 AM, Christoffer Dall wrote:
On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
#endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16e7994..70f0f02 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -521,6 +521,7
On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
reasons
why
On 08/19/2014 07:24 AM, Christoffer Dall wrote:
On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it seems like a good time to also set
things at run-time instead of
On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote:
On 08/19/2014 07:22 AM, Christoffer Dall wrote:
On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
#endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16e7994..70f0f02 100644
On Tue, Aug 19, 2014 at 09:23:57AM -0500, Joel Schopp wrote:
On 08/19/2014 07:24 AM, Christoffer Dall wrote:
On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it
On 19/08/14 16:23, David Hildenbrand wrote:
On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
We dont have to wait for a grace period if there is no oldpid that
we are going to free. putpid also checks for NULL, so this patch
only fences synchronize_rcu.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
virt/kvm/kvm_main.c | 3 ++-
1 file changed, 2 insertions(+), 1
The return is a value,not just an error code. Because of this returning
an error overloads that value. 0 just seemed like a convenient invalid
value to check since a vttbr_x of 0 is invalid, but returning a negative
error code would be as equally invalid. If this is the only issue it
Hmm. We want to not only reduce, we want them be zero.
In addition to a reworked MP_STATE patch set, we might be able to change
the code to call KVM_S390_INITIAL_RESET only from the cpu thread itself.
If that simplifies things, we could avoid doing KVM_S390_INITIAL_RESET on
CPU
On 08/19/2014 09:37 AM, Christoffer Dall wrote:
On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote:
On 08/19/2014 07:22 AM, Christoffer Dall wrote:
On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
#endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/mmu.c
On Tue, Aug 19, 2014 at 09:49:07AM -0500, Joel Schopp wrote:
The return is a value,not just an error code. Because of this returning
an error overloads that value. 0 just seemed like a convenient invalid
value to check since a vttbr_x of 0 is invalid, but returning a negative
error code
On 08/19/2014 08:15 PM, Christian Borntraeger wrote:
We dont have to wait for a grace period if there is no oldpid that
we are going to free. putpid also checks for NULL, so this patch
only fences synchronize_rcu.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Feel free to add:
On Tue, Aug 19, 2014 at 09:53:51AM -0500, Joel Schopp wrote:
On 08/19/2014 09:37 AM, Christoffer Dall wrote:
On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote:
On 08/19/2014 07:22 AM, Christoffer Dall wrote:
On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote:
#endif
hmmm, the point is that we need to ensure that we have a properly
aligned allocated PGD, that's what this patch currently addresses, and as
you pointed out, the BUG_ON() just before trying to run a VM is not the
nicest solution - we should really be dealing with this properly at
allocation
Hello maintainers:
Please help check this patch, when you have time.
Thanks.
On 08/08/2014 11:37 PM, Chen Gang wrote:
As a generic function, deassign_guest_irq() assumes it can be called
even if assign_guest_irq() is not be called successfully (which can be
triggered by ioctl from user mode,
Il 19/08/2014 17:44, Chen Gang ha scritto:
Hello maintainers:
Please help check this patch, when you have time.
Hi, it's already on its way to 3.17-rc2, but I first have to run a bunch
of tests.
Paolo
Thanks.
On 08/08/2014 11:37 PM, Chen Gang wrote:
As a generic function,
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #2 from Ansa89 ansalonistef...@gmail.com ---
1) I would prefer stay on stable kernel if it's possible (which commits of
3.17-rc1 would be relevant for this bug?).
2) Yes, all of the 8169 NICs are up and running.
3) lspci -vvs 04:00.0
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #3 from Alex Williamson alex.william...@redhat.com ---
(In reply to Ansa89 from comment #2)
1) I would prefer stay on stable kernel if it's possible (which commits of
3.17-rc1 would be relevant for this bug?).
579305f iommu/vt-d:
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #4 from Ansa89 ansalonistef...@gmail.com ---
I will try 3.17-rc1 (hoping it's enough stable for home-server).
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send
$ uname -r
3.16.1-1-ARCH
-
As a regular user, member of the libvirt group, I run this command to
create a basic VM:
virt-install --connect qemu:///system --name=test --ram 2048 --cpu
host-model-only --os-variant=win7 --disk /myVM/test --boot cdrom,hd
--virt-type kvm
This RFC's intention is to show what an interface to access device node
properties for VFIO_PLATFORM can look like.
If a device tree node corresponding to a platform device bound by
VFIO_PLATFORM
is available, this patch series will allow the user to query the properties
associated with
Introduce preempt notifiers for architecture specific code.
Advantage over creating a new notifier in every arch is slightly simpler
code and guaranteed call order with respect to kvm_sched_in.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/arm/kvm/arm.c | 4
Modifications could get unwanted values of PLE window. (low or negative)
Use ple_window and the maximal value that cannot overflow as bounds.
ple_window_max defaults to a very high value, but it would make sense to
set it to some fraction of the scheduler tick.
Signed-off-by: Radim Krčmář
Tracepoint for dynamic PLE window, fired on every potential change.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/trace.h | 29 +
arch/x86/kvm/vmx.c | 4
arch/x86/kvm/x86.c | 1 +
3 files changed, 34 insertions(+)
diff --git
Every increase of ple_window_grow creates potential overflows.
They are not serious, because we clamp ple_window and userspace is
expected to fix ple_window_max within a second.
---
arch/x86/kvm/vmx.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff
They were almost identical and thus merged with a loathable macro.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
This solution is hopefully more acceptable than function pointers.
arch/x86/kvm/vmx.c | 53 +++--
1 file changed, 19
ple_window is updated on every vmentry, so there is no reason to have it
read-only anymore.
ple_window_* weren't writable to prevent runtime overflow races;
they are mitigated by clamping the value of ple_window.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
If we decide to ignore insane
Window is increased on every PLE exit and decreased on every sched_in.
The idea is that we don't want to PLE exit if there is no preemption
going on.
We do this with sched_in() because it does not hold rq lock.
There are two new kernel parameters for changing the window:
ple_window_grow and
sched_in preempt notifier is available for x86, allow its use in
specific virtualization technlogies as well.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/svm.c | 6 ++
arch/x86/kvm/vmx.c | 6 ++
Change PLE window into per-vcpu variable, seeded from module parameter,
to allow greater flexibility.
Brings in a small overhead on every vmentry.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
I've been thinking about a general hierarchical per-vcpu variable model,
but it's hard to have
PLE does not scale in its current form. When increasing VCPU count
above 150, one can hit soft lockups because of runqueue lock contention.
(Which says a lot about performance.)
The main reason is that kvm_ple_loop cycles through all VCPUs.
Replacing it with a scalable solution would be ideal,
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #5 from Ansa89 ansalonistef...@gmail.com ---
Tested with 3.17-rc1: the errors still there, but the spam rate seems lower
than 3.16.1 (with 3.16.1 I get the errors repeated a lot of times and the count
grows fast; with 3.17-rc1 I get
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #6 from Alex Williamson alex.william...@redhat.com ---
Ok, then it's probably not a result of the PCIe-to-PCI bridge since 05:00.0 is
the correct requester ID for all the devices behind the bridge. Unfortunately
that means that the
Hello,
ran into this error for a first time over veru large hardware
span/uptime (the server which experienced the error is identical to
others, and I had absolutely none of MSI-related problems with this
hardware ever).
Running 3.10 at host, I had one (of many) VM on it which produced
enormous
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #7 from Alex Williamson alex.william...@redhat.com ---
I'm guessing this might be the motherboard here: MSI ZH77A-G43
Since you're apparently trying to use VT-d on this system for KVM and therefore
presumably device assignment, I'll
On Tue, Aug 19, 2014 at 04:04:03PM +0200, Christian Borntraeger wrote:
On 18/08/14 07:02, Wanpeng Li wrote:
Hi Christian,
On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for
On 08/19/2014 11:49 PM, Paolo Bonzini wrote:
Il 19/08/2014 17:44, Chen Gang ha scritto:
Hello maintainers:
Please help check this patch, when you have time.
Hi, it's already on its way to 3.17-rc2, but I first have to run a bunch
of tests.
OK, thanks. Also can let me try the test,
By the way, at present, I use Qemu as user mode program, is there common
test with both Qemu and KVM/Xen? And is a PC enough for the common test?
Thanks.
On 08/20/2014 07:58 AM, Chen Gang wrote:
On 08/19/2014 11:49 PM, Paolo Bonzini wrote:
Il 19/08/2014 17:44, Chen Gang ha scritto:
Hello
On 08/19/2014 05:03 PM, Paolo Bonzini wrote:
Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
Okay, what confused me it that it seems that the single line patch
is ok to you. :)
No, it was late and I was confused. :)
Now, do we really need to care the case 2? like David said:
Sorry I
On Tue, Aug 19, 2014 at 5:29 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/19/2014 05:03 PM, Paolo Bonzini wrote:
Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
Okay, what confused me it that it seems that the single line patch
is ok to you. :)
No, it was late and I was
On Thu, Aug 14, 2014 at 03:03:07PM +1000, Alexey Kardashevskiy wrote:
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings reserved for
future functionality. However, the handler can't identify if
paging-structure entry of reserved bits for
Hi Paolo,
On Tue, Aug 19, 2014 at 11:09:49AM +0200, Paolo Bonzini wrote:
[...]
I suggest that you write a testcase for kvm-unit-tests.
Just send out v3. The testcase will be written later since I'm not familiar
with kvm-unit-tests before and time is still needed.
Regards,
Wanpeng Li
Paolo
--
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Guest. Patch also adds support for
software
On Thu, Aug 14, 2014 at 03:03:07PM +1000, Alexey Kardashevskiy wrote:
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Guest. Patch also adds support for
software
99 matches
Mail list logo
