Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization
On 05/26/2015 10:48 PM, Paolo Bonzini wrote: On 26/05/2015 16:45, Edward Cree wrote: This breaks older compilers that can't initialize anon structures. How old ? Even gcc 3.1 says you can use unnamed struct/union fields and 3.2 is the minimum version required to compile the kernel as mentioned in the README. We could simply just name the structure, but I doubt this is the only place in the kernel code where it's being used this way :) This appears to be GCC bug #10676, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 Says it was fixed in 4.6, but I believe the kernel supports GCCs much older than that (back to 3.2). I personally hit it on 4.4.7, the version shipped with RHEL6.6. Yes, it will be fixed soon(ish). Probably before you can get rid of the obnoxious disclaimer... :) It has been fixed by Andrew: From: Andrew Morton a...@linux-foundation.org Subject: arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug arch/x86/kvm/mmu.c: In function 'kvm_mmu_pte_write': arch/x86/kvm/mmu.c:4256: error: unknown field 'cr0_wp' specified in initializer arch/x86/kvm/mmu.c:4257: error: unknown field 'cr4_pae' specified in initializer arch/x86/kvm/mmu.c:4257: warning: excess elements in union initializer ... gcc-4.4.4 (at least) has issues when using anonymous unions in initializers. Fixes: edc90b7dc4ceef6 (KVM: MMU: fix SMAP virtualization) Cc: Xiao Guangrong guangrong.x...@linux.intel.com Cc: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org Should be found at -mm tree. -- 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
[PATCH v3 1/1] KVM: PPC: Book3S: correct width in XER handling
In 64 bit kernels, the Fixed Point Exception Register (XER) is a 64
bit field (e.g. in kvm_regs and kvm_vcpu_arch) and in most places it is
accessed as such.
This patch corrects places where it is accessed as a 32 bit field by a
64 bit kernel. In some cases this is via a 32 bit load or store
instruction which, depending on endianness, will cause either the
lower or upper 32 bits to be missed. In another case it is cast as a
u32, causing the upper 32 bits to be cleared.
This patch corrects those places by extending the access methods to
64 bits.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
v3:
Adjust booke set/get xer to match book3s.
v2:
Also extend kvmppc_book3s_shadow_vcpu.xer to 64 bit.
arch/powerpc/include/asm/kvm_book3s.h |4 ++--
arch/powerpc/include/asm/kvm_book3s_asm.h |2 +-
arch/powerpc/include/asm/kvm_booke.h |4 ++--
arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 +++---
arch/powerpc/kvm/book3s_segment.S |4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index b91e74a..05a875a 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -225,12 +225,12 @@ static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
return vcpu-arch.cr;
}
-static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
+static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, ulong val)
{
vcpu-arch.xer = val;
}
-static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
+static inline ulong kvmppc_get_xer(struct kvm_vcpu *vcpu)
{
return vcpu-arch.xer;
}
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 5bdfb5d..c4ccd2d 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -112,7 +112,7 @@ struct kvmppc_book3s_shadow_vcpu {
bool in_use;
ulong gpr[14];
u32 cr;
- u32 xer;
+ ulong xer;
ulong ctr;
ulong lr;
ulong pc;
diff --git a/arch/powerpc/include/asm/kvm_booke.h
b/arch/powerpc/include/asm/kvm_booke.h
index 3286f0d..bc6e29e 100644
--- a/arch/powerpc/include/asm/kvm_booke.h
+++ b/arch/powerpc/include/asm/kvm_booke.h
@@ -54,12 +54,12 @@ static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
return vcpu-arch.cr;
}
-static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
+static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, ulong val)
{
vcpu-arch.xer = val;
}
-static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
+static inline ulong kvmppc_get_xer(struct kvm_vcpu *vcpu)
{
return vcpu-arch.xer;
}
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 4d70df2..d75be59 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -870,7 +870,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
blt hdec_soon
ld r6, VCPU_CTR(r4)
- lwz r7, VCPU_XER(r4)
+ ld r7, VCPU_XER(r4)
mtctr r6
mtxer r7
@@ -1103,7 +1103,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
mfctr r3
mfxer r4
std r3, VCPU_CTR(r9)
- stw r4, VCPU_XER(r9)
+ std r4, VCPU_XER(r9)
/* If this is a page table miss then see if it's theirs or ours */
cmpwi r12, BOOK3S_INTERRUPT_H_DATA_STORAGE
@@ -1675,7 +1675,7 @@ kvmppc_hdsi:
bl kvmppc_msr_interrupt
fast_interrupt_c_return:
6: ld r7, VCPU_CTR(r9)
- lwz r8, VCPU_XER(r9)
+ ld r8, VCPU_XER(r9)
mtctr r7
mtxer r8
mr r4, r9
diff --git a/arch/powerpc/kvm/book3s_segment.S
b/arch/powerpc/kvm/book3s_segment.S
index acee37c..ca8f174 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -123,7 +123,7 @@ no_dcbz32_on:
PPC_LL r8, SVCPU_CTR(r3)
PPC_LL r9, SVCPU_LR(r3)
lwz r10, SVCPU_CR(r3)
- lwz r11, SVCPU_XER(r3)
+ PPC_LL r11, SVCPU_XER(r3)
mtctr r8
mtlrr9
@@ -237,7 +237,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
mfctr r8
mflrr9
- stw r5, SVCPU_XER(r13)
+ PPC_STL r5, SVCPU_XER(r13)
PPC_STL r6, SVCPU_FAULT_DAR(r13)
stw r7, SVCPU_FAULT_DSISR(r13)
PPC_STL r8, SVCPU_CTR(r13)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/4] KVM: x86: Add KVM exit for IOAPIC EOIs
On Sun, May 24, 2015 at 07:46:03PM +0300, Avi Kivity wrote:
On 05/13/2015 04:47 AM, Steve Rutherford wrote:
Adds KVM_EXIT_IOAPIC_EOI which passes the interrupt vector up to
userspace.
Uses a per VCPU exit bitmap to decide whether or not the IOAPIC needs
to be informed (which is identical to the EOI_EXIT_BITMAP field used
by modern x86 processors, but can also be used to elide kvm IOAPIC EOI
exits on older processors).
[Note: A prototype using ResampleFDs found that decoupling the EOI
from the VCPU's thread made it possible for the VCPU to not see a
recent EOI after reentering the guest. This does not match real
hardware.]
Compile tested for Intel x86.
Signed-off-by: Steve Rutherford srutherf...@google.com
---
Documentation/virtual/kvm/api.txt | 10 ++
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/lapic.c | 9 +
arch/x86/kvm/x86.c| 11 +++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 5 +
6 files changed, 39 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 0744b4e..dd92996 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3285,6 +3285,16 @@ Valid values for 'type' are:
*/
__u64 kvm_valid_regs;
__u64 kvm_dirty_regs;
+
+/* KVM_EXIT_IOAPIC_EOI */
+struct {
+ __u8 vector;
+} eoi;
+
+Indicates that an eoi of a level triggered IOAPIC interrupt on vector has
+occurred, which should be handled by the userspace IOAPIC. Triggers when
+the Irqchip has been split between userspace and the kernel.
+
The ioapic is a global resource, so it doesn't make sense for
information about it to be returned in a per-vcpu structure
EOI exits are a per-vcpu behavior, so this doesn't seem all that strange.
(or to block the vcpu while it is being processed).
Blocking doesn't feel clean, but doesn't seem all that bad, given
that these operations are relatively rare on modern configurations.
The way I'd model it is to emulate the APIC bus that connects local
APICs and the IOAPIC, using a socket pair. When the user-space
ioapic wants to inject an interrupt, it sends a message to the local
APICs which then inject it, and when it's ack'ed the EOI is sent
back on the same bus.
Although I'm not certain about this, it sounds to me like this would
require a kernel thread to be waiting (in some way) on this socket, which
seems rather heavy handed.
--
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
Re: Query regarding a kvm patch.
Hi Puneet, On Tue, May 26, 2015 at 01:07:02PM -0700, Puneet Zaroo wrote: Wanpeng, I am encountering the issue mentioned in the following patch request https://lkml.org/lkml/2014/7/4/52, while running Ubuntu, linux kernel version : 3.13.0-32. I was wondering if the patch you proposed made it to the kernel or the issue got fixed in some alternate manner. Most importantly which is the earliest kernel version which has the fix. Paolo also send a patchset to fix it and they are merged upstream. https://lkml.org/lkml/2014/7/21/262 Thanks in advance, - Puneet -- 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
Re: [RFC PATCH 2/4] KVM: x86: Add KVM exit for IOAPIC EOIs
On 05/27/2015 05:06 AM, Steve Rutherford wrote:
On Sun, May 24, 2015 at 07:46:03PM +0300, Avi Kivity wrote:
On 05/13/2015 04:47 AM, Steve Rutherford wrote:
Adds KVM_EXIT_IOAPIC_EOI which passes the interrupt vector up to
userspace.
Uses a per VCPU exit bitmap to decide whether or not the IOAPIC needs
to be informed (which is identical to the EOI_EXIT_BITMAP field used
by modern x86 processors, but can also be used to elide kvm IOAPIC EOI
exits on older processors).
[Note: A prototype using ResampleFDs found that decoupling the EOI
from the VCPU's thread made it possible for the VCPU to not see a
recent EOI after reentering the guest. This does not match real
hardware.]
Compile tested for Intel x86.
Signed-off-by: Steve Rutherford srutherf...@google.com
---
Documentation/virtual/kvm/api.txt | 10 ++
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/lapic.c | 9 +
arch/x86/kvm/x86.c| 11 +++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 5 +
6 files changed, 39 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 0744b4e..dd92996 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3285,6 +3285,16 @@ Valid values for 'type' are:
*/
__u64 kvm_valid_regs;
__u64 kvm_dirty_regs;
+
+ /* KVM_EXIT_IOAPIC_EOI */
+struct {
+ __u8 vector;
+} eoi;
+
+Indicates that an eoi of a level triggered IOAPIC interrupt on vector has
+occurred, which should be handled by the userspace IOAPIC. Triggers when
+the Irqchip has been split between userspace and the kernel.
+
The ioapic is a global resource, so it doesn't make sense for
information about it to be returned in a per-vcpu structure
EOI exits are a per-vcpu behavior, so this doesn't seem all that strange.
(or to block the vcpu while it is being processed).
Blocking doesn't feel clean, but doesn't seem all that bad, given
that these operations are relatively rare on modern configurations.
Agree, maybe the realtime people have an interest here.
The way I'd model it is to emulate the APIC bus that connects local
APICs and the IOAPIC, using a socket pair. When the user-space
ioapic wants to inject an interrupt, it sends a message to the local
APICs which then inject it, and when it's ack'ed the EOI is sent
back on the same bus.
Although I'm not certain about this, it sounds to me like this would
require a kernel thread to be waiting (in some way) on this socket, which
seems rather heavy handed.
It's been a while since I did kernel programming, but I think you can
queue a callback to be called when an I/O is ready, and not require a
thread. IIRC we do that with irqfd to cause an interrupt to be injected.
--
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
Re: Announcing qboot, a minimal x86 firmware for QEMU
On Fri, May 22, 2015 at 10:53:54AM +0800, Yong Wang wrote: On Thu, May 21, 2015 at 03:51:43PM +0200, Paolo Bonzini wrote: On the QEMU side, there is no support yet for persistent memory and the NFIT tables from ACPI 6.0. Once that (and ACPI support) is added, qboot will automatically start using it. We are working on adding NFIT support into virtual bios. Great. I asked about this on the #pmem (irc.oftc.net) IRC channel last week. Which virtual bios are you targeting? Stefan pgp1LQizfjfkd.pgp Description: PGP signature
Re: [PATCH v2 1/1] KVM: PPC: Book3S: correct width in XER handling
On 26.05.15 02:27, Sam Bobroff wrote:
In 64 bit kernels, the Fixed Point Exception Register (XER) is a 64
bit field (e.g. in kvm_regs and kvm_vcpu_arch) and in most places it is
accessed as such.
This patch corrects places where it is accessed as a 32 bit field by a
64 bit kernel. In some cases this is via a 32 bit load or store
instruction which, depending on endianness, will cause either the
lower or upper 32 bits to be missed. In another case it is cast as a
u32, causing the upper 32 bits to be cleared.
This patch corrects those places by extending the access methods to
64 bits.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
v2:
Also extend kvmppc_book3s_shadow_vcpu.xer to 64 bit.
arch/powerpc/include/asm/kvm_book3s.h |4 ++--
arch/powerpc/include/asm/kvm_book3s_asm.h |2 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 +++---
arch/powerpc/kvm/book3s_segment.S |4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index b91e74a..05a875a 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -225,12 +225,12 @@ static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
return vcpu-arch.cr;
}
-static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
+static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, ulong val)
Now we have book3s and booke files with different prototypes on the same
inline function names. That's really ugly. Please keep them in sync ;).
Alex
{
vcpu-arch.xer = val;
}
-static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
+static inline ulong kvmppc_get_xer(struct kvm_vcpu *vcpu)
{
return vcpu-arch.xer;
}
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 5bdfb5d..c4ccd2d 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -112,7 +112,7 @@ struct kvmppc_book3s_shadow_vcpu {
bool in_use;
ulong gpr[14];
u32 cr;
- u32 xer;
+ ulong xer;
ulong ctr;
ulong lr;
ulong pc;
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 4d70df2..d75be59 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -870,7 +870,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
blt hdec_soon
ld r6, VCPU_CTR(r4)
- lwz r7, VCPU_XER(r4)
+ ld r7, VCPU_XER(r4)
mtctr r6
mtxer r7
@@ -1103,7 +1103,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
mfctr r3
mfxer r4
std r3, VCPU_CTR(r9)
- stw r4, VCPU_XER(r9)
+ std r4, VCPU_XER(r9)
/* If this is a page table miss then see if it's theirs or ours */
cmpwi r12, BOOK3S_INTERRUPT_H_DATA_STORAGE
@@ -1675,7 +1675,7 @@ kvmppc_hdsi:
bl kvmppc_msr_interrupt
fast_interrupt_c_return:
6: ld r7, VCPU_CTR(r9)
- lwz r8, VCPU_XER(r9)
+ ld r8, VCPU_XER(r9)
mtctr r7
mtxer r8
mr r4, r9
diff --git a/arch/powerpc/kvm/book3s_segment.S
b/arch/powerpc/kvm/book3s_segment.S
index acee37c..ca8f174 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -123,7 +123,7 @@ no_dcbz32_on:
PPC_LL r8, SVCPU_CTR(r3)
PPC_LL r9, SVCPU_LR(r3)
lwz r10, SVCPU_CR(r3)
- lwz r11, SVCPU_XER(r3)
+ PPC_LL r11, SVCPU_XER(r3)
mtctr r8
mtlrr9
@@ -237,7 +237,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
mfctr r8
mflrr9
- stw r5, SVCPU_XER(r13)
+ PPC_STL r5, SVCPU_XER(r13)
PPC_STL r6, SVCPU_FAULT_DAR(r13)
stw r7, SVCPU_FAULT_DSISR(r13)
PPC_STL r8, SVCPU_CTR(r13)
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] KVM: x86: add KVM_MEM_X86_SMRAM memory slot flag
On 05/08/2015 02:20 PM, Paolo Bonzini wrote:
This adds an arch-specific memslot flag that hides slots unless the
VCPU is in system management mode.
Some care is needed in order to limit the overhead of x86_gfn_to_memslot
when compared with gfn_to_memslot. Thankfully, we have __gfn_to_memslot
and search_memslots which are the same, so we can add some extra output
to search_memslots. The compiler will optimize it as dead code in
__gfn_to_memslot, and will use it to thread jumps in x86_gfn_to_memslot.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Documentation/virtual/kvm/api.txt | 18 --
arch/x86/include/uapi/asm/kvm.h | 3 +++
arch/x86/kvm/smram.c | 25 +++--
include/linux/kvm_host.h | 14 ++
virt/kvm/kvm_main.c | 4
5 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 51523b70b6b2..2bc99ae040da 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -933,18 +933,24 @@ It is recommended that the lower 21 bits of
guest_phys_addr and userspace_addr
be identical. This allows large pages in the guest to be backed by large
pages in the host.
-The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
-KVM_MEM_READONLY. The former can be set to instruct KVM to keep track of
-writes to memory within the slot. See KVM_GET_DIRTY_LOG ioctl to know how to
-use it. The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
-to make a new slot read-only. In this case, writes to this memory will be
-posted to userspace as KVM_EXIT_MMIO exits.
+The flags field supports two architecture-independent flags:
+KVM_MEM_LOG_DIRTY_PAGES and KVM_MEM_READONLY. The former can be set
+to instruct KVM to keep track of writes to memory within the slot.
+See KVM_GET_DIRTY_LOG ioctl to know how to use it. The latter can
+be set, if KVM_CAP_READONLY_MEM capability allows it, to make a new
+slot read-only. In this case, writes to this memory will be posted to
+userspace as KVM_EXIT_MMIO exits.
When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
the memory region are automatically reflected into the guest. For example, an
mmap() that affects the region will be made visible immediately. Another
example is madvise(MADV_DROP).
+Each architectures can support other specific flags. Right now there is
+only one defined. On x86, if KVM_CAP_X86_SMM is available, the
+KVM_MEM_X86_SMRAM flag will hide the slot to VCPUs that are not
+in system management mode.
Is this generic enough? For example, a system could configure itself so
that an SMRAM region goes to mmio, hiding real RAM.
I see two alternatives:
- have three states: SMM, !SMM, both
- define two tables: SMM, !SMM, both spanning the entire address space
you should probably document how dirty bitmap handling happens in the
presence of SMM.
+
It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
allocation and is deprecated.
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 30100a3c1bed..46df15bc844f 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -45,6 +45,9 @@
#define __KVM_HAVE_XCRS
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_ARCH_VALID_FLAGS KVM_MEM_X86_SMRAM
+#define KVM_MEM_X86_SMRAM (1 24)
+
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
diff --git a/arch/x86/kvm/smram.c b/arch/x86/kvm/smram.c
index 73616edab631..e7dd933673a4 100644
--- a/arch/x86/kvm/smram.c
+++ b/arch/x86/kvm/smram.c
@@ -19,10 +19,23 @@
#include linux/module.h
#include linux/kvm_host.h
+#include kvm_cache_regs.h
struct kvm_memory_slot *x86_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn)
{
- struct kvm_memory_slot *slot = gfn_to_memslot(vcpu-kvm, gfn);
+ /* By using search_memslots directly the compiler can optimize away
+* the if (found) check below.
+ *
+* It cannot do the same for gfn_to_memslot because it is not inlined,
+* and it also cannot do the same for __gfn_to_memslot because the
+* kernel is compiled with -fno-delete-null-pointer-checks.
+*/
+ bool found;
+ struct kvm_memslots *memslots = kvm_memslots(vcpu-kvm);
+ struct kvm_memory_slot *slot = search_memslots(memslots, gfn, found);
+
+ if (found unlikely(slot-flags KVM_MEM_X86_SMRAM) !is_smm(vcpu))
+ return NULL;
return slot;
}
@@ -112,7 +125,15 @@ EXPORT_SYMBOL_GPL(x86_read_guest);
int x86_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
gpa_t gpa, unsigned long len)
{
- return kvm_gfn_to_hva_cache_init(kvm, ghc, gpa,
Re: [PATCH] KVM: x86: preserve x2APIC LDR on INIT
On 22/05/2015 19:22, Radim Krčmář wrote: Logical x2APIC stops working if we rewrite it with zeros. The best references are SDM April 2015: 10.12.10.1 Logical Destination Mode in x2APIC Mode [...], the LDR are initialized by hardware based on the value of x2APIC ID upon x2APIC state transitions. and SDM April 2015: 10.12.10.2 Deriving Logical x2APIC ID from the Local x2APIC ID The LDR initialization occurs whenever the x2APIC mode is enabled Signed-off-by: Radim Krčmář rkrc...@redhat.com --- arch/x86/kvm/lapic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index c2a7d8a7a414..c789e00dfa8b 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -1594,7 +1594,8 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) apic_set_reg(apic, APIC_DFR, 0xU); apic_set_spiv(apic, 0xff); apic_set_reg(apic, APIC_TASKPRI, 0); - kvm_apic_set_ldr(apic, 0); + if (!apic_x2apic_mode(apic)) + kvm_apic_set_ldr(apic, 0); apic_set_reg(apic, APIC_ESR, 0); apic_set_reg(apic, APIC_ICR, 0); apic_set_reg(apic, APIC_ICR2, 0); Applied, thanks. Paolo -- 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
Re: kvm: odd time values since kvmclock: set scheduler clock stable
On 05/26/2015 09:21 AM, Luiz Capitulino wrote: Sasha, Can you give the suggested patch (hypervisor patch...) a try please? (with a patched guest, obviously). KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR I've tried your v2, it works for me. My test-case is very simple though: I just boot a VM, log in and reboot. This reproduces the issue Sasha reported 100% of the times for me (don't need multi-vcpu guest either). Sorry for the delay, we had a long weekend here. It seems to work fine here, no more jumps when booting. Thanks, Sasha -- 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
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 05/25/2015 08:53 AM, Paolo Bonzini wrote: On 22/05/2015 13:12, Daniel P. Berrange wrote: In particular I don't see why we need to have a SATA controller and ISA/LPC bridge in every virt machine - root PCI bus only should be possible, as you can provide disks via virtio-blk or virtio-scsi and serial, parallel, mouse, floppy via PCI devices and/or by adding a USB bus in the cases where you really need one. I think removing the ISA/LPC bridge is hard. It includes the real-time clock and fw_cfg, for example. Could VirtIO specified replacements make sense for these peripherals? Chris -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
Re: kvm: odd time values since kvmclock: set scheduler clock stable
On Thu, 21 May 2015 21:41:23 -0300 Marcelo Tosatti mtosa...@redhat.com wrote: On Mon, May 18, 2015 at 10:13:03PM -0400, Sasha Levin wrote: On 05/18/2015 10:02 PM, Sasha Levin wrote: On 05/18/2015 08:13 PM, Marcelo Tosatti wrote: GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote: On 05/18/2015 06:39 PM, Marcelo Tosatti wrote: On Tue, May 12, 2015 at 07:17:24PM -0400, Sasha Levin wrote: Hi all, I'm seeing odd jump in time values during boot of a KVM guest: [...] [0.00] tsc: Detected 2260.998 MHz processor [3376355.247558] Calibrating delay loop (skipped) preset value.. [...] I've bisected it to: Paolo, Sasha, Although this might seem undesirable, there is no requirement for sched_clock to initialize at 0: * * There is no strict promise about the base, although it tends to start * at 0 on boot (but people really shouldn't rely on that). * Sasha, are you seeing any problem other than the apparent time jump? Nope, but I've looked at it again and it seems that it jumps to the host's clock (that is, in the example above the 3376355 value was the host's clock value). Thanks, Sasha Sasha, thats right. Its the host monotonic clock. It's worth figuring out if (what) userspace breaks on that. I know it says that you shouldn't rely on that, but I'd happily place a bet on at least one userspace treating it as seconds since boot or something similar. Didn't need to go far... In the guest: # date Tue May 19 02:11:46 UTC 2015 # echo hi /dev/kmsg [3907533.080112] hi # dmesg -T [Fri Jul 3 07:33:41 2015] hi Sasha, Can you give the suggested patch (hypervisor patch...) a try please? (with a patched guest, obviously). KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR I've tried your v2, it works for me. My test-case is very simple though: I just boot a VM, log in and reboot. This reproduces the issue Sasha reported 100% of the times for me (don't need multi-vcpu guest either). Would be nice to hear from Sasha too. -- 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
Re: KVM call agenda for 2015-05-26
Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. As there are no topics on the agenda, call get cancelled. Happy hacking, Juan. Call details: By popular demand, a google calendar public entry with it https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ (Let me know if you have any problems with the calendar entry. I just gave up about getting right at the same time CEST, CET, EDT and DST). If you need phone number details, contact me privately Thanks, Juan. -- 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
Re: [PATCH v6 0/8] vhost: support for cross endian guests
On Tue, 12 May 2015 12:52:55 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Tue, May 12, 2015 at 12:44:26PM +0200, Greg Kurz wrote: On Fri, 24 Apr 2015 15:31:54 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Fri, Apr 24, 2015 at 02:24:15PM +0200, Greg Kurz wrote: Only cosmetic and documentation changes since v5. --- Looks sane to me. I plan to review and apply next week. Hi Michael, I realize you just got back and have tons of things to do... Do you still plan to apply shortly ? Would you also have time to comment the QEMU part ? Thanks. -- Greg Yes, sorry about the delay - I also got virtio upstream landed on my lap. I'll do my best to prioritize. Hi Michael, This is just a friendly reminder. Are there chances you pick up this kernel series before virtio 1.0 is in upstream QEMU ? Cheers. -- Greg Greg Kurz (8): virtio: introduce virtio_is_little_endian() helper tun: add tun_is_little_endian() helper macvtap: introduce macvtap_is_little_endian() helper vringh: introduce vringh_is_little_endian() helper vhost: introduce vhost_is_little_endian() helper virtio: add explicit big-endian support to memory accessors vhost: cross-endian support for legacy devices macvtap/tun: cross-endian support for little-endian hosts drivers/net/Kconfig | 14 ++ drivers/net/macvtap.c| 66 +- drivers/net/tun.c| 68 ++ drivers/vhost/Kconfig| 15 +++ drivers/vhost/vhost.c| 85 ++ drivers/vhost/vhost.h| 25 --- include/linux/virtio_byteorder.h | 24 ++- include/linux/virtio_config.h| 18 +--- include/linux/vringh.h | 18 +--- include/uapi/linux/if_tun.h |6 +++ include/uapi/linux/vhost.h | 14 ++ 11 files changed, 320 insertions(+), 33 deletions(-) -- Greg -- 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
Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization
This breaks older compilers that can't initialize anon structures. How old ? Even gcc 3.1 says you can use unnamed struct/union fields and 3.2 is the minimum version required to compile the kernel as mentioned in the README. We could simply just name the structure, but I doubt this is the only place in the kernel code where it's being used this way :) This appears to be GCC bug #10676, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 Says it was fixed in 4.6, but I believe the kernel supports GCCs much older than that (back to 3.2). I personally hit it on 4.4.7, the version shipped with RHEL6.6. So I think the kernel code has to change, probably by naming the structure. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. -- 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
Re: [PATCH v2] KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR
On Sat, 23 May 2015 17:06:29 -0300 Marcelo Tosatti mtosa...@redhat.com wrote: Initialize kvmclock base, on kvmclock system MSR write time, so that the guest sees kvmclock counting from zero. This matches baremetal behaviour when kvmclock in guest sets sched clock stable. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Tested-by: Luiz Capitulino lcapitul...@redhat.com diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index cc2c759..ea40d24 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2188,6 +2188,8 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) vcpu-requests); ka-boot_vcpu_runs_old_kvmclock = tmp; + + ka-kvmclock_offset = -get_kernel_ns(); } vcpu-arch.time = data; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
Re: [PATCH] KVM: x86: use correct APIC ID on x2APIC transition
On 22/05/2015 18:45, Radim Krčmář wrote:
SDM April 2015, 10.12.5 State Changes From xAPIC Mode to x2APIC Mode
• Any APIC ID value written to the memory-mapped local APIC ID register
is not preserved.
Fix it by sourcing vcpu_id (= initial APIC ID) instead of memory-mapped
APIC ID. Proper use of apic functions would result in two calls to
recalculate_apic_map(), so this patch makes a new helper.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index dc5b57bb1f76..c2a7d8a7a414 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -240,6 +240,15 @@ static inline void kvm_apic_set_ldr(struct kvm_lapic
*apic, u32 id)
recalculate_apic_map(apic-vcpu-kvm);
}
+static inline void kvm_apic_set_x2apic_id(struct kvm_lapic *apic, u8 id)
+{
+ u32 ldr = ((id 4) 16) | (1 (id 0xf));
+
+ apic_set_reg(apic, APIC_ID, id 24);
+ apic_set_reg(apic, APIC_LDR, ldr);
+ recalculate_apic_map(apic-vcpu-kvm);
+}
+
static inline int apic_lvt_enabled(struct kvm_lapic *apic, int lvt_type)
{
return !(kvm_apic_get_reg(apic, lvt_type) APIC_LVT_MASKED);
@@ -1538,9 +1547,7 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
value)
if ((old_value ^ value) X2APIC_ENABLE) {
if (value X2APIC_ENABLE) {
- u32 id = kvm_apic_id(apic);
- u32 ldr = ((id 4) 16) | (1 (id 0xf));
- kvm_apic_set_ldr(apic, ldr);
+ kvm_apic_set_x2apic_id(apic, vcpu-vcpu_id);
kvm_x86_ops-set_virtual_x2apic_mode(vcpu, true);
} else
kvm_x86_ops-set_virtual_x2apic_mode(vcpu, false);
Applied, thanks.
Paolo
--
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
Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization
On 26/05/2015 16:45, Edward Cree wrote: This breaks older compilers that can't initialize anon structures. How old ? Even gcc 3.1 says you can use unnamed struct/union fields and 3.2 is the minimum version required to compile the kernel as mentioned in the README. We could simply just name the structure, but I doubt this is the only place in the kernel code where it's being used this way :) This appears to be GCC bug #10676, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 Says it was fixed in 4.6, but I believe the kernel supports GCCs much older than that (back to 3.2). I personally hit it on 4.4.7, the version shipped with RHEL6.6. Yes, it will be fixed soon(ish). Probably before you can get rid of the obnoxious disclaimer... :) Paolo The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. -- 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
Re: [PATCH v4] i386: Introduce ARAT CPU feature
(Fixing subject line)
On Tue, May 26, 2015 at 06:35:45AM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
ARAT signals that the APIC timer does not stop in power saving states.
As our APICs are emulated, it's fine to expose this feature to guests,
at least when asking for KVM host features or with CPU types that
include the flag. The exact model number that introduced the feature is
not known, but reports can be found that it's at least available since
Sandy Bridge.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v4:
- followed suggestions by Eduardo, now using PC_COMPAT_2_3 define
hw/i386/pc_piix.c| 4
hw/i386/pc_q35.c | 4
include/hw/i386/pc.h | 8
target-i386/cpu.c| 33 -
target-i386/cpu.h| 3 +++
target-i386/kvm.c| 2 ++
6 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 212e263..b675d2c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -543,6 +543,10 @@ static QEMUMachine pc_i440fx_machine_v2_3 = {
PC_I440FX_2_3_MACHINE_OPTIONS,
.name = pc-i440fx-2.3,
.init = pc_init_pci_2_3,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_2_3,
+{ /* end of list */ }
+},
};
#define PC_I440FX_2_2_MACHINE_OPTIONS PC_I440FX_2_3_MACHINE_OPTIONS
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e67f2de..38c3cf2 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -439,6 +439,10 @@ static QEMUMachine pc_q35_machine_v2_3 = {
PC_Q35_2_3_MACHINE_OPTIONS,
.name = pc-q35-2.3,
.init = pc_q35_init_2_3,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_2_3,
+{ /* end of list */ }
+},
};
This breaks pc-*-2.2 and pc-*-2.1, because 2.2 nas no .compat_props set,
and 2.1 has .compat_props = HW_COMPAT_2_1.
Those issues are fixed by the series:
[PATCH v2 00/13] pc, hw, spapr: Cleanup of {HW, PC, SPAPR}_COMPAT_* macros
I suggest we base this patch on top of it.
--
Eduardo
--
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
Re: [Qemu-devel] [PATCH v4] i386: Introduce ARAT CPU feature
On Tue, May 26, 2015 at 02:18:32PM -0300, Eduardo Habkost wrote:
(Fixing subject line)
On Tue, May 26, 2015 at 06:35:45AM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
ARAT signals that the APIC timer does not stop in power saving states.
As our APICs are emulated, it's fine to expose this feature to guests,
at least when asking for KVM host features or with CPU types that
include the flag. The exact model number that introduced the feature is
not known, but reports can be found that it's at least available since
Sandy Bridge.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v4:
- followed suggestions by Eduardo, now using PC_COMPAT_2_3 define
hw/i386/pc_piix.c| 4
hw/i386/pc_q35.c | 4
include/hw/i386/pc.h | 8
target-i386/cpu.c| 33 -
target-i386/cpu.h| 3 +++
target-i386/kvm.c| 2 ++
6 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 212e263..b675d2c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -543,6 +543,10 @@ static QEMUMachine pc_i440fx_machine_v2_3 = {
PC_I440FX_2_3_MACHINE_OPTIONS,
.name = pc-i440fx-2.3,
.init = pc_init_pci_2_3,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_2_3,
+{ /* end of list */ }
+},
};
#define PC_I440FX_2_2_MACHINE_OPTIONS PC_I440FX_2_3_MACHINE_OPTIONS
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e67f2de..38c3cf2 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -439,6 +439,10 @@ static QEMUMachine pc_q35_machine_v2_3 = {
PC_Q35_2_3_MACHINE_OPTIONS,
.name = pc-q35-2.3,
.init = pc_q35_init_2_3,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_2_3,
+{ /* end of list */ }
+},
};
This breaks pc-*-2.2 and pc-*-2.1, because 2.2 nas no .compat_props set,
and 2.1 has .compat_props = HW_COMPAT_2_1.
Those issues are fixed by the series:
[PATCH v2 00/13] pc, hw, spapr: Cleanup of {HW, PC, SPAPR}_COMPAT_* macros
I suggest we base this patch on top of it.
For reference, the PC compat series I have submitted recently are
available on git, at:
git://github.com/ehabkost/qemu-hacks.git work/pc-compat-cleanup2
(Subject: pc, hw, spapr: Cleanup of {HW, PC, SPAPR}_COMPAT_* macros)
git://github.com/ehabkost/qemu-hacks.git work/pc-compat-macros
(Subject: pc: Don't use QEMUMachine, simplify compat+init code)
--
Eduardo
--
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
