Re: [PATCH] target-mips: Ignore unassigned accesses with KVM
On Mon, Jul 28, 2014 at 12:37:50PM +0100, James Hogan wrote:
MIPS registers an unassigned access handler which raises a guest bus
error exception. However this causes QEMU to crash when KVM is enabled
as it isn't called from the main execution loop so longjmp() gets called
without a corresponding setjmp().
Until the KVM API can be updated to trigger a guest exception in
response to an MMIO exit, prevent the bus error exception being raised
from mips_cpu_unassigned_access() if KVM is enabled.
The check is at run time since the do_unassigned_access callback is
initialised before it is known whether KVM will be enabled.
The problem can be triggered with Malta emulation by making the guest
write to the reset region at physical address 0x1bf0, since it is
marked read-only which is treated as unassigned for writes.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Gleb Natapov g...@redhat.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Sanjay Lal sanj...@kymasys.com
---
target-mips/op_helper.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 27651a4a00c1..df97b35f8701 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -21,6 +21,7 @@
#include qemu/host-utils.h
#include exec/helper-proto.h
#include exec/cpu_ldst.h
+#include sysemu/kvm.h
#ifndef CONFIG_USER_ONLY
static inline void cpu_mips_tlb_flush (CPUMIPSState *env, int flush_global);
@@ -2168,6 +2169,16 @@ void mips_cpu_unassigned_access(CPUState *cs, hwaddr
addr,
MIPSCPU *cpu = MIPS_CPU(cs);
CPUMIPSState *env = cpu-env;
+/*
+ * Raising an exception with KVM enabled will crash because it won't be
from
+ * the main execution loop so the longjmp won't have a matching setjmp.
+ * Until we can trigger a bus error exception through KVM lets just
ignore
+ * the access.
+ */
+if (kvm_enabled()) {
+return;
+}
+
if (is_exec) {
helper_raise_exception(env, EXCP_IBE);
} else {
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
Note that even if the test is added for each exception, it is light
enough compared to triggering and handling an exception so that it has
no impact on performance.
Paolo, do you want to take this patch in your kvm tree?
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mips/kvm: Init EBase to correct KSEG0
On Thu, Jun 26, 2014 at 10:44:22AM +0100, James Hogan wrote:
The EBase CP0 register is initialised to 0x8000, however with KVM
the guest's KSEG0 is at 0x4000. The incorrect value doesn't get
passed to KVM yet as KVM doesn't implement the EBase register, however
we should set it correctly now so as not to break migration/loadvm to a
future version of QEMU that does support EBase.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: Paolo Bonzini pbonz...@redhat.com
---
target-mips/translate.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 2f91959ed7b1..d7b8c4dbc81a 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -28,6 +28,7 @@
#include exec/helper-proto.h
#include exec/helper-gen.h
+#include sysemu/kvm.h
#define MIPS_DEBUG_DISAS 0
//#define MIPS_DEBUG_SIGN_EXTENSIONS
@@ -16076,7 +16077,12 @@ void cpu_state_reset(CPUMIPSState *env)
env-CP0_Random = env-tlb-nb_tlb - 1;
env-tlb-tlb_in_use = env-tlb-nb_tlb;
env-CP0_Wired = 0;
-env-CP0_EBase = 0x8000 | (cs-cpu_index 0x3FF);
+env-CP0_EBase = (cs-cpu_index 0x3FF);
+if (kvm_enabled()) {
+env-CP0_EBase |= 0x4000;
+} else {
+env-CP0_EBase |= 0x8000;
+}
env-CP0_Status = (1 CP0St_BEV) | (1 CP0St_ERL);
/* vectored interrupts not implemented, timer on int 7,
no performance counters. */
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
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 3/4] mips_malta: Remove incorrect KVM TE references
On Thu, Jun 26, 2014 at 10:44:24AM +0100, James Hogan wrote:
Fix the error message and code comments relating to KVM not supporting
booting from the flash mapping when no kernel is provided. The issue is
a general MIPS KVM issue and isn't specific to the Trap Emulate
version of MIPS KVM.
Reported-by: Andreas Färber afaer...@suse.de
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: Paolo Bonzini pbonz...@redhat.com
---
hw/mips/mips_malta.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index c0841991f4e9..76cf5f2c48f4 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -1033,7 +1033,7 @@ void mips_malta_init(MachineState *machine)
fl_idx++;
if (kernel_filename) {
ram_low_size = MIN(ram_size, 256 20);
-/* For KVM TE we reserve 1MB of RAM for running bootloader */
+/* For KVM we reserve 1MB of RAM for running bootloader */
if (kvm_enabled()) {
ram_low_size -= 0x10;
bootloader_run_addr = 0x4000 + ram_low_size;
@@ -1057,10 +1057,10 @@ void mips_malta_init(MachineState *machine)
bootloader_run_addr, kernel_entry);
}
} else {
-/* The flash region isn't executable from a KVM TE guest */
+/* The flash region isn't executable from a KVM guest */
if (kvm_enabled()) {
error_report(KVM enabled but no -kernel argument was specified.
- Booting from flash is not supported with KVM
TE.);
+ Booting from flash is not supported with KVM.);
exit(1);
}
/* Load firmware from flash. */
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
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 2/4] mips_malta: Change default KVM cpu to 24Kc (no FP)
On Thu, Jun 26, 2014 at 10:44:23AM +0100, James Hogan wrote:
Change the default Malta CPU model for when KVM is enabled to 24Kc which
doesn't have floating point support compared to the 24Kf.
The resulting incorrect Config CP0 register value doesn't get passed to
KVM yet as KVM doesn't expose it, however we should ensure it is set
correctly now to reduce the risk of breaking migration/loadvm to a
future version of QEMU/Linux that does support them.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: Paolo Bonzini pbonz...@redhat.com
---
hw/mips/mips_malta.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 2868ee5b0307..c0841991f4e9 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -949,7 +949,12 @@ void mips_malta_init(MachineState *machine)
#ifdef TARGET_MIPS64
cpu_model = 20Kc;
#else
-cpu_model = 24Kf;
+if (kvm_enabled()) {
+/* Don't enable FPU on KVM yet */
+cpu_model = 24Kc;
+} else {
+cpu_model = 24Kf;
+}
#endif
}
Given the explanations in the other mails, that looks fine to me, that
said I think we should at least warn the user that we are disabling some
features, instead of doing it silently. This is what is done for example
on x86 when a CPU feature is not available.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
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 4/4] mips_malta: Catch kernels linked at wrong address
On Thu, Jun 26, 2014 at 10:44:25AM +0100, James Hogan wrote:
Add error reporting if the wrong type of kernel is provided for the
current mode of acceleration.
Currently a KVM kernel linked at 0x4000 can't be used with TCG, and
a normal kernel linked at 0x8000 can't be used with KVM.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: Paolo Bonzini pbonz...@redhat.com
---
hw/mips/mips_malta.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 76cf5f2c48f4..95df42e6a4d5 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -792,9 +792,23 @@ static int64_t load_kernel (void)
loaderparams.kernel_filename);
exit(1);
}
+
+/* Sanity check where the kernel has been linked */
if (kvm_enabled()) {
+if (kernel_entry 0x8000ll) {
+error_report(KVM guest kernels must be linked in useg.
+ Did you forget to enable CONFIG_KVM_GUEST?);
+exit(1);
+}
+
xlate_to_kseg0 = cpu_mips_kvm_um_phys_to_kseg0;
} else {
+if (!(kernel_entry 0x8000ll)) {
+error_report(KVM guest kernels aren't supported with TCG.
+ Did you unintentionally enable CONFIG_KVM_GUEST?);
+exit(1);
+}
+
xlate_to_kseg0 = cpu_mips_phys_to_kseg0;
}
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Fri, Jun 20, 2014 at 02:07:05AM -0400, Paolo Bonzini wrote: - Messaggio originale - Da: Aurelien Jarno aurel...@aurel32.net A: Sanjay Lal sanj...@kymasys.com Cc: James Hogan james.ho...@imgtec.com, qemu-de...@nongnu.org, Peter Maydell peter.mayd...@linaro.org, kvm@vger.kernel.org, Gleb Natapov g...@redhat.com, Paolo Bonzini pbonz...@redhat.com Inviato: Giovedì, 19 giugno 2014 23:47:34 Oggetto: Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: On Jun 19, 2014, at 9:27 AM, Aurelien Jarno aurel...@aurel32.net wrote: On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: In KVM mode the bootrom is loaded and executed from the last 1MB of DRAM. What is the reason for that? I am not opposed to that, but if it is really needed, it means that loading a bootloader into the flash area (for example YAMON) won't work and that this should be forbidden to the user. In trap and emulate mode, both the kernel and userland run in user mode on the processor. Virtual addresses = 0x8000 are only accessible in kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) falls in this range. We therefore decided to relocate the bootloader to the last 1MB of RAM. This area is excluded from the RAM ranges supplied to the kernel, so it should not be accessible to the user. Thanks for the explanation. It means we should disable the support for booting from the flash (using -pflash) in KVM mode, as it would simply not work. My idea was to add a machines-specific option umkernel=on, and require it in order to run KVM. Later we can add umkernel=on support for TCG as well, while umkernel=off with KVM requires virtualization extensions. The same option can disable pflash boot. What do you think? For what I understand the current KVM support in MIPS uses trap and emulate and thus doesn't need hardware support, just a recent kernel with the option enabled. That's why I do wonder if there is a real point in supporting UM kernels in TCG mode. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Fri, Jun 20, 2014 at 12:38:30PM +0200, Paolo Bonzini wrote: Il 20/06/2014 11:10, Aurelien Jarno ha scritto: My idea was to add a machines-specific option umkernel=on, and require it in order to run KVM. Later we can add umkernel=on support for TCG as well, while umkernel=off with KVM requires virtualization extensions. The same option can disable pflash boot. What do you think? For what I understand the current KVM support in MIPS uses trap and emulate and thus doesn't need hardware support, just a recent kernel with the option enabled. Yes, but work to support virtualization extensions is underway. Patches were posted a few months ago. That's why I do wonder if there is a real point in supporting UM kernels in TCG mode. Debugging, mainly. It is sometimes useful to compare TCG with KVM on x86, and I suppose it could be the same on MIPS. Ok, then we can indeed add a umkernel option, which is always enabled with KVM, and which disable the flash (and why not other devices) in that case. At some point it might be a good idea to add a specific machine for emulation/virtualization, like it is done on ARM, which do not have to handle this kind of devices, and which does not have all the current limitations of the Malta board. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Fri, Jun 20, 2014 at 10:25:24AM +0100, James Hogan wrote:
On 19/06/14 22:47, Aurelien Jarno wrote:
On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote:
On Jun 19, 2014, at 9:27 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
In KVM mode the bootrom is loaded and executed from the last 1MB of
DRAM.
What is the reason for that? I am not opposed to that, but if it is
really needed, it means that loading a bootloader into the flash area
(for example YAMON) won't work and that this should be forbidden to the
user.
In trap and emulate mode, both the kernel and userland run in user mode on
the processor. Virtual addresses = 0x8000 are only accessible in
kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0)
falls in this range.
We therefore decided to relocate the bootloader to the last 1MB of RAM.
This area is excluded from the RAM ranges supplied to the kernel, so it
should not be accessible to the user.
Thanks for the explanation. It means we should disable the support for
booting from the flash (using -pflash) in KVM mode, as it would simply
not work.
Hi Aurelien,
Is this fixup to the malta patch the sort of thing you had in mind? If
so I'll generate a v6 patchset with it.
Cheers
James
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 8bc5392b4223..91b0ce566111 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -1052,6 +1052,12 @@ void mips_malta_init(MachineState *machine)
bootloader_run_addr, kernel_entry);
}
} else {
+/* The flash region isn't executable from a KVM TE guest */
+if (kvm_enabled()) {
+error_report(KVM enabled but no -kernel argument was specified.
+ Booting from flash is not supported with KVM
TE.);
+exit(1);
+}
/* Load firmware from flash. */
if (!dinfo) {
/* Load a BIOS image. */
This looks fine to me.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
In KVM mode the bootrom is loaded and executed from the last 1MB of
DRAM.
What is the reason for that? I am not opposed to that, but if it is
really needed, it means that loading a bootloader into the flash area
(for example YAMON) won't work and that this should be forbidden to the
user.
Based on [PATCH 12/12] KVM/MIPS: General KVM support and support for
SMP Guests by Sanjay Lal sanj...@kymasys.com.
Signed-off-by: James Hogan james.ho...@imgtec.com
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Sanjay Lal sanj...@kymasys.com
---
Changes in v5:
- Kseg0 doesn't actually change size, so use cpu_mips_kseg0_to_phys()
rather than having the KVM specific cpu_mips_kvm_um_kseg0_to_phys().
Changes in v3:
- Remove unnecessary includes, especially linux/kvm.h which isn't a
good idea on non-Linux (Peter Maydell).
Changes in v2:
- Removal of cps / GIC / SMP support
- Minimal bootloader modified to execute safely from RAM
- Remove Writing bootloader to final 1MB of RAM printf
---
hw/mips/mips_malta.c | 73
++--
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index f4a7d4712952..8bc5392b4223 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -51,6 +51,7 @@
#include sysemu/qtest.h
#include qemu/error-report.h
#include hw/empty_slot.h
+#include sysemu/kvm.h
//#define DEBUG_BOARD_INIT
@@ -603,29 +604,31 @@ static void network_init(PCIBus *pci_bus)
*/
static void write_bootloader (CPUMIPSState *env, uint8_t *base,
- int64_t kernel_entry)
+ int64_t run_addr, int64_t kernel_entry)
{
uint32_t *p;
/* Small bootloader */
p = (uint32_t *)base;
-stl_p(p++, 0x0bf00160); /* j
0x1fc00580 */
+
+stl_p(p++, 0x0800 | /* j
0x1fc00580 */
+ ((run_addr + 0x580) 0x0fff) 2);
stl_p(p++, 0x); /* nop */
/* YAMON service vector */
-stl_p(base + 0x500, 0xbfc00580); /* start: */
-stl_p(base + 0x504, 0xbfc0083c); /* print_count: */
-stl_p(base + 0x520, 0xbfc00580); /* start: */
-stl_p(base + 0x52c, 0xbfc00800); /* flush_cache: */
-stl_p(base + 0x534, 0xbfc00808); /* print: */
-stl_p(base + 0x538, 0xbfc00800); /* reg_cpu_isr: */
-stl_p(base + 0x53c, 0xbfc00800); /* unred_cpu_isr: */
-stl_p(base + 0x540, 0xbfc00800); /* reg_ic_isr: */
-stl_p(base + 0x544, 0xbfc00800); /* unred_ic_isr: */
-stl_p(base + 0x548, 0xbfc00800); /* reg_esr: */
-stl_p(base + 0x54c, 0xbfc00800); /* unreg_esr: */
-stl_p(base + 0x550, 0xbfc00800); /* getchar: */
-stl_p(base + 0x554, 0xbfc00800); /* syscon_read: */
+stl_p(base + 0x500, run_addr + 0x0580); /* start: */
+stl_p(base + 0x504, run_addr + 0x083c); /* print_count: */
+stl_p(base + 0x520, run_addr + 0x0580); /* start: */
+stl_p(base + 0x52c, run_addr + 0x0800); /* flush_cache: */
+stl_p(base + 0x534, run_addr + 0x0808); /* print: */
+stl_p(base + 0x538, run_addr + 0x0800); /* reg_cpu_isr: */
+stl_p(base + 0x53c, run_addr + 0x0800); /* unred_cpu_isr: */
+stl_p(base + 0x540, run_addr + 0x0800); /* reg_ic_isr: */
+stl_p(base + 0x544, run_addr + 0x0800); /* unred_ic_isr: */
+stl_p(base + 0x548, run_addr + 0x0800); /* reg_esr: */
+stl_p(base + 0x54c, run_addr + 0x0800); /* unreg_esr: */
+stl_p(base + 0x550, run_addr + 0x0800); /* getchar: */
+stl_p(base + 0x554, run_addr + 0x0800); /* syscon_read: */
/* Second part of the bootloader */
@@ -701,7 +704,7 @@ static void write_bootloader (CPUMIPSState *env, uint8_t
*base,
p = (uint32_t *) (base + 0x800);
stl_p(p++, 0x03e8); /* jr ra */
stl_p(p++, 0x2402); /* li v0,0 */
- /* 808 YAMON print */
+/* 808 YAMON print */
stl_p(p++, 0x03e06821); /* move
t5,ra */
stl_p(p++, 0x00805821); /* move
t3,a0 */
stl_p(p++, 0x00a05021); /* move
t2,a1 */
@@ -774,6 +777,7 @@ static int64_t load_kernel (void)
uint32_t *prom_buf;
long prom_size;
int prom_index = 0;
+uint64_t (*xlate_to_kseg0) (void *opaque, uint64_t addr);
#ifdef TARGET_WORDS_BIGENDIAN
big_endian = 1;
@@ -788,6 +792,11 @@ static int64_t load_kernel (void)
loaderparams.kernel_filename);
exit(1
Re: [PATCH v5 00/12] KVM Support for MIPS32 Processors
kernels are configured to
a sufficient page size to avoid aliasing (which the kernel
arch/mips/kvm/00README.txt alludes to anyway).
- Rewrote kvm sigmask patch to allow sigmask length to be set by
kvm_arch_init(), so that MIPS can set it to 16 as it has 128 signals.
This is better than cluttering kvm-all.c with TARGET_* ifdefs (Peter
Maydell).
- Set sigmask length to 16 from kvm_arch_init() since MIPS Linux has
128 signals. This is better than cluttering kvm_all.c with TARGET_*
ifdefs (Peter Maydell).
- s/dprintf/DPRINTF/ (Andreas Färber).
- Use cs rather than cpu or env for CPUState variable names
(Andreas Färber).
- Use CPUMIPSState rather than CPUArchState (Andreas Färber).
- Pass MIPSCPU to cpu_mips_io_interrupts_pending() rather than
CPUMIPSState (Andreas Färber).
- Remove spurious parentheses around cpu_mips_io_interrupts_pending()
call (Andreas Färber).
- Pass MIPSCPU to kvm_mips_set_[ipi_]interrupt (Andreas Färber).
- Make use of error_report (Andreas Färber) and clean up error messages
a little to include __func__.
- Remove inline kvm_mips_{put,get}_one_[ul]reg() declarations from
kvm_mips.h. They're only used in target-mips/kvm.c anyway.
- Make kvm_arch_{put,get}_registers static within target-mips/kvm.c and
remove from kvm_mips.h.
- Remove unnecessary includes from Malta patch, especially linux/kvm.h
which isn't a good idea on non-Linux (Peter Maydell).
Changes in v2:
This patchset is based on Sanjay Lal's V1 patchset from 2nd March 2013:
https://patchwork.kernel.org/project/kvm/list/?submitter=51991state=*q=qemu-devel
I think I've addressed all the V1 feedback. The other main change is the
removal of the boot-CPS ROM code binary blob and GIC/SMP support since
it's all slightly orthogonal to KVM support. Instead the existing
minimal bootloader code for Malta has been updated to work with KVM TE.
A git tag for this version of the patchset can also be found on github:
https://github.com/jahogan/qemu-kvm-mips.git kvm-mips-v2
- Expand commit messages
- Rebase on v1.7.0
- Misc checkpatch and other cleanups
- Some interrupt bug fixes from Yann Le Du l...@kymasys.com
- Add get/set register functionality from Yann Le Du l...@kymasys.com
- Use new 64 bit compatible ABI from Cavium from Sanjay Lal
sanj...@kymasys.com
- Add dummy kvm_arch_init_irq_routing()
The common KVM code insists on calling kvm_arch_init_irq_routing() as
soon as it sees kernel header support for it (regardless of whether
QEMU supports it). Provide a dummy function to satisfy this.
- Remove request_interrupt_window code (Peter Maydell)
- Remove #ifdef CONFIG_KVM where guarded by kvm_enabled() already
- Removal of cps / GIC / SMP support
- Minimal bootloader modified to execute safely from RAM
- Create asm-mips symlink using generic code and move above default
case (Peter Maydell)
- Remove redundant check of target_name = cpu = mips
- Remove mipsel cross compilation fix, which is now fixed by commit
61cc919f73ea (configure: detect endian via compile test)
- Add translation of guest kernel segments to allow an attached gdb to
see kernel memory correctly
James Hogan (7):
target-mips: Reset CPU timer consistently
target-mips: get_physical_address: Add defines for segment bases
target-mips: get_physical_address: Add KVM awareness
kvm: Allow arch to set sigmask length
target-mips: Call kvm_mips_reset_vcpu() from mips_cpu_reset()
hw/mips: malta: Add KVM support
MAINTAINERS: Add entry for MIPS KVM
Sanjay Lal (5):
hw/mips/cputimer: Don't start periodic timer in KVM mode
hw/mips: Add API to convert KVM guest KSEG0 - GPA
target-mips: kvm: Add main KVM support for MIPS
hw/mips: In KVM mode, inject IRQ2 (I/O) interrupts via ioctls
target-mips: Enable KVM support in build system
MAINTAINERS | 5 +
configure | 6 +-
hw/mips/addr.c| 7 +-
hw/mips/cputimer.c| 18 +-
hw/mips/mips_int.c| 11 +
hw/mips/mips_malta.c | 73 +++--
include/hw/mips/cpudevs.h | 2 +
include/sysemu/kvm.h | 2 +
kvm-all.c | 11 +-
target-mips/Makefile.objs | 1 +
target-mips/cpu.c | 8 +
target-mips/helper.c | 51 +++-
target-mips/kvm.c | 683
++
target-mips/kvm_mips.h| 26 ++
target-mips/translate.c | 2 +
15 files changed, 866 insertions(+), 40 deletions(-)
create mode 100644 target-mips/kvm.c
create mode 100644 target-mips/kvm_mips.h
Thanks, it's a very clean patch set. I'll leave a few days for
Aurelien to comment, and then apply to uq/master.
Except the minor comment on patch 10 it looks fine to me. That said I
haven't reviewed the KVM interface part very deeply, I trust you for
that part.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: On Jun 19, 2014, at 9:27 AM, Aurelien Jarno aurel...@aurel32.net wrote: On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: In KVM mode the bootrom is loaded and executed from the last 1MB of DRAM. What is the reason for that? I am not opposed to that, but if it is really needed, it means that loading a bootloader into the flash area (for example YAMON) won't work and that this should be forbidden to the user. In trap and emulate mode, both the kernel and userland run in user mode on the processor. Virtual addresses = 0x8000 are only accessible in kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) falls in this range. We therefore decided to relocate the bootloader to the last 1MB of RAM. This area is excluded from the RAM ranges supplied to the kernel, so it should not be accessible to the user. Thanks for the explanation. It means we should disable the support for booting from the flash (using -pflash) in KVM mode, as it would simply not work. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/10] hw/mips: In KVM mode, inject IRQ2 (I/O) interupts via ioctls
On Mon, Dec 16, 2013 at 02:12:43PM +, James Hogan wrote:
From: Sanjay Lal sanj...@kymasys.com
COP0 emulation is in-kernel for KVM, so inject IRQ2 (I/O) interrupts via
ioctls.
Signed-off-by: Sanjay Lal sanj...@kymasys.com
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
---
Changes in v2:
- Expand commit message
- Remove #ifdef CONFIG_KVM since it's guarded by kvm_enabled() already
---
hw/mips/mips_int.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/mips/mips_int.c b/hw/mips/mips_int.c
index 7dbd24d..1b9981e 100644
--- a/hw/mips/mips_int.c
+++ b/hw/mips/mips_int.c
@@ -23,6 +23,8 @@
#include hw/hw.h
#include hw/mips/cpudevs.h
#include cpu.h
+#include sysemu/kvm.h
+#include kvm_mips.h
static void cpu_mips_irq_request(void *opaque, int irq, int level)
{
@@ -35,8 +37,17 @@ static void cpu_mips_irq_request(void *opaque, int irq,
int level)
if (level) {
env-CP0_Cause |= 1 (irq + CP0Ca_IP);
+
+if (kvm_enabled() irq == 2) {
+kvm_mips_set_interrupt(env, irq, level);
+}
+
} else {
env-CP0_Cause = ~(1 (irq + CP0Ca_IP));
+
+if (kvm_enabled() irq == 2) {
+kvm_mips_set_interrupt(env, irq, level);
+}
}
if (env-CP0_Cause CP0Ca_IP_mask) {
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/10] target-mips: Enable KVM support in build system
On Mon, Dec 16, 2013 at 02:12:45PM +, James Hogan wrote: From: Sanjay Lal sanj...@kymasys.com Enable KVM support for MIPS in the build system. Signed-off-by: Sanjay Lal sanj...@kymasys.com Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Aurelien Jarno aurel...@aurel32.net --- Changes in v2: - Expand commit message - Remove GIC code - Create asm-mips symlink using generic code and move above default case (Peter Maydell) - Remove redundant check of target_name = cpu = mips - Remove mipsel cross compilation fix, which is now fixed by commit 61cc919f73ea (configure: detect endian via compile test) --- configure | 6 +- target-mips/Makefile.objs | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 0666228..7d86eea 100755 --- a/configure +++ b/configure @@ -4329,6 +4329,9 @@ if test $linux = yes ; then aarch64) linux_arch=arm64 ;; + mips64) +linux_arch=mips +;; *) # For most CPUs the kernel architecture name and QEMU CPU name match. linux_arch=$cpu @@ -4518,7 +4521,7 @@ case $target_name in *) esac case $target_name in - arm|i386|x86_64|ppcemb|ppc|ppc64|s390x) + arm|i386|x86_64|ppcemb|ppc|ppc64|s390x|mipsel|mips) # Make sure the target and host cpus are compatible if test $kvm = yes -a $target_softmmu = yes -a \ \( $target_name = $cpu -o \ @@ -4526,6 +4529,7 @@ case $target_name in \( $target_name = ppc64 -a $cpu = ppc \) -o \ \( $target_name = ppc-a $cpu = ppc64 \) -o \ \( $target_name = ppcemb -a $cpu = ppc64 \) -o \ + \( $target_name = mipsel -a $cpu = mips \) -o \ \( $target_name = x86_64 -a $cpu = i386 \) -o \ \( $target_name = i386 -a $cpu = x86_64 \) \) ; then echo CONFIG_KVM=y $config_target_mak diff --git a/target-mips/Makefile.objs b/target-mips/Makefile.objs index 0277d56..716244f 100644 --- a/target-mips/Makefile.objs +++ b/target-mips/Makefile.objs @@ -1,3 +1,4 @@ obj-y += translate.o dsp_helper.o op_helper.o lmi_helper.o helper.o cpu.o obj-y += gdbstub.o obj-$(CONFIG_SOFTMMU) += machine.o +obj-$(CONFIG_KVM) += kvm.o Reviewed-by: Aurelien Jarno aurel...@aurel32.net -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/10] hw/mips/cputimer: Don't start periodic timer in KVM mode
On Mon, Dec 16, 2013 at 02:12:36PM +, James Hogan wrote:
From: Sanjay Lal sanj...@kymasys.com
Compare/Count timer interrupts are handled in-kernel for KVM, so don't
bother starting it in QEMU.
Signed-off-by: Sanjay Lal sanj...@kymasys.com
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
---
Changes in v2:
- Expand commit message
- Rebase on v1.7.0
- Wrap comment
---
hw/mips/cputimer.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/hw/mips/cputimer.c b/hw/mips/cputimer.c
index c8b4b00..52570fd 100644
--- a/hw/mips/cputimer.c
+++ b/hw/mips/cputimer.c
@@ -23,6 +23,7 @@
#include hw/hw.h
#include hw/mips/cpudevs.h
#include qemu/timer.h
+#include sysemu/kvm.h
#define TIMER_FREQ 100 * 1000 * 1000
@@ -141,7 +142,13 @@ static void mips_timer_cb (void *opaque)
void cpu_mips_clock_init (CPUMIPSState *env)
{
-env-timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, mips_timer_cb, env);
-env-CP0_Compare = 0;
-cpu_mips_store_count(env, 1);
+/*
+ * If we're in KVM mode, don't start the periodic timer, that is handled
in
+ * kernel.
+ */
+if (!kvm_enabled()) {
+env-timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, mips_timer_cb, env);
+env-CP0_Compare = 0;
+cpu_mips_store_count(env, 1);
+}
}
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/10] hw/mips: malta: Add KVM support
On Mon, Dec 16, 2013 at 02:12:44PM +, James Hogan wrote:
In KVM mode the bootrom is loaded and executed from the last 1MB of
DRAM.
Based on [PATCH 12/12] KVM/MIPS: General KVM support and support for
SMP Guests by Sanjay Lal sanj...@kymasys.com.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
---
Changes in v2:
- Removal of cps / GIC / SMP support
- Minimal bootloader modified to execute safely from RAM
- Remove Writing bootloader to final 1MB of RAM printf
---
hw/mips/mips_malta.c | 85
++--
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 05c8771..3fff07c 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -51,6 +51,10 @@
#include sysemu/qtest.h
#include qemu/error-report.h
#include hw/empty_slot.h
+#include qemu/bitmap.h
+#include sysemu/kvm.h
+#include linux/kvm.h
+#include kvm_mips.h
//#define DEBUG_BOARD_INIT
@@ -603,29 +607,31 @@ static void network_init(PCIBus *pci_bus)
*/
static void write_bootloader (CPUMIPSState *env, uint8_t *base,
- int64_t kernel_entry)
+ int64_t run_addr, int64_t kernel_entry)
{
uint32_t *p;
/* Small bootloader */
p = (uint32_t *)base;
-stl_raw(p++, 0x0bf00160); /* j
0x1fc00580 */
+
+stl_raw(p++, 0x0800 | /* j
0x1fc00580 */
+ ((run_addr + 0x580) 0x0fff) 2);
stl_raw(p++, 0x); /* nop */
/* YAMON service vector */
-stl_raw(base + 0x500, 0xbfc00580); /* start: */
-stl_raw(base + 0x504, 0xbfc0083c); /* print_count: */
-stl_raw(base + 0x520, 0xbfc00580); /* start: */
-stl_raw(base + 0x52c, 0xbfc00800); /* flush_cache: */
-stl_raw(base + 0x534, 0xbfc00808); /* print: */
-stl_raw(base + 0x538, 0xbfc00800); /* reg_cpu_isr: */
-stl_raw(base + 0x53c, 0xbfc00800); /* unred_cpu_isr: */
-stl_raw(base + 0x540, 0xbfc00800); /* reg_ic_isr: */
-stl_raw(base + 0x544, 0xbfc00800); /* unred_ic_isr: */
-stl_raw(base + 0x548, 0xbfc00800); /* reg_esr: */
-stl_raw(base + 0x54c, 0xbfc00800); /* unreg_esr: */
-stl_raw(base + 0x550, 0xbfc00800); /* getchar: */
-stl_raw(base + 0x554, 0xbfc00800); /* syscon_read: */
+stl_raw(base + 0x500, run_addr + 0x0580); /* start: */
+stl_raw(base + 0x504, run_addr + 0x083c); /* print_count: */
+stl_raw(base + 0x520, run_addr + 0x0580); /* start: */
+stl_raw(base + 0x52c, run_addr + 0x0800); /* flush_cache: */
+stl_raw(base + 0x534, run_addr + 0x0808); /* print: */
+stl_raw(base + 0x538, run_addr + 0x0800); /* reg_cpu_isr: */
+stl_raw(base + 0x53c, run_addr + 0x0800); /* unred_cpu_isr: */
+stl_raw(base + 0x540, run_addr + 0x0800); /* reg_ic_isr: */
+stl_raw(base + 0x544, run_addr + 0x0800); /* unred_ic_isr: */
+stl_raw(base + 0x548, run_addr + 0x0800); /* reg_esr: */
+stl_raw(base + 0x54c, run_addr + 0x0800); /* unreg_esr: */
+stl_raw(base + 0x550, run_addr + 0x0800); /* getchar: */
+stl_raw(base + 0x554, run_addr + 0x0800); /* syscon_read: */
/* Second part of the bootloader */
@@ -701,7 +707,7 @@ static void write_bootloader (CPUMIPSState *env, uint8_t
*base,
p = (uint32_t *) (base + 0x800);
stl_raw(p++, 0x03e8); /* jr ra */
stl_raw(p++, 0x2402); /* li v0,0
*/
- /* 808 YAMON print */
+/* 808 YAMON print */
stl_raw(p++, 0x03e06821); /* move
t5,ra */
stl_raw(p++, 0x00805821); /* move
t3,a0 */
stl_raw(p++, 0x00a05021); /* move
t2,a1 */
@@ -774,6 +780,9 @@ static int64_t load_kernel (void)
uint32_t *prom_buf;
long prom_size;
int prom_index = 0;
+uint64_t (*xlate_to_phys) (void *opaque, uint64_t addr);
+uint64_t (*xlate_to_kseg0) (void *opaque, uint64_t addr);
+
#ifdef TARGET_WORDS_BIGENDIAN
big_endian = 1;
@@ -781,7 +790,15 @@ static int64_t load_kernel (void)
big_endian = 0;
#endif
-if (load_elf(loaderparams.kernel_filename, cpu_mips_kseg0_to_phys, NULL,
+if (kvm_enabled()) {
+xlate_to_phys = cpu_mips_kvm_um_kseg0_to_phys;
+xlate_to_kseg0 = cpu_mips_kvm_um_phys_to_kseg0;
+} else {
+xlate_to_phys = cpu_mips_kseg0_to_phys;
+xlate_to_kseg0 = cpu_mips_phys_to_kseg0;
+}
+
+if (load_elf(loaderparams.kernel_filename, xlate_to_phys, NULL,
(uint64_t
Re: [PATCH v2 04/10] target-mips: get_physical_address: Add KVM awareness
On Mon, Dec 16, 2013 at 02:12:39PM +, James Hogan wrote:
MIPS KVM trap emulate mode (which is currently the only supported
mode) has to add an extra kseg0/kseg1 at 0x4000 and an extra
kseg2/kseg3 at 0x6000. Take this into account in
get_physical_address() so that debug memory access works.
This is done by translating the address to a standard kseg0 or kseg2
address before doing the normal address translation. The real virtual
address is still used for TLB lookups.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
---
target-mips/helper.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 2e96655..c4be887 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -24,6 +24,7 @@
#include signal.h
#include cpu.h
+#include sysemu/kvm.h
enum {
TLBRET_DIRTY = -4,
@@ -100,7 +101,7 @@ int r4k_map_address (CPUMIPSState *env, hwaddr *physical,
int *prot,
}
static int get_physical_address (CPUMIPSState *env, hwaddr *physical,
-int *prot, target_ulong address,
+int *prot, target_ulong real_address,
int rw, int access_type)
{
/* User mode can only access useg/xuseg */
@@ -113,6 +114,8 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
int KX = (env-CP0_Status (1 CP0St_KX)) != 0;
#endif
int ret = TLBRET_MATCH;
+/* effective address (modified for KVM TE kernel segments) */
+target_ulong address = real_address;
#if 0
qemu_log(user mode %d h %08x\n, user_mode, env-hflags);
@@ -124,19 +127,35 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
#define KSEG2_BASE 0xC000UL
#define KSEG3_BASE 0xE000UL
+#define KVM_KSEG0_BASE 0x4000UL
+#define KVM_KSEG2_BASE 0x6000UL
+
+if (kvm_enabled()) {
+/* KVM TE adds guest kernel segments in useg */
+if (real_address = KVM_KSEG0_BASE) {
+if (real_address KVM_KSEG2_BASE) {
+/* kseg0 */
+address += KSEG0_BASE - KVM_KSEG0_BASE;
+} else if (real_address = USEG_LIMIT) {
+/* kseg2/3 */
+address += KSEG2_BASE - KVM_KSEG2_BASE;
+}
+}
+}
+
if (address = USEG_LIMIT) {
/* useg */
if (env-CP0_Status (1 CP0St_ERL)) {
*physical = address 0x;
*prot = PAGE_READ | PAGE_WRITE;
} else {
-ret = env-tlb-map_address(env, physical, prot, address, rw,
access_type);
+ret = env-tlb-map_address(env, physical, prot, real_address,
rw, access_type);
}
#if defined(TARGET_MIPS64)
} else if (address 0x4000ULL) {
/* xuseg */
if (UX address = (0x3FFFULL env-SEGMask)) {
-ret = env-tlb-map_address(env, physical, prot, address, rw,
access_type);
+ret = env-tlb-map_address(env, physical, prot, real_address,
rw, access_type);
} else {
ret = TLBRET_BADADDR;
}
@@ -144,7 +163,7 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
/* xsseg */
if ((supervisor_mode || kernel_mode)
SX address = (0x7FFFULL env-SEGMask)) {
-ret = env-tlb-map_address(env, physical, prot, address, rw,
access_type);
+ret = env-tlb-map_address(env, physical, prot, real_address,
rw, access_type);
} else {
ret = TLBRET_BADADDR;
}
@@ -161,7 +180,7 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
/* xkseg */
if (kernel_mode KX
address = (0x7FFFULL env-SEGMask)) {
-ret = env-tlb-map_address(env, physical, prot, address, rw,
access_type);
+ret = env-tlb-map_address(env, physical, prot, real_address,
rw, access_type);
} else {
ret = TLBRET_BADADDR;
}
@@ -185,7 +204,7 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
} else if (address (int32_t)KSEG3_BASE) {
/* sseg (kseg2) */
if (supervisor_mode || kernel_mode) {
-ret = env-tlb-map_address(env, physical, prot, address, rw,
access_type);
+ret = env-tlb-map_address(env, physical, prot, real_address,
rw, access_type);
} else {
ret = TLBRET_BADADDR;
}
@@ -193,7 +212,7 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
/* kseg3 */
/* XXX: debug segment is not emulated */
if (kernel_mode) {
-ret = env-tlb-map_address(env, physical, prot, address, rw
Re: [PATCH v2 02/10] hw/mips: Add API to convert KVM guest KSEG0 - GPA
On Mon, Dec 16, 2013 at 02:12:37PM +, James Hogan wrote:
From: Sanjay Lal sanj...@kymasys.com
Add APIs for converting between KVM guest KSEG0 addresses and guest
physical addresses. These will be used for translating addresses when
loading a kernel ELF in KVM mode.
In KVM trap and emulate mode both the guest kernel and guest userspace
execute in useg:
Guest User address space: 0x..0x3fff
Guest Kernel Unmapped: 0x4000..0x5fff
Guest Kernel Mapped:0x6000..0x7fff
Signed-off-by: Sanjay Lal sanj...@kymasys.com
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
---
Changes in v2:
- Expand commit message
- Remove unnecessary include
---
hw/mips/addr.c| 10 ++
include/hw/mips/cpudevs.h | 4
2 files changed, 14 insertions(+)
diff --git a/hw/mips/addr.c b/hw/mips/addr.c
index 99488f1..e62d6f4 100644
--- a/hw/mips/addr.c
+++ b/hw/mips/addr.c
@@ -28,7 +28,17 @@ uint64_t cpu_mips_kseg0_to_phys(void *opaque, uint64_t
addr)
return addr 0x7fffll;
}
+uint64_t cpu_mips_kvm_um_kseg0_to_phys(void *opaque, uint64_t addr)
+{
+return addr 0x3fffll;
+}
+
uint64_t cpu_mips_phys_to_kseg0(void *opaque, uint64_t addr)
{
return addr | ~0x7fffll;
}
+
+uint64_t cpu_mips_kvm_um_phys_to_kseg0(void *opaque, uint64_t addr)
+{
+return addr | 0x4000ll;
+}
diff --git a/include/hw/mips/cpudevs.h b/include/hw/mips/cpudevs.h
index 6bea24b..9e5af37 100644
--- a/include/hw/mips/cpudevs.h
+++ b/include/hw/mips/cpudevs.h
@@ -6,6 +6,10 @@
uint64_t cpu_mips_kseg0_to_phys(void *opaque, uint64_t addr);
uint64_t cpu_mips_phys_to_kseg0(void *opaque, uint64_t addr);
+uint64_t cpu_mips_kvm_um_kseg0_to_phys(void *opaque, uint64_t addr);
+uint64_t cpu_mips_kvm_um_phys_to_kseg0(void *opaque, uint64_t addr);
+
+
/* mips_int.c */
void cpu_mips_irq_init_cpu(CPUMIPSState *env);
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/10] target-mips: Set target page size to 16K in KVM mode
On Mon, Dec 16, 2013 at 02:12:41PM +, James Hogan wrote: From: Sanjay Lal sanj...@kymasys.com With larger set associative caches KVM can open the possibility of cache aliasing between the memory that QEMU allocates with mmap and the mapping into the guest address space. Therefore increase the target page size to 16K when KVM is configured. Signed-off-by: Sanjay Lal sanj...@kymasys.com Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Aurelien Jarno aurel...@aurel32.net --- Changes in v2: - Expand commit message --- target-mips/mips-defs.h | 5 + 1 file changed, 5 insertions(+) diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h index bf094a3..473ddf8 100644 --- a/target-mips/mips-defs.h +++ b/target-mips/mips-defs.h @@ -5,7 +5,12 @@ //#define USE_HOST_FLOAT_REGS /* Real pages are variable size... */ +#ifdef CONFIG_KVM +/* For KVM/MIPS the minimum page size is 16K due to cache aliasing issues */ +#define TARGET_PAGE_BITS 14 +#else #define TARGET_PAGE_BITS 12 +#endif #define MIPS_TLB_MAX 128 #if defined(TARGET_MIPS64) I am not sure it is something correct. It means that the emulated CPU won't support 4K pages anymore, even when running in TCG mode without KVM. If the kernel maps a 4K page, in practice a 16K page is going to be mapped by the qemu tlb. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/10] kvm: Set sigmask length to 16 for MIPS targets
On Mon, Dec 16, 2013 at 02:12:40PM +, James Hogan wrote: From: Sanjay Lal sanj...@kymasys.com MIPS/Linux is unusual in having 128 signals rather than just 64 like most other architectures. This means its sigmask is 16 bytes instead of 8, so correct kvm_set_signal_mask to pass the correct sigmask-len to KVM_SET_SIGNAL_MASK. Signed-off-by: Sanjay Lal sanj...@kymasys.com Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Gleb Natapov g...@redhat.com Cc: Paolo Bonzini pbonz...@redhat.com --- Changes in v2: - Expand commit message - Reword comment --- kvm-all.c | 5 + 1 file changed, 5 insertions(+) diff --git a/kvm-all.c b/kvm-all.c index 4478969..c831326 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -2044,7 +2044,12 @@ int kvm_set_signal_mask(CPUState *cpu, const sigset_t *sigset) sigmask = g_malloc(sizeof(*sigmask) + sizeof(*sigset)); +#ifdef TARGET_MIPS +/* MIPS has 128 signals */ +sigmask-len = 16; +#else sigmask-len = 8; +#endif memcpy(sigmask-sigset, sigset, sizeof(*sigset)); r = kvm_vcpu_ioctl(cpu, KVM_SET_SIGNAL_MASK, sigmask); g_free(sigmask); Reviewed-by: Aurelien Jarno aurel...@aurel32.net -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/10] target-mips: get_physical_address: Add defines for segment bases
On Mon, Dec 16, 2013 at 02:12:38PM +, James Hogan wrote:
Add preprocessor definitions for 32bit segment bases for use in
get_physical_address(). These will also be taken advantage of in the
next patch which adds KVM awareness.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
---
target-mips/helper.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 33e0e88..2e96655 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -118,7 +118,13 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
qemu_log(user mode %d h %08x\n, user_mode, env-hflags);
#endif
-if (address = (int32_t)0x7FFFUL) {
+#define USEG_LIMIT 0x7FFFUL
+#define KSEG0_BASE 0x8000UL
+#define KSEG1_BASE 0xA000UL
+#define KSEG2_BASE 0xC000UL
+#define KSEG3_BASE 0xE000UL
+
+if (address = USEG_LIMIT) {
/* useg */
if (env-CP0_Status (1 CP0St_ERL)) {
*physical = address 0x;
@@ -160,23 +166,23 @@ static int get_physical_address (CPUMIPSState *env,
hwaddr *physical,
ret = TLBRET_BADADDR;
}
#endif
-} else if (address (int32_t)0xA000UL) {
+} else if (address (int32_t)KSEG1_BASE) {
/* kseg0 */
if (kernel_mode) {
-*physical = address - (int32_t)0x8000UL;
+*physical = address - (int32_t)KSEG0_BASE;
*prot = PAGE_READ | PAGE_WRITE;
} else {
ret = TLBRET_BADADDR;
}
-} else if (address (int32_t)0xC000UL) {
+} else if (address (int32_t)KSEG2_BASE) {
/* kseg1 */
if (kernel_mode) {
-*physical = address - (int32_t)0xA000UL;
+*physical = address - (int32_t)KSEG1_BASE;
*prot = PAGE_READ | PAGE_WRITE;
} else {
ret = TLBRET_BADADDR;
}
-} else if (address (int32_t)0xE000UL) {
+} else if (address (int32_t)KSEG3_BASE) {
/* sseg (kseg2) */
if (supervisor_mode || kernel_mode) {
ret = env-tlb-map_address(env, physical, prot, address, rw,
access_type);
Reviewed-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] target-mips: kvm: Add main KVM support for MIPS
On Mon, Dec 16, 2013 at 02:12:42PM +, James Hogan wrote:
From: Sanjay Lal sanj...@kymasys.com
Implement the main KVM arch API for MIPS.
Signed-off-by: Sanjay Lal sanj...@kymasys.com
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: Gleb Natapov g...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com
---
Changes in v2:
- Expand commit message
- Checkpatch cleanups.
- Some interrupt bug fixes from Yann Le Du l...@kymasys.com
- Add get/set register functionality from Yann Le Du l...@kymasys.com
- Use new 64 bit compatible ABI from Cavium from Sanjay Lal
sanj...@kymasys.com
- Add dummy kvm_arch_init_irq_routing()
The common KVM code insists on calling kvm_arch_init_irq_routing() as
soon as it sees kernel header support for it (regardless of whether
QEMU supports it). Provide a dummy function to satisfy this.
- Remove request_interrupt_window code (Peter Maydell)
---
target-mips/kvm.c | 463
+
target-mips/kvm_mips.h | 28 +++
2 files changed, 491 insertions(+)
create mode 100644 target-mips/kvm.c
create mode 100644 target-mips/kvm_mips.h
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
new file mode 100644
index 000..951959b
--- /dev/null
+++ b/target-mips/kvm.c
@@ -0,0 +1,463 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * KVM/MIPS: MIPS specific KVM APIs
+ *
+ * Copyright (C) 2012-2013 Imagination Technologies Ltd.
+ * Authors: Sanjay Lal sanj...@kymasys.com
+*/
+
+#include sys/types.h
+#include sys/ioctl.h
+#include sys/mman.h
+
+#include linux/kvm.h
+
+#include qemu-common.h
+#include qemu/timer.h
+#include sysemu/sysemu.h
+#include sysemu/kvm.h
+#include cpu.h
+#include sysemu/cpus.h
+#include kvm_mips.h
+
+#define DEBUG_KVM 0
+
+#define dprintf(fmt, ...) \
+do { if (DEBUG_KVM) { fprintf(stderr, fmt, ## __VA_ARGS__); } } while (0)
+
+const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
+KVM_CAP_LAST_INFO
+};
+
+unsigned long kvm_arch_vcpu_id(CPUState *cpu)
+{
+return cpu-cpu_index;
+}
+
+int kvm_arch_init(KVMState *s)
+{
+dprintf(%s\n, __func__);
+return 0;
+}
+
+int kvm_arch_init_vcpu(CPUState *env)
+{
+int ret = 0;
+dprintf(%s\n, __func__);
+return ret;
+}
+
+void kvm_arch_reset_vcpu(CPUState *env)
+{
+dprintf(%s\n, __func__);
+}
+
+int kvm_arch_put_registers(CPUState *cs, int level)
+{
+MIPSCPU *cpu = MIPS_CPU(cs);
+CPUMIPSState *env = cpu-env;
+struct kvm_regs regs;
+int ret;
+int i;
+
+/* Set the registers based on QEMU's view of things */
+for (i = 0; i 32; i++) {
+regs.gpr[i] = env-active_tc.gpr[i];
+}
+
+regs.hi = env-active_tc.HI[0];
+regs.lo = env-active_tc.LO[0];
+regs.pc = env-active_tc.PC;
+
+ret = kvm_vcpu_ioctl(cs, KVM_SET_REGS, regs);
+
+if (ret 0) {
+return ret;
+}
+
+ret = kvm_mips_te_put_cp0_registers(cs, KVM_PUT_FULL_STATE);
+if (ret 0) {
+return ret;
+}
+
+return ret;
+}
+
+int kvm_arch_get_registers(CPUState *cs)
+{
+MIPSCPU *cpu = MIPS_CPU(cs);
+CPUMIPSState *env = cpu-env;
+int ret = 0;
+struct kvm_regs regs;
+int i;
+
+/* Get the current register set as KVM seems it */
+ret = kvm_vcpu_ioctl(cs, KVM_GET_REGS, regs);
+
+if (ret 0) {
+return ret;
+}
+
+for (i = 0; i 32; i++) {
+env-active_tc.gpr[i] = regs.gpr[i];
+}
+
+env-active_tc.HI[0] = regs.hi;
+env-active_tc.LO[0] = regs.lo;
+env-active_tc.PC = regs.pc;
+
+kvm_mips_te_get_cp0_registers(cs);
+
+return ret;
+}
+
+int kvm_arch_insert_sw_breakpoint(CPUState *env, struct kvm_sw_breakpoint
*bp)
+{
+dprintf(%s\n, __func__);
+return 0;
+}
+
+int kvm_arch_remove_sw_breakpoint(CPUState *env, struct kvm_sw_breakpoint
*bp)
+{
+dprintf(%s\n, __func__);
+return 0;
+}
+
+static inline int cpu_mips_io_interrupts_pending(CPUArchState *env)
+{
+dprintf(%s: %#x\n, __func__, env-CP0_Cause (1 (2 + CP0Ca_IP)));
+return env-CP0_Cause (0x1 (2 + CP0Ca_IP));
+}
+
+
+void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
+{
+MIPSCPU *cpu = MIPS_CPU(cs);
+CPUMIPSState *env = cpu-env;
+int r;
+struct kvm_mips_interrupt intr;
+
+if ((cs-interrupt_request CPU_INTERRUPT_HARD)
+(cpu_mips_io_interrupts_pending(env))) {
+intr.cpu = -1;
+intr.irq = 2;
+r = kvm_vcpu_ioctl(cs, KVM_INTERRUPT, intr);
+if (r 0) {
+printf(cpu %d fail inject %x\n, cs-cpu_index, intr.irq);
+}
+}
+}
+
+void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
+{
+dprintf(%s\n
Re: virtio-rng only returns zeros with CONFIG_HW_RANDOM=m
On Wed, Feb 27, 2013 at 10:43:37AM +1030, Rusty Russell wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Hi,
I have noticed that virtio-rng only returns zero for kernels = 2.6.33
built with CONFIG_HW_RANDOM=m. This is a bit much too predictable for a
random generator ;-).
Wow. Fortunately, all of SLES, RHEL, Ubuntu or Fedora set
CONFIG_HW_RANDOM=y. What do they know that we don't?
Oops, looks like Debian testing: config-3.2.0-4-amd64:CONFIG_HW_RANDOM=m
The reason for that is virtio expects guest real addresses, while
rng_core.ko (ie when built as a module) is passing a vmalloced buffer
to the virtio-rng read function, declared as such:
static u8 rng_buffer[SMP_CACHE_BYTES 32 ? 32 : SMP_CACHE_BYTES]
__cacheline_aligned;
Yuck... It would be nice if this has oopsed. Jens, what about this patch?
Cheers,
Rusty.
Subject: scatterlist: sg_set_buf() argument must be in linear mapping.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 4bd6c06..9365375 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -111,6 +111,9 @@ static inline struct page *sg_page(struct scatterlist *sg)
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
unsigned int buflen)
{
+#ifdef CONFIG_DEBUG_SG
+ BUG_ON(!virt_addr_valid(buf));
+#endif
sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
}
I confirm this patch catches the issue. Thanks.
Tested-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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: virtio-rng only returns zeros with CONFIG_HW_RANDOM=m
On Wed, Feb 27, 2013 at 11:56:55AM +1030, Rusty Russell wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Hi,
I have noticed that virtio-rng only returns zero for kernels = 2.6.33
built with CONFIG_HW_RANDOM=m. This is a bit much too predictable for a
random generator ;-).
The reason for that is virtio expects guest real addresses, while
rng_core.ko (ie when built as a module) is passing a vmalloced buffer
to the virtio-rng read function, declared as such:
static u8 rng_buffer[SMP_CACHE_BYTES 32 ? 32 : SMP_CACHE_BYTES]
__cacheline_aligned;
This is basically the same issue than the following one:
https://lists.linux-foundation.org/pipermail/virtualization/2008-May/010946.html
but introduced in a more subtle way in this commit:
commit bb347d98079a547e80bd4722dee1de61e4dca0e8
Author: Ian Molton ian.mol...@collabora.co.uk
Date: Tue Dec 1 15:26:33 2009 +0800
OK, I looked at doing a kmalloc and copy in virtio_rng, but it's very
inelegant (we don't know what size of buffer to allocate).
On the other hand, the rng API allows to return less bytes than
requested, so it's possible to have a fixed buffer size of for example
64 or 128 bytes. But I agree it's better to do that in rng core.
No driver other than virtio_rng cares about this issue, but it's still
far easier to fix in the core.
How's this? Works here...
Subject: hw_random: make buffer usable in scatterlist.
virtio_rng feeds the randomness buffer handed by the core directly
into the scatterlist, since commit bb347d98079a547e80bd4722dee1de61e4dca0e8.
However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
(at least on most archs). We could fix this in virtio_rng, but it's actually
far easier to just do it in the core as virtio_rng would have to allocate
a buffer every time (it doesn't know how much the core will want to read).
Reported-by: Aurelien Jarno aurel...@aurel32.net
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 1bafb40..69ae597 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -40,6 +40,7 @@
#include linux/init.h
#include linux/miscdevice.h
#include linux/delay.h
+#include linux/slab.h
#include asm/uaccess.h
@@ -52,8 +53,12 @@ static struct hwrng *current_rng;
static LIST_HEAD(rng_list);
static DEFINE_MUTEX(rng_mutex);
static int data_avail;
-static u8 rng_buffer[SMP_CACHE_BYTES 32 ? 32 : SMP_CACHE_BYTES]
- __cacheline_aligned;
+static u8 *rng_buffer;
+
+static size_t rng_buffer_size(void)
+{
+ return SMP_CACHE_BYTES 32 ? 32 : SMP_CACHE_BYTES;
+}
static inline int hwrng_init(struct hwrng *rng)
{
@@ -116,7 +121,7 @@ static ssize_t rng_dev_read(struct file *filp, char
__user *buf,
if (!data_avail) {
bytes_read = rng_get_data(current_rng, rng_buffer,
- sizeof(rng_buffer),
+ rng_buffer_size(),
!(filp-f_flags O_NONBLOCK));
if (bytes_read 0) {
err = bytes_read;
@@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
mutex_lock(rng_mutex);
+ /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
+ err = -ENOMEM;
+ if (!rng_buffer) {
+ rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_buffer)
+ goto out_unlock;
+ }
+
/* Must not register two RNGs with the same name. */
err = -EEXIST;
list_for_each_entry(tmp, rng_list, list) {
It works fine for me. Thanks for the patch.
Tested-by: Aurelien Jarno aurel...@aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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
virtio-rng only returns zeros with CONFIG_HW_RANDOM=m
Hi, I have noticed that virtio-rng only returns zero for kernels = 2.6.33 built with CONFIG_HW_RANDOM=m. This is a bit much too predictable for a random generator ;-). The reason for that is virtio expects guest real addresses, while rng_core.ko (ie when built as a module) is passing a vmalloced buffer to the virtio-rng read function, declared as such: static u8 rng_buffer[SMP_CACHE_BYTES 32 ? 32 : SMP_CACHE_BYTES] __cacheline_aligned; This is basically the same issue than the following one: https://lists.linux-foundation.org/pipermail/virtualization/2008-May/010946.html but introduced in a more subtle way in this commit: commit bb347d98079a547e80bd4722dee1de61e4dca0e8 Author: Ian Molton ian.mol...@collabora.co.uk Date: Tue Dec 1 15:26:33 2009 +0800 hwrng: virtio-rng - Convert to new API This patch converts virtio-rng to the new hw_rng API. In the process it fixes a previously untriggered buffering bug where the buffer is not drained correctly if it has a non-multiple-of-4 length. Performance has improved under qemu-kvm testing also. Signed-off-by: Ian Molton ian.mol...@collabora.co.uk Acked-by: Matt Mackall m...@selenic.com Acked-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Herbert Xu herb...@gondor.apana.org.au I basically see three possible way of fixing that: - prevent rng_core to be built as a module; - use an intermediary kmalloced buffer in virtio-rng passed to virtio functions, followed by a memcpy to get the data in the rng core buffer; - use a kmalloc buffer in rng_core instead of vmalloc one. What would be best way to fix that? Did I miss another way? Thanks, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [patch 2/6] Use machine options to emulate -no-kvm-irqchip
On Wed, Oct 03, 2012 at 07:52:57AM -0300, Marcelo Tosatti wrote:
Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git.
From: Jan Kiszka jan.kis...@siemens.com
Upstream is moving towards this mechanism, so start using it in qemu-kvm
already to configure the specific defaults: kvm enabled on, just like
in-kernel irqchips.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu-compat-kvm/vl.c
===
--- qemu-compat-kvm.orig/vl.c
+++ qemu-compat-kvm/vl.c
@@ -3061,6 +3061,12 @@ int main(int argc, char **argv, char **e
machine = machine_parse(optarg);
}
break;
+case QEMU_OPTION_no_kvm_irqchip: {
+olist = qemu_find_opts(machine);
+qemu_opts_parse(olist, kernel_irqchip=off, 0);
+break;
+}
+
case QEMU_OPTION_usb:
usb_enabled = 1;
break;
Index: qemu-compat-kvm/qemu-options.hx
===
--- qemu-compat-kvm.orig/qemu-options.hx
+++ qemu-compat-kvm/qemu-options.hx
@@ -2838,6 +2838,10 @@ STEXI
Enable FIPS 140-2 compliance mode.
ETEXI
+DEF(no-kvm-irqchip, 0, QEMU_OPTION_no_kvm_irqchip,
+-no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC\n,
+QEMU_ARCH_I386)
+
HXCOMM This is the last statement. Insert new options before this line!
STEXI
@end table
As far as I understand, this option was not in QEMU, because this syntax
is considered as deprecated. Can we also add an output a warning message
in that case?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] kvm: Set default accelerator to kvm if the host supports it
On Tue, Oct 02, 2012 at 09:46:12AM +0200, Markus Armbruster wrote: Daniel P. Berrange berra...@redhat.com writes: On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote: Hello Jan, Am 01.10.2012 16:34, schrieb Jan Kiszka: If we built a target for a host that supports KVM in principle, set the default accelerator to KVM as well. This also means the start of QEMU will fail to start if KVM support turns out to be unavailable at runtime. From a distro point of view this of course means that we will build against KVM and that the new KVM default will start to fail for users on very old hardware. Can't we do a runtime check to select the default? NB, this is *not* only about old hardware. There are plenty of users who use QEMU inside VMs. One very common usage I know of is image building tools which are run inside Amazon VMs, using libguestfs QEMU. IMHO, default to KVM, fallback to TCG is the most friendly default behaviour. Friendly perhaps, generating an infinite series of questions why is my guest slow as molasses? certainly. And for each instance of the question, there's an unknown number of users who give QEMU a quick try, screw up KVM unknowingly, observe the glacial speed, and conclude it's crap. That's why it should not fallback silently to TCG, but warn the user about that. On the other hand, on a machine without KVM support (which might just be because of local policy admin policy which doesn't provide access the /dev/kvm, nested virtualization, etc.), if QEMU fails to start (while previous versions were working), the user can conclude that QEMU is crap. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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: Set default accelerator to kvm if the host supports it
On Mon, Oct 01, 2012 at 11:20:41AM -0500, Anthony Liguori wrote:
Jan Kiszka jan.kis...@siemens.com writes:
If we built a target for a host that supports KVM in principle, set the
default accelerator to KVM as well. This also means the start of QEMU
will fail to start if KVM support turns out to be unavailable at
runtime.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c |1 +
kvm-stub.c |1 +
kvm.h |1 +
vl.c |4 ++--
4 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 92a7137..4d5f86c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -103,6 +103,7 @@ struct KVMState
#endif
};
+bool kvm_configured = true;
KVMState *kvm_state;
bool kvm_kernel_irqchip;
bool kvm_async_interrupts_allowed;
diff --git a/kvm-stub.c b/kvm-stub.c
index 3c52eb5..86a6451 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -17,6 +17,7 @@
#include gdbstub.h
#include kvm.h
+bool kvm_configured;
KVMState *kvm_state;
bool kvm_kernel_irqchip;
bool kvm_async_interrupts_allowed;
diff --git a/kvm.h b/kvm.h
index dea2998..9936e5f 100644
--- a/kvm.h
+++ b/kvm.h
@@ -22,6 +22,7 @@
#include linux/kvm.h
#endif
+extern bool kvm_configured;
extern int kvm_allowed;
extern bool kvm_kernel_irqchip;
extern bool kvm_async_interrupts_allowed;
diff --git a/vl.c b/vl.c
index 8d305ca..f557bd1 100644
--- a/vl.c
+++ b/vl.c
@@ -2215,8 +2215,8 @@ static int configure_accelerator(void)
}
if (p == NULL) {
-/* Use the default accelerator, tcg */
-p = tcg;
+/* The default accelerator depends on the availability of KVM. */
+p = kvm_configured ? kvm : tcg;
}
How about making this an arch_init() function call and then using a #if
defined(KVM_CONFIG) in arch_init.c?
I hate to introduce another global variable if we can avoid it...
Otherwise:
Acked-by: Anthony Liguori aligu...@us.ibm.com
Blue/Aurelien, any objections?
I am not sure this way of doing is really distribution friendly, where
the QEMU package is built for a large variety of hosts, some of them
maybe without KVM support.
I am all for enabling KVM by default, but I think it should fall back to
TCG if it is not enabled (probably with a warning so that the user is
aware of that). On the other hand, if the user explicitly enables KVM
support with -enable-kvm or with accel=kvm, it should fail to start. In
other words, a bit like the configure script options, by default we
use auto-detection, but if an option is explicitly enabled, it fails if
it can't be enabled.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 22/23] x86: Fix MCA broadcast parameters for TCG case
On Fri, Feb 04, 2011 at 01:47:25PM -0200, Marcelo Tosatti wrote:
From: Jan Kiszka jan.kis...@web.de
When broadcasting MCEs, we need to set MCIP and RIPV in mcg_status like
it is done for KVM. Use the symbolic constants at this chance.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
target-i386/helper.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
I don't feel very comfortable about this whole series (not in my
knowledge area), but as nobody else seems to care about 32-bit support,
I have committed this patch to master and the stable-0.14 tree.
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 1217452..f0c546d 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1147,8 +1147,8 @@ void cpu_inject_x86_mce(CPUState *cenv, int bank,
uint64_t status,
if (cenv == env) {
continue;
}
-
-qemu_inject_x86_mce(env, 1, 0xa000, 0, 0, 0);
+qemu_inject_x86_mce(env, 1, MCI_STATUS_VAL | MCI_STATUS_UC,
+MCG_STATUS_MCIP | MCG_STATUS_RIPV, 0, 0);
}
}
}
--
1.7.2.3
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote: Chris Wright chr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. For those oddball machines, qdev doesn't really bring anything, that's why there is so little interest in converting them, and why I prefer to spend my time on the emulation correctness than converting those remaining to qdev. Of course I agree it's something to do, and with an unlimited amount of free time, I'll do them immediately. Let's take for example the SH4 target. It's nice to be able to create the whole machine from a script, except your kernel won't boot if the machine: - has a different cpu - doesn't a SM501 chipset - has not the correct memory size - doesn't have 2 serial port That basically only leaves the PCI and USB devices configurable, but those are already using qdev. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
Luiz Capitulino a écrit : On Mon, 24 Jan 2011 16:06:34 -0600 Anthony Liguori anth...@codemonkey.ws wrote: On 01/24/2011 07:25 AM, Chris Wright wrote: Please send in any agenda items you are interested in covering. - coroutines for the block layer - glib everywhere - Let's start planning our next release in advance, here's a simple example: http://wiki.qemu.org/Planning/0.15-example What about planning the 0.14 release first? From what I see on the mailing list, we are more in a development phase than in a bug fix phase before a release. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
On Tue, Jan 25, 2011 at 03:42:04PM +0100, Kevin Wolf wrote: Am 25.01.2011 15:11, schrieb Aurelien Jarno: Luiz Capitulino a écrit : On Mon, 24 Jan 2011 16:06:34 -0600 Anthony Liguori anth...@codemonkey.ws wrote: On 01/24/2011 07:25 AM, Chris Wright wrote: Please send in any agenda items you are interested in covering. - coroutines for the block layer - glib everywhere - Let's start planning our next release in advance, here's a simple example: http://wiki.qemu.org/Planning/0.15-example What about planning the 0.14 release first? From what I see on the mailing list, we are more in a development phase than in a bug fix phase before a release. If we want to get into a bug fix phase, all we need to have is a stable-0.14 branch. It's not like creating a branch is a lot of work, it just didn't happen on the announced date. Agreed. That said when you see the branch date approaching you already focus more on identifying and fixing bugs than on new features, that's human. For example after seeing the mail from Anthony I started to test the main TCG targets (actually 8 of them) on the main supported hosts (7 of them if you count endianness). That's quite a lot of work that has been quite useful, that said given the number of patches that have been committed in the meanwhile, it's probably something to redo. And I'm almost sure that when it happens, it's going to come as a surprise once again... If we decide on a date in advance, it's something I can easily do if Anthony or someone else is busy. We just have to agree on that before. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for July 20
It's a pitty I can't easily attend to this conference call, as it seems a lot of decisions are taken there. Anyway let me comment the part concerning 0.12 stable: On Tue, Jul 20, 2010 at 07:45:51AM -0700, Chris Wright wrote: 0.12.stable - start w/ git tree + pull requests - release process is separate from commit access - justin will put up a tree for pull requests - there's current backlog, what about that? I think someone should actively follow the patches committed to HEAD and backport them when they seems to be stable material. I guess it's what's Justin plans to do. OTOH, it might be useful if people sending patches to HEAD adds a small comment about cherry-picking the patch to stable if it applies. - anthony's concern with -stable is the testing (upstream tree gets more testing than -stable) Debian gets regular uploads with the contents of the -stable tree between to releases. Also patches from trunk are all cherry-picked from HEAD. - 0.12.5? - planning to do next w/ 0.13 release - aurelien may cut a release Following the minutes from last week, I sent a call for release, with a deadline today. I only got the patch series from Kevin. There are currently 44 patches waiting in the stable tree, so I guess we can go for a release. I plan to do that later this week if nobody opposes. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
On Thu, Jul 15, 2010 at 01:43:28PM -0500, Justin M. Forbes wrote: On Tue, Jul 13, 2010 at 12:19:21PM -0500, Brian Jackson wrote: On Tuesday, July 13, 2010 12:01:22 pm Avi Kivity wrote: On 07/13/2010 07:57 PM, Anthony Liguori wrote: I'd like to see more frequent stable releases, at least if the stable branch contains fixes to user-reported bugs (or of course security or data integrity fixes). Would you like to see more frequent stable releases or more frequent master releases? Yes. But in this context I'm interested in stable releases. We have bugs reported, fixed, and the fix applied, yet the fixes are unreachable to users. Especially so since qemu-kvm 0.12-stable hasn't been merged with qemu basically since 0.12.4 came out. I was trying to help one of the Gentoo maintainers find post 0.12.4 patches the other day and had to point them to the upstream qemu stable tree. I have offered to take care of this, but so far I do not have commit access. You don't necessarily need commit access for that. Just create your own tree with backported patches, and then send a stable pull request to the mailing list. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM Call agenda for July 13th
Avi Kivity a écrit : On 07/12/2010 05:57 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.12.n+1 I won't be at the KVM call, but I can work on that in the next days. Basically the stable tree already contains a lot of fixes and we can do a call for patches for this release. One week should be enough, so that we can have the release at the end of next week (a few technical days are needed in addition). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Add QMP/qmp-commands.txt to .gitignore
On Thu, Jul 01, 2010 at 12:30:23PM +0900, Hidetoshi Seto wrote: QMP/qmp-commands.txt is a generated file. Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com --- .gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Thanks, applied. diff --git a/.gitignore b/.gitignore index ce66ed5..a32b7c4 100644 --- a/.gitignore +++ b/.gitignore @@ -28,6 +28,7 @@ qemu-img-cmds.texi qemu-img-cmds.h qemu-io qemu-monitor.texi +QMP/qmp-commands.txt .gdbinit *.a *.aux -- 1.7.0 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] QEMU: Update .gitignore
On Mon, Jun 21, 2010 at 06:14:17PM +0900, Hidetoshi Seto wrote: (2010/06/21 17:19), Avi Kivity wrote: On 06/21/2010 08:24 AM, Hidetoshi Seto wrote: I think some people have noticed that: $ ./configure $ make $ git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # QMP/qmp-commands.txt # libdis-user/ # libdis/ # pc-bios/optionrom/vapic.bin nothing added to commit but untracked files present (use git add to track) Please consider applying this patch to qemu-kvm.git. This is equally applicable to qemu.git, so please sent it to the qemu mailing list, qemu-de...@nongnu.org. Thanks for your advice, Avi. Now this mail is sent to qemu ML, w/ above quotes as short history. Could someone pick this up? Thanks, H.Seto = This patch looks good, but doesn't apply anymore, as the libdis/ and libdis-user/ part has already been applied from another patch. Care to resend it? Subject: [PATCH] QEMU: Update .gitignore Add some files/directories to .gitignore - vapic.bin A generated binary file. - libdis/ and libdis-user/ These are directories generated by ./configure. - QMP/qmp-commands.txt A generated text. Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com --- .gitignore |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 2d7f439..fa4f241 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,8 @@ config-target.* libhw32 libhw64 libuser +libdis +libdis-user qemu-doc.html qemu-tech.html qemu-doc.info @@ -26,6 +28,7 @@ qemu-img-cmds.texi qemu-img-cmds.h qemu-io qemu-monitor.texi +QMP/qmp-commands.txt .gdbinit *.a *.aux @@ -50,4 +53,5 @@ pc-bios/optionrom/linuxboot.bin pc-bios/optionrom/multiboot.bin pc-bios/optionrom/multiboot.raw pc-bios/optionrom/extboot.bin +pc-bios/optionrom/vapic.bin .stgit-* -- 1.7.0 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 15
On Tue, Jun 15, 2010 at 11:41:53AM -0400, Christoph Hellwig wrote: On Tue, Jun 15, 2010 at 08:18:12AM -0700, Chris Wright wrote: KVM/qemu patches - patch rate is high, documentation is low, review is low - patches need to include better descriptions and documentation - will slow down patch writers - will make it easier for patch reviewers What is the qemu patch review policy anyway? There are no Reviewed-by: included in the actual commits, and the requirement for a positive review also seem to vary a lot, up to the point that some commiters commit code that has never hit a public mailing list before. This is indeed something very useful that should be encouraged. Depending on the patch and the persons that have reviewed/acked it, I commit some patches only after a very quick look. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
On Tue, May 18, 2010 at 05:38:27PM -0500, Anthony Liguori wrote: Hi, In an effort to improve the 0.13 release quality, I'd like to host a Bug Day on June 1st, 2010. I've setup a quick wiki page with some more info (http://wiki.qemu.org/BugDay/June2010). Here's my basic thinking: - Anyone who can should try to spend some time either triaging bugs, updating bug status, or actually fixing bugs. - We'll have a special IRC channel (#qemu-bugday) on OFTC. As many QEMU and KVM developers as possible should join this channel for that day to help assist people working on bugs. - We'll try to migrate as many confirmable bugs from the Source Forge tracker to Launchpad. If this is successful, we'll try to have regular bug days. Any suggestions on how to make the experience as fun and productive as possible are certainly appreciated! The idea is nice, but would it be possible to hold this on a week-end, I personally won't be able to attend such thing on a day week. Or maybe holding that on two days: friday and saturday so that people can participate at least one of the two days, depending if they do that from work or from home. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
On Mon, Apr 26, 2010 at 10:15:58PM -0300, Luiz Capitulino wrote: On Mon, 26 Apr 2010 12:51:08 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 04/26/2010 12:26 PM, Chris Wright wrote: Please send in any agenda items you are interested in covering. While I don't expect it to be the case this week, if we have a lack of agenda items I'll cancel the week's call. - qemu management interface (and libvirt) - stable tree policy (push vs. pull and call for stable volunteers) What do you mean by push vs. pull? Anyway, Aurelien was working on a stable release last week, maybe he's interested in helping with the stables (or not :)). I didn't find the time to do the stable release, but we should be very close now. I am interested to have stable releases, but if someone else want to work on that, I am fine. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] qemu: jaso-parser: Output the content of invalid keyword
On Wed, Mar 24, 2010 at 11:12:05PM +0800, Amos Kong wrote:
When input some invialid word 'unknowcmd' through QMP port, qemu outputs this
error message:
parse error: invalid keyword `%s'
This patch makes qemu output the content of invalid keyword, like:
parse error: invalid keyword `unknowcmd'
Thanks, applied.
Signed-off-by: Amos Kong ak...@redhat.com
---
json-parser.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/json-parser.c b/json-parser.c
index 579928f..b55d763 100644
--- a/json-parser.c
+++ b/json-parser.c
@@ -12,6 +12,7 @@
*/
#include stdbool.h
+#include stdarg.h
#include qemu-common.h
#include qstring.h
@@ -93,7 +94,12 @@ static int token_is_escape(QObject *obj, const char *value)
*/
static void parse_error(JSONParserContext *ctxt, QObject *token, const char
*msg, ...)
{
-fprintf(stderr, parse error: %s\n, msg);
+va_list ap;
+va_start(ap, msg);
+fprintf(stderr, parse error: );
+vfprintf(stderr, msg, ap);
+fprintf(stderr, \n);
+va_end(ap);
}
/**
--
1.6.3.3
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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] qemu-kvm: jaso-parser: Output the content of invalid keyword
Hi,
On Wed, Mar 24, 2010 at 06:00:53PM +0800, Amos Kong wrote:
When input some invialid words in QMP port, qemu outputs this error message:
parse error: invalid keyword `%s'
This patch makes qemu output the content.
Is this patch for QEMU or KVM? If it is for QEMU, you should put the
QEMU mailing list in Cc:. If it is for KVM, I don't have commit access
there.
Signed-off-by: Amos Kong ak...@redhat.com
---
json-parser.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/json-parser.c b/json-parser.c
index 579928f..98a82af 100644
--- a/json-parser.c
+++ b/json-parser.c
@@ -12,6 +12,7 @@
*/
#include stdbool.h
+#include stdarg.h
#include qemu-common.h
#include qstring.h
@@ -93,7 +94,11 @@ static int token_is_escape(QObject *obj, const char *value)
*/
static void parse_error(JSONParserContext *ctxt, QObject *token, const char
*msg, ...)
{
-fprintf(stderr, parse error: %s\n, msg);
+va_list ap;
+va_start(ap, msg);
+fprintf(stderr, parse error:);
+vfprintf(stderr, msg, ap);
+fprintf(stderr, \n);
}
/**
--
1.6.3.3
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Fix segfault with ram_size 4095M without kvm
On Thu, Mar 04, 2010 at 03:34:34PM -0600, Ryan Harper wrote:
* Aurelien Jarno aurel...@aurel32.net [2010-03-04 15:27]:
On Tue, Feb 23, 2010 at 06:02:15PM +0100, Aurelien Jarno wrote:
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M
memsize.
This patch adds a simple check and error message (much like the 2047
limit on
32-bit hosts) on ram_size in the control path after we determine we're
not using kvm
Upstream qemu-kvm is affected if using the -no-kvm option; this patch
address
the segfault there as well.
It looks like workarounding the real bug. At some point both
i386-softmmu (via PAE) and x86_64-softmmu were able to support 4GB of
memory. I remember adding the support long time ago, and testing it with
32GB of emulated RAM.
I have looked into that, and actually one patch to get full support for
4GB of memory was not merged:
Thanks for looking into this.
diff --git a/exec.c b/exec.c
index 8389c54..b0bb058 100644
--- a/exec.c
+++ b/exec.c
@@ -166,7 +166,7 @@ typedef struct PhysPageDesc {
*/
#define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
#else
-#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS)
+#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
#endif
#define L1_SIZE (1 L1_BITS)
While this patch is acceptable for qemu i386, it creates a big L1 table
for x86_64 or other 64-bit architectures, resulting in huge memory
overhead.
The recent multilevel tables patches from Richard Henderson should fix
the problem for HEAD (I haven't found time to look at them in details).
As this is not something we really want to backport, your patch makes
sense in stable-0.12.
Anthony, do you want me to resend and rebase against 0.12-stable?
The patch applies correctly on stable-0.12. I have just applied it.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: pc-bios/bios.bin - where it comes from?
Anthony Liguori a écrit : On 03/04/2010 04:46 PM, Michael Tokarev wrote: Hello. There are a few bugs filed about an.. interesting behavour. For example: http://www.mail-archive.com/kvm@vger.kernel.org/msg29834.html https://bugs.launchpad.net/qemu/+bug/513273 After quite some mix-n-matching, at least on my test machine, I can say that the issue gets triggered by seabios. When using pc-bios/bios.bin everything is ok. But when using any other bios.bin, even downloading seabios-0.5.1.tar.gz and building it - on a debian lenny system anyway - by running `make', the problem triggers. I tried different versions/variations of vgabios.bin (it's only -vga std which triggers the issue so far), including 0.6b and 0.6c built from sources, vgabios.bin from debian packages (0.6b and 0.6c), and the one included in qemu-0.12.3.tar.gz. And my conclusion so far is that vgabios.bin has exactly _no_ effect on the issue. But when using bios.bin from qemu-kvm-0.12.3.tar.gz, and _only_ that bios.bin, the problem goes away. pc-bios/bios.bin gets built from roms/seabios. We don't ship seabios 0.5.1 in 0.12.3, we ship 0.5.1-stable which is two commits ahead of 0.5.1. So the question arises: where that pc-bios/bios.bin comes from into qemu-0.12.3.tar.gz? It is either built from some other sources (not from seabios-0.5.1), or built with some extra/different compiler/linker options, or built using different compiler/linker. This is partially confirmed on ubuntu as well, but, as far as I understand, there the behavour is different with different versions of vgabios. One of the reasons we include a git submodule and the source for the bios is so that distributors don't have to deal with building the packages independently. Morale of the story is, just use the source we ship and don't try to be more clever than that :-) This is exactly what distribution usually fight about: same code in different packages, but with subtle differences. If every software was like that, we would not have shared libraries anymore. This is a nightmare at different levels, and especially at security level. We should probably interact more with the maintainers of the various BIOS package (that could mean synced release), in order to avoid this kind of problem. Of course it doesn't mean we should not provide the BIOS sources in QEMU. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Fix segfault with ram_size 4095M without kvm
On Tue, Feb 23, 2010 at 06:02:15PM +0100, Aurelien Jarno wrote:
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit
on
32-bit hosts) on ram_size in the control path after we determine we're
not using kvm
Upstream qemu-kvm is affected if using the -no-kvm option; this patch
address
the segfault there as well.
It looks like workarounding the real bug. At some point both
i386-softmmu (via PAE) and x86_64-softmmu were able to support 4GB of
memory. I remember adding the support long time ago, and testing it with
32GB of emulated RAM.
I have looked into that, and actually one patch to get full support for
4GB of memory was not merged:
diff --git a/exec.c b/exec.c
index 8389c54..b0bb058 100644
--- a/exec.c
+++ b/exec.c
@@ -166,7 +166,7 @@ typedef struct PhysPageDesc {
*/
#define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
#else
-#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS)
+#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
#endif
#define L1_SIZE (1 L1_BITS)
While this patch is acceptable for qemu i386, it creates a big L1 table
for x86_64 or other 64-bit architectures, resulting in huge memory
overhead.
The recent multilevel tables patches from Richard Henderson should fix
the problem for HEAD (I haven't found time to look at them in details).
As this is not something we really want to backport, your patch makes
sense in stable-0.12.
Signed-off-by: Ryan Harper ry...@us.ibm.com
---
vl.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index db7a178..a659e98 100644
--- a/vl.c
+++ b/vl.c
@@ -5760,6 +5760,12 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, failed to initialize KVM\n);
exit(1);
}
+} else {
+/* without kvm enabled, we can only support 4095 MB RAM */
+if (ram_size (4095UL 20)) {
+fprintf(stderr, qemu: without kvm support at most 4095 MB RAM
can be simulated\n);
+exit(1);
+}
}
if (qemu_init_main_loop()) {
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Fix segfault with ram_size 4095M without kvm
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit on
32-bit hosts) on ram_size in the control path after we determine we're
not using kvm
Upstream qemu-kvm is affected if using the -no-kvm option; this patch address
the segfault there as well.
It looks like workarounding the real bug. At some point both
i386-softmmu (via PAE) and x86_64-softmmu were able to support 4GB of
memory. I remember adding the support long time ago, and testing it with
32GB of emulated RAM.
Signed-off-by: Ryan Harper ry...@us.ibm.com
---
vl.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index db7a178..a659e98 100644
--- a/vl.c
+++ b/vl.c
@@ -5760,6 +5760,12 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, failed to initialize KVM\n);
exit(1);
}
+} else {
+/* without kvm enabled, we can only support 4095 MB RAM */
+if (ram_size (4095UL 20)) {
+fprintf(stderr, qemu: without kvm support at most 4095 MB RAM
can be simulated\n);
+exit(1);
+}
}
if (qemu_init_main_loop()) {
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Fix segfault with ram_size 4095M without kvm
On Tue, Feb 23, 2010 at 03:07:20PM -0600, Anthony Liguori wrote: On 02/23/2010 02:30 PM, Alexander Graf wrote: On 23.02.2010, at 18:02, Aurelien Jarno wrote: Ryan Harper a écrit : Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well. It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM. Sounds like a perfect candidate for -stable then. For HEAD I agree that finding the cause would be the way to go. No, it's wrong. A good candidate for -stable would be something that fixes the SEGV :-) It actually depends on the patch and how invasive it is. I'll bisect that later this week. For now what I can say it hasn't worked for a lot of time. It works in 0.9.1, but not in 0.10.0. It probably hasn't been noticed due to kqemu which was limiting the size to 2GB. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [trivial patch] Add missing newline at the end of options list
On Thu, Dec 24, 2009 at 12:15:47PM +0300, Michael Tokarev wrote: In qemu-kvm this place looks even more interesting: -runas user Change to user id user just before starting the VM. -readconfig file -writeconfig file read/write config file-no-kvm disable KVM hardware virtualization -no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC -no-kvm-pit disable KVM kernel mode PIT Signed-off-by: Michael Tokarev m...@tls.msk.ru Thanks applied. diff --git a/qemu-options.hx b/qemu-options.hx index b8cc375..ecd50eb 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -1936,4 +1936,4 @@ DEF(readconfig, HAS_ARG, QEMU_OPTION_readconfig, -readconfig file\n) DEF(writeconfig, HAS_ARG, QEMU_OPTION_writeconfig, -writeconfig file\n -read/write config file) +read/write config file\n) -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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] KVM: fix LAPIC timer period overflow
Don't overflow when computing the 64-bit period from 32-bit registers.
Fixes sourceforge bug #2826486.
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
arch/x86/kvm/lapic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 9c8f901..3ca7767 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -658,7 +658,7 @@ static void start_apic_timer(struct kvm_lapic *apic)
{
ktime_t now = apic-lapic_timer.timer.base-get_time();
- apic-lapic_timer.period = apic_get_reg(apic, APIC_TMICT) *
+ apic-lapic_timer.period = (u64)apic_get_reg(apic, APIC_TMICT) *
APIC_BUS_CYCLE_NS * apic-divide_count;
atomic_set(apic-lapic_timer.pending, 0);
--
1.6.4.3
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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: cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest
On Fri, Apr 03, 2009 at 06:45:48PM -0300, Marcelo Tosatti wrote: On Tue, Mar 24, 2009 at 11:47:33AM +0200, Avi Kivity wrote: index 2ea8262..48169d7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3109,6 +3109,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) kvm_write_guest_time(vcpu); if (test_and_clear_bit(KVM_REQ_MMU_SYNC, vcpu-requests)) kvm_mmu_sync_roots(vcpu); + if (test_and_clear_bit(KVM_REQ_MMU_GLOBAL_SYNC, vcpu-requests)) + kvm_mmu_sync_global(vcpu); if (test_and_clear_bit(KVM_REQ_TLB_FLUSH, vcpu-requests)) kvm_x86_ops-tlb_flush(vcpu); if (test_and_clear_bit(KVM_REQ_REPORT_TPR_ACCESS Windows will (I think) write a PDE on every context switch, so this effectively disables global unsync for that guest. What about recursively syncing the newly linked page in FNAME(fetch)()? If the page isn't global, this becomes a no-op, so no new overhead. The only question is the expense when linking a populated top-level page, especially in long mode. How about this? KVM: MMU: sync global pages on fetch() If an unsync global page becomes unreachable via the shadow tree, which can happen if one its parent pages is zapped, invlpg will fail to invalidate translations for gvas contained in such unreachable pages. So sync global pages in fetch(). Signed-off-by: Marcelo Tosatti mtosa...@redhat.com I have tried this patch, and unfortunately it does not solve the original problem, while the previous one did. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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: cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest
On Mon, Mar 23, 2009 at 02:27:25PM -0300, Marcelo Tosatti wrote: On Sun, Mar 22, 2009 at 11:35:00AM +0200, Avi Kivity wrote: Good catch, indeed. But is it sufficient? We could unlink a page through other means, for example by the guest zapping a page directory entry. Yep. Maybe it's best to resync when relinking a global page? How about this. It will shorten the unsync period of global pages, unfortunately. JFYI, it still fixes the problem seen with FreeBSD. diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 2a36f7f..bccdcc7 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -1238,6 +1238,10 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu, set_bit(KVM_REQ_MMU_SYNC, vcpu-requests); kvm_mmu_mark_parents_unsync(vcpu, sp); } + if (role.level != PT_PAGE_TABLE_LEVEL + !list_empty(vcpu-kvm-arch.oos_global_pages)) + set_bit(KVM_REQ_MMU_GLOBAL_SYNC, vcpu-requests); + pgprintk(%s: found\n, __func__); return sp; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2ea8262..48169d7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3109,6 +3109,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) kvm_write_guest_time(vcpu); if (test_and_clear_bit(KVM_REQ_MMU_SYNC, vcpu-requests)) kvm_mmu_sync_roots(vcpu); + if (test_and_clear_bit(KVM_REQ_MMU_GLOBAL_SYNC, vcpu-requests)) + kvm_mmu_sync_global(vcpu); if (test_and_clear_bit(KVM_REQ_TLB_FLUSH, vcpu-requests)) kvm_x86_ops-tlb_flush(vcpu); if (test_and_clear_bit(KVM_REQ_REPORT_TPR_ACCESS, diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 11eb702..8efd6e3 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -37,7 +37,8 @@ #define KVM_REQ_PENDING_TIMER 5 #define KVM_REQ_UNHALT 6 #define KVM_REQ_MMU_SYNC 7 -#define KVM_REQ_KVMCLOCK_UPDATE8 +#define KVM_REQ_MMU_GLOBAL_SYNC8 +#define KVM_REQ_KVMCLOCK_UPDATE9 #define KVM_USERSPACE_IRQ_SOURCE_ID 0 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-84 screen corruption
Dustin Kirkland a écrit : On Tue, Feb 24, 2009 at 8:47 PM, Zhang, Xiantao xiantao.zh...@intel.com wrote: I can confirm it on ia64 platform with kvm-84 and kvm-userspace upstream source. Another issue is that the text color is not correct. For what it's worth, I was able to fix this in kvm (1:84+dfsg-0ubuntu5) jaunty by applying: * http://svn.savannah.gnu.org/viewvc/trunk/exec.c?r1=6601r2=6628pathrev=6628root=qemuview=patch This is exactly the patch I told you to try, so it is already in the git tree. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] powerpc/kvm: Add MPC8544DS board support
On Thu, Feb 26, 2009 at 06:35:40PM +0800, Liu Yu wrote: patch 1: enable mpic for E500 platform. patch 2: add E500 pci controller emulation. patch 3: add E500 irq support. patch 4: add MPC8544DS board support. patch 5: FDT of MPC8544DS Thanks, whole series applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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 1/5] kvm/powerpc: Enable MPIC for E500 platform.
On Fri, Feb 27, 2009 at 10:04:17PM +0200, Blue Swirl wrote:
On 2/27/09, Liu Yu-B13201 yu@freescale.com wrote:
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: Friday, February 27, 2009 2:47 AM
To: Liu Yu-B13201
Cc: qemu-de...@nongnu.org; aurel...@aurel32.net;
holl...@us.ibm.com; kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 1/5] kvm/powerpc: Enable MPIC for E500 platform.
On 2/26/09, Liu Yu yu@freescale.com wrote:
MPIC and OpenPIC have very similar design.
So a lot of code can be reused.
Modification mainly include:
1. keep struct openpic_t to the maximum size of both MPIC
and OpenPIC.
2. endianess swap.
MPIC has the same endianess as target, so no need to
swap for MPIC.
3. using different init functions and function pointers
for reset and irq raise.
Haven't test OpenPIC.
Signed-off-by: Liu Yu yu@freescale.com
+struct {
+CPUReadMemoryFunc **read;
+CPUWriteMemoryFunc **write;
+target_phys_addr_t start_addr;
+ram_addr_t size;
+} list[] = {
+{mpic_glb_read, mpic_glb_write,
MPIC_GLB_REG_START, MPIC_GLB_REG_SIZE},
+{mpic_tmr_read, mpic_tmr_write,
MPIC_TMR_REG_START, MPIC_TMR_REG_SIZE},
+{mpic_ext_read, mpic_ext_write,
MPIC_EXT_REG_START, MPIC_EXT_REG_SIZE},
+{mpic_int_read, mpic_int_write,
MPIC_INT_REG_START, MPIC_INT_REG_SIZE},
+{mpic_msg_read, mpic_msg_write,
MPIC_MSG_REG_START, MPIC_MSG_REG_SIZE},
+{mpic_msi_read, mpic_msi_write,
MPIC_MSI_REG_START, MPIC_MSI_REG_SIZE},
+{mpic_cpu_read, mpic_cpu_write,
MPIC_CPU_REG_START, MPIC_CPU_REG_SIZE},
+};
static const ?
Why static? It's allocated on stack and will be free when function return.
True, but it will be constructed for every call. But as this function
will be called only once, it does not matter too much.
I have committed another patch to fix that.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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: kvm-84 screen corruption
Dustin Kirkland a écrit : Howdy- I recently merged kvm-84 into Ubuntu Jaunty. We're experiencing corruption of the VM's screen. The text becomes garbled through any one of a number of vectors. Our bug report with screenshots can be found at: * https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/333920 I can reproduce this very simply by booting a basic image, no additional options, and cat'ing a file, perhaps 5-10 times. At some point, the text is completely jumbled. A clear/reset will clean things up temporarily, but it will eventually happen again. Suggestions? This is most probably fixed in git, commit 7def4ba752cf629043e884dac8541fa5114c4c91 -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aure...@debian.org | aurel...@aurel32.net `-people.debian.org/~aurel32 | www.aurel32.net -- 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: cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest
On Sun, Feb 22, 2009 at 10:47:13PM -0300, Marcelo Tosatti wrote: On Mon, Feb 23, 2009 at 01:33:05AM +0100, Aurelien Jarno wrote: Hi, Since kvm-81, I have noticed that GNU/kFreeBSD 32-bit guest are crashing under high load (during a compilation for example) with the following error message: | Fatal trap 12: page fault while in kernel mode | fault virtual address = 0x4 | fault code = supervisor read, page not present | instruction pointer = 0x20:0xc0a4fc00 | stack pointer = 0x28:0xe66d7a70 | frame pointer = 0x28:0xe66d7a80 | code segment= base 0x0, limit 0xf, type 0x1b | = DPL 0, pres 1, def32 1, gran 1 | processor eflags= interrupt enabled, resume, IOPL = 0 | current process = 24037 (bash) | trap number = 12 | panic: page fault | Uptime: 4m7s | Cannot dump. No dump device defined. | Automatic reboot in 15 seconds - press a key on the console to abort I haven't tried yet with a plain FreeBSD guest, but I also expect it to crash given the kernel (version 7.1) is almost the same. A closer investigation has shown that the following commit is causing the problem: | commit 6364a3918cb5c28376849e7fca3e09bd66b859f3 | Author: Marcelo Tosatti mtosa...@redhat.com | Date: Mon Dec 1 22:32:04 2008 -0200 | | KVM: MMU: skip global pgtables on sync due to cr3 switch | | Skip syncing global pages on cr3 switch (but not on cr4/cr0). This is | important for Linux 32-bit guests with PAE, where the kmap page is | marked as global. | | Signed-off-by: Marcelo Tosatti mtosa...@redhat.com | Signed-off-by: Avi Kivity a...@redhat.com As expected, loading the KVM module with oos_shadow=0 workaround the problem. Please note that the guest is running in 32-bit mode, does not use PAE, and uses global pages. My host has an Intel Q9450 CPU, and the problem appears with both a 2.6.26 and a 2.6.28 64-bit kernel. Does anybody see any problem in this patch? How can I further debug the problem? Aurelien, Maybe there is a bug in the syncing code (eg: not all global pages are sync'ed when the OS requests a global sync), or FreeBSD is relying on invlpg/cr3 write to sync global pages (remember TLB entries can be invalidated internally by CPU). As far as I understand the Intel IA32 manual, using invlpg to sync global pages is correct. OTOH, cr3 is not. I think that if FreeBSD is using cr3 to sync global pages that should also cause a problem on real hardware sooner or later, right? I'll try to look at the kernel code. If you want to debug it, would suggest looping over all MMU pages in mmu_sync_global, after the kvm_sync_page loop, and WARN_ON(sp-unsync sp-global); If that fails, check if the unsync and global flags mean what they are supposed to. This doesn't detect any problem, which means that all pages marked as global are synced correctly. I have also tried to call kvm_mmu_sync_global() in kvm_set_cr3(), and as expected the guest works correctly in that case. If I understand correctly, and if the problem is not on the FreeBSD side, the only remaining possible problem is if normal pages are wrongly marked as global, and thus should be synced with cr3, while they are not. Am I right here? Sorry for the trouble and thanks for the detailed report, will take a close look at it this week. Thanks for your fast answer and for your help for debugging. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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
cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest
Hi, Since kvm-81, I have noticed that GNU/kFreeBSD 32-bit guest are crashing under high load (during a compilation for example) with the following error message: | Fatal trap 12: page fault while in kernel mode | fault virtual address = 0x4 | fault code = supervisor read, page not present | instruction pointer = 0x20:0xc0a4fc00 | stack pointer = 0x28:0xe66d7a70 | frame pointer = 0x28:0xe66d7a80 | code segment= base 0x0, limit 0xf, type 0x1b | = DPL 0, pres 1, def32 1, gran 1 | processor eflags= interrupt enabled, resume, IOPL = 0 | current process = 24037 (bash) | trap number = 12 | panic: page fault | Uptime: 4m7s | Cannot dump. No dump device defined. | Automatic reboot in 15 seconds - press a key on the console to abort I haven't tried yet with a plain FreeBSD guest, but I also expect it to crash given the kernel (version 7.1) is almost the same. A closer investigation has shown that the following commit is causing the problem: | commit 6364a3918cb5c28376849e7fca3e09bd66b859f3 | Author: Marcelo Tosatti mtosa...@redhat.com | Date: Mon Dec 1 22:32:04 2008 -0200 | | KVM: MMU: skip global pgtables on sync due to cr3 switch | | Skip syncing global pages on cr3 switch (but not on cr4/cr0). This is | important for Linux 32-bit guests with PAE, where the kmap page is | marked as global. | | Signed-off-by: Marcelo Tosatti mtosa...@redhat.com | Signed-off-by: Avi Kivity a...@redhat.com As expected, loading the KVM module with oos_shadow=0 workaround the problem. Please note that the guest is running in 32-bit mode, does not use PAE, and uses global pages. My host has an Intel Q9450 CPU, and the problem appears with both a 2.6.26 and a 2.6.28 64-bit kernel. Does anybody see any problem in this patch? How can I further debug the problem? Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/5] kvm/powerpc: Enable MPIC for E500 platform.
On Tue, Feb 17, 2009 at 04:55:51PM +0200, Blue Swirl wrote: On 2/17/09, Liu Yu yu@freescale.com wrote: MPIC and OpenPIC have very similar design. So a lot of code can be reused. Modification mainly include: 1. keep struct openpic_t to the maximum size of both MPIC and OpenPIC. 2. endianess swap. MPIC has the same endianess as target, so no need to swap for MPIC. I don't think this is correct, the host can still be different endian from target. I do not agree. As long as we don't manipulate host memory, the host endianess has nothing to do. The values are simply passed by value, they don't need to be swapped. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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: [Qemu-devel] [PATCH 2/6] kvm/powerpc: Add freescale pci controller's support
;
+
+if (version_id != 1)
+return -EINVAL;
+
+pci_device_load(controller-pci_dev, f);
+
+for (i = 0; i PPCE500_PCI_NR_POBS; i++) {
+qemu_get_be32s(f, controller-pob[i].potar);
+qemu_get_be32s(f, controller-pob[i].potear);
+qemu_get_be32s(f, controller-pob[i].powbar);
+qemu_get_be32s(f, controller-pob[i].powar);
+}
+
+for (i = 0; i PPCE500_PCI_NR_PIBS; i++) {
+qemu_get_be32s(f, controller-pib[i].pitar);
+qemu_get_be32s(f, controller-pib[i].piwbar);
+qemu_get_be32s(f, controller-pib[i].piwbear);
+qemu_get_be32s(f, controller-pib[i].piwar);
+}
+qemu_get_be32s(f, controller-gasket_time);
+
+return 0;
+}
+
+PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t registers)
+{
+PPCE500PCIState *controller;
+PCIDevice *d;
+int index;
+static int ppce500_pci_id;
+
+controller = qemu_mallocz(sizeof(PPCE500PCIState));
+if (!controller)
+ return NULL;
+
+controller-pci_state.bus = pci_register_bus(mpc85xx_pci_set_irq,
+ mpc85xx_pci_map_irq,
+ pci_irqs, 0x88, 4);
+d = pci_register_device(controller-pci_state.bus,
+host bridge, sizeof(PCIDevice),
+0, NULL, NULL);
+
+d-config[0x00] = 0x57; // vendor_id
+d-config[0x01] = 0x19;
+d-config[0x02] = 0x30; // device_id
+d-config[0x03] = 0x00;
+d-config[0x0a] = 0x20; // class_sub = other bridge type
+d-config[0x0b] = 0x0B; // class_base = PCI_bridge
+
+controller-pci_dev = d;
+
+/* CFGADDR */
+index = cpu_register_io_memory(0, pcie500_cfgaddr_read,
+ pcie500_cfgaddr_write, controller);
+if (index 0)
+goto free;
+cpu_register_physical_memory(registers + PCIE500_CFGADDR, 4, index);
+
+/* CFGDATA */
+index = cpu_register_io_memory(0, pcie500_cfgdata_read,
+ pcie500_cfgdata_write,
+ controller-pci_state);
+if (index 0)
+goto free;
+cpu_register_physical_memory(registers + PCIE500_CFGDATA, 4, index);
+
+index = cpu_register_io_memory(0, e500_pci_reg_read,
+e500_pci_reg_write, controller);
+if (index 0)
+ goto free;
+cpu_register_physical_memory(registers + PCIE500_REG_BASE,
+ PCIE500_REG_SIZE, index);
+
+/* XXX load/save code not tested. */
+register_savevm(ppce500_pci, ppce500_pci_id++, 1,
+ppce500_pci_save, ppce500_pci_load, controller);
+
+return controller-pci_state.bus;
+
+free:
+printf(%s error\n, __func__);
+qemu_free(controller);
+return NULL;
+}
--
1.5.4
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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: [Qemu-devel] [PATCH 4/6] kvm/powerpc: extern one function for MPC85xx code use
On Thu, Jan 22, 2009 at 06:14:14PM +0800, Liu Yu wrote:
Signed-off-by: Liu Yu yu@freescale.com
---
target-ppc/kvm_ppc.c |2 +-
target-ppc/kvm_ppc.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
Thanks, applied.
diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
index f7ce52b..82c0f42 100644
--- a/target-ppc/kvm_ppc.c
+++ b/target-ppc/kvm_ppc.c
@@ -22,7 +22,7 @@ static QEMUTimer *kvmppc_timer;
static unsigned int kvmppc_timer_rate;
#ifdef HAVE_FDT
-static int kvmppc_read_host_property(const char *node_path, const char *prop,
+int kvmppc_read_host_property(const char *node_path, const char *prop,
void *val, size_t len)
{
char *path;
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index e536a88..3792ef7 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -11,5 +11,7 @@
void kvmppc_init(void);
void kvmppc_fdt_update(void *fdt);
+int kvmppc_read_host_property(const char *node_path, const char *prop,
+ void *val, size_t len);
#endif /* __KVM_PPC_H__ */
--
1.5.4
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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: [Qemu-devel] [PATCH] hpet config mask fix
On Wed, Jan 14, 2009 at 09:45:36AM -0500, Beth Kon wrote:
I discovered a bug in the hpet code that caused Windows to boot without
hpet. The config mask I was using was preventing the guest from placing
the hpet into 32 bit mode.
Thanks, applied.
diff --git a/qemu/hw/hpet.c b/qemu/hw/hpet.c
index 5c1aca2..7df2d05 100644
--- a/qemu/hw/hpet.c
+++ b/qemu/hw/hpet.c
@@ -388,7 +388,8 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
switch ((addr - 0x100) % 0x20) {
case HPET_TN_CFG:
dprintf(qemu: hpet_ram_writel HPET_TN_CFG\n);
-timer-config = hpet_fixup_reg(new_val, old_val, 0x3e4e);
+timer-config = hpet_fixup_reg(new_val, old_val,
+ HPET_TN_CFG_WRITE_MASK);
if (new_val HPET_TN_32BIT) {
timer-cmp = (uint32_t)timer-cmp;
timer-period = (uint32_t)timer-period;
@@ -456,7 +457,8 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
case HPET_ID:
return;
case HPET_CFG:
-s-config = hpet_fixup_reg(new_val, old_val, 0x3);
+s-config = hpet_fixup_reg(new_val, old_val,
+ HPET_CFG_WRITE_MASK);
if (activating_bit(old_val, new_val, HPET_CFG_ENABLE)) {
/* Enable main counter and interrupt generation. */
s-hpet_offset = ticks_to_ns(s-hpet_counter)
diff --git a/qemu/hw/hpet_emul.h b/qemu/hw/hpet_emul.h
index fbe7a44..60893b6 100644
--- a/qemu/hw/hpet_emul.h
+++ b/qemu/hw/hpet_emul.h
@@ -36,6 +36,7 @@
#define HPET_TN_CFG 0x000
#define HPET_TN_CMP 0x008
#define HPET_TN_ROUTE 0x010
+#define HPET_CFG_WRITE_MASK 0x3
#define HPET_TN_ENABLE 0x004
@@ -45,6 +46,7 @@
#define HPET_TN_SETVAL 0x040
#define HPET_TN_32BIT0x100
#define HPET_TN_INT_ROUTE_MASK 0x3e00
+#define HPET_TN_CFG_WRITE_MASK 0x3f4e
#define HPET_TN_INT_ROUTE_SHIFT 9
#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aure...@debian.org | aurel...@aurel32.net
`-people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 3/9] powerpc/kvm: Enable mpic for E500 platform
On Fri, Jan 16, 2009 at 12:17:40PM -0600, Hollis Blanchard wrote: On Fri, 2009-01-16 at 13:34 +0800, Liu Yu wrote: -Original Message- From: Anthony Liguori [mailto:anth...@codemonkey.ws] Sent: Friday, January 16, 2009 5:23 AM To: qemu-de...@nongnu.org Cc: Liu Yu-B13201; kvm-ppc@vger.kernel.org Subject: Re: [Qemu-devel] [PATCH 3/9] powerpc/kvm: Enable mpic for E500 platform Liu Yu wrote: The modify is based on original author's method to switch openpic and mpic by static define, like the switch between USE_INTEL_GW80314 and USE_MPCxxx. (Although the support for intel has broken) So they can't be used at the same time. I guess it's not the correct way to do this. but I am not sure is the USE_MPC85xx and openpic are still needed? Have you tested some of the other (TCG) boards (for instance, with the debian image Aurelien recently posted)? This image is only for g3beige, it won't work on mac99 which is moreover broken. You mean test powerpc mac99? No. It doesn't sound like mac99 works right now anyways, so that may not be possible to test. Confirmed. We hope to get it working in the next few weeks/months using OpenBIOS, the same way as for the g3beige machine. I only modified few places to the original code. I think it won't be influenced. But mpic and openpic couldnot work in the same qemu binary with this patch. If they should both be supported, then I need to modify more. Due to the (artificial) ppc vs ppcemb split, I'm not sure this is a requirement. Agreed. I am fine with some changes if they are only done for the ppcemb binary. The only issue I can see is if there are ppc targets (e.g. 970) that use the same[1] MPIC as found on e500, and that is different from and not supported by the current OpenPIC emulation. The person adding support for those ppc targets, will have to modify the code to support both versions at runtime. [1] By same I mean substantially similar. As I understand it, OpenPIC and MPIC are very similar designs, but there are different bugs/quirks to different implementations. So even if e500's MPIC isn't *exactly* the same as 970 chipsets' MPIC, if they're close enough that the code could be shared, it should be. -- Hollis Blanchard IBM Linux Technology Center -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aure...@debian.org | aurel...@aurel32.net `-people.debian.org/~aurel32 | www.aurel32.net -- 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: [Qemu-devel] KVM PowerPC support v3
On Mon, Dec 15, 2008 at 06:17:28PM -0600, Hollis Blanchard wrote: I've fixed the configure output in patch #1, and the comment in patch #4. Patch #2 was already acked. Thanks, all applied. I still have a few questions though, see the answer to individual patches. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aure...@debian.org | aurel...@aurel32.net `-people.debian.org/~aurel32 | www.aurel32.net -- 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: [Qemu-devel] [PATCH 1/8] Move PPC4xx SDRAM controller emulation from ppc405_uc.c to ppc4xx_devs.c
+/* invalidate all RAM mappings */
+sdram_unmap_bcr(sdram);
+sdram-status |= 0x8000;
+}
+if (!(sdram-cfg 0x4000) (val 0x4000))
+sdram-status |= 0x4000;
+else if ((sdram-cfg 0x4000) !(val 0x4000))
+sdram-status = ~0x4000;
+sdram-cfg = val;
+break;
+case 0x24: /* SDRAM_STATUS */
+/* Read-only register */
+break;
+case 0x30: /* SDRAM_RTR */
+sdram-rtr = val 0x3FF8;
+break;
+case 0x34: /* SDRAM_PMIT */
+sdram-pmit = (val 0xF800) | 0x07C0;
+break;
+case 0x40: /* SDRAM_B0CR */
+sdram_set_bcr(sdram-bcr[0], val, sdram-cfg 0x8000);
+break;
+case 0x44: /* SDRAM_B1CR */
+sdram_set_bcr(sdram-bcr[1], val, sdram-cfg 0x8000);
+break;
+case 0x48: /* SDRAM_B2CR */
+sdram_set_bcr(sdram-bcr[2], val, sdram-cfg 0x8000);
+break;
+case 0x4C: /* SDRAM_B3CR */
+sdram_set_bcr(sdram-bcr[3], val, sdram-cfg 0x8000);
+break;
+case 0x80: /* SDRAM_TR */
+sdram-tr = val 0x018FC01F;
+break;
+case 0x94: /* SDRAM_ECCCFG */
+sdram-ecccfg = val 0x00F0;
+break;
+case 0x98: /* SDRAM_ECCESR */
+val = 0xFFF0F000;
+if (sdram-eccesr == 0 val != 0)
+qemu_irq_raise(sdram-irq);
+else if (sdram-eccesr != 0 val == 0)
+qemu_irq_lower(sdram-irq);
+sdram-eccesr = val;
+break;
+default: /* Error */
+break;
+}
+break;
+}
+}
+
+static void sdram_reset (void *opaque)
+{
+ppc4xx_sdram_t *sdram;
+
+sdram = opaque;
+sdram-addr = 0x;
+sdram-bear = 0x;
+sdram-besr0 = 0x; /* No error */
+sdram-besr1 = 0x; /* No error */
+sdram-cfg = 0x;
+sdram-ecccfg = 0x; /* No ECC */
+sdram-eccesr = 0x; /* No error */
+sdram-pmit = 0x07C0;
+sdram-rtr = 0x05F0;
+sdram-tr = 0x00854009;
+/* We pre-initialize RAM banks */
+sdram-status = 0x;
+sdram-cfg = 0x0080;
+sdram_unmap_bcr(sdram);
+}
+
+void ppc405_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
+target_phys_addr_t *ram_bases,
+target_phys_addr_t *ram_sizes,
+int do_init)
+{
+ppc4xx_sdram_t *sdram;
+
+sdram = qemu_mallocz(sizeof(ppc4xx_sdram_t));
+if (sdram != NULL) {
+sdram-irq = irq;
+sdram-nbanks = nbanks;
+memset(sdram-ram_bases, 0, 4 * sizeof(target_phys_addr_t));
+memcpy(sdram-ram_bases, ram_bases,
+ nbanks * sizeof(target_phys_addr_t));
+memset(sdram-ram_sizes, 0, 4 * sizeof(target_phys_addr_t));
+memcpy(sdram-ram_sizes, ram_sizes,
+ nbanks * sizeof(target_phys_addr_t));
+sdram_reset(sdram);
+qemu_register_reset(sdram_reset, sdram);
+ppc_dcr_register(env, SDRAM0_CFGADDR,
+ sdram, dcr_read_sdram, dcr_write_sdram);
+ppc_dcr_register(env, SDRAM0_CFGDATA,
+ sdram, dcr_read_sdram, dcr_write_sdram);
+if (do_init)
+sdram_map_bcr(sdram);
+}
+}
--
1.5.6.5
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aure...@debian.org | aurel...@aurel32.net
`-people.debian.org/~aurel32 | www.aurel32.net
--
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: [Qemu-devel] [PATCH 3/8] Create a helper function to allow more flexible RAM allocation for PPC 4xx
On Mon, Dec 15, 2008 at 10:44:14AM -0600, Hollis Blanchard wrote:
The 4xx SDRAM controller supports a small number of banks, and each bank must
be one of a small set of sizes. The number of banks and the supported sizes
varies by SoC.
This function uses the user-specified RAM size to fill in the ram_bases and
ram_sizes arrays required by ppc4xx_sdram_init().
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
Applied, thanks.
---
hw/ppc4xx.h |5 +
hw/ppc4xx_devs.c | 42 ++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/hw/ppc4xx.h b/hw/ppc4xx.h
index 3b98662..7832cd9 100644
--- a/hw/ppc4xx.h
+++ b/hw/ppc4xx.h
@@ -48,6 +48,11 @@ enum {
qemu_irq *ppcuic_init (CPUState *env, qemu_irq *irqs,
uint32_t dcr_base, int has_ssr, int has_vr);
+ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
+ target_phys_addr_t ram_bases[],
+ target_phys_addr_t ram_sizes[],
+ const unsigned int sdram_bank_sizes[]);
+
void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
target_phys_addr_t *ram_bases,
target_phys_addr_t *ram_sizes,
diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c
index 2d27e23..939e066 100644
--- a/hw/ppc4xx_devs.c
+++ b/hw/ppc4xx_devs.c
@@ -873,3 +873,45 @@ void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int
nbanks,
sdram_map_bcr(sdram);
}
}
+
+/* Fill in consecutive SDRAM banks with 'ram_size' bytes of memory.
+ *
+ * sdram_bank_sizes[] must be 0-terminated.
+ *
+ * The 4xx SDRAM controller supports a small number of banks, and each bank
+ * must be one of a small set of sizes. The number of banks and the supported
+ * sizes varies by SoC. */
+ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
+ target_phys_addr_t ram_bases[],
+ target_phys_addr_t ram_sizes[],
+ const unsigned int sdram_bank_sizes[])
+{
+ram_addr_t ram_end = 0;
+int i;
+int j;
+
+for (i = 0; i nr_banks; i++) {
+for (j = 0; sdram_bank_sizes[j] != 0; j++) {
+unsigned int bank_size = sdram_bank_sizes[j];
+
+if (bank_size = ram_size) {
+ram_bases[i] = ram_end;
+ram_sizes[i] = bank_size;
+ram_end += bank_size;
+ram_size -= bank_size;
+break;
+}
+}
+
+if (!ram_size) {
+/* No need to use the remaining banks. */
+break;
+}
+}
+
+if (ram_size)
+printf(Truncating memory to %d MiB to fit SDRAM controller
limits.\n,
+ (int)(ram_end 20));
+
+return ram_end;
+}
--
1.5.6.5
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aure...@debian.org | aurel...@aurel32.net
`-people.debian.org/~aurel32 | www.aurel32.net
--
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: Is this a bug in qemu-img?
On Sun, Nov 23, 2008 at 09:29:48AM -0800, walt wrote: Everything above works perfectly. I can reboot vista, check for new updates, create user accounts, all the normal stuff. Now comes the trouble: #qemu-img commit vista.delta [takes 1 hour] The facts it takes very long is fixed in QEMU SVN. It will be fixed in KVM as soon as the QEMU SVN is pulleD. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- 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: Out of sync shadow core breaks Hurd
On Thu, Nov 20, 2008 at 10:48:21AM +0100, Marcelo Tosatti wrote: Hi Aurelien, Hi, On Wed, Nov 12, 2008 at 08:00:37PM +0100, Aurelien Jarno wrote: Hi, Starting with kvm-76 (and including kvm-79), Hurd does not boot anymore under KVM. The ext2fs translator issues a strange error message: | Hurd server bootstrap: ext2fs.static[device:hd0s3] execext2fs.static: /build/bui | ldd/hurd-20080607/build-tree/hurd/ext2fs/dir.c:494: dirscanblock: Assertion `dp- | dn-dirents[idx] == -1 || dp-dn-dirents[idx] == nentries' failed. - | dn-dirents[idx] == -1 || dp-dn-dirents[idx] == nentries' failed. Bisecting the problem, I have found that it comes from this patch: | 641fb03992b20aa640781a245f6b7136f0b845e4 is first bad commit | commit 641fb03992b20aa640781a245f6b7136f0b845e4 | Author: Marcelo Tosatti [EMAIL PROTECTED] | Date: Tue Sep 23 13:18:39 2008 -0300 | | KVM: MMU: out of sync shadow core v2 | | Allow guest pagetables to go out of sync. | | Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] | Signed-off-by: Avi Kivity [EMAIL PROTECTED] The problem can be workarounded loading the kvm module with oos_shadow=0. The easiest way to reproduce the problem is to download a ready to use Hurd image [1]. The error message from the ext2fs translator is not exactly the same, but it still fails. It seems Hurd does not always explicitly flush the TLB via cr0/cr3/cr4 writes or invlpg after updating pagetables. Debugging shows that OOS is properly syncing the sptes wrt the guest pagetables, and that all pages are synced before guest re-entry on TLB flush exits. Thanks for your investigation. The Intel TLB doc says (5.1 Invalidation Instructions): (Other instructions and operations may invalidate entries in the TLBs and the paging structure caches, but the instructions identified above are recommended.) As a test, syncing on every exit makes it happy: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 7a2aeba..47e2550 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3052,6 +3052,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) kvm_lapic_sync_from_vapic(vcpu); + kvm_mmu_sync_roots(vcpu); + r = kvm_x86_ops-handle_exit(kvm_run, vcpu); out: return r; It would be necessary to confirm this by hacking Hurd to flush on every pagetable update. Perhaps something like RCS file: /sources/hurd/gnumach/i386/intel/pmap.c,v retrieving revision 1.4.2.22 diff -u -r1.4.2.22 pmap.c --- pmap.c 11 Nov 2008 02:24:18 - 1.4.2.22 +++ pmap.c 20 Nov 2008 12:47:01 - @@ -82,7 +82,7 @@ #include i386/proc_reg.h #include i386/locore.h -#defineWRITE_PTE(pte_p, pte_entry) *(pte_p) = (pte_entry); +#defineWRITE_PTE(pte_p, pte_entry) *(pte_p) = (pte_entry); flush_tlb(); /* * Private data structures. I have tried this patch, but it doesn't change anything. I'll try to see if there are more place when the PTE is written. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- 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
Out of sync shadow core breaks Hurd
Hi, Starting with kvm-76 (and including kvm-79), Hurd does not boot anymore under KVM. The ext2fs translator issues a strange error message: | Hurd server bootstrap: ext2fs.static[device:hd0s3] execext2fs.static: /build/bui | ldd/hurd-20080607/build-tree/hurd/ext2fs/dir.c:494: dirscanblock: Assertion `dp- | dn-dirents[idx] == -1 || dp-dn-dirents[idx] == nentries' failed. - | dn-dirents[idx] == -1 || dp-dn-dirents[idx] == nentries' failed. Bisecting the problem, I have found that it comes from this patch: | 641fb03992b20aa640781a245f6b7136f0b845e4 is first bad commit | commit 641fb03992b20aa640781a245f6b7136f0b845e4 | Author: Marcelo Tosatti [EMAIL PROTECTED] | Date: Tue Sep 23 13:18:39 2008 -0300 | | KVM: MMU: out of sync shadow core v2 | | Allow guest pagetables to go out of sync. | | Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] | Signed-off-by: Avi Kivity [EMAIL PROTECTED] The problem can be workarounded loading the kvm module with oos_shadow=0. The easiest way to reproduce the problem is to download a ready to use Hurd image [1]. The error message from the ext2fs translator is not exactly the same, but it still fails. Aurelien [1] http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd-k16-qemu.img.tar.gz -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- 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: [Qemu-devel] [PATCH 1/3] qemu: ppc: define maximum SMP limit as 1 for Bamboo
On Tue, Oct 28, 2008 at 10:08:20AM +0100, [EMAIL PROTECTED] wrote:
From: Christian Ehrhardt [EMAIL PROTECTED]
Fix for qemu runtime error. Full error message:
Number of SMP cpus requested (1), exceeds max cpus supported by machine
`bamboo' (0)
The default max number of CPU has been set to 1 in revision 5566, so
this patch is not necessary anymore.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
[diffstat]
ppc440_bamboo.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
[diff]
diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -203,7 +203,8 @@ void bamboo_init(ram_addr_t ram_size, in
}
QEMUMachine bamboo_machine = {
- bamboo,
- bamboo,
- bamboo_init,
+ .name = bamboo,
+ .desc = bamboo,
+ .init = bamboo_init,
+ .max_cpus = 1,
};
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
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: [Qemu-devel] [PATCH] uhci: improved TD matching, working ISOC transfers
On Fri, Aug 22, 2008 at 05:54:53AM +, Max Krasnyansky wrote:
While trying to make VX-3000 camera work on XP under KVM I realized that
we do not necessarily have to find original TD address. All we care about
is the token which identifies the transfer rather well (direction, endpoint,
size, etc).
This is especially important for the isochronous transfers because otherwise
they are being canceled left and right and we do not make much progress.
With this patch all devices that used bulk transfers that I've tried so
far continue to work just as well. And now my USB web cammera (isoc transfers)
is working well tool. It's not as smooth as native Windows but it's pretty
darn smooth.
The cool thing is that new USB code (both usb-uhci and usb-linux) is totaly
generic and does not need any special logic for ISOC.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
Thanks, applied.
---
hw/usb-uhci.c | 40
1 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1b15074..0714520 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -265,25 +265,41 @@ static void uhci_async_cancel_all(UHCIState *s)
static UHCIAsync *uhci_async_find_td(UHCIState *s, uint32_t addr, uint32_t
token)
{
UHCIAsync *async = s-async_pending;
+UHCIAsync *match = NULL;
+int count = 0;
+
+/*
+ * We're looking for the best match here. ie both td addr and token.
+ * Otherwise we return last good match. ie just token.
+ * It's ok to match just token because it identifies the transaction
+ * rather well, token includes: device addr, endpoint, size, etc.
+ *
+ * Also since we queue async transactions in reverse order by returning
+ * last good match we restores the order.
+ *
+ * It's expected that we wont have a ton of outstanding transactions.
+ * If we ever do we'd want to optimize this algorithm.
+ */
while (async) {
-if (async-td == addr) {
-if (async-token == token)
-return async;
-
-/*
- * TD was reused for a different transfer.
- * Invalidate the original one asap.
- */
-if (async-valid 0) {
-async-valid = 0;
-dprintf(husb: bad reuse. td 0x%x\n, async-td);
+if (async-token == token) {
+/* Good match */
+match = async;
+
+if (async-td == addr) {
+/* Best match */
+break;
}
}
async = async-next;
+count++;
}
-return NULL;
+
+if (count 64)
+ fprintf(stderr, uhci: warning lots of async transactions\n);
+
+return match;
}
static void uhci_attach(USBPort *port1, USBDevice *dev);
--
1.5.5.1
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
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: [Qemu-devel] [PATCH] uhci: Fixed length handling for SETUP and OUT tokens
On Fri, Aug 22, 2008 at 05:54:31AM +, Max Krasnyansky wrote:
Fixes regression reported agains Linux 2.6.18.
Looks like XP and newer Linux kernels are less sensitive
to length returned for control transfers.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
Applied, thanks.
---
hw/usb-uhci.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 0714520..86b4696 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -651,7 +651,7 @@ static int uhci_broadcast_packet(UHCIState *s, USBPacket
*p)
dprintf(uhci: packet enter. pid %s addr 0x%02x ep %d len %d\n,
pid2str(p-pid), p-devaddr, p-devep, p-len);
-if (p-pid == USB_TOKEN_OUT)
+if (p-pid == USB_TOKEN_OUT || p-pid == USB_TOKEN_SETUP)
dump_data(p-data, p-len);
ret = USB_RET_NODEV;
@@ -771,7 +771,7 @@ out:
static int uhci_handle_td(UHCIState *s, uint32_t addr, UHCI_TD *td, uint32_t
*int_mask)
{
UHCIAsync *async;
-int len = 0, max_len, ret = 0;
+int len = 0, max_len;
uint8_t pid;
/* Is active ? */
@@ -814,12 +814,13 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
case USB_TOKEN_OUT:
case USB_TOKEN_SETUP:
cpu_physical_memory_read(td-buffer, async-buffer, max_len);
-ret = uhci_broadcast_packet(s, async-packet);
-len = max_len;
+len = uhci_broadcast_packet(s, async-packet);
+if (len = 0)
+len = max_len;
break;
case USB_TOKEN_IN:
-ret = uhci_broadcast_packet(s, async-packet);
+len = uhci_broadcast_packet(s, async-packet);
break;
default:
@@ -830,17 +831,17 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
return -1;
}
-if (ret == USB_RET_ASYNC) {
+if (len == USB_RET_ASYNC) {
uhci_async_link(s, async);
return 2;
}
-async-packet.len = ret;
+async-packet.len = len;
done:
-ret = uhci_complete_td(s, td, async, int_mask);
+len = uhci_complete_td(s, td, async, int_mask);
uhci_async_free(s, async);
-return ret;
+return len;
}
static void uhci_async_complete(USBPacket *packet, void *opaque)
--
1.5.5.1
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
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
