...@cs.technion.ac.il
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
+++ b/arch/x86/kvm/x86.c
@@ -3132,15 +3132,89 @@ static int kvm_vcpu_ioctl_x86_set_debugregs(struct
kvm_vcpu *vcpu,
+ u64 xstate_bv = xsave-xsave_hdr.xstate_bv;
(This looks like
2014-12-04 16:57+0100, Paolo Bonzini:
From: Wanpeng Li wanpeng...@linux.intel.com
Add logic to get/set the XSS model-specific register.
Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
-by: Radim Krčmář rkrc...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2014-12-04 16:57+0100, Paolo Bonzini:
From: Wanpeng Li wanpeng...@linux.intel.com
Add logic to get/set the XSS model-specific register.
Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
2014-12-04 16:57+0100, Paolo Bonzini:
From: Wanpeng Li wanpeng...@linux.intel.com
Add vmcs12 support for xsaves.
Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
+ case
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -69,6 +69,7 @@
#define SECONDARY_EXEC_PAUSE_LOOP_EXITING0x0400
#define SECONDARY_EXEC_ENABLE_INVPCID
2014-12-10 00:18+0300, Eugene Korenevsky:
+static bool vmx_load_msr_entry_verify(struct kvm_vcpu *vcpu,
+ struct vmx_msr_entry *e)
[...]
+ /* x2APIC MSR accesses are not allowed */
+ if (apic_x2apic_mode(vcpu-arch.apic) (e-index 24) == 0x800)
+
2014-12-10 18:55+0100, Paolo Bonzini:
Well, my preferred choice would be automatic adjustment with a module
parameter. If we need manual tuning, per-CPU would be my choice, but
automatic is nicer anyway. :)
I agree with Paolo, and think it would be better not to touch QEMU ...
it makes little
2014-12-11 16:07+0800, zhanghailiang:
User space (i.e. QEMU) should be able to check whether KVM
supports apic-v. User space will use this to decide whether enable
emulated MSR-based APIC (i.e. hyperv-vapic).
Userspace is able to look at enable_apicv module parameter.
(This decision probably
2014-12-11 20:53+0800, zhanghailiang:
On 2014/12/11 19:48, Paolo Bonzini wrote:
On 11/12/2014 09:07, zhanghailiang wrote:
User space (i.e. QEMU) should be able to check whether KVM
supports apic-v. User space will use this to decide whether enable
emulated MSR-based APIC (i.e. hyperv-vapic).
2015-01-21 23:40-0200, Marcelo Tosatti:
On Wed, Jan 21, 2015 at 06:00:37PM +0100, Radim Krčmář wrote:
1) The bug happens because a guest expects greater precision.
I consider that as a guest problem. kvmclock never guaranteed
anything, so unmet expectations should be a recoverable
2015-01-28 10:54+0800, Kai Huang:
This patch adds PML support in VMX. A new module parameter 'enable_pml' is
added
(+module_param_named(pml, enable_pml, bool, S_IRUGO);)
to allow user to enable/disable it manually.
Signed-off-by: Kai Huang kai.hu...@linux.intel.com
---
diff --git
2015-01-30 10:22+0100, Paolo Bonzini:
On 29/01/2015 22:48, Radim Krčmář wrote:
This patch series is made our of three logical parts,
[1-3/8] are just a cleanup and could be omitted
[4-6/8] improve broadcast detection and unoptimized delivery
[7-8/8] handle mixed mode (by falling back
2015-01-30 16:23+0100, Paolo Bonzini:
On 30/01/2015 16:14, Radim Krčmář wrote:
+ case KVM_APIC_MODE_XAPIC_FLAT:
+ *cid = 0;
+ *lid = ldr 0xff;
+ return true;
+ case KVM_APIC_MODE_XAPIC_CLUSTER:
+ *cid
2015-01-30 16:10+0100, Paolo Bonzini:
On 30/01/2015 15:56, Radim Krčmář wrote:
Do you know of a difference with it?
new-mode (new-mode - 1) | hweight8(new-mode) != 1
lea-0x1(%rax),%edi |popcnt %edi,%eax
test %eax,%edi|cmp$1,%eax
x (x
2015-01-30 10:18+0100, Paolo Bonzini:
On 29/01/2015 22:48, Radim Krčmář wrote:
+static inline bool
+apic_logical_id(struct kvm_apic_map *map, u32 ldr, u16 *cid, u16 *lid)
{
+ switch (map-mode) {
+ case KVM_APIC_MODE_XAPIC_FLAT:
+ *cid = 0;
+ *lid = ldr 0xff
2015-01-30 09:52+0100, Paolo Bonzini:
On 29/01/2015 22:48, Radim Krčmář wrote:
The majority of this patch turns
result = 0; if (CODE) result = 1; return result;
into
return CODE;
because we return bool now.
Added a bunch of != 0 to avoid automagic conversion to bool.
(I haven't
2015-02-02 15:26+0100, Radim Krčmář:
2015-01-30 09:52+0100, Paolo Bonzini:
+ return ((logical_id 4) == (mda 4))
+ (logical_id mda 0xf) != 0;
but it has to be parenthesized ('' has lower precedence than '!=').
No, my bad, I understood it now
2015-02-02 15:28+0100, Paolo Bonzini:
On 02/02/2015 15:26, Radim Krčmář wrote:
+ return ((logical_id 4) == (mda 4))
+ (logical_id mda 0xf);
was merged as
+ return ((logical_id 4) == (mda 4))
+ (logical_id mda
2015-01-28 10:54+0800, Kai Huang:
This patch adds new kvm_x86_ops dirty logging hooks to enable/disable dirty
logging for particular memory slot, and to flush potentially logged dirty GPAs
before reporting slot-dirty_bitmap to userspace.
kvm x86 common code calls these hooks when they are
2015-02-03 16:39+0100, Paolo Bonzini:
On 03/02/2015 16:18, Radim Krčmář wrote:
(I see the same code in handle_ept_violation(), but wasn't that needed
just because of a hardware error?)
That was how I read it initially, but actually that means: this
statement could be broken
of kvm_arch_commit_memory_region from
'struct kvm_userspace_memory_region *' to 'struct kvm_memory_slot * new', but
it
requires changes on other non-x86 ARCH too, so avoid it now.
Signed-off-by: Kai Huang kai.hu...@linux.intel.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
--- a/arch
2015-01-28 10:54+0800, Kai Huang:
This patch adds new mmu layer functions to clear/set D-bit for memory slot,
and
to write protect superpages for memory slot.
In case of PML, CPU logs the dirty GPA automatically to PML buffer when CPU
updates D-bit from 0 to 1, therefore we don't have to
2015-02-05 14:29+0800, Kai Huang:
+ /* Still write protect RO slot */
+ if (new-flags KVM_MEM_READONLY) {
+ kvm_mmu_slot_remove_write_access(kvm, new);
We didn't write protect RO slots before, does this patch depend on it?
No PML doesn't depend on it to work. It's suggested by
2015-02-05 13:59+0800, Kai Huang:
Thanks for your review and sorry for the late reply. I was working on
something else these days.
(No problem, a reply within a week is instantaneous for me :)
For rest of your comments, as this patch series have already been in Paolo's
queue branch, I think
2015-02-05 14:23+0800, Kai Huang:
On 02/03/2015 11:18 PM, Radim Krčmář wrote:
You have it protected by CONFIG_X86_64, but use it unconditionally.
Thanks for catching. This has been fixed by another patch, and the fix has
also been merged by Paolo.
(And I haven't noticed the followup either
2015-01-15 20:36+0800, Li Kaihang:
This patch fix a external interrupt injecting bug in linux 3.19-rc4.
Was the bug introduced in earlier 3.19 release candidate?
GuestOS is running and handling some interrupt with RFLAGS.IF = 0 while a
external interrupt coming,
then can lead to a vm
x86/unittests.cfg uses the variant with underscore.
Rename tscdeadline-latency.c instead of fixing x86/unittests.cfg because
we use only underscores elsewhere.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
config/config-x86-common.mak | 2 +-
config/config-x86_64.mak
There is no point in executing it through run_tests.sh.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
x86/unittests.cfg | 5 -
1 file changed, 5 deletions(-)
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index 75b959535c01..badb08ad138e 100644
--- a/x86/unittests.cfg
+++ b/x86
unittest.cfg expects tscdeadline_latency.flat, while the existing
filename contains a dash = we don't call it from ./run_tests.sh.
(Which is considered a PASS :)
tscdeadline_latency isn't a unit test so we can omit it.
(Feel free to drop [1/2], I just loathe inconsistencies.)
Radim Krčmář (2
We failed smptest [1/2], but didn't notice [2/2].
APICv returns 0 on APIC MMIO reads under x2APIC,
KVM returns real APIC ID instead.
Do we want to test this weirdness in another unit test?
(I'll post a patch for KVM after checking that there aren't quirks.)
Radim Krčmář (2):
lib/x86: fix
smptest was failing and we didn't notice, turn it into unit test.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
x86/smptest.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/x86/smptest.c b/x86/smptest.c
index 37805999b3b0..acda22e18314 100644
--- a/x86/smptest.c
We used MMIO (xAPIC) for x2APIC.
This is the same as using xAPIC in globally disabled mode.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
lib/x86/apic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/x86/apic.c b/lib/x86/apic.c
index 6876d85fac95..9c42c4d0a4fc
2015-01-21 12:16-0200, Marcelo Tosatti:
On Wed, Jan 21, 2015 at 03:09:27PM +0100, Radim Krčmář wrote:
2015-01-20 15:54-0200, Marcelo Tosatti:
SuSE's 2.6.16 kernel fails to boot if the delta between tsc_timestamp
and rdtsc is larger than a given threshold:
[...]
Disable masterclock
2015-01-16 16:07+0800, Li Kaihang:
GuestOS is running and handling some interrupt with RFLAGS.IF = 0 while a
external interrupt coming,
then can lead to a vm exit,in this case,we must avoid inject this external
interrupt or it will generate
a processor hardware exception causing
2015-01-09 15:37+0100, Radim Krčmář:
Lowest priority should take the task priority into account.
SDM 10.6.2.4 Lowest Priority Delivery Mode.
(Too long to quote; second and last paragraphs are relevant.)
Before this patch, we strived to have the same amount of handled
lowest-priority
2015-01-20 15:54-0200, Marcelo Tosatti:
SuSE's 2.6.16 kernel fails to boot if the delta between tsc_timestamp
and rdtsc is larger than a given threshold:
[...]
Disable masterclock support (which increases said delta) in case the
boot vcpu does not use MSR_KVM_SYSTEM_TIME_NEW.
Why do we care
2015-01-22 16:12-0200, Marcelo Tosatti:
On Thu, Jan 22, 2015 at 02:59:28PM +0100, Radim Krčmář wrote:
I don't understand what the guest wants to achieve with the delta.
Neither do I. It seems to assume that TSC delta is unreliable, while
system_timestamp is reliable.
Therefore if TSC
2015-01-22 09:10+0100, Paolo Bonzini:
On 21/01/2015 18:00, Radim Krčmář wrote:
2015-01-21 12:16-0200, Marcelo Tosatti:
On Wed, Jan 21, 2015 at 03:09:27PM +0100, Radim Krčmář wrote:
2015-01-20 15:54-0200, Marcelo Tosatti:
SuSE's 2.6.16 kernel fails to boot if the delta between
We want to support mixed modes and the easiest solution is to avoid
optimizing those weird and unlikely scenarios.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
v2
- optimize and name a check for valid map [Paolo]
- don't use cluster id with invalid map [Paolo]
- define KVM_APIC_MODE_
an interesting design decision: it didn't
consider IOxAPIC 0xff as broadcast in x2APIC mode ...
everything worked because IOxAPIC can't set that in physical mode and
logical mode considered it as a message for first 8 VCPUs.
This patch interprets IOxAPIC 0xff as x2APIC broadcast.
Signed-off-by: Radim
of logical MDA is a function of the mode, so we encode it in
apic_logical_id() and drop obsoleted variables from the struct.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
v2
- use different optimization to shorten apic_logical_id [Paolo]
- move apic_logical_id to lapic.c [Paolo]
- keep apic map
disagrees. This patch aims for simple code by considering most of real
behavior as undefined.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
v2
- don't deliver all phys messages beginning with 0xff to xAPIC
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/lapic.c| 9 -
2
to Linux (ideally
writing a custom kernel), so this series implements something that makes
some sense and isn't too far from reality.
Radim Krčmář (4):
KVM: x86: use MDA for interrupt matching
KVM: x86: fix mixed APIC mode broadcast
KVM: x86: avoid logical_map when it is invalid
KVM: x86
2015-02-19 16:01+0100, Radim Krčmář:
2015-02-19 13:07+0100, Kashyap Chamarthy:
5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
This concept is based on the rule that a pending vmlaunch/vmresume is
not canceled. Otherwise, we would risk to lose injected events or leak
them
2015-02-19 17:02+0100, Radim Krčmář:
Fixes: e011c663b9c7 (Check all exceptions for intercept during delivery to
L2)
Note: I haven't verified that it was introduced by this patch, just
nothing against the hypothesis popped out in a short gravedigging.
--
To unsubscribe from this list: send
2015-02-19 13:07+0100, Kashyap Chamarthy:
Just did two tests with 3.18:
(1) Kernel 3.18 on L0 and 3.20 on L1
Result: Booting L2 guest causes L1 to reboot, and the same[*] stack
trace on L0 (mentioned on this thread previously).
But, annoyingly enough, when I
2015-01-30 10:19+0100, Paolo Bonzini:
On 29/01/2015 22:48, Radim Krčmář wrote:
We want to support mixed modes and the easiest solution is to avoid
optimizing those weird and unlikely scenarios.
Hmm, what happens if use maxcpus to disable some CPUs at startup?
Their APICs are kept sw
2015-01-30 10:38+0100, Paolo Bonzini:
On 29/01/2015 22:48, Radim Krčmář wrote:
+ if (hweight8(new-mode) != 1)
Better (more optimized):
if (new-mode (new-mode - 1))
True, hweight needs to have X86_FEATURE_POPCNT to be efficient ...
Do you know of a difference
2015-01-09 15:56+0100, Paolo Bonzini:
On 09/01/2015 15:54, Radim Krčmář wrote:
There are two points relevant to this patch in new KVM's implementation,
(KVM: x86: amend APIC lowest priority arbitration,
https://lkml.org/lkml/2015/1/9/362)
1) lowest priority depends on TPR
2
2015-01-09 16:18+0100, Paolo Bonzini:
On 09/01/2015 16:12, Radim Krčmář wrote:
The chipset doesn't support it. :(
I meant that we need to recompute PI entries for lowest priority
interrupts every time guest's TPR changes.
Luckily, Linux doesn't use TPR, but other OS might
a complication, but kept for compatibility.
Real modern Intels can't send lowest priority IPIs and the chipset
directs external ones using processors' TPR.
AMD still has rough edges.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 10 +-
1 file changed, 9 insertions(+), 1
-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/lapic.c| 8 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 97a5dd0222c8..aa4bd8286232 100644
2015-02-06 17:30+, Andre Przywara:
As kvm_run is a member of kvm_vcpu, the vcpu alone should be sufficient,
right?
Yes.
Also I see the very top of the call chain is effectively:
kvm_arch_vcpu_ioctl_run(vcpu, vcpu-run);
:(
So is that just legacy code still lingering around from the
2015-02-06 13:48+0100, Paolo Bonzini:
[...]
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
Noticed changes since RFC:
- polling is used in more situations
- new tracepoint
- module parameter in nanoseconds
- properly handled time
2015-02-09 17:10+0100, Paolo Bonzini:
On 09/02/2015 16:21, Radim Krčmář wrote:
2015-02-06 13:48+0100, Paolo Bonzini:
+TRACE_EVENT(kvm_vcpu_wakeup,
+ TP_PROTO(__u64 ns, bool waited),
(__u64 is preferred here?)
Preferred to what?
To 'u64'. (The header file shouldn't
(get_cpu_mask(vcpu-cpu),
^
---8---
KVM: VMX: include asm/apic.h to fix build error
asm/apic.h isn't included directly and without CONFIG_SMP, an option
that automagically pulls it can't be enabled.
Reported-by: Jim Davis jim.ep...@gmail.com
Signed-off-by: Radim Krčmář rkrc...@redhat.com
,
(I guess the value is going to be overestimated when used.)
Reviewed-by: Radim Krčmář rkrc...@redhat.com
+++ b/arch/x86/kvm/x86.c
@@ -5819,13 +5823,29 @@ void kvm_arch_exit(void)
int kvm_emulate_halt(struct kvm_vcpu *vcpu)
+ if (halt_poll) {
+ u64 start, curr
Emulation does not utilize the feature.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/x86.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 933a373..ed879f1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm
kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled.
We need to do that for irq notifiers. (Like with edge interrupts.)
Fix it by skipping EOI broadcast only.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=82211
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm
2015-03-14 18:00-0600, James Sullivan:
* DM=1, RH=0 : Logical destination mode without redirection. Interrupt
is delivered to all LAPICs in the logical group
specified by the IRQ's destination map and delivery
mode.
Your previous
2015-03-16 11:16-0500, Joel Schopp:
On 03/12/2015 04:20 PM, Radim Krčmář wrote:
2015-03-12 15:17-0500, Joel Schopp:
There isn't really a valid reason for kvm to intercept cr* reads
on svm hardware. The current kvm code just ends up returning
the register
There is no need to intercept
to true when RH=1 in kvm_set_msi_irq(), and initialized
to false in all other cases.
Added value of msi_redir_hint to a debug message dump of an IRQ in
apic_send_ipi().
Signed-off-by: James Sullivan sullivan.jame...@gmail.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
Thanks.
---
Btw
+0x96e/0xb00 [kvm_intel] ()
Prevent this scenario by masking SECONDARY_EXEC_UNRESTRICTED_GUEST when
the host doesn't have it enabled.
Fixes: 78051e3b7e35 (KVM: nVMX: Disable unrestricted mode if ept=0)
Cc: sta...@vger.kernel.org
Tested-By: Kashyap Chamarthy kcham...@redhat.com
Signed-off-by: Radim
2015-03-18 22:09-0300, Marcelo Tosatti:
See native_compose_msi_msg:
((apic-irq_dest_mode == 0) ?
MSI_ADDR_DEST_MODE_PHYSICAL :
MSI_ADDR_DEST_MODE_LOGICAL) |
((apic-irq_delivery_mode != dest_LowestPrio) ?
2015-03-19 18:44-0300, Marcelo Tosatti:
On Wed, Mar 18, 2015 at 07:38:22PM +0100, Radim Krčmář wrote:
kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled.
We need to do that for irq notifiers. (Like with edge interrupts.)
Fix it by skipping EOI broadcast only.
Bug
2015-03-19 16:51-0600, James Sullivan:
I played around with native_compose_msi_msg and discovered the following:
* dm=0, rh=0 = Physical Destination Mode
* dm=0, rh=1 = Failed delivery
* dm=1, rh=0 = Logical Destination Mode, No Redirection
* dm=1, rh=1 = Logical Destination Mode,
2015-03-19 18:24+0100, Paolo Bonzini:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
@@ -833,8 +833,7 @@ int kvm_apic_compare_prio(struct kvm_vcpu *vcpu1,
struct kvm_vcpu *vcpu2)
- if (!(kvm_apic_get_reg(apic, APIC_SPIV) APIC_SPIV_DIRECTED_EOI)
-
An overhead from function call is not appropriate for its size and
frequency of execution.
Suggested-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
I'm not very fond of that smp_rmb(): there is no real synchronization
against update_handled_vectors
kvm_is_dm_lowest_prio() into lapic.h and renamed to
kvm_lowest_prio_delivery().
Changed a check in kvm_irq_delivery_to_apic_fast() from
irq-delivery_mode == APIC_DM_LOWPRI to kvm_is_dm_lowest_prio().
Signed-off-by: James Sullivan sullivan.jame...@gmail.com
---
Reviewed-by: Radim Krčmář rkrc
2015-03-16 11:28-0600, James Sullivan:
Changes Since v1:
* Reworked patches into two commits:
1) [Patch v2 1/2] Extended struct kvm_lapic_irq with bool
msi_redir_hint
* Initialize msi_redir_hint = true in kvm_set_msi_irq when RH=1
* Initialize
is tangled, but looks like everything works,)
Reviewed-by: Radim Krčmář rkrc...@redhat.com
Thanks.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-03-09 20:28-0300, Marcelo Tosatti:
On Fri, Feb 27, 2015 at 06:19:18PM -0600, Joel Schopp wrote:
From: David Kaplan david.kap...@amd.com
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan david.kap...@amd.com
[extracted from larger
2015-03-09 23:05-0600, James Sullivan:
Hi folks,
This is a small patch that implements logic to handle the RH bit
being set in the msi message address register. Currently the DM bit is
the only thing used to decide irq-dest_mode (logical when DM set,
physical when unset). Documentation
2015-03-11 09:05-0600, James Sullivan:
This is a revised patch to the previous submission, adding a check for
RH=1/DM=1
in kvm_set_msi_irq.
(Btw. you can put it below the /^---$/ line, where it gets automatically
trimmed -- information on changes since the last version is very
important in
/CodingStyle, Chapter 2. It's nitpicking, sorry, but we
recently had a patch that fixed just that too ...
http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/133110)
Then,
Reviewed-by: Radim Krčmář rkrc...@redhat.com
Thanks.
---
The warning message is very clever:
- it contains
2015-03-13 08:47-0600, James Sullivan:
On 03/13/2015 08:39 AM, Radim Krčmář wrote:
...
The warning message is very clever:
- it contains the magical may qualifier and being protected only by
RH=1 creates weird-looking code structure, but it is technically right
1) lowest-priority
check
* Aligned quotation blocks in multiline pr_warn_once argument
Changes since v4:
* Put error message string on single line
Thanks,
Reviewed-by: Radim Krčmář rkrc...@redhat.com
diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
@@ -103,12 +103,24 @@ static inline void
‘:’ or ‘)’ before string constant
orl $0x200, (%%Rsp)\n\t
Fix it by putting a space between macro R and a string literal.
(We already do that somewhere.)
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
I think it would be better to replace
[...]R ax [...]
with
[...] ASM_AX
2015-03-12 15:17-0500, Joel Schopp:
There isn't really a valid reason for kvm to intercept cr* reads
on svm hardware. The current kvm code just ends up returning
the register
There is no need to intercept CR* if the value that the guest should see
is equal to what we set there, but that is
2015-03-10 16:39-0600, James Sullivan:
On 03/10/2015 08:47 AM, Radim Krčmář wrote:
+ irq-dest_mode = phys ? 0 : (MSI_ADDR_DEST_MODE_LOGICAL);
(Should be APIC_DEST_LOGICAL. All works because it is a boolean and we
only checked for APIC_DEST_PHYSICAL, which is 0.)
Thank you
2015-03-23 16:46-0600, James Sullivan:
On 03/23/2015 03:13 PM, Radim Krčmář wrote:
I meant if the delivery mode from data register isn't ignored with RH=1,
and the message delivered as if lowest-priority was set there.
(Decided by having something else than fixed or lowest-priority
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
I think that the revert doesn't fix point 2.: KVM: x86:
2015-03-25 12:08+0100, Radim Krčmář:
Reverting the patch protects us from any migration, but I don't think we
need to care about changing VCPUs as long as we read a consistent data
from kvmclock. (VCPU can change outside of this loop too, so it doesn't
matter if we return a value not fit
are fixing now, (reverted patch just was just wrong)
Reviewed-by: Radim Krčmář rkrc...@redhat.com
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
@@ -82,18 +82,15 @@ static notrace cycle_t vread_pvclock(int *mode)
/*
- * Note: hypervisor must guarantee
2015-03-27 13:16+0300, Andrey Korolyov:
On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das b...@redhat.com wrote:
Radim Krčmář rkrc...@redhat.com writes:
I second Bandan -- checking that it reproduces on other machine would be
great for sanity :) (Although a bug in our APICv is far more likely
2015-03-27 14:54+0300, Andrey Korolyov:
Trace with new bits:
Thanks.
KVM internal error. Suberror: 2
extra data[0]: 80ef
extra data[1]: 8b0d
extra data[2]: 77b
The #GP code looks formatted as documented under INT in SDM,
(vector 3) | 2 | ext
where 'ext' stands for 'external' (as
2015-03-30 22:32+0300, Andrey Korolyov:
On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-27 13:16+0300, Andrey Korolyov:
On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das b...@redhat.com wrote:
Radim Krčmář rkrc...@redhat.com writes:
I second Bandan -- checking
2015-03-31 21:23+0300, Andrey Korolyov:
On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das b...@redhat.com wrote:
Bandan Das b...@redhat.com writes:
Andrey Korolyov and...@xdel.ru writes:
...
http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
Something a bit
2015-03-26 20:08+0300, Andrey Korolyov:
KVM internal error. Suberror: 2
extra data[0]: 80ef
extra data[1]: 8b0d
Btw. does this part ever change?
I see that first report had:
KVM internal error. Suberror: 2
extra data[0]: 80d1
extra data[1]: 8b0d
Was that a Windows
2015-03-26 12:36-0400, Kevin O'Connor:
On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
Notice the 0xef. My best hypothesis so far is that we fail at resetting
devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted.
(The bug happens at the first place
2015-03-26 19:48+0300, Andrey Korolyov:
I`ll post a sample event
capture with and without Radim`s proposed patch maybe today or
tomorrow.
Thanks.
The patch doesn't change runtime behavior, it just adds another data
field to the error report, so
2015-03-31 17:56+0300, Andrey Korolyov:
Chasing the culprit this way could take a long time, so a new tracepoint
that shows if 0xef is set on entry would let us guess the bug faster ...
Please provide a failing trace with the following patch:
Thanks, please see below:
2015-03-02 13:43-0600, Joel Schopp:
Currently kvm_emulate() skips the instruction but kvm_emulate_* sometimes
don't. The end reult is the caller ends up doing the skip themselves.
Let's make them consistant.
Signed-off-by: Joel Schopp joel.sch...@amd.com
---
Reviewed-by: Radim Krčmář rkrc
2015-03-02 15:02-0600, Joel Schopp:
+int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port)
+{
+ unsigned long val;
+ int ret = emulator_pio_in_emulated(vcpu-arch.emulate_ctxt, size,
+port, val, 1);
+
Btw. does this return 1
2015-03-02 15:02-0600, Joel Schopp:
From: David Kaplan david.kap...@amd.com
We can make the in instruction go faster the same way the out instruction is
already.
(How much faster do benchmarks run?)
Changes from v2[Joel]:
* changed rax from u32 to unsigned long
* changed a
-by: Joel Schopp joel.sch...@amd.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
Thanks.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-03-01 21:29-0500, Bandan Das:
Joel Schopp joel.sch...@amd.com writes:
From: David Kaplan david.kap...@amd.com
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan david.kap...@amd.com
[extracted from larger unlrelated patch, forward
joel.sch...@amd.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
+static int wbinvd_interception(struct vcpu_svm *svm)
+{
+ kvm_emulate_wbinvd(svm-vcpu);
+ skip_emulated_instruction(svm-vcpu);
+ return 1;
+}
+
+
(One
2015-02-27 18:04-0600, Joel Schopp:
From: David Kaplan david.kap...@amd.com
We can make the in instruction go faster the same way the out instruction is
already.
Signed-off-by: David Kaplan david.kap...@amd.com
[extracted from larger unlrelated patch, forward ported, tested]
201 - 300 of 525 matches
Mail list logo
