Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8
On 20/11/2015 09:11, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has to be shifted by > two, not only by one. This fixes hardware watchpoints in gdb of > older guests that only use the H_SET_DABR/X interface instead > of the new H_SET_MODE interface. > > Signed-off-by: Thomas Huth <th...@redhat.com> > --- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > index b98889e..3983b87 100644 > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > @@ -2143,7 +2143,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) > > /* Emulate H_SET_DABR/X on P8 for the sake of compat mode guests */ > 2: rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW > - rlwimi r5, r4, 1, DAWRX_WT > + rlwimi r5, r4, 2, DAWRX_WT > clrrdi r4, r4, 3 > std r4, VCPU_DAWR(r3) > std r5, VCPU_DAWRX(r3) > Nice catch. Reviewed-by: Laurent Vivier <lviv...@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
Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8
On 20/11/2015 09:11, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has to be shifted by > two, not only by one. This fixes hardware watchpoints in gdb of > older guests that only use the H_SET_DABR/X interface instead > of the new H_SET_MODE interface. > > Signed-off-by: Thomas Huth <th...@redhat.com> > --- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > index b98889e..3983b87 100644 > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > @@ -2143,7 +2143,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) > > /* Emulate H_SET_DABR/X on P8 for the sake of compat mode guests */ > 2: rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW > - rlwimi r5, r4, 1, DAWRX_WT > + rlwimi r5, r4, 2, DAWRX_WT > clrrdi r4, r4, 3 > std r4, VCPU_DAWR(r3) > std r5, VCPU_DAWRX(r3) > Nice catch. Reviewed-by: Laurent Vivier <lviv...@redhat.com> -- 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 v3 1/1] KVM: PPC: Book3S: correct width in XER handling
Hi,
I'd also like to see this patch in the mainstream as it fixes a bug
appearing when we switch from vCPU context to hypervisor context (guest
crash).
Laurent
On 06/08/2015 03:25, Sam Bobroff wrote:
Ping?
I think I've addressed all the comments in this version. Is there anything
else
I need to look at?
Cheers,
Sam.
On Wed, May 27, 2015 at 09:56:57AM +1000, 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
---
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
Re: [PATCH 0/2] Two fixes for dynamic micro-threading
On 23/07/2015 14:02, Alexander Graf wrote: On 20.07.15 08:49, David Gibson wrote: On Thu, Jul 16, 2015 at 05:11:12PM +1000, Paul Mackerras wrote: This series contains two fixes for the new dynamic micro-threading code that was added recently for HV-mode KVM on Power servers. The patches are against Alex Graf's kvm-ppc-queue branch. Please apply. agraf, Any word on these? These appear to fix a really nasty host crash in current upstream. I'd really like to see them merged ASAP. Thanks, applied to kvm-ppc-queue. The host crash should only occur with dynamic micro-threading enabled, which is not in Linus' tree, correct? Yes, it only occurs with dynamic micro-threading enabled. Yes, this is not in Linus' tree. Laurent -- 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 0/2] Two fixes for dynamic micro-threading
On 23/07/2015 14:02, Alexander Graf wrote: On 20.07.15 08:49, David Gibson wrote: On Thu, Jul 16, 2015 at 05:11:12PM +1000, Paul Mackerras wrote: This series contains two fixes for the new dynamic micro-threading code that was added recently for HV-mode KVM on Power servers. The patches are against Alex Graf's kvm-ppc-queue branch. Please apply. agraf, Any word on these? These appear to fix a really nasty host crash in current upstream. I'd really like to see them merged ASAP. Thanks, applied to kvm-ppc-queue. The host crash should only occur with dynamic micro-threading enabled, which is not in Linus' tree, correct? Yes, it only occurs with dynamic micro-threading enabled. Yes, this is not in Linus' tree. Laurent -- 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 0/2] Two fixes for dynamic micro-threading
On 16/07/2015 09:11, Paul Mackerras wrote: This series contains two fixes for the new dynamic micro-threading code that was added recently for HV-mode KVM on Power servers. The patches are against Alex Graf's kvm-ppc-queue branch. Please apply. Paul. arch/powerpc/kvm/book3s_hv.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) Tested-by: Laurent Vivier lviv...@redhat.com [this series has corrected a host kernel crash when CPU are overcommitted] -- 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 0/2] Two fixes for dynamic micro-threading
On 16/07/2015 09:11, Paul Mackerras wrote: This series contains two fixes for the new dynamic micro-threading code that was added recently for HV-mode KVM on Power servers. The patches are against Alex Graf's kvm-ppc-queue branch. Please apply. Paul. arch/powerpc/kvm/book3s_hv.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) Tested-by: Laurent Vivier lviv...@redhat.com [this series has corrected a host kernel crash when CPU are overcommitted] -- 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 v3 1/1] KVM: PPC: Book3S: correct width in XER handling
On 27/05/2015 01:56, 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
---
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)
Reviewed-by: Laurent Vivier lviv...@redhat.com
--
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] KVM: Add Kconfig option to signal cross-endian guests
On 09/07/2015 09:49, Thomas Huth wrote: The option for supporting cross-endianness legacy guests in the vhost and tun code should only be available on systems that support cross-endian guests. I'm sure I misunderstand something, but what happens if we use QEMU with TCG instead of KVM, i.e. a big endian powerpc kernel guest on x86_64 little endian host ? Do you forbid the use of vhost in this case ? Signed-off-by: Thomas Huth th...@redhat.com --- arch/arm/kvm/Kconfig | 1 + arch/arm64/kvm/Kconfig | 1 + arch/powerpc/kvm/Kconfig | 1 + drivers/net/Kconfig | 1 + drivers/vhost/Kconfig| 1 + virt/kvm/Kconfig | 3 +++ 6 files changed, 8 insertions(+) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index bfb915d..9d8f363 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -31,6 +31,7 @@ config KVM select KVM_VFIO select HAVE_KVM_EVENTFD select HAVE_KVM_IRQFD + select KVM_CROSS_ENDIAN_GUESTS depends on ARM_VIRT_EXT ARM_LPAE ARM_ARCH_TIMER ---help--- Support hosting virtualized guest machines. diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index bfffe8f..9af39fe 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -31,6 +31,7 @@ config KVM select KVM_VFIO select HAVE_KVM_EVENTFD select HAVE_KVM_IRQFD + select KVM_CROSS_ENDIAN_GUESTS ---help--- Support hosting virtualized guest machines. diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 3caec2c..e028710 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -79,6 +79,7 @@ config KVM_BOOK3S_64_HV select KVM_BOOK3S_HV_POSSIBLE select MMU_NOTIFIER select CMA + select KVM_CROSS_ENDIAN_GUESTS ---help--- Support running unmodified book3s_64 guest kernels in virtual machines on POWER7 and PPC970 processors that have diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index c18f9e6..0c4ce47 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -261,6 +261,7 @@ config TUN config TUN_VNET_CROSS_LE bool Support for cross-endian vnet headers on little-endian kernels default n + depends on KVM_CROSS_ENDIAN_GUESTS ---help--- This option allows TUN/TAP and MACVTAP device drivers in a little-endian kernel to parse vnet headers that come from a diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig index 533eaf0..4d8ae6b 100644 --- a/drivers/vhost/Kconfig +++ b/drivers/vhost/Kconfig @@ -35,6 +35,7 @@ config VHOST config VHOST_CROSS_ENDIAN_LEGACY bool Cross-endian support for vhost + depends on KVM_CROSS_ENDIAN_GUESTS default n ---help--- This option allows vhost to support guests with a different byte diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig index e2c876d..cc7b28a 100644 --- a/virt/kvm/Kconfig +++ b/virt/kvm/Kconfig @@ -47,3 +47,6 @@ config KVM_GENERIC_DIRTYLOG_READ_PROTECT config KVM_COMPAT def_bool y depends on COMPAT !S390 + +config KVM_CROSS_ENDIAN_GUESTS + bool -- 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] KVM: Add Kconfig option to signal cross-endian guests
On 09/07/2015 09:49, Thomas Huth wrote: The option for supporting cross-endianness legacy guests in the vhost and tun code should only be available on systems that support cross-endian guests. I'm sure I misunderstand something, but what happens if we use QEMU with TCG instead of KVM, i.e. a big endian powerpc kernel guest on x86_64 little endian host ? Do you forbid the use of vhost in this case ? Signed-off-by: Thomas Huth th...@redhat.com --- arch/arm/kvm/Kconfig | 1 + arch/arm64/kvm/Kconfig | 1 + arch/powerpc/kvm/Kconfig | 1 + drivers/net/Kconfig | 1 + drivers/vhost/Kconfig| 1 + virt/kvm/Kconfig | 3 +++ 6 files changed, 8 insertions(+) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index bfb915d..9d8f363 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -31,6 +31,7 @@ config KVM select KVM_VFIO select HAVE_KVM_EVENTFD select HAVE_KVM_IRQFD + select KVM_CROSS_ENDIAN_GUESTS depends on ARM_VIRT_EXT ARM_LPAE ARM_ARCH_TIMER ---help--- Support hosting virtualized guest machines. diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index bfffe8f..9af39fe 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -31,6 +31,7 @@ config KVM select KVM_VFIO select HAVE_KVM_EVENTFD select HAVE_KVM_IRQFD + select KVM_CROSS_ENDIAN_GUESTS ---help--- Support hosting virtualized guest machines. diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 3caec2c..e028710 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -79,6 +79,7 @@ config KVM_BOOK3S_64_HV select KVM_BOOK3S_HV_POSSIBLE select MMU_NOTIFIER select CMA + select KVM_CROSS_ENDIAN_GUESTS ---help--- Support running unmodified book3s_64 guest kernels in virtual machines on POWER7 and PPC970 processors that have diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index c18f9e6..0c4ce47 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -261,6 +261,7 @@ config TUN config TUN_VNET_CROSS_LE bool Support for cross-endian vnet headers on little-endian kernels default n + depends on KVM_CROSS_ENDIAN_GUESTS ---help--- This option allows TUN/TAP and MACVTAP device drivers in a little-endian kernel to parse vnet headers that come from a diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig index 533eaf0..4d8ae6b 100644 --- a/drivers/vhost/Kconfig +++ b/drivers/vhost/Kconfig @@ -35,6 +35,7 @@ config VHOST config VHOST_CROSS_ENDIAN_LEGACY bool Cross-endian support for vhost + depends on KVM_CROSS_ENDIAN_GUESTS default n ---help--- This option allows vhost to support guests with a different byte diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig index e2c876d..cc7b28a 100644 --- a/virt/kvm/Kconfig +++ b/virt/kvm/Kconfig @@ -47,3 +47,6 @@ config KVM_GENERIC_DIRTYLOG_READ_PROTECT config KVM_COMPAT def_bool y depends on COMPAT !S390 + +config KVM_CROSS_ENDIAN_GUESTS + bool -- 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 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
On 22/06/2015 02:09, Paul Mackerras wrote: On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote: Tested-by: Laurent Vivier lviv...@redhat.com Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ? Did I miss something ? My test system is an IBM Power S822L. I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both attached on the same core (with pinning option of virt-manager). Then, I measure the time needed to compile a kernel in parallel in both guests with make -j 16. My kernel without micro-threading: real37m23.424s real37m24.959s user167m31.474suser165m44.142s sys 113m26.195ssys 113m45.072s With micro-threading patches (PATCH 1+2): target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is max threads/sub-core] dynamic_mt_modes 6 real32m13.338s real 32m26.652s user139m21.181suser 140m20.994s sys 77m35.339s sys 78m16.599s It's better, but if I disable dynamic micro-threading (but PATCH 1+2): target_smt_mode 0 dynamic_mt_modes 0 real30m49.100s real 30m48.161s user144m22.989suser 142m53.886s sys 65m4.942s sys 66m8.159s it's even better. I think what's happening here is that with dynamic_mt_modes=0 the system alternates between the two guests, whereas with dynamic_mt_modes=6 it will spend some of the time running both guests simultaneously in two-way split mode. Since you have two compute-bound guests that each have threads=1 and 8 vcpus, it can fill up the core either way. In that case it is more efficient to fill up the core with vcpus from one guest and not have to split the core, firstly because you avoid the split/unsplit latency and secondly because the threads run a little faster in whole-core mode than in split-core. Thank you for the explanation. So it has more sense to have vCPUs with threads ? It seems: I did same tests with 4 vCPUs x 2 threads x 2 guests concurrently on one 8 threaded bare metal core. target_smt_mode 0 dynamic_mt_modes 0 real35m33.142s real35m44.967s user167m16.971s user163m14.320s sys 84m19.618s sys 90m38.978s target_smt_mode 0 dynamic_mt_modes 6 real26m41.993s real25m54.270s user130m31.362s user127m55.145s sys 58m17.378s sys 55m10.202s In this case, it really improves performance. Laurent -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in
Re: [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
On 22/06/2015 02:09, Paul Mackerras wrote: On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote: Tested-by: Laurent Vivier lviv...@redhat.com Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ? Did I miss something ? My test system is an IBM Power S822L. I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both attached on the same core (with pinning option of virt-manager). Then, I measure the time needed to compile a kernel in parallel in both guests with make -j 16. My kernel without micro-threading: real37m23.424s real37m24.959s user167m31.474suser165m44.142s sys 113m26.195ssys 113m45.072s With micro-threading patches (PATCH 1+2): target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is max threads/sub-core] dynamic_mt_modes 6 real32m13.338s real 32m26.652s user139m21.181suser 140m20.994s sys 77m35.339s sys 78m16.599s It's better, but if I disable dynamic micro-threading (but PATCH 1+2): target_smt_mode 0 dynamic_mt_modes 0 real30m49.100s real 30m48.161s user144m22.989suser 142m53.886s sys 65m4.942s sys 66m8.159s it's even better. I think what's happening here is that with dynamic_mt_modes=0 the system alternates between the two guests, whereas with dynamic_mt_modes=6 it will spend some of the time running both guests simultaneously in two-way split mode. Since you have two compute-bound guests that each have threads=1 and 8 vcpus, it can fill up the core either way. In that case it is more efficient to fill up the core with vcpus from one guest and not have to split the core, firstly because you avoid the split/unsplit latency and secondly because the threads run a little faster in whole-core mode than in split-core. Thank you for the explanation. So it has more sense to have vCPUs with threads ? It seems: I did same tests with 4 vCPUs x 2 threads x 2 guests concurrently on one 8 threaded bare metal core. target_smt_mode 0 dynamic_mt_modes 0 real35m33.142s real35m44.967s user167m16.971s user163m14.320s sys 84m19.618s sys 90m38.978s target_smt_mode 0 dynamic_mt_modes 6 real26m41.993s real25m54.270s user130m31.362s user127m55.145s sys 58m17.378s sys 55m10.202s In this case, it really improves performance. Laurent -- To unsubscribe from this list: send the line unsubscribe kvm in
Re: [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
[I resend my message because MLs have refused the first one in HTML] On 28/05/2015 07:17, Paul Mackerras wrote: This patch series provides a way to use more of the capacity of each processor core when running guests configured with threads=1, 2 or 4 on a POWER8 host with HV KVM, without having to change the static micro-threading (the official name for split-core) mode for the whole machine. The problem with setting the machine to static 2-way or 4-way micro-threading mode is that (a) then you can't run guests with threads=8 and (b) selecting the right mode can be tricky and requires knowledge of what guests you will be running. Instead, with these two patches, we can now run more than one virtual core (vcore) on a given physical core if possible, and if that means we need to switch the core to 2-way or 4-way micro-threading mode, then we do that on entry to the guests and switch back to whole-core mode on exit (and we only switch the one core, not the whole machine). The core mode switching is only done if the machine is in static whole-core mode. All of this only comes into effect when a core is over-committed. When the machine is lightly loaded everything operates the same with these patches as without. Only when some core has a vcore that is able to run while there is also another vcore that was wanting to run on that core but got preempted does the logic kick in to try to run both vcores at once. Paul. --- arch/powerpc/include/asm/kvm_book3s_asm.h | 20 + arch/powerpc/include/asm/kvm_host.h | 22 +- arch/powerpc/kernel/asm-offsets.c | 9 + arch/powerpc/kvm/book3s_hv.c | 648 ++ arch/powerpc/kvm/book3s_hv_builtin.c | 32 +- arch/powerpc/kvm/book3s_hv_rm_xics.c | 4 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 111 - 7 files changed, 740 insertions(+), 106 deletions(-) Tested-by: Laurent Vivier lviv...@redhat.com Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ? Did I miss something ? My test system is an IBM Power S822L. I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both attached on the same core (with pinning option of virt-manager). Then, I measure the time needed to compile a kernel in parallel in both guests with make -j 16. My kernel without micro-threading: real37m23.424s real37m24.959s user167m31.474suser165m44.142s sys 113m26.195ssys 113m45.072s With micro-threading patches (PATCH 1+2): target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is max threads/sub-core] dynamic_mt_modes 6 real32m13.338s real 32m26.652s user139m21.181suser 140m20.994s sys 77m35.339s sys 78m16.599s It's better, but if I disable dynamic micro-threading (but PATCH 1+2): target_smt_mode 0 dynamic_mt_modes 0 real30m49.100s real 30m48.161s user144m22.989suser 142m53.886s sys 65m4.942s sys 66m8.159s it's even better. without dynamic micro-threading patch (with PATCH1 but not PATCH2): target_smt_mode 0 real33m57.279s real 34m19.524s user158m43.064suser 156m19.863s sys 74m25.442s sys 76m42.994s Laurent -- 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 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
[I resend my message because MLs have refused the first one in HTML] On 28/05/2015 07:17, Paul Mackerras wrote: This patch series provides a way to use more of the capacity of each processor core when running guests configured with threads=1, 2 or 4 on a POWER8 host with HV KVM, without having to change the static micro-threading (the official name for split-core) mode for the whole machine. The problem with setting the machine to static 2-way or 4-way micro-threading mode is that (a) then you can't run guests with threads=8 and (b) selecting the right mode can be tricky and requires knowledge of what guests you will be running. Instead, with these two patches, we can now run more than one virtual core (vcore) on a given physical core if possible, and if that means we need to switch the core to 2-way or 4-way micro-threading mode, then we do that on entry to the guests and switch back to whole-core mode on exit (and we only switch the one core, not the whole machine). The core mode switching is only done if the machine is in static whole-core mode. All of this only comes into effect when a core is over-committed. When the machine is lightly loaded everything operates the same with these patches as without. Only when some core has a vcore that is able to run while there is also another vcore that was wanting to run on that core but got preempted does the logic kick in to try to run both vcores at once. Paul. --- arch/powerpc/include/asm/kvm_book3s_asm.h | 20 + arch/powerpc/include/asm/kvm_host.h | 22 +- arch/powerpc/kernel/asm-offsets.c | 9 + arch/powerpc/kvm/book3s_hv.c | 648 ++ arch/powerpc/kvm/book3s_hv_builtin.c | 32 +- arch/powerpc/kvm/book3s_hv_rm_xics.c | 4 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 111 - 7 files changed, 740 insertions(+), 106 deletions(-) Tested-by: Laurent Vivier lviv...@redhat.com Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ? Did I miss something ? My test system is an IBM Power S822L. I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both attached on the same core (with pinning option of virt-manager). Then, I measure the time needed to compile a kernel in parallel in both guests with make -j 16. My kernel without micro-threading: real37m23.424s real37m24.959s user167m31.474suser165m44.142s sys 113m26.195ssys 113m45.072s With micro-threading patches (PATCH 1+2): target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is max threads/sub-core] dynamic_mt_modes 6 real32m13.338s real 32m26.652s user139m21.181suser 140m20.994s sys 77m35.339s sys 78m16.599s It's better, but if I disable dynamic micro-threading (but PATCH 1+2): target_smt_mode 0 dynamic_mt_modes 0 real30m49.100s real 30m48.161s user144m22.989suser 142m53.886s sys 65m4.942s sys 66m8.159s it's even better. without dynamic micro-threading patch (with PATCH1 but not PATCH2): target_smt_mode 0 real33m57.279s real 34m19.524s user158m43.064suser 156m19.863s sys 74m25.442s sys 76m42.994s Laurent -- 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 0/2][v2] Add BIOS splash image support
This series of patches adds a nice BIOS startup splash screen. It adds a -splash option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable a fade in, fade out and the bootmenu. The time to display the image can be also given (in seconds). Idea stollen from VirtualBox. [PATCH 1/2] [BIOS] Add splash image support [PATCH 2/2] [QEMU] Add BIOS splash image -- 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 1/2][v2][BIOS] Add splash image support
This patch adds Qemu firmware configuration device interface to display
a splash image at BIOS startup.
Idea stollen from VirtualBox.
Signed-off-by: Laurent Vivier laurent.viv...@bull.net
---
bios/Makefile |4 +-
bios/rombios.c | 142 ---
bios/splash.c | 144
bios/splash.h | 32
4 files changed, 271 insertions(+), 51 deletions(-)
create mode 100644 bios/splash.c
create mode 100644 bios/splash.h
Changelog:
v2: totally remove code from VirtualBox to not bring GPLv2 to bios.
diff --git a/bios/Makefile b/bios/Makefile
index a2759a9..605d31f 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -79,7 +79,7 @@ dist-clean: clean
bios-clean:
rm -f BIOS-bochs-*
-BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
+BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h splash.c splash.h
$(GCC) $(BIOS_BUILD_DATE) -DLEGACY -E -P $ _rombiosl_.c
$(BCC) -o rombiosl.s -C-c -D__i86__ -0 -S _rombiosl_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s _rombiosl_.s
@@ -90,7 +90,7 @@ BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
rm -f _rombiosl_.s
-rombios16.bin: rombios.c apmbios.S biossums rombios.h
+rombios16.bin: rombios.c apmbios.S biossums rombios.h splash.c splash.h
$(GCC) $(BIOS_BUILD_DATE) -E -P $ _rombios_.c
$(BCC) -o rombios.s -C-c -D__i86__ -0 -S _rombios_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombios.s _rombios_.s
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..a02b50f 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1433,6 +1433,22 @@ void uart_tx_byte(base_port, data)
#endif
void
+set_video(mode)
+ Bit8u mode;
+{
+ ASM_START
+ push bp
+ mov bp, sp
+
+ mov ah, #0x00
+ mov al, 4[bp]
+ int #0x10
+
+ pop bp
+ ASM_END
+}
+
+ void
wrch(c)
Bit8u c;
{
@@ -1533,6 +1549,8 @@ void put_str(action, segment, offset)
}
}
+#define TICKS_PER_SECONDS 18
+
void
delay_ticks(ticks)
Bit16u ticks;
@@ -1917,6 +1935,10 @@ shutdown_status_panic(status)
BX_PANIC(Unimplemented shutdown status: %02x\n,(Bit8u)status);
}
+#ifdef BX_QEMU
+#include splash.c
+#endif
+
//--
// print_bios_banner
// displays a the bios version
@@ -1924,6 +1946,10 @@ shutdown_status_panic(status)
void
print_bios_banner()
{
+#ifdef BX_QEMU
+ if (splash_enabled())
+return;
+#endif
printf(BX_APPNAME BIOS - build: %s\n%s\nOptions: ,
BIOS_BUILD_DATE, bios_cvs_version_string);
printf(
@@ -2021,65 +2047,77 @@ interactive_bootkey()
Bit16u ss = get_SS();
Bit16u valid_choice = 0;
+#ifdef BX_QEMU
+ if (splash_enabled()) {
+Bit16u duration;
+
+splash_show();
+duration = splash_duration();
+if (!check_for_keystroke())
+ delay_ticks_and_check_for_keystroke(TICKS_PER_SECONDS, duration / 1000);
+splash_hide();
+if (!splash_display_boot_list())
+ return;
+ } else
+#endif // BX_QEMU
+ {
+while (check_for_keystroke())
+ get_keystroke();
+printf(Press F12 for boot menu.\n\n);
+delay_ticks_and_check_for_keystroke(11, 5); /* ~3 seconds */
+ }
+ if (!check_for_keystroke())
+return;
+ scan_code = get_keystroke();
+ if (scan_code != 0x58) /* F12 */
+return;
+
while (check_for_keystroke())
get_keystroke();
- printf(Press F12 for boot menu.\n\n);
+ printf(Select boot device:\n\n);
- delay_ticks_and_check_for_keystroke(11, 5); /* ~3 seconds */
- if (check_for_keystroke())
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ for (i = 0; i count; i++)
{
-scan_code = get_keystroke();
-if (scan_code == 0x58) /* F12 */
+memcpyb(ss, e, IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (e), sizeof (e));
+printf(%d. , i+1);
+switch(e.type)
{
- while (check_for_keystroke())
-get_keystroke();
-
- printf(Select boot device:\n\n);
-
- count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
- for (i = 0; i count; i++)
- {
-memcpyb(ss, e, IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (e), sizeof
(e));
-printf(%d. , i+1);
-switch(e.type)
+ case IPL_TYPE_FLOPPY:
+ case IPL_TYPE_HARDDISK:
+ case IPL_TYPE_CDROM:
+printf(%s\n, drivetypes[e.type]);
+break;
+ case IPL_TYPE_BEV:
+printf(%s, drivetypes[4]);
+if (e.description != 0)
{
- case IPL_TYPE_FLOPPY:
- case IPL_TYPE_HARDDISK:
- case IPL_TYPE_CDROM:
-printf(%s\n, drivetypes[e.type]);
-break;
- case IPL_TYPE_BEV:
-printf(%s, drivetypes[4]);
-if (e.description != 0)
-{
- memcpyb(ss, description, (Bit16u)(e.description 16),
(Bit16u)(e.description 0x), 32);
- description[32] = 0;
- printf( [%S], ss, description
[PATCH 2/2][v2][QEMU] Add BIOS splash image
This patch adds to qemu the functions needed to display a splash image
under BIOS control through the firmware control device.
It adds a -splash option allowing to specify the picture file name (a
.PNG) to display. You can enable/disable a fade in, fade out and the
bootmenu. The time to display the image can be also given (in seconds).
Signed-off-by: Laurent Vivier laurent.viv...@bull.net
---
qemu/Makefile.target |5 +-
qemu/configure | 19 +++
qemu/hw/fw_cfg.h |1 +
qemu/hw/pc.c | 11 ++-
qemu/hw/press_f12.h | 231 +++
qemu/hw/splash.c | 297 ++
qemu/hw/splash.h | 38 +++
qemu/qemu-doc.texi | 20
qemu/sysemu.h|1 +
qemu/vl.c| 19 +++
10 files changed, 639 insertions(+), 3 deletions(-)
create mode 100644 qemu/hw/press_f12.h
create mode 100644 qemu/hw/splash.c
create mode 100644 qemu/hw/splash.h
Changelog:
v2: make it generic, move splash functions to their own files,
add documentation
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 315c3c9..5887bba 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -613,6 +613,9 @@ ifndef CONFIG_USER_ONLY
OBJS=vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o machine.o
OBJS+=fw_cfg.o
+ifdef CONFIG_PNGLITE
+OBJS+=splash.o
+endif
ifdef CONFIG_KVM
OBJS+=kvm.o kvm-all.o
endif
@@ -865,7 +868,7 @@ firmware.o: firmware.c
endif
$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(DEPLIBS)
- $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
+ $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(PNGLITE_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
endif # !CONFIG_USER_ONLY
diff --git a/qemu/configure b/qemu/configure
index 5f5264f..60523fd 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -767,6 +767,19 @@ else
fi
##
+# libpnglite check
+
+cat $TMPC EOF
+#include pnglite.h
+int main(void) { (void)png_init(NULL, NULL); return 0; }
+EOF
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lz -lpnglite 2 /dev/null ;
then
+pnglite=yes
+else
+pnglite=no
+fi
+
+##
# SDL probe
sdl_too_old=no
@@ -1145,6 +1158,7 @@ echo SDL support $sdl
if test $sdl != no ; then
echo SDL static link $sdl_static
fi
+echo pnglite support $pnglite
echo curses support$curses
echo mingw32 support $mingw32
echo Audio drivers $audio_drv_list
@@ -1437,6 +1451,11 @@ if test $cocoa = yes ; then
echo #define CONFIG_COCOA 1 $config_h
echo CONFIG_COCOA=yes $config_mak
fi
+if test $pnglite = yes ; then
+ echo #define CONFIG_PNGLITE 1 $config_h
+ echo CONFIG_PNGLITE=yes $config_mak
+ echo PNGLITE_LIBS=-lpnglite $config_mak
+fi
if test $curses = yes ; then
echo #define CONFIG_CURSES 1 $config_h
echo CONFIG_CURSES=yes $config_mak
diff --git a/qemu/hw/fw_cfg.h b/qemu/hw/fw_cfg.h
index ef8f378..41fdde8 100644
--- a/qemu/hw/fw_cfg.h
+++ b/qemu/hw/fw_cfg.h
@@ -8,6 +8,7 @@
#define FW_CFG_NOGRAPHIC0x04
#define FW_CFG_NB_CPUS 0x05
#define FW_CFG_MACHINE_ID 0x06
+#define FW_CFG_SPLASH (FW_CFG_WRITE_CHANNEL | 0x07)
#define FW_CFG_MAX_ENTRY0x10
#define FW_CFG_WRITE_CHANNEL0x4000
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 2924b2a..f6979fe 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -36,6 +36,8 @@
#include virtio-blk.h
#include virtio-balloon.h
#include device-assignment.h
+#include splash.h
+#include press_f12.h
#include qemu-kvm.h
@@ -423,7 +425,7 @@ static void bochs_bios_write(void *opaque, uint32_t addr,
uint32_t val)
}
}
-static void bochs_bios_init(void)
+static void *bochs_bios_init(void)
{
void *fw_cfg;
@@ -441,6 +443,8 @@ static void bochs_bios_init(void)
fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
+
+return fw_cfg;
}
/* Generate an initial boot sector which sets state and jump to
@@ -818,6 +822,7 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
int index;
BlockDriverState *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
BlockDriverState *fd[MAX_FD];
+void *fw_cfg;
if (ram_size = 0xe000 ) {
above_4g_mem_size = ram_size - 0xe000;
@@ -977,7 +982,7 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
cpu_register_physical_memory((uint32_t)(-bios_size),
bios_size, bios_offset | IO_MEM_ROM);
-bochs_bios_init();
+fw_cfg = bochs_bios_init();
cpu_irq = qemu_allocate_irqs(pic_irq_request, NULL, 1);
i8259 = i8259_init(cpu_irq[0]);
@@ -1020,6 +1025,8 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size,
}
}
+splash_init(fw_cfg
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a écrit : On 16.12.2008 22:51, Laurent Vivier wrote: Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : On 12/16/08, Anthony Liguori anth...@codemonkey.ws wrote: Blue Swirl wrote: The control channel may still be needed. Alternatively the BIOS could load the image and fade parameters from a new ROM or from the configuration device and draw it to screen. This would need some PNG support to BIOS, or that the image stored in raw form. Yeah, having QEMU render to the VGA directly is a bit ugly. It would be nicer if the BIOS actually rendered the image but I'm not sure I think we should reject the patch just because it doesn't. Actually this way the image can be in full color even if the emulated device was an EGA in text mode. And you can provide the image name on the command line, and complexity is in Qemu, not in BIOS. If one of the goals of QEMU is to be somewhat similar to hardware, this should be done in the BIOS. A lot of things in Qemu are already not similar to hardware: virtio, firmware configuration device, instruction timing... What happens if the BIOS provides a splash screen? Will it override the QEMU splash screen? Yes. The BIOS asks Qemu to display the image... or not. But in fact, my first idea was to read the image data from the configuration device (which is always possible with LOGO_CMD_OFFSET), but when I saw how it has been done in VirtualBox, I though it was a good idea. Modern x86 BIOSes read the splash screen from the BIOS ROM and the settings from NVRAM (sometimes the BIOS ROM is used for that as well by reflashing a sector of the ROM on every boot). A BIOS, by definition, is not modern... ;-) (Openfirmware is...) Laurent -- -- laurent.viv...@bull.net -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- 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: [Bochs-developers] [PATCH 0/3] Add BIOS splash image support
Le mercredi 17 décembre 2008 à 22:58 +0100, Sebastian Herbszt a écrit : Laurent Vivier wrote: This series of patches adds a nice BIOS startup splash screen. It adds a -splash option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in, fade out and bootmenu. The time to display the image can be also given (in seconds). Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL). rombios.c is LGPL. Can we mix it with GPLv2/CDDL code without any downsides? Good question. But the GPLv2 code is not in rombios.c (but in logo.h, logo.c) and moreover VirtualBox uses the same rombios.c with their GPLv2 logo.[ch]... perhaps we can ask Sun lawyers ;-) ? I'm the author of all the code added to rombios.c to manage splash screen and I agree to put this under LGPL. For the logo.[ch], I keep only approximately 20% of original VirtualBox code (data structure, to set vga mode, to clear screen and some name), if needed I can rewrite this to put logo.[ch] under LGPL. Regards, Laurent -- -- laurent.viv...@bull.net -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- 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 2/3] [BIOS] Add splash image support
This patch adds Qemu firmware configuration device interface to display
a splash image at BIOS startup.
Idea and some parts of code are stollen from VirtualBox.
Signed-off-by: Laurent Vivier laurent.viv...@bull.net
---
bios/Makefile |4 +-
bios/logo.c| 206
bios/logo.h| 56 +++
bios/rombios.c | 125 +-
4 files changed, 340 insertions(+), 51 deletions(-)
create mode 100644 bios/logo.c
create mode 100644 bios/logo.h
diff --git a/bios/Makefile b/bios/Makefile
index a2759a9..d30be7d 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -79,7 +79,7 @@ dist-clean: clean
bios-clean:
rm -f BIOS-bochs-*
-BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
+BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h logo.c logo.h
$(GCC) $(BIOS_BUILD_DATE) -DLEGACY -E -P $ _rombiosl_.c
$(BCC) -o rombiosl.s -C-c -D__i86__ -0 -S _rombiosl_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s _rombiosl_.s
@@ -90,7 +90,7 @@ BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
rm -f _rombiosl_.s
-rombios16.bin: rombios.c apmbios.S biossums rombios.h
+rombios16.bin: rombios.c apmbios.S biossums rombios.h logo.c logo.h
$(GCC) $(BIOS_BUILD_DATE) -E -P $ _rombios_.c
$(BCC) -o rombios.s -C-c -D__i86__ -0 -S _rombios_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombios.s _rombios_.s
diff --git a/bios/logo.c b/bios/logo.c
new file mode 100644
index 000..d41eb10
--- /dev/null
+++ b/bios/logo.c
@@ -0,0 +1,206 @@
+/**
+ * Stuff for drawing the BIOS logo.
+ */
+
+/*
+ * Copyright (C) 2004-2008 Sun Microsystems, Inc.
+ *
+ * This file is part of VirtualBox Open Source Edition (OSE), as
+ * available from http://www.virtualbox.org. This file is free software;
+ * you can redistribute it and/or modify it under the terms of the GNU
+ * General Public License (GPL) as published by the Free Software
+ * Foundation, in version 2 as it comes in the COPYING file of the
+ * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
+ * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa
+ * Clara, CA 95054 USA or visit http://www.sun.com if you need
+ * additional information or have any questions.
+ *
+ * QEMU/KVM port by Laurent Vivier laurent.viv...@bull.net
+ *
+ */
+
+#include logo.h
+
+#define BIOS_CFG_IOPORT 0x510
+#define BIOS_CFG_SIGNATURE 0x
+#define BIOS_CFG_SPLASH 0x4007
+
+#define WAIT_MS 16
+
+/**
+ * Set video mode (VGA).
+ * @paramsNew video mode.
+ */
+void set_mode(mode)
+ Bit8u mode;
+ {
+ ASM_START
+push bp
+mov bp, sp
+
+ push ax
+
+ mov ah, #0
+ mov al, 4[bp] ; mode
+ int #0x10
+
+ pop ax
+
+pop bp
+ ASM_END
+ }
+
+Bit8u read_logo_byte(offset)
+ Bit8u offset;
+{
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SET_OFFSET);
+outb(BIOS_CFG_IOPORT + 1, offset);
+return inb(BIOS_CFG_IOPORT + 1);
+}
+
+Bit16u read_logo_word(offset)
+ Bit8u offset;
+{
+Bit16u word;
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SET_OFFSET);
+outb(BIOS_CFG_IOPORT + 1, offset);
+word = inb(BIOS_CFG_IOPORT + 1);
+word = (inb(BIOS_CFG_IOPORT + 1) 8) | word;
+return word;
+}
+
+void clear_screen()
+{
+// Hide cursor, clear screen and move cursor to starting position
+ASM_START
+push bx
+push cx
+push dx
+
+mov ax, #0x100
+mov cx, #0x1000
+int #0x10
+
+mov ax, #0x700
+mov bh, #7
+xor cx, cx
+mov dx, #0x184f
+int #0x10
+
+mov ax, #0x200
+xor bx, bx
+xor dx, dx
+int #0x10
+
+pop dx
+pop cx
+pop bx
+ASM_END
+}
+
+Bit8u
+logo_enabled()
+{
+LOGOHDR*logo_hdr = 0;
+Bit8u is_fade_in, is_fade_out, uBootMenu;
+Bit16u logo_time;
+
+/* check QEMU signature */
+
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SIGNATURE);
+if (inb(BIOS_CFG_IOPORT + 1) != 'Q')
+return 0;
+if (inb(BIOS_CFG_IOPORT + 1) != 'E')
+return 0;
+if (inb(BIOS_CFG_IOPORT + 1) != 'M')
+return 0;
+if (inb(BIOS_CFG_IOPORT + 1) != 'U')
+return 0;
+
+/* check splash signature */
+
+if (read_logo_word(logo_hdr-u16Signature) != LOGO_HDR_MAGIC)
+return 0;
+
+/* Get options */
+
+is_fade_in = read_logo_byte(logo_hdr-fu8FadeIn);
+is_fade_out = read_logo_byte(logo_hdr-fu8FadeOut);
+logo_time = read_logo_word(logo_hdr-u16LogoMillies);
+
+return (is_fade_in || is_fade_out || logo_time);
+}
+
+void logo_show()
+{
+LOGOHDR*logo_hdr = 0;
+Bit8u is_fade_in;
+Bit16u i;
+
+set_mode(0x12); /* 640x480 */
+
+is_fade_in = read_logo_byte(logo_hdr-fu8FadeIn);
+
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+if (is_fade_in)
+{
+for (i = 0; i
[PATCH 1/3] Correct fw_cfg_add_callback()
This patch is needed to be able to register firmware configuration
device callback.
It is already included in qemu as commit r5978.
Signed-off-by: Laurent Vivier laurent.viv...@bull.net
---
qemu/hw/fw_cfg.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/qemu/hw/fw_cfg.c b/qemu/hw/fw_cfg.c
index 4e68670..c3b09c6 100644
--- a/qemu/hw/fw_cfg.c
+++ b/qemu/hw/fw_cfg.c
@@ -57,7 +57,6 @@ static void fw_cfg_write(FWCfgState *s, uint8_t value)
FWCfgEntry *e = s-entries[arch][s-cur_entry FW_CFG_ENTRY_MASK];
FW_CFG_DPRINTF(write %d\n, value);
-
if (s-cur_entry FW_CFG_WRITE_CHANNEL s-cur_offset e-len) {
e-data[s-cur_offset++] = value;
if (s-cur_offset == e-len) {
@@ -240,10 +239,12 @@ int fw_cfg_add_callback(void *opaque, uint16_t key,
FWCfgCallback callback,
FWCfgState *s = opaque;
int arch = !!(key FW_CFG_ARCH_LOCAL);
+if (!(key FW_CFG_WRITE_CHANNEL))
+return 0;
+
key = FW_CFG_ENTRY_MASK;
-if (key = FW_CFG_MAX_ENTRY || !(key FW_CFG_WRITE_CHANNEL)
-|| len 65535)
+if (key = FW_CFG_MAX_ENTRY || len 65535)
return 0;
s-entries[arch][key].data = data;
--
1.5.6.5
--
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 3/3] [QEMU] Add BIOS splash image
This patch adds to qemu the function needed to display a splash image under
BIOS control through the firmware control device.
It adds a -splash option allowing to specify the picture file name (a .PNG)
to display. You can enable/disable a fade in, fade out and the bootmenu. The
time to display the image can be also given (in seconds).
Signed-off-by: Laurent Vivier laurent.viv...@bull.net
---
qemu/Makefile.target |2 +-
qemu/configure| 19 +++
qemu/hw/bootmenu_pixmap.h | 231 +
qemu/hw/fw_cfg.h |1 +
qemu/hw/pc.c | 276 -
qemu/sysemu.h |1 +
qemu/vl.c | 19 +++
7 files changed, 545 insertions(+), 4 deletions(-)
create mode 100644 qemu/hw/bootmenu_pixmap.h
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index d6a6479..65f0252 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -894,7 +894,7 @@ firmware.o: firmware.c
endif
$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(DEPLIBS)
- $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
+ $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(PNGLITE_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
endif # !CONFIG_USER_ONLY
diff --git a/qemu/configure b/qemu/configure
index 1f8b9b4..7f20a4b 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -833,6 +833,19 @@ else
fi
##
+# libpnglite check
+
+cat $TMPC EOF
+#include pnglite.h
+int main(void) { (void)png_init(NULL, NULL); return 0; }
+EOF
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lz -lpnglite 2 /dev/null ;
then
+pnglite=yes
+else
+pnglite=no
+fi
+
+##
# SDL probe
sdl_too_old=no
@@ -1187,6 +1200,7 @@ echo SDL support $sdl
if test $sdl != no ; then
echo SDL static link $sdl_static
fi
+echo pnglite support $pnglite
echo curses support$curses
echo mingw32 support $mingw32
echo Audio drivers $audio_drv_list
@@ -1477,6 +1491,11 @@ if test $cocoa = yes ; then
echo #define CONFIG_COCOA 1 $config_h
echo CONFIG_COCOA=yes $config_mak
fi
+if test $pnglite = yes ; then
+ echo #define CONFIG_PNGLITE 1 $config_h
+ echo CONFIG_PNGLITE=yes $config_mak
+ echo PNGLITE_LIBS=-lpnglite $config_mak
+fi
if test $curses = yes ; then
echo #define CONFIG_CURSES 1 $config_h
echo CONFIG_CURSES=yes $config_mak
diff --git a/qemu/hw/bootmenu_pixmap.h b/qemu/hw/bootmenu_pixmap.h
new file mode 100644
index 000..a33ddb4
--- /dev/null
+++ b/qemu/hw/bootmenu_pixmap.h
@@ -0,0 +1,231 @@
+/* GIMP header image file format (INDEXED): /home/vivierl/Desktop/Press F12
for boot menu.h */
+
+#define SPLASH_BOOTMENU_WIDTH 216
+#define SPLASH_BOOTMENU_HEIGHT 16
+
+static char bootmenu_pixmap[] = {
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,
+ 1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,1,1,1,1,1,1,1,0,0,0,
+ 0,0,1,1,0,0,0,0,0,1,1,1,1,1,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,
+ 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : On 12/16/08, Anthony Liguori anth...@codemonkey.ws wrote: Blue Swirl wrote: The control channel may still be needed. Alternatively the BIOS could load the image and fade parameters from a new ROM or from the configuration device and draw it to screen. This would need some PNG support to BIOS, or that the image stored in raw form. Yeah, having QEMU render to the VGA directly is a bit ugly. It would be nicer if the BIOS actually rendered the image but I'm not sure I think we should reject the patch just because it doesn't. Actually this way the image can be in full color even if the emulated device was an EGA in text mode. And you can provide the image name on the command line, and complexity is in Qemu, not in BIOS. But in fact, my first idea was to read the image data from the configuration device (which is always possible with LOGO_CMD_OFFSET), but when I saw how it has been done in VirtualBox, I though it was a good idea. But I agree, it's ugly. Regards, Laurent -- -- laurent.viv...@bull.net -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- 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][BIOS][v2] Fill IPL table according discovered ATA drives
This patch shows in boot menu only available devices.
This patch has been tested with Bochs BIOS version from the KVM source tree.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
bios/rombios.c | 49 ++---
1 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index e0a419f..8c7ead2 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1982,16 +1982,11 @@ init_boot_vectors()
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
count++;
+#if !BX_USE_ATADRV
/* First HDD */
e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
count++;
-
-#if BX_ELTORITO_BOOT
- /* CDROM */
- e.type = IPL_TYPE_CDROM; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
- count++;
#endif
/* Remember how many devices we have */
@@ -2031,15 +2026,19 @@ Bit16u i;
if (i = count) return 0;
type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
sizeof(Bit16u));
- if (type != IPL_TYPE_HARDDISK)
+ if (type == IPL_TYPE_HARDDISK)
+drv = 0x80;
+ else if (type == IPL_TYPE_CDROM)
+drv = 0xe0;
+ else
return 0;
- for (curr = 0, drv = 0; curr i; curr++) {
+ for (curr = 0; curr i; curr++) {
curr_type = read_word(IPL_SEG,
IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
sizeof(Bit16u));
if (type == curr_type) drv++;
}
- return 0x80 + drv;
+ return drv;
}
#if BX_ELTORITO_BOOT
@@ -2086,6 +2085,9 @@ interactive_bootkey()
memcpyb(ss, description, (Bit16u)(e.description 16),
(Bit16u)(e.description 0x), 32);
description[32] = 0;
printf( [%S], ss, description);
+ } else {
+ Bit8u drive = get_bootdrv(i);
+ if (drive) printf( (0x%02x), drive);
}
printf(\n);
break;
@@ -2488,6 +2490,9 @@ void ata_detect( )
Bit16u ebda_seg=read_word(0x0040,0x000E);
Bit8u hdcount, cdcount, device, type;
Bit8u buffer[0x0200];
+ Bit16u ss = get_SS();
+ ipl_entry_t e;
+ Bit16u count;
#if BX_MAX_ATA_INTERFACES 0
write_byte(ebda_seg,EbdaData-ata.channels[0].iface,ATA_IFACE_ISA);
@@ -2754,6 +2759,16 @@ void ata_detect( )
printf( ATA-%d Hard-Disk (%4u MBytes)\n, version,
(Bit16u)sizeinmb);
else
printf( ATA-%d Hard-Disk (%4u GBytes)\n, version,
(Bit16u)(sizeinmb10));
+ /* add to IPL list */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_HARDDISK;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
break;
case ATA_TYPE_ATAPI:
printf(ata%d %s: ,channel,slave? slave:master);
@@ -2762,6 +2777,18 @@ void ata_detect( )
printf( ATAPI-%d CD-Rom/DVD-Rom\n,version);
else
printf( ATAPI-%d Device\n,version);
+ /* add to IPL list */
+#if BX_ELTORITO_BOOT
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_CDROM;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
+#endif
break;
case ATA_TYPE_UNKNOWN:
printf(ata%d %s: Unknown device\n,channel,slave? slave:master);
@@ -10667,6 +10694,8 @@ post_default_ints:
;;
call hard_drive_post
+ call _init_boot_vectors
+
#if BX_USE_ATADRV
;;
@@ -10686,8 +10715,6 @@ post_default_ints:
;;
#endif // BX_ELTORITO_BOOT
- call _init_boot_vectors
-
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][BIOS][v2] Add BCV option rom in boot menu
This patch allows to select and boot from an option ROM
with a Boot Connection Vector (BCV) entry.
The BIOS detects the BCV option ROM and adds it to the IPL table, and then
you are able to select it to boot.
This patch has been tested with Bochs BIOS version from the KVM source tree
and a gPXE ROM modified to be a BCV one.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
bios/rombios.c | 75 ++-
1 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..e0a419f 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -177,10 +177,15 @@
#define IPL_SEQUENCE_OFFSET 0x0082 /* u16: next boot device */
#define IPL_BOOTFIRST_OFFSET 0x0084 /* u16: user selected device */
#define IPL_SIZE 0xff
+#define IPL_TYPE_RESERVED0x00
#define IPL_TYPE_FLOPPY 0x01
#define IPL_TYPE_HARDDISK0x02
#define IPL_TYPE_CDROM 0x03
+#define IPL_TYPE_PCMCIA 0x04
+#define IPL_TYPE_USBDEVICE 0x05
+#define IPL_TYPE_NETWORK 0x06/* Embedded Network */
#define IPL_TYPE_BEV 0x80
+#define IPL_TYPE_UNKNOWN 0xff
// Sanity Checks
#if BX_USE_ATADRV BX_CPU3
@@ -2009,6 +2014,34 @@ Bit16u i; ipl_entry_t *e;
return 1;
}
+static Bit8u
+get_bootdrv(i)
+Bit16u i;
+{
+ Bit16u count;
+ Bit16u type;
+ Bit16u curr_type;
+ Bit16u curr;
+ Bit16u drv;
+ /* Get the count of boot devices, and refuse to overrun the array
+ * in case of overrun or invalid IPL type entry, return 0
+ * to boot from floppy.
+ */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ if (i = count) return 0;
+ type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+ if (type != IPL_TYPE_HARDDISK)
+return 0;
+ for (curr = 0, drv = 0; curr i; curr++) {
+curr_type = read_word(IPL_SEG,
+ IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+if (type == curr_type) drv++;
+ }
+ return 0x80 + drv;
+}
+
#if BX_ELTORITO_BOOT
void
interactive_bootkey()
@@ -2047,8 +2080,15 @@ interactive_bootkey()
case IPL_TYPE_FLOPPY:
case IPL_TYPE_HARDDISK:
case IPL_TYPE_CDROM:
-printf(%s\n, drivetypes[e.type]);
-break;
+printf(%s, drivetypes[e.type]);
+if (e.description != 0)
+{
+ memcpyb(ss, description, (Bit16u)(e.description 16),
(Bit16u)(e.description 0x), 32);
+ description[32] = 0;
+ printf( [%S], ss, description);
+ }
+ printf(\n);
+ break;
case IPL_TYPE_BEV:
printf(%s, drivetypes[4]);
if (e.description != 0)
@@ -8045,7 +8085,7 @@ Bit16u seq_nr;
case IPL_TYPE_FLOPPY: /* FDD */
case IPL_TYPE_HARDDISK: /* HDD */
-bootdrv = (e.type == IPL_TYPE_HARDDISK) ? 0x80 : 0x00;
+bootdrv = get_bootdrv(bootdev);
bootseg = 0x07c0;
status = 0;
@@ -10245,10 +10285,11 @@ block_count_rounded:
mov bx, 0x001a ;; 0x1A is the offset into ROM header that contains...
mov ax, [bx] ;; the offset of PnP expansion header, where...
cmp ax, #0x5024 ;; we look for signature $PnP
- jne no_bev
+ jne no_pnp
mov ax, 2[bx]
cmp ax, #0x506e
- jne no_bev
+ jne no_pnp
+ ;; Look for the Bootstrap Entry Vector (BEV)
mov ax, 0x1a[bx] ;; 0x1A is also the offset into the expansion header of...
cmp ax, #0x ;; the Bootstrap Entry Vector, or zero if there is none.
je no_bev
@@ -10259,9 +10300,29 @@ block_count_rounded:
mov ds, bx
mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
cmp bx, #IPL_TABLE_ENTRIES
- je no_bev ;; Get out if the table is full
+ je no_pnp ;; Get out if the table is full
shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
mov 0[bx], #IPL_TYPE_BEV;; This entry is a BEV device
+ jmp add_ipl
+
+no_bev:
+ ;; Look for the Boot Connection Vector (BCV)
+ mov ax, 0x16[bx] ;; 0x16 is the offset into the expansion header of...
+ cmp ax, #0x ;; the Boot Connection Vector, or zero if there is none.
+ je no_pnp
+
+ ;; Found a device that thinks it can boot the system.
+ mov di, 0x10[bx];; Pointer to the product name string or zero
if none
+ mov bx, #IPL_SEG;; Go to the segment where the IPL table lives
+ mov ds, bx
+ mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
+ cmp bx, #IPL_TABLE_ENTRIES
+ je no_pnp ;; Get out if the table is full
+ shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
+ mov 0[bx], #IPL_TYPE_HARDDISK;; This entry is a BCV device
+
+add_ipl:
+
mov 6[bx], cx ;; Build a far pointer from the segment...
mov 4[bx], ax ;; and the offset
cmp di, #0x
[PATCH][BIOS] Fill IPL table according discovered ATA drives
This patch shows in boot menu only available devices.
This patch has been tested with Bochs BIOS version from the KVM source tree.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
bios/rombios.c | 54 +-
1 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 70b3584..d2a7c09 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1981,18 +1981,6 @@ init_boot_vectors()
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
count++;
- /* First HDD */
- e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
- count++;
-
-#if BX_ELTORITO_BOOT
- /* CDROM */
- e.type = IPL_TYPE_CDROM; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
- count++;
-#endif
-
/* Remember how many devices we have */
write_word(IPL_SEG, IPL_COUNT_OFFSET, count);
/* Not tried booting anything yet */
@@ -2027,15 +2015,19 @@ Bit16u i;
if (i = count) return 0;
type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
sizeof(Bit16u));
- if (type != IPL_TYPE_HARDDISK)
+ if (type == IPL_TYPE_HARDDISK)
+drv = 0x80;
+ else if(type == IPL_TYPE_CDROM)
+drv = 0xe0;
+ else
return 0;
- for (curr = 0, drv = 0; curr i; curr++) {
+ for (curr = 0; curr i; curr++) {
curr_type = read_word(IPL_SEG,
IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
sizeof(Bit16u));
if (type == curr_type) drv++;
}
- return 0x80 + drv;
+ return drv;
}
#if BX_ELTORITO_BOOT
@@ -2082,6 +2074,9 @@ interactive_bootkey()
memcpyb(ss, description, (Bit16u)(e.description 16),
(Bit16u)(e.description 0x), 32);
description[32] = 0;
printf( [%S], ss, description);
+ } else {
+ Bit16u drive = get_bootdrv(i);
+ if (drive) printf( (0x%02x), drive);
}
printf(\n);
break;
@@ -2484,6 +2479,9 @@ void ata_detect( )
Bit16u ebda_seg=read_word(0x0040,0x000E);
Bit8u hdcount, cdcount, device, type;
Bit8u buffer[0x0200];
+ Bit16u ss = get_SS();
+ ipl_entry_t e;
+ Bit16u count;
#if BX_MAX_ATA_INTERFACES 0
write_byte(ebda_seg,EbdaData-ata.channels[0].iface,ATA_IFACE_ISA);
@@ -2750,6 +2748,16 @@ void ata_detect( )
printf( ATA-%d Hard-Disk (%4u MBytes)\n, version,
(Bit16u)sizeinmb);
else
printf( ATA-%d Hard-Disk (%4u GBytes)\n, version,
(Bit16u)(sizeinmb10));
+ /* add to IPL list */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_HARDDISK;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
break;
case ATA_TYPE_ATAPI:
printf(ata%d %s: ,channel,slave? slave:master);
@@ -2758,6 +2766,18 @@ void ata_detect( )
printf( ATAPI-%d CD-Rom/DVD-Rom\n,version);
else
printf( ATAPI-%d Device\n,version);
+ /* add to IPL list */
+#if BX_ELTORITO_BOOT
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_CDROM;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
+#endif
break;
case ATA_TYPE_UNKNOWN:
printf(ata%d %s: Unknown device\n,channel,slave? slave:master);
@@ -10663,6 +10683,8 @@ post_default_ints:
;;
call hard_drive_post
+ call _init_boot_vectors
+
#if BX_USE_ATADRV
;;
@@ -10682,8 +10704,6 @@ post_default_ints:
;;
#endif // BX_ELTORITO_BOOT
- call _init_boot_vectors
-
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Le mardi 30 septembre 2008 à 10:41 +0200, Sven Rudolph a écrit : Hello, I have an (as far as I understand it) complex problem. I just got some good debugging hints, so I tried some more things and reproduced the problem with recent KVM. I tested it now with kvm-76 (both kernel and userspace) with virtio Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003 (Standard Edition, SP2) with the virtio guest driver (Version 5.1.0.3107). First a description of my environment. I start KVM's qemu: /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \ -net nic,macaddr=00:50:56:24:0b:37,model=virtio \ -net tap,ifname=vm03,script=no,downscript=no \ -usb -usbdevice tablet This does a DHCP request via an etherboot virtio rom; it reports the version as Etherboot 5.4.3, the MD5 sum is: 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin Where is coming from your rom ? Is etherboot or gPXE rom ? This starts pxegrub; pxegrub configuration is compiled-in and boots from harddisk: default 0 timeout 5 title boot from first disk root (hd0) chainloader +1 (This is our way of configuring DHCP to boot the locally-installed Windows. In order to boot a network Linux, the DHCP configuration is automatically changed.) Is linux able to reboot ? Now the problem: When I reboot Windows (shutdown /r), the newly booted windows hangs during boot. (The problem stays the same when I reset the VM (using the monitor command system_reset) instead of rebooting with shutdown /r.) It hangs in the first graphical screen (where the windows logo and Microsoft Windows Server 2003 are displayed in the center), and the activity bar below this stops after some seconds (and qemu starts eating 100% CPU). Resetting the VM with system_reset does not solve the problem; the next booted Windows hangs in the same place. There are many ways that make the problem disappear: When I stop the qemu process and start a new one, Windows boots again (but the problem can be reproduced by rebooting Windows as described above). When I reset the VM with system_reset, boot Linux (Version 2.6.25.9) from network, reboot this Linux and then boot Windows again, it works. When I use the Realtek network driver (model=rtl8139), Windows boots again. When I do not use the network boot, etherboot and pxegrub sequence (using -boot c instead of -boot n), Windows boots again. And now the real fun: when I remove the -usb -usbdevice tablet option (and this is the only change!), everything works. (It is the -usb part that makes the difference, -usbdevice tablet doesn't influence this problem.) I have no idea how virtio Ethernet and USB interact in order to cause this problem... Did you try to reduce the amount of memory (-m 1024) ? Trying a summary: When using virtio Ethernet and -usb; Windows leaves something (virtio Ethernet or USB ?) in a state that isn't reset by my reboot sequence (etherboot/pxegrub) and makes the next Windows boot hang. Booting Linux inbetween resets that state, and using the -boot c path does that too. So my first workaround would be to not use the USB tablet, because this isn't critical for me. But it took us some time to diagnose the problem, hence I wanted to tell you about this in order to save you the same work. Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Device Assignment with VT-d
Le mardi 16 septembre 2008 à 00:58 +, Avi Kivity a écrit :
From: Ben-Ami Yassour [EMAIL PROTECTED]
Based on a patch by: Kay, Allen M [EMAIL PROTECTED]
This patch enables PCI device assignment based on VT-d support.
When a device is assigned to the guest, the guest memory is pinned and
the mapping is updated in the VT-d IOMMU.
[Amit: Expose KVM_CAP_IOMMU so we can check if an IOMMU is present
and also control enable/disable from userspace]
Signed-off-by: Kay, Allen M [EMAIL PROTECTED]
Signed-off-by: Weidong Han [EMAIL PROTECTED]
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
Signed-off-by: Amit Shah [EMAIL PROTECTED]
Acked-by: Mark Gross [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index d0e940b..3072b17 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,6 +12,9 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
i8254.o
+ifeq ($(CONFIG_DMAR),y)
+kvm-objs += vtd.o
+endif
obj-$(CONFIG_KVM) += kvm.o
kvm-intel-objs = vmx.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
new file mode 100644
index 000..667bf3f
--- /dev/null
+++ b/arch/x86/kvm/vtd.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2006, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Copyright (C) 2006-2008 Intel Corporation
+ * Copyright IBM Corporation, 2008
+ * Author: Allen M. Kay [EMAIL PROTECTED]
+ * Author: Weidong Han [EMAIL PROTECTED]
+ * Author: Ben-Ami Yassour [EMAIL PROTECTED]
+ */
+
+#include linux/list.h
+#include linux/kvm_host.h
+#include linux/pci.h
+#include linux/dmar.h
+#include linux/intel-iommu.h
+
+static int kvm_iommu_unmap_memslots(struct kvm *kvm);
+static void kvm_iommu_put_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages);
+
+int kvm_iommu_map_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages)
+{
+ gfn_t gfn = base_gfn;
+ pfn_t pfn;
+ int i, r;
+ struct dmar_domain *domain = kvm-arch.intel_iommu_domain;
+
+ /* check if iommu exists and in use */
+ if (!domain)
+ return 0;
+
+ r = -EINVAL;
+ for (i = 0; i npages; i++) {
+ /* check if already mapped */
+ pfn = (pfn_t)intel_iommu_iova_to_pfn(domain,
+ gfn_to_gpa(gfn));
+ if (pfn !is_mmio_pfn(pfn))
+ continue;
+
+ pfn = gfn_to_pfn(kvm, gfn);
+ if (!is_mmio_pfn(pfn)) {
+ r = intel_iommu_page_mapping(domain,
+ gfn_to_gpa(gfn),
+ pfn_to_hpa(pfn),
+ PAGE_SIZE,
+ DMA_PTE_READ |
+ DMA_PTE_WRITE);
+ if (r) {
+ printk(KERN_DEBUG kvm_iommu_map_pages:
+iommu failed to map pfn=%lx\n, pfn);
+ goto unmap_pages;
+ }
+ } else {
+ printk(KERN_DEBUG kvm_iommu_map_page:
+invalid pfn=%lx\n, pfn);
+ goto unmap_pages;
+ }
+ gfn++;
+ }
+ return 0;
+
+unmap_pages:
+ kvm_iommu_put_pages(kvm, base_gfn, i);
+ return r;
+}
+
+static int kvm_iommu_map_memslots(struct kvm *kvm)
+{
+ int i, r;
+
+ down_read(kvm-slots_lock);
+ for (i = 0; i kvm-nmemslots; i++) {
+ r = kvm_iommu_map_pages(kvm, kvm-memslots[i].base_gfn,
+ kvm-memslots[i].npages);
+ if (r)
+ break;
+ }
+ up_read(kvm-slots_lock);
+ return r;
+}
+
+int kvm_iommu_map_guest(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *assigned_dev)
+{
+ struct pci_dev *pdev = NULL;
+ int r;
+
+ if (!intel_iommu_found()) {
+ printk(KERN_ERR %s:
Re: tape support
Le samedi 13 septembre 2008 à 07:51 +0300, Avi Kivity a écrit : Laurent Vivier wrote: Le jeudi 11 septembre 2008 à 12:54 +0200, Dietmar Maurer a écrit : Is there a way to use a scsi tape? I tried -drive file=/dev/sg0, but that does not work (eject, rewind works, but read/write fails - no date is written - no errors) try -drive file=/dev/sg0,if=scsi How would that work? Won't qemu attempt to show the tape as a disk? Or does it detect this special case and passes-through the scsi device? Yes, Qemu detects it's SCSI interface and passes the SCSI commands to devices. But qemu ignores the type of the device but OS (linux) detects this as a tape (with INQUIRY). It works well for CD/DVD and disk, but I'm working with Dietmar to make it working with tape (commands encoding differs)... and I found some devices to test. Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Clear temporary interrupt blocking on halt in real mode
Le dimanche 10 août 2008 à 11:36 +0300, Avi Kivity a écrit :
Laurent Vivier wrote:
When halt is emulated, skip_emulated_instruction() is called and
interruptibility state is cleared.
But when halt is emulated in real mode, skip_emulated_instruction() is not
called and the interruptiblity state is not cleared.
The following code, from gPXE, never exits from loop because interrupts are
not delivered to increase %fs:(0x6c):
movl%fs:(0x6c), %eax
1: pushf
sti
hlt
popf
cmpl%fs:(0x6c), %eax
je 1b
This patch clears the interruptibility state when halt is emulated in real
mode.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
arch/x86/kvm/vmx.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c4510fe..82c4324 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2329,7 +2329,17 @@ static int handle_exception(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
handle_rmode_exception(vcpu, intr_info INTR_INFO_VECTOR_MASK,
error_code)) {
if (vcpu-arch.halt_request) {
+ u32 interruptibility;
vcpu-arch.halt_request = 0;
+ /*
+* We emulated an instruction, so temporary interrupt
blocking
+* should be removed, if set.
+ */
+ interruptibility =
vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ if (interruptibility 3)
+ vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
+interruptibility ~3);
+ vcpu-arch.interrupt_window_open = 1;
return kvm_emulate_halt(vcpu);
}
return 1;
Shouldn't interruptibility state be cleared if *any* instruction is
emulated?
(of course, an emulated instruction may update interruptibility state
itself, say sti).
I don't know what to do with that...
I think emulated instructions already clear interruptibility state via
skip_emulated_instruction().
The case of kvm_emulate_halt() and real mode is a special case.
Laurent
--
- [EMAIL PROTECTED] --
La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever. Saint Exupéry
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Clear temporary interrupt blocking on halt in real mode
When halt is emulated, skip_emulated_instruction() is called and
interruptibility state is cleared.
But when halt is emulated in real mode, skip_emulated_instruction() is not
called and the interruptiblity state is not cleared.
The following code, from gPXE, never exits from loop because interrupts are not
delivered to increase %fs:(0x6c):
movl%fs:(0x6c), %eax
1: pushf
sti
hlt
popf
cmpl%fs:(0x6c), %eax
je 1b
This patch clears the interruptibility state when halt is emulated in real mode.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
arch/x86/kvm/vmx.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c4510fe..82c4324 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2329,7 +2329,17 @@ static int handle_exception(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
handle_rmode_exception(vcpu, intr_info INTR_INFO_VECTOR_MASK,
error_code)) {
if (vcpu-arch.halt_request) {
+ u32 interruptibility;
vcpu-arch.halt_request = 0;
+ /*
+* We emulated an instruction, so temporary interrupt
blocking
+* should be removed, if set.
+ */
+ interruptibility =
vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ if (interruptibility 3)
+ vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
+interruptibility ~3);
+ vcpu-arch.interrupt_window_open = 1;
return kvm_emulate_halt(vcpu);
}
return 1;
--
1.5.2.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ROM][v2] virtio-net etherboot ROM
Le mercredi 18 juin 2008 à 06:26 -0700, Avi Kivity a écrit : Laurent Vivier wrote: This new version of virtio-net etherboot ROM clears the ISR on reset, and thus allows linux to use it again (on Qemu/KVM). What's the status of upstreaming this? Didn't see it on etherboot.git. Virtio-net driver is now included in etherboot git and gPXE git (thank you to Stefan Hajnoczi for his work on this) So, virtio-net ROM image is now available from http://rom-o-matic.net. Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 09:37 +0100, Daniel P. Berrange a écrit : The following two command lines should be identical from the user's point of view: # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 # qemu-kvm -drive file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 -cdrom /home/berrange/boot.iso is identical to -drive file=/home/berrange/boot.iso,index=1,media=cdrom with if=ide by default. Could you try you command line without boot=on ? With the 2nd though, the initial CDROM syslinux loads, but fails to load the graphical menu, and also fails to boot in text mode fallback: 'vesamenu.c32: attempted DOS system call (See screenshot: https://bugzilla.redhat.com/attachment.cgi?id=311221 ) I've reproduced this with both KVM 65 and 70, on a Fedora 9 host. The CDROM boot.iso image I'm using here is the Fedora 9 $URL/images/boot.iso from any standard Fedora install tree. I can only imagine there's something different in the way extboot sets up the CPU/pagetables during cdrom boot, but its rather beyond my skills This was originally reported by a Fedora user here https://bugzilla.redhat.com/show_bug.cgi?id=452355 Daniel -- - [EMAIL PROTECTED] -- L'avenir ne se prévoit pas, il se prépare. - Maurice Blondel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Test result, kernel a81a686.., userspace 619ca34..
Le mardi 08 juillet 2008 à 16:58 +0800, Xu, Jiajun a écrit : Hi All, This is today's KVM test result against kvm.git a81a686682d6f04c842ebf9e084e30cd875f1048 and kvm-userspace.git 619ca34310a8968b6939fa6aba5b85a16b20315e. There's no new issue today. Three Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. vista auto-unattended installation failed on kvm guests https://sourceforge.net/tracker/?func=detailatid=893831aid=1991653group_id=180599 Is this a duplicate of https://sourceforge.net/tracker/?func=detailatid=893831aid=1967368group_id=180599 ? If so, it is corrected in qemu. 3. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 Test environment Platform Woodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot guest with 1500M memory PASS 3. boot 4 same guest in parallel PASS 4. boot two windows xp guestPASS 5. boot linux and windows guest in parallel PASS 6. save/restore 32-bit HVM guests PASS 7. save/restore 32-bit HVM guests with 4 vcpus PASS 8. live migration 32-bit HVM guests PASS 9. live migration 32-bit HVM guests with 4 vcpus PASS 10. boot base kernel linux PASS 11. kernel build on SMP linux guestPASS 12. LTP on linux guest PASS 13. boot Windows 2000 without ACPI PASS 14. boot Windows 2000 with ACPI enabled PASS 15. boot Windows 2003 with ACPI enabled PASS 16. boot Windows xp with ACPI enabled PASS 17. boot Windows vista with ACPI enabled PASS 18. boot SMP Windows 2000 with ACPI enabled PASS 19. boot SMP Windows 2003 with ACPI enabled PASS 20. boot SMP Windows xp with ACPI enabled PASS 21. boot SMP Windows 2008 with ACPI enabled PASS IA32e: 1. boot 32-bit guest with 256M memory PASS 2. boot 64-bit guest with 256M memory PASS 3. boot 32-bit guest with 1500M memory PASS 4. boot 64-bit guest with 1500M memory PASS 5. boot 4G pae guest PASS 6. boot 4G 64-bit guest PASS 7. boot four 32-bit guest in parallel PASS 8. boot four 64-bit guest in parallel PASS 9. boot two 32-bit windows xp in parallel PASS 10. boot 32-bit linux and 32 bit windows guest in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 32-bit linux guests PASS 13. save/restore 64-bit linux guests PASS 14. save/restore 64-bit linux guests with 4 vcpus PASS 15. save/restore 32-bit linux guests with 4 vcpus PASS 16. live migration 64bit linux guests PASS 17. live migration 32bit linux guests PASS 18. live migration 64bit linux guests with 4 vcpus PASS 19. live migration 32bit linux guests with 4 vcpus PASS 20. boot 32-bit x-server PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on 32-bit linux guest OS PASS 24. LTP on 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit Windows 2000 without ACPIPASS 27. boot 32-bit Windows xp without ACPIPASS 28. boot 64-bit Windows xp with ACPI enabledPASS 29. boot 64-bit Windows vista with ACPI enabled PASS 30. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 31.
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 11:17 +0200, Soren Hansen a écrit : On Tue, Jul 08, 2008 at 09:37:30AM +0100, Daniel P. Berrange wrote: The following two command lines should be identical from the user's point of view: # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 # qemu-kvm -drive file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 http://sourceforge.net/tracker/index.php?func=detailaid=1977971group_id=180599atid=893831 yes, in fact media=cdrom,boot=on is not equal to -cdrom ... -boot d. boot=on means use bios extension extboot with this drive, and using extboot allows the bios to manage this device and to boot from it. Laurent -- - [EMAIL PROTECTED] -- L'avenir ne se prévoit pas, il se prépare. - Maurice Blondel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 10:21 +0100, Daniel P. Berrange a écrit : On Tue, Jul 08, 2008 at 11:17:24AM +0200, Soren Hansen wrote: On Tue, Jul 08, 2008 at 09:37:30AM +0100, Daniel P. Berrange wrote: The following two command lines should be identical from the user's point of view: # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 # qemu-kvm -drive file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 http://sourceforge.net/tracker/index.php?func=detailaid=1977971group_id=180599atid=893831 Ok, so basically this is saying that boot=on only works for media=disk. I really don't like the fact that we now have 2 different ways of flagging bootable disks, depending on whether want to use BIOS boot or extboot. The management apps shouldn't have to make such a decision - QEMU should be picking the most appropriate choice for us. ie, if we have boot=on with an IDE cdrom, then QEMU should automatically do a BIOS boot instead of extboot. This way if extboot gets improved, QEMU can update its logic to correspond without needing to change all the management apps using QEMU. I agree. Laurent -- - [EMAIL PROTECTED] -- L'avenir ne se prévoit pas, il se prépare. - Maurice Blondel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 08:01 -0500, Anthony Liguori a écrit : Daniel P. Berrange wrote: On Tue, Jul 08, 2008 at 11:17:24AM +0200, Soren Hansen wrote: On Tue, Jul 08, 2008 at 09:37:30AM +0100, Daniel P. Berrange wrote: The following two command lines should be identical from the user's point of view: # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 # qemu-kvm -drive file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 http://sourceforge.net/tracker/index.php?func=detailaid=1977971group_id=180599atid=893831 Ok, so basically this is saying that boot=on only works for media=disk. I really don't like the fact that we now have 2 different ways of flagging bootable disks, depending on whether want to use BIOS boot or extboot. Semantically, boot=on means make this the first bootable hard disk. That's not to say that there shouldn't be a check. If you did: qemu-system-x86 -drive file=foo.img,boot=on -boot d You would still boot from the cdrom. So, boot=on means in fact bootable=true Regards, Laurent -- - [EMAIL PROTECTED] -- L'avenir ne se prévoit pas, il se prépare. - Maurice Blondel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use qemu_memalign instead of qemu_malloc
Le mercredi 25 juin 2008 à 16:15 +0200, Kevin Wolf a écrit : Anthony Liguori schrieb: Kevin Wolf wrote: Anthony Liguori schrieb: I guess the main block code is not as defensive as I thought it was. This patch uses qemu_memalign to allocate the buffers for IO so that you don't get errors when using O_DIRECT. Actually, the block code should be able to deal with unaligned buffers since qemu rev. 4599. This change seems to be present in current KVM. That was what I thought at first too. Can you tell exactly which operation failed? The aio requests fail with -22 (EINVAL). Yes, if it fails, the EINVAL is no surprise. I meant what code path it was using. Obviously we missed something in our patch and I'd like to fix that. Did the error occur on raw images or something like qcow2? Generally EINVAL with O_DIRECT opened files means there is an alignment problem with offset, buffer address or size to read (must be multiple of 512). Regards, Laurent -- - [EMAIL PROTECTED] --- The best way to predict the future is to invent it. - Alan Kay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ROM][v2] virtio-net etherboot ROM
Le mercredi 18 juin 2008 à 06:26 -0700, Avi Kivity a écrit : Laurent Vivier wrote: This new version of virtio-net etherboot ROM clears the ISR on reset, and thus allows linux to use it again (on Qemu/KVM). What's the status of upstreaming this? Didn't see it on etherboot.git. I have no answer from etherboot maintainers... Regards, Laurent -- - [EMAIL PROTECTED] --- The best way to predict the future is to invent it. - Alan Kay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libkvm: export init for coalesced MMIO support
Le mercredi 18 juin 2008 à 00:22 -0500, Carlo Marcelo Arenas Belon a écrit : complement 2680f3df932a3119880a692609943587ecc8f409 to export the definition for kvm_init_coalesced_mmio as it is used by the per arch libkvm as shown by the following warning : libkvm-x86.c: In function 'kvm_arch_create': libkvm-x86.c:182: warning: implicit declaration of function 'kvm_init_coalesced_mmio' Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED] Looks good for me. Laurent --- libkvm/libkvm.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h index a33e9db..4fd8587 100644 --- a/libkvm/libkvm.h +++ b/libkvm/libkvm.h @@ -576,6 +576,15 @@ int kvm_set_lapic(kvm_context_t kvm, int vcpu, struct kvm_lapic_state *s); */ int kvm_pit_in_kernel(kvm_context_t kvm); +/*! + * \brief Initialize coalesced MMIO + * + * Check for coalesced MMIO capability and store in context + * + * \param kvm Pointer to the current kvm_context + */ +int kvm_init_coalesced_mmio(kvm_context_t kvm); + #ifdef KVM_CAP_PIT #if defined(__i386__) || defined(__x86_64__) -- - [EMAIL PROTECTED] --- The best way to predict the future is to invent it. - Alan Kay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ kvm-Bugs-1985977 ] Guests crash while rebooting
Le samedi 14 juin 2008 à 11:58 -0700, Avi Kivity a écrit : Yunfeng Zhao wrote: Date: 2008-06-12 16:26 Message: Logged In: YES user_id=539971 Originator: NO Okay, I reverted the patch. Avi, The issue still exists on our nightly testing machine even after reverted the pmode transition patch. Okay, I think I found the real problem. I just pushed 3a82930aa403 which ought to fix this. Perhaps you can re-apply 36742c5470 ? Laurent -- - [EMAIL PROTECTED] --- The best way to predict the future is to invent it. - Alan Kay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [v2] etherboot: add virtio-net driver
This patch allows to boot from network using the virtio-net adapter
provided by KVM.
It applies on etherboot-5.4 sources from
git://git.etherboot.org/scm/etherboot.git
Changelog:
v2: Clear ISR on reset, some cosmetic changes, implement virtnet_irq().
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
src/Families |5 +
src/drivers/net/virtio-net.c | 493 +
src/drivers/net/virtio-net.h | 44
src/drivers/net/virtio-pci.h | 96
src/drivers/net/virtio-ring.h | 93
5 files changed, 731 insertions(+), 0 deletions(-)
create mode 100644 src/drivers/net/virtio-net.c
create mode 100644 src/drivers/net/virtio-net.h
create mode 100644 src/drivers/net/virtio-pci.h
create mode 100644 src/drivers/net/virtio-ring.h
diff --git a/src/Families b/src/Families
index ee47d13..160c4ee 100644
--- a/src/Families
+++ b/src/Families
@@ -148,3 +148,8 @@ family drivers/net/mlx_ipoib/mt25218
family drivers/net/via-velocity
family drivers/net/etherfabric
+
+# KVM virtio
+
+family drivers/net/virtio-net
+virtio-net - Virtio Network Interface
diff --git a/src/drivers/net/virtio-net.c b/src/drivers/net/virtio-net.c
new file mode 100644
index 000..4cecefc
--- /dev/null
+++ b/src/drivers/net/virtio-net.c
@@ -0,0 +1,493 @@
+/* virtio-net.c - etherboot driver for virtio network interface
+ *
+ * (c) Copyright 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier [EMAIL PROTECTED]
+ *
+ * some parts from Linux Virtio PCI driver
+ *
+ * Copyright IBM Corp. 2007
+ * Authors: Anthony Liguori [EMAIL PROTECTED]
+ *
+ * some parts from Linux Virtio Ring
+ *
+ * Copyright Rusty Russell IBM Corporation 2007
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ *
+ */
+
+#include etherboot.h
+#include pci.h
+#include nic.h
+#include timer.h
+#include virtio-ring.h
+#include virtio-pci.h
+#include virtio-net.h
+
+#define BUG() do { \
+ printf(BUG: failure at %s:%d/%s()!\n, \
+ __FILE__, __LINE__, __FUNCTION__); \
+ while(1); \
+} while (0)
+#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
+
+/* Ethernet header */
+
+struct eth_hdr {
+ unsigned char dst_addr[ETH_ALEN];
+ unsigned char src_addr[ETH_ALEN];
+ unsigned short type;
+};
+
+struct eth_frame {
+ struct eth_hdr hdr;
+ unsigned char data[ETH_MAX_MTU];
+};
+
+typedef unsigned char virtio_queue_t[PAGE_MASK + vring_size(MAX_QUEUE_NUM)];
+
+/* TX: virtio header and eth buffer */
+
+static struct virtio_net_hdr tx_virtio_hdr;
+static struct eth_frame tx_eth_frame;
+
+/* RX: virtio headers and buffers */
+
+#define RX_BUF_NB 6
+static struct virtio_net_hdr rx_hdr[RX_BUF_NB];
+static unsigned char rx_buffer[RX_BUF_NB][ETH_FRAME_LEN];
+
+/* virtio queues and vrings */
+
+enum {
+ RX_INDEX = 0,
+ TX_INDEX,
+ QUEUE_NB
+};
+
+static virtio_queue_t queue[QUEUE_NB];
+static struct vring vring[QUEUE_NB];
+static u16 free_head[QUEUE_NB];
+static u16 last_used_idx[QUEUE_NB];
+static u16 vdata[QUEUE_NB][MAX_QUEUE_NUM];
+
+/*
+ * Virtio PCI interface
+ *
+ */
+
+static int vp_find_vq(struct nic *nic, int queue_index)
+{
+ struct vring * vr = vring[queue_index];
+ u16 num;
+
+ /* select the queue */
+
+ outw(queue_index, nic-ioaddr + VIRTIO_PCI_QUEUE_SEL);
+
+ /* check if the queue is available */
+
+ num = inw(nic-ioaddr + VIRTIO_PCI_QUEUE_NUM);
+ if (!num) {
+ printf(ERROR: queue size is 0\n);
+ return -1;
+ }
+
+ if (num MAX_QUEUE_NUM) {
+ printf(ERROR: queue size %d %d\n, num, MAX_QUEUE_NUM);
+ return -1;
+ }
+
+ /* check if the queue is already active */
+
+ if (inl(nic-ioaddr + VIRTIO_PCI_QUEUE_PFN)) {
+ printf(ERROR: queue already active\n);
+ return -1;
+ }
+
+ /* initialize the queue */
+
+ vring_init(vr, num, (unsigned char*)queue[queue_index]);
+
+ /* activate the queue
+*
+* NOTE: vr-desc is initialized by vring_init()
+*/
+
+ outl((unsigned long)virt_to_phys(vr-desc) PAGE_SHIFT,
+nic-ioaddr + VIRTIO_PCI_QUEUE_PFN);
+
+ return num;
+}
+
+/*
+ * Virtual ring management
+ *
+ */
+
+static void vring_enable_cb(int queue_index)
+{
+ vring[queue_index].avail-flags = ~VRING_AVAIL_F_NO_INTERRUPT;
+}
+
+static void vring_disable_cb(int queue_index)
+{
+ vring[queue_index].avail-flags |= VRING_AVAIL_F_NO_INTERRUPT;
+}
+
+/*
+ * vring_free
+ *
+ * put at the begin of the free list the current desc[head]
+ */
+
+static void vring_detach(int queue_index, unsigned int head)
+{
+ struct vring *vr = vring[queue_index];
+unsigned int i;
+
+/* find end of given descriptor */
+
+ i = head;
+ while (vr-desc[i
[PATCH] Add virtio-net driver
This patch allows to boot from network using the virtio-net adapter
provided by KVM.
It applies on etherboot-5.4 sources from
git://git.etherboot.org/scm/etherboot.git
[why etherboot-5.4 ?
because it doesn't hang like gPXE and ROM size is only 32 KB]
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
src/Families |5 +
src/drivers/net/virtio-net.c | 476 +
src/drivers/net/virtio-net.h | 41
src/drivers/net/virtio-pci.h | 91
src/drivers/net/virtio-ring.h | 90
5 files changed, 703 insertions(+), 0 deletions(-)
create mode 100644 src/drivers/net/virtio-net.c
create mode 100644 src/drivers/net/virtio-net.h
create mode 100644 src/drivers/net/virtio-pci.h
create mode 100644 src/drivers/net/virtio-ring.h
diff --git a/src/Families b/src/Families
index ee47d13..160c4ee 100644
--- a/src/Families
+++ b/src/Families
@@ -148,3 +148,8 @@ family drivers/net/mlx_ipoib/mt25218
family drivers/net/via-velocity
family drivers/net/etherfabric
+
+# KVM virtio
+
+family drivers/net/virtio-net
+virtio-net - Virtio Network Interface
diff --git a/src/drivers/net/virtio-net.c b/src/drivers/net/virtio-net.c
new file mode 100644
index 000..db7bdae
--- /dev/null
+++ b/src/drivers/net/virtio-net.c
@@ -0,0 +1,476 @@
+/* virtnet.c - etherboot driver for virtio network interface
+ *
+ * (c) Copyright 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier [EMAIL PROTECTED]
+ *
+ * some parts from Linux Virtio PCI driver
+ *
+ * Copyright IBM Corp. 2007
+ * Authors: Anthony Liguori [EMAIL PROTECTED]
+ *
+ * some parts from Linux Virtio Ring
+ *
+ * Copyright Rusty Russell IBM Corporation 2007
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ *
+ */
+
+#include etherboot.h
+#include pci.h
+#include nic.h
+#include timer.h
+#include virtio-ring.h
+#include virtio-pci.h
+#include virtio-net.h
+
+#define BUG() do { \
+ printf(BUG: failure at %s:%d/%s()!\n, \
+ __FILE__, __LINE__, __FUNCTION__); \
+ while(1); \
+} while (0)
+#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
+
+/* Ethernet header */
+
+struct eth_hdr {
+ unsigned char dst_addr[ETH_ALEN];
+ unsigned char src_addr[ETH_ALEN];
+ unsigned short type;
+};
+
+struct eth_frame {
+ struct eth_hdr hdr;
+ unsigned char data[ETH_MAX_MTU];
+};
+
+typedef unsigned char virtio_queue_t[PAGE_MASK + vring_size(MAX_QUEUE_NUM)];
+
+/* TX: virtio header and eth buffer */
+
+static struct virtio_net_hdr tx_virtio_hdr;
+static struct eth_frame tx_eth_frame;
+
+/* RX: virtio headers and buffers */
+
+#define RX_BUF_NB 6
+static struct virtio_net_hdr rx_hdr[RX_BUF_NB];
+static unsigned char rx_buffer[RX_BUF_NB][ETH_FRAME_LEN];
+
+/* virtio queues and vrings */
+
+enum {
+ RX_INDEX = 0,
+ TX_INDEX,
+ QUEUE_NB
+};
+
+static virtio_queue_t queue[QUEUE_NB];
+static struct vring vring[QUEUE_NB];
+static u16 free_head[QUEUE_NB];
+static u16 last_used_idx[QUEUE_NB];
+static u16 vdata[QUEUE_NB][MAX_QUEUE_NUM];
+
+/*
+ * Virtio PCI interface
+ *
+ */
+
+static int vp_find_vq(struct nic *nic, int queue_index)
+{
+ struct vring * vr = vring[queue_index];
+ u16 num;
+
+ /* select the queue */
+
+ outw(queue_index, nic-ioaddr + VIRTIO_PCI_QUEUE_SEL);
+
+ /* check if the queue is available */
+
+ num = inw(nic-ioaddr + VIRTIO_PCI_QUEUE_NUM);
+ if (!num) {
+ printf(ERROR: queue size is 0\n);
+ return -1;
+ }
+
+ if (num MAX_QUEUE_NUM) {
+ printf(ERROR: queue size %d %d\n, num, MAX_QUEUE_NUM);
+ return -1;
+ }
+
+ /* check if the queue is already active */
+
+ if (inl(nic-ioaddr + VIRTIO_PCI_QUEUE_PFN)) {
+ printf(ERROR: queue already active\n);
+ return -1;
+ }
+
+ /* initialize the queue */
+
+ vring_init(vr, num, (unsigned char*)queue[queue_index]);
+
+ /* activate the queue
+*
+* NOTE: vr-desc is initialized by vring_init()
+*/
+
+ outl((unsigned long)virt_to_phys(vr-desc) PAGE_SHIFT,
+nic-ioaddr + VIRTIO_PCI_QUEUE_PFN);
+
+ return num;
+}
+
+/*
+ * Virtual ring management
+ *
+ */
+
+static void vring_disable_cb(int queue_index)
+{
+ vring[queue_index].avail-flags |= VRING_AVAIL_F_NO_INTERRUPT;
+}
+
+/*
+ * vring_free
+ *
+ * put at the begin of the free list the current desc[head]
+ */
+
+static void vring_detach(int queue_index, unsigned int head)
+{
+ struct vring *vr = vring[queue_index];
+unsigned int i;
+
+/* find end of given descriptor */
+
+ i = head;
+ while (vr-desc[i].flags VRING_DESC_F_NEXT)
+ i = vr-desc[i].next;
+
+ /* link it with free list and point to it */
+
+ vr
[PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute
Modify member in_range() of structure kvm_io_device to pass length and the type
of the I/O (write or read).
This modification allows to use kvm_io_device with coalesced MMIO.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
arch/ia64/kvm/kvm-ia64.c |6 +++---
arch/x86/kvm/i8254.c |6 --
arch/x86/kvm/i8259.c |3 ++-
arch/x86/kvm/lapic.c |3 ++-
arch/x86/kvm/x86.c | 28 +---
include/linux/kvm_host.h |3 ++-
virt/kvm/ioapic.c|3 ++-
virt/kvm/iodev.h |8 +---
virt/kvm/kvm_main.c |5 +++--
9 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index adb74f7..b59231b 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -195,11 +195,11 @@ int kvm_dev_ioctl_check_extension(long ext)
}
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len, int is_write)
{
struct kvm_io_device *dev;
- dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr);
+ dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr, len, is_write);
return dev;
}
@@ -231,7 +231,7 @@ static int handle_mmio(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
kvm_run-exit_reason = KVM_EXIT_MMIO;
return 0;
mmio:
- mmio_dev = vcpu_find_mmio_dev(vcpu, p-addr);
+ mmio_dev = vcpu_find_mmio_dev(vcpu, p-addr, p-size, !p-dir);
if (mmio_dev) {
if (!p-dir)
kvm_iodevice_write(mmio_dev, p-addr, p-size,
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6d6dc6c..1558034 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -445,7 +445,8 @@ static void pit_ioport_read(struct kvm_io_device *this,
mutex_unlock(pit_state-lock);
}
-static int pit_in_range(struct kvm_io_device *this, gpa_t addr)
+static int pit_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return ((addr = KVM_PIT_BASE_ADDRESS)
(addr KVM_PIT_BASE_ADDRESS + KVM_PIT_MEM_LENGTH));
@@ -486,7 +487,8 @@ static void speaker_ioport_read(struct kvm_io_device *this,
mutex_unlock(pit_state-lock);
}
-static int speaker_in_range(struct kvm_io_device *this, gpa_t addr)
+static int speaker_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return (addr == KVM_SPEAKER_BASE_ADDRESS);
}
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index ab29cf2..5857f59 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -346,7 +346,8 @@ static u32 elcr_ioport_read(void *opaque, u32 addr1)
return s-elcr;
}
-static int picdev_in_range(struct kvm_io_device *this, gpa_t addr)
+static int picdev_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
switch (addr) {
case 0x20:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 8fcd84e..7d0670e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -785,7 +785,8 @@ static void apic_mmio_write(struct kvm_io_device *this,
}
-static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr)
+static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int size)
{
struct kvm_lapic *apic = (struct kvm_lapic *)this-private;
int ret = 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2751e98..f829319 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1748,13 +1748,14 @@ static void kvm_init_msr_list(void)
* Only apic need an MMIO device hook, so shortcut now..
*/
static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
if (vcpu-arch.apic) {
dev = vcpu-arch.apic-dev;
- if (dev-in_range(dev, addr))
+ if (dev-in_range(dev, addr, len, is_write))
return dev;
}
return NULL;
@@ -1762,13 +1763,15 @@ static struct kvm_io_device
*vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
- dev = vcpu_find_pervcpu_dev(vcpu, addr);
+ dev = vcpu_find_pervcpu_dev(vcpu, addr, len, is_write);
if (dev == NULL)
- dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr
[PATCH 2/5] Add coalesced MMIO support (common part)
This patch adds all needed structures to coalesce MMIOs.
Until an architecture uses it, it is not compiled.
Coalesced MMIO introduces two ioctl() to define where are the MMIO zones that
can be coalesced:
- KVM_REGISTER_COALESCED_MMIO registers a coalesced MMIO zone.
It requests one parameter (struct kvm_coalesced_mmio_zone) which defines
a memory area where MMIOs can be coalesced until the next switch to
user space. The maximum number of MMIO zones is KVM_COALESCED_MMIO_ZONE_MAX.
- KVM_UNREGISTER_COALESCED_MMIO cancels all registered zones inside
the given bounds (bounds are also given by struct kvm_coalesced_mmio_zone).
The userspace client can check kernel coalesced MMIO availability by asking
ioctl(KVM_CHECK_EXTENSION) for the KVM_CAP_COALESCED_MMIO capability.
The ioctl() call to KVM_CAP_COALESCED_MMIO will return 0 if not supported,
or the page offset where will be stored the ring buffer.
The page offset depends on the architecture.
After an ioctl(KVM_RUN), the first page of the KVM memory mapped points to
a kvm_run structure. The offset given by KVM_CAP_COALESCED_MMIO is
an offset to the coalesced MMIO ring expressed in PAGE_SIZE relatively
to the address of the start of th kvm_run structure. The MMIO ring buffer
is defined by the structure kvm_coalesced_mmio_ring.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
include/linux/kvm.h | 29
include/linux/kvm_host.h |4 +
virt/kvm/coalesced_mmio.c | 156 +
virt/kvm/coalesced_mmio.h | 23 +++
virt/kvm/kvm_main.c | 57
5 files changed, 269 insertions(+), 0 deletions(-)
create mode 100644 virt/kvm/coalesced_mmio.c
create mode 100644 virt/kvm/coalesced_mmio.h
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a281afe..1c908ac 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -173,6 +173,30 @@ struct kvm_run {
};
};
+/* for KVM_REGISTER_COALESCED_MMIO / KVM_UNREGISTER_COALESCED_MMIO */
+
+struct kvm_coalesced_mmio_zone {
+ __u64 addr;
+ __u32 size;
+ __u32 pad;
+};
+
+struct kvm_coalesced_mmio {
+ __u64 phys_addr;
+ __u32 len;
+ __u32 pad;
+ __u8 data[8];
+};
+
+struct kvm_coalesced_mmio_ring {
+ __u32 first, last;
+ struct kvm_coalesced_mmio coalesced_mmio[0];
+};
+
+#define KVM_COALESCED_MMIO_MAX \
+ ((PAGE_SIZE - sizeof(struct kvm_coalesced_mmio_ring)) / \
+sizeof(struct kvm_coalesced_mmio))
+
/* for KVM_TRANSLATE */
struct kvm_translation {
/* in */
@@ -346,6 +370,7 @@ struct kvm_trace_rec {
#define KVM_CAP_NOP_IO_DELAY 12
#define KVM_CAP_PV_MMU 13
#define KVM_CAP_MP_STATE 14
+#define KVM_CAP_COALESCED_MMIO 15
/*
* ioctls for VM fds
@@ -371,6 +396,10 @@ struct kvm_trace_rec {
#define KVM_CREATE_PIT _IO(KVMIO, 0x64)
#define KVM_GET_PIT _IOWR(KVMIO, 0x65, struct kvm_pit_state)
#define KVM_SET_PIT _IOR(KVMIO, 0x66, struct kvm_pit_state)
+#define KVM_REGISTER_COALESCED_MMIO \
+ _IOW(KVMIO, 0x67, struct kvm_coalesced_mmio_zone)
+#define KVM_UNREGISTER_COALESCED_MMIO \
+ _IOW(KVMIO, 0x68, struct kvm_coalesced_mmio_zone)
/*
* ioctls for vcpu fds
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 57b376b..5424ecc 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -116,6 +116,10 @@ struct kvm {
struct kvm_vm_stat stat;
struct kvm_arch arch;
atomic_t users_count;
+#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
+ struct kvm_coalesced_mmio_dev *coalesced_mmio_dev;
+ struct kvm_coalesced_mmio_ring *coalesced_mmio_ring;
+#endif
};
/* The guest did something we don't support. */
diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
new file mode 100644
index 000..5ae620d
--- /dev/null
+++ b/virt/kvm/coalesced_mmio.c
@@ -0,0 +1,156 @@
+/*
+ * KVM coalesced MMIO
+ *
+ * Copyright (c) 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier [EMAIL PROTECTED]
+ *
+ */
+
+#include iodev.h
+
+#include linux/kvm_host.h
+#include linux/kvm.h
+
+#include coalesced_mmio.h
+
+static int coalesced_mmio_in_range(struct kvm_io_device *this,
+ gpa_t addr, int len, int is_write)
+{
+ struct kvm_coalesced_mmio_dev *dev =
+ (struct kvm_coalesced_mmio_dev*)this-private;
+ struct kvm_coalesced_mmio_zone *zone;
+ int next;
+ int i;
+
+ if (!is_write)
+ return 0;
+
+ /* kvm-lock is taken by the caller and must be not released before
+ * dev.read/write
+ */
+
+ /* Are we able to batch it ? */
+
+ /* last is the first free entry
+* check if we don't meet the first used entry
+* there is always one unused entry in the buffer
+*/
+
+ next = (dev-kvm-coalesced_mmio_ring-last + 1
[PATCH 3/5] Add coalesced MMIO support (x86 part)
This patch enables coalesced MMIO for x86 architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_COALESCED_MMIO. It enables the compilation of coalesced_mmio.c. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] --- arch/x86/kvm/Makefile |3 ++- arch/x86/kvm/x86.c |3 +++ include/asm-x86/kvm_host.h |1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile index c97d35c..d0e940b 100644 --- a/arch/x86/kvm/Makefile +++ b/arch/x86/kvm/Makefile @@ -2,7 +2,8 @@ # Makefile for Kernel-based Virtual Machine module # -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \ +coalesced_mmio.o) ifeq ($(CONFIG_KVM_TRACE),y) common-objs += $(addprefix ../../../virt/kvm/, kvm_trace.o) endif diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f829319..c7c41b7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -836,6 +836,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_MP_STATE: r = 1; break; + case KVM_CAP_COALESCED_MMIO: + r = KVM_COALESCED_MMIO_PAGE_OFFSET; + break; case KVM_CAP_VAPIC: r = !kvm_x86_ops-cpu_has_accelerated_tpr(); break; diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h index 8322fc1..f414858 100644 --- a/include/asm-x86/kvm_host.h +++ b/include/asm-x86/kvm_host.h @@ -26,6 +26,7 @@ #define KVM_PRIVATE_MEM_SLOTS 4 #define KVM_PIO_PAGE_OFFSET 1 +#define KVM_COALESCED_MMIO_PAGE_OFFSET 2 #define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1) #define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) ~(X86_CR3_PWT | X86_CR3_PCD)) -- 1.5.2.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] Add coalesced MMIO support (powerpc part)
This patch enables coalesced MMIO for powerpc architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_COALESCED_MMIO. It enables the compilation of coalesced_mmio.c. WARNING: this has not been tested. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] --- arch/powerpc/kvm/Makefile |2 +- arch/powerpc/kvm/powerpc.c |3 +++ include/asm-powerpc/kvm_host.h |2 ++ 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile index d0d358d..04e3449 100644 --- a/arch/powerpc/kvm/Makefile +++ b/arch/powerpc/kvm/Makefile @@ -4,7 +4,7 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/powerpc/kvm -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o) kvm-objs := $(common-objs) powerpc.o emulate.o booke_guest.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 0513b35..b850d24 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -145,6 +145,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_USER_MEMORY: r = 1; break; + case KVM_CAP_COALESCED_MMIO: + r = KVM_COALESCED_MMIO_PAGE_OFFSET; + break; default: r = 0; break; diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h index 81a69d7..2655e2a 100644 --- a/include/asm-powerpc/kvm_host.h +++ b/include/asm-powerpc/kvm_host.h @@ -31,6 +31,8 @@ /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 +#define KVM_COALESCED_MMIO_PAGE_OFFSET 1 + /* We don't currently support large pages. */ #define KVM_PAGES_PER_HPAGE (131) -- 1.5.2.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] kvm: Batch writes to MMIO
When kernel has to send MMIO writes to userspace, it stores them in memory until it has to pass the hand to userspace for another reason. This avoids to have too many context switches on operations that can wait. These patches introduce an ioctl() to define MMIO allowed to be coalesced. This is the kernel part of the coalesced MMIO functionality. [PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute Modify member in_range() of structure kvm_io_device to pass length and the type of the I/O (write or read). [PATCH 2/5] Add coalesced MMIO support (common part) This patch adds all needed structures to coalesce MMIOs. [PATCH 3/5] Add coalesced MMIO support (x86 part) This patch enables coalesced MMIO for x86 architecture. [PATCH 4/5] Add coalesced MMIO support (powerpc part) This patch enables coalesced MMIO for powerpc architecture. WARNING: this has not been tested. [PATCH 5/5] Add coalesced MMIO support (ia64 part) This patch enables coalesced MMIO for ia64 architecture. WARNING: this has not been tested. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] Add coalesced MMIO support (ia64 part)
This patch enables coalesced MMIO for ia64 architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_COALESCED_MMIO. It enables the compilation of coalesced_mmio.c. WARNING: this has not been tested. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] --- arch/ia64/kvm/Makefile |3 ++- arch/ia64/kvm/kvm-ia64.c|3 +++ include/asm-ia64/kvm_host.h |1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile index 112791d..bf22fb9 100644 --- a/arch/ia64/kvm/Makefile +++ b/arch/ia64/kvm/Makefile @@ -43,7 +43,8 @@ $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/ EXTRA_AFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/ -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \ + coalesced_mmio.o) kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c index b59231b..4815c31 100644 --- a/arch/ia64/kvm/kvm-ia64.c +++ b/arch/ia64/kvm/kvm-ia64.c @@ -187,6 +187,9 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; + case KVM_CAP_COALESCED_MMIO:: + r = KVM_COALESCED_MMIO_PAGE_OFFSET; + break; default: r = 0; } diff --git a/include/asm-ia64/kvm_host.h b/include/asm-ia64/kvm_host.h index 5c958b0..1efe513 100644 --- a/include/asm-ia64/kvm_host.h +++ b/include/asm-ia64/kvm_host.h @@ -38,6 +38,7 @@ /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 +#define KVM_COALESCED_MMIO_PAGE_OFFSET 1 /* define exit reasons from vmm to kvm*/ #define EXIT_REASON_VM_PANIC 0 -- 1.5.2.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] libkvm: coalesced MMIO support (common part)
This patch introduces in libkvm the common part of coalesced MMIO interface.
It checks the coalesced MMIO availability with ioctl(KVM_CHECK_EXTENSION).
If KVM_CAP_COALESCED_MMIO is available, it processes the MMIO ring buffer
at the return of ioctl(KVM_RUN).
It defines kvm_register_coalesced_mmio() to register a coalesced MMIO zone, and
kvm_unregister_coalesced_mmio() to unregister it.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
libkvm/kvm-common.h |2 +
libkvm/libkvm.c | 75 +++
libkvm/libkvm.h |4 +++
3 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h
index a3549e2..9780fb8 100644
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -49,6 +49,8 @@ struct kvm_context {
int no_pit_creation;
/// in-kernel pit status
int pit_in_kernel;
+ /// in-kernel coalesced mmio
+ int coalesced_mmio;
};
void init_slots(void);
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d1e95a4..1e7bbed 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -879,6 +879,22 @@ again:
post_kvm_run(kvm, vcpu);
+#if defined(KVM_CAP_COALESCED_MMIO)
+ if (kvm-coalesced_mmio) {
+ struct kvm_coalesced_mmio_ring *ring = (void *)run +
+ kvm-coalesced_mmio * PAGE_SIZE;
+ while (ring-first != ring-last) {
+ kvm-callbacks-mmio_write(kvm-opaque,
+ring-coalesced_mmio[ring-first].phys_addr,
+ ring-coalesced_mmio[ring-first].data[0],
+ring-coalesced_mmio[ring-first].len);
+ smp_wmb();
+ ring-first = (ring-first + 1) %
+ KVM_COALESCED_MMIO_MAX;
+ }
+ }
+#endif
+
if (r == -1) {
r = handle_io_window(kvm);
goto more;
@@ -983,3 +999,62 @@ int kvm_pit_in_kernel(kvm_context_t kvm)
{
return kvm-pit_in_kernel;
}
+
+int kvm_init_coalesced_mmio(kvm_context_t kvm)
+{
+ int r = 0;
+ kvm-coalesced_mmio = 0;
+#ifdef KVM_CAP_COALESCED_MMIO
+ r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_COALESCED_MMIO);
+ if (r 0) {
+ kvm-coalesced_mmio = r;
+ return 0;
+ }
+#endif
+ return r;
+}
+
+int kvm_register_coalesced_mmio(kvm_context_t kvm, uint64_t addr, uint32_t
size)
+{
+#ifdef KVM_CAP_COALESCED_MMIO
+ struct kvm_coalesced_mmio_zone zone;
+ int r;
+
+ if (kvm-coalesced_mmio) {
+
+ zone.addr = addr;
+ zone.size = size;
+
+ r = ioctl(kvm-vm_fd, KVM_REGISTER_COALESCED_MMIO, zone);
+ if (r == -1) {
+ perror(kvm_register_coalesced_mmio_zone);
+ return -errno;
+ }
+ return 0;
+ }
+#endif
+ return -ENOSYS;
+}
+
+int kvm_unregister_coalesced_mmio(kvm_context_t kvm, uint64_t addr, uint32_t
size)
+{
+#ifdef KVM_CAP_COALESCED_MMIO
+ struct kvm_coalesced_mmio_zone zone;
+ int r;
+
+ if (kvm-coalesced_mmio) {
+
+ zone.addr = addr;
+ zone.size = size;
+
+ r = ioctl(kvm-vm_fd, KVM_UNREGISTER_COALESCED_MMIO, zone);
+ if (r == -1) {
+ perror(kvm_unregister_coalesced_mmio_zone);
+ return -errno;
+ }
+ return 0;
+ }
+#endif
+ return -ENOSYS;
+}
+
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 63183b8..a33e9db 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -457,6 +457,10 @@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned
long phys_addr,
unsigned long end_addr, void *buf, void*opaque,
int (*cb)(unsigned long start, unsigned long len,
void*bitmap, void *opaque));
+int kvm_register_coalesced_mmio(kvm_context_t kvm,
+ uint64_t addr, uint32_t size);
+int kvm_unregister_coalesced_mmio(kvm_context_t kvm,
+ uint64_t addr, uint32_t size);
/*!
* \brief Create a memory alias
--
1.5.2.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] libkvm: coalesced MMIO support (x86 part)
This patch enables coalesced MMIO for x86 architecture. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] --- libkvm/kvm-x86.h|2 ++ libkvm/libkvm-x86.c |4 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/libkvm/kvm-x86.h b/libkvm/kvm-x86.h index 1dccf64..e988cb7 100644 --- a/libkvm/kvm-x86.h +++ b/libkvm/kvm-x86.h @@ -50,4 +50,6 @@ int kvm_disable_tpr_access_reporting(kvm_context_t kvm, int vcpu); #endif +#define smp_wmb() asm volatile( ::: memory) + #endif diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c index d46fdcc..ea97bdd 100644 --- a/libkvm/libkvm-x86.c +++ b/libkvm/libkvm-x86.c @@ -179,6 +179,10 @@ int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes, if (r 0) return r; + r = kvm_init_coalesced_mmio(kvm); + if (r 0) + return r; + return 0; } -- 1.5.2.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] libkvm: coalesced support (ia64 part)
This patch enables coalesced MMIO for ia64 architecture.
WARNING: this has not been tested.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
libkvm/kvm-ia64.h|3 +++
libkvm/libkvm-ia64.c |6 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-ia64.h b/libkvm/kvm-ia64.h
index 304496d..ad87ae7 100644
--- a/libkvm/kvm-ia64.h
+++ b/libkvm/kvm-ia64.h
@@ -25,4 +25,7 @@ extern int kvm_page_size;
#define PAGE_SIZE kvm_page_size
#define PAGE_MASK (~(kvm_page_size - 1))
+#define ia64_mf() asm volatile (mf ::: memory)
+#define smp_wmb() ia64_mf()
+
#endif
diff --git a/libkvm/libkvm-ia64.c b/libkvm/libkvm-ia64.c
index d7477d0..f35a16c 100644
--- a/libkvm/libkvm-ia64.c
+++ b/libkvm/libkvm-ia64.c
@@ -67,6 +67,12 @@ void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned
long phys_start,
int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
void **vm_mem)
{
+ int r;
+
+ r = kvm_init_coalesced_mmio(kvm);
+ if (r 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute
Modify member in_range() of structure kvm_io_device to pass length and the type
of the I/O (write or read).
This modification allows to use kvm_io_device with MMIO batching.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
arch/ia64/kvm/kvm-ia64.c |6 +++---
arch/x86/kvm/i8254.c |6 --
arch/x86/kvm/i8259.c |3 ++-
arch/x86/kvm/lapic.c |3 ++-
arch/x86/kvm/x86.c | 28 +---
include/linux/kvm_host.h |3 ++-
virt/kvm/ioapic.c|3 ++-
virt/kvm/iodev.h |8 +---
virt/kvm/kvm_main.c |5 +++--
9 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index adb74f7..b59231b 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -195,11 +195,11 @@ int kvm_dev_ioctl_check_extension(long ext)
}
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len, int is_write)
{
struct kvm_io_device *dev;
- dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr);
+ dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr, len, is_write);
return dev;
}
@@ -231,7 +231,7 @@ static int handle_mmio(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
kvm_run-exit_reason = KVM_EXIT_MMIO;
return 0;
mmio:
- mmio_dev = vcpu_find_mmio_dev(vcpu, p-addr);
+ mmio_dev = vcpu_find_mmio_dev(vcpu, p-addr, p-size, !p-dir);
if (mmio_dev) {
if (!p-dir)
kvm_iodevice_write(mmio_dev, p-addr, p-size,
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6d6dc6c..1558034 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -445,7 +445,8 @@ static void pit_ioport_read(struct kvm_io_device *this,
mutex_unlock(pit_state-lock);
}
-static int pit_in_range(struct kvm_io_device *this, gpa_t addr)
+static int pit_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return ((addr = KVM_PIT_BASE_ADDRESS)
(addr KVM_PIT_BASE_ADDRESS + KVM_PIT_MEM_LENGTH));
@@ -486,7 +487,8 @@ static void speaker_ioport_read(struct kvm_io_device *this,
mutex_unlock(pit_state-lock);
}
-static int speaker_in_range(struct kvm_io_device *this, gpa_t addr)
+static int speaker_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return (addr == KVM_SPEAKER_BASE_ADDRESS);
}
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index ab29cf2..5857f59 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -346,7 +346,8 @@ static u32 elcr_ioport_read(void *opaque, u32 addr1)
return s-elcr;
}
-static int picdev_in_range(struct kvm_io_device *this, gpa_t addr)
+static int picdev_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
switch (addr) {
case 0x20:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 8fcd84e..7d0670e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -785,7 +785,8 @@ static void apic_mmio_write(struct kvm_io_device *this,
}
-static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr)
+static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int size)
{
struct kvm_lapic *apic = (struct kvm_lapic *)this-private;
int ret = 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e537005..e500651 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1704,13 +1704,14 @@ static void kvm_init_msr_list(void)
* Only apic need an MMIO device hook, so shortcut now..
*/
static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
if (vcpu-arch.apic) {
dev = vcpu-arch.apic-dev;
- if (dev-in_range(dev, addr))
+ if (dev-in_range(dev, addr, len, is_write))
return dev;
}
return NULL;
@@ -1718,13 +1719,15 @@ static struct kvm_io_device
*vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
- dev = vcpu_find_pervcpu_dev(vcpu, addr);
+ dev = vcpu_find_pervcpu_dev(vcpu, addr, len, is_write);
if (dev == NULL)
- dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr
[PATCH 3/7] libkvm: delayed MMIO support (powerpc part)
This patch enables MMIO batching for powerpc architecture.
WARNING: this has not been tested.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
libkvm/libkvm-powerpc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm-powerpc.c b/libkvm/libkvm-powerpc.c
index 53a2478..0f342d7 100644
--- a/libkvm/libkvm-powerpc.c
+++ b/libkvm/libkvm-powerpc.c
@@ -93,6 +93,12 @@ void kvm_show_regs(kvm_context_t kvm, int vcpu)
int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
void **vm_mem)
{
+ int r;
+
+ r = kvm_init_delayed_mmio(kvm);
+ if (r 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] kvm: Batch writes to MMIO
When kernel has to send MMIO writes to userspace, it stores them in memory until it has to pass the hand to userspace for another reason. This avoids to have too many context switches on operations that can wait. These patches introduce an ioctl() to define MMIO allowed to be delayed. WITHOUT WITH PATCH PATCH iperf (e1000) 169 MB/s185,5 MB/s +9,7% host_state_reload(626594)(391825)-37% [9,7% is a more realistic value than my previous benchmark] boot XP host_state_reload 764677 516059 -32% VGA text scroll host_state_reload 13280568 (6:15) 3608362 (4:42) -73% (-25%) This is the kernel part of the MMIO batching functionality. [PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute Modify member in_range() of structure kvm_io_device to pass length and the type of the I/O (write or read). [PATCH 2/5] Add delayed MMIO support (common part) This patch adds all needed structures to batch MMIOs. Until an architecture uses it, it is not compiled. [PATCH 3/5] Add delayed MMIO support (x86 part) This patch enables MMIO batching for x86 architecture. [PATCH 4/5] Add delayed MMIO support (powerpc part) This patch enables MMIO batching for powerpc architecture. WARNING: this has not been tested. [PATCH 5/5] Add delayed MMIO support (ia64 part) This patch enables MMIO batching for ia64 architecture. WARNING: this has not been tested. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
