Re: error: building kvm for powerpc using cross compiler on x86
On Thu, Jan 6, 2011 at 10:39 AM, Dushyant Bansal cs5070...@cse.iitd.ac.in wrote: I want to build kvm kernel module for powerpc using cross compiler. I downloaded kernel source code from http://www.linux-kvm.org/page/PowerPC_440_Host_Kernel. Inside that kvm_source folder when I do make ARCH=powerpc menuconfig, inside virtualization menu, option kvm is not present. I have attached the screenshot. It's impossible to say from your description, but I would guess that you haven't configured for a 440 processor before visiting the Virtualization menu. -Hollis -- 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: re-writing on powerpc
On 12/14/2010 12:48 AM, Avi Kivity wrote: On 12/13/2010 07:17 PM, Hollis Blanchard wrote: Rewriting is dangerous if the guest is unaware of it. As soon as it is made aware of it, it might as well actually do it in the best way that suits it. Can you list some examples of dangerous scenarios? Perhaps I should rephrase... any real-world dangerous scenarios? :) I was hoping you could share some traps you've hit with Linux or Windows on x86. - guest checksums own kernel pages For runtime intrusion detection? Such guests can simply not ask the hypervisor to enable the rewriting feature. - clever compiler reuses code for constant pool Not sure what you mean here. Anyways I think clever compilers are irrelevant, since a compiler will not ordinarily emit a supervisor-mode instruction. The hypervisor has no need to patch normal user-mode instructions. - guest patches itself (a la linux alternatives), surprised when it sees a different instruction PowerPC Linux does patch itself, which is a write-only operation. - guest jits own kernel code (like Singularity), gets confused when it reads back something it didn't write This is getting really hypothetical, but why would a JIT need to read the generated code? Hollis Blanchard Mentor Graphics, Embedded Systems Division -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm/e500v2: MMU optimization
On 09/09/2010 04:03 AM, Liu Yu-B13201 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard Sent: Thursday, September 09, 2010 12:07 AM To: Liu Yu-B13201 Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de Subject: Re: [PATCH 0/2] kvm/e500v2: MMU optimization On 09/08/2010 02:40 AM, Liu Yu wrote: The patchset aims at mapping guest TLB1 to host TLB0. And it includes: [PATCH 1/2] kvm/e500v2: Remove shadow tlb [PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0 The reason we need patch 1 is because patch 1 make things simple and flexible. Only applying patch 1 aslo make kvm work. I've always thought the best long-term optimization on these cores is to share in the host PID allocation (i.e. __init_new_context()). This way, the TID in guest mappings would not overlap the TID in host mappings, and guest mappings could be demand-faulted rather than swapped wholesale. To do that, you would need to track the host PID in KVM data structures, I guess in the tlbe_ref structure. Hi Hollis, Guest uses AS=1 and host uses AS=0, so even guest uses the same TID with host, they're in different space. Then why guest needs to care about host TID? You're absolutely right, but this makes a couple key assumptions: 1. The guest doesn't try to use AS=1. This is already false in Linux, because the udbg code uses an AS=1 mapping for the UART, but this can be configured out (with a small loss in functionality). In non-Linux guests the AS=0 restriction could be onerous. 2. A Book E MMU. If we participate in the host MMU context allocation, the guest - host address space code could be generalized to include e.g. an e600 guest on an e500 host, or vice versa. So you're right that optimization is not the right word; this would be more of a functionality and design improvement. (In fact, I suppose it could reduce performance on Book E, since AS=1 space actually *is* unused by the host. I think it would be worth finding out.) Hollis Blanchard Mentor Graphics, Embedded Systems Division -- 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/2] kvm/e500v2: Remove shadow tlb
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote: Yes, it's hard to resume TLB0. We only resume TLB1 in previous code. But TLB1 is even more smaller (13 free entries) than 440, So that it still has little possibility to get hit. thus the resumption is useless. The only reason hits are unlikely in TLB1 is because you still don't have large page support in the host. Once you have that, you can use TLB1 for large guest mappings, and it will become extremely likely that you get hits in TLB1. This is true even if the guest wants 256MB but the host supports only e.g. 16MB large pages, and must split the guest mapping into multiple large host pages. When will you have hugetlbfs for e500? That's going to make such a dramatic difference, I'm not sure it's worth investing time in optimizing the MMU code until then. Hollis Blanchard Mentor Graphics, Embedded Systems Division -- 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/2] kvm/e500v2: Remove shadow tlb
On 09/09/2010 04:26 PM, Alexander Graf wrote: On 09.09.2010, at 20:13, Hollis Blanchard wrote: On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote: Yes, it's hard to resume TLB0. We only resume TLB1 in previous code. But TLB1 is even more smaller (13 free entries) than 440, So that it still has little possibility to get hit. thus the resumption is useless. The only reason hits are unlikely in TLB1 is because you still don't have large page support in the host. Once you have that, you can use TLB1 for large guest mappings, and it will become extremely likely that you get hits in TLB1. This is true even if the guest wants 256MB but the host supports only e.g. 16MB large pages, and must split the guest mapping into multiple large host pages. When will you have hugetlbfs for e500? That's going to make such a dramatic difference, I'm not sure it's worth investing time in optimizing the MMU code until then. I'm not sure I agree. Sure, huge pages give another big win, but the state as is should at least be fast enough for prototyping. Sure, and it sounds like you can prototype with it already. My point is that, in your 80-20 rule of optimization, the 20% is going to change radically once large page support is in place. Remember that the guest kernel is mapped with just a couple large pages. During guest Linux boot on 440, I think about half the boot time is spent TLB thrashing in the initcalls. Using TLB0 can ameliorate that for now, but why bother, since it doesn't help you towards the real solution? I'm not saying this shouldn't be committed, if that's how you interpreted my comments, but in my opinion there are more useful things to do than continuing to optimize a path that is going to disappear in the future. Once you *do* have hugetlbfs in the host, you're not going to want to use TLB0 for guest TLB1 mappings any more anyways. Hollis Blanchard Mentor Graphics, Embedded Systems Division -- 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/2] kvm/e500v2: Remove shadow tlb
On 09/08/2010 02:40 AM, Liu Yu wrote: It is unnecessary to keep shadow tlb. first, shadow tlb keep fixed value in shadow, which make things unflexible. second, remove shadow tlb can save a lot memory. This patch remove shadow tlb and caculate the shadow tlb entry value before we write it to hardware. Also we use new struct tlbe_ref to trace the relation between guest tlb entry and page. Did you look at the performance impact? Back in the day, we did essentially the same thing on 440. However, rather than discard the whole TLB when context switching away from the host (to be demand-faulted when the guest is resumed), we found a noticeable performance improvement by preserving a shadow TLB across context switches. We only use it in the vcpu_put/vcpu_load path. Of course, our TLB was much smaller (64 entries), so the use model may not be the same at all (e.g. it takes longer to restore a full guest TLB working set, but maybe it's not really possible to use all 1024 TLB0 entries in one timeslice anyways). -- Hollis Blanchard Mentor Graphics, Embedded Systems Division -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm/e500v2: MMU optimization
On 09/08/2010 02:40 AM, Liu Yu wrote: The patchset aims at mapping guest TLB1 to host TLB0. And it includes: [PATCH 1/2] kvm/e500v2: Remove shadow tlb [PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0 The reason we need patch 1 is because patch 1 make things simple and flexible. Only applying patch 1 aslo make kvm work. I've always thought the best long-term optimization on these cores is to share in the host PID allocation (i.e. __init_new_context()). This way, the TID in guest mappings would not overlap the TID in host mappings, and guest mappings could be demand-faulted rather than swapped wholesale. To do that, you would need to track the host PID in KVM data structures, I guess in the tlbe_ref structure. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] fix PowerPC 440 Bamboo platform emulation
On 08/04/2010 05:21 PM, Hollis Blanchard wrote: These patches get the PowerPC Bamboo platform working again. I've re-written two of the patches based on feedback from qemu-devel. Hi Aurelien, any comment on these? Hollis Blanchard Mentor Graphics, Embedded Systems Division -- 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 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses
On Thu, Aug 5, 2010 at 7:39 PM, Liu Yu-B13201 b13...@freescale.com wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard Sent: Thursday, August 05, 2010 8:22 AM To: qemu-de...@nongnu.org Cc: kvm-ppc@vger.kernel.org Subject: [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses We can't use the return value of load_uimage() for the kernel because it can't account for BSS size, and the PowerPC kernel does not relocate blobs before zeroing BSS. Instead, we now load at the fixed addresses chosen by u-boot (the normal firmware for the board). What will us do if the uImage become bigger and fixed size is not enough? That was my question to Edgar, which was not answered. In u-boot, one would change some environment variables. With this code in qemu, the only recourse would be to edit ppc440_bamboo.c and rebuild. Perhaps in the future we can do something more sophisticated by specifying load addresses in a qemu device tree, but I don't understand that stuff enough to know if that is an intended use. -Hollis -- 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 17/27] KVM: PPC: KVM PV guest stubs
On 07/29/2010 05:47 AM, Alexander Graf wrote:
We will soon start and replace instructions from the text section with
other, paravirtualized versions. To ease the readability of those patches
I split out the generic looping and magic page mapping code out.
This patch still only contains stubs. But at least it loops through the
text section :).
Signed-off-by: Alexander Grafag...@suse.de
---
v1 - v2:
- kvm guest patch framework: introduce patch_ins
v2 - v3:
- add self-test in guest code
- remove superfluous new lines in generic guest code
---
arch/powerpc/kernel/kvm.c | 95 +
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index a5ece71..e93366f 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -33,6 +33,62 @@
#define KVM_MAGIC_PAGE(-4096L)
#define magic_var(x) KVM_MAGIC_PAGE + offsetof(struct kvm_vcpu_arch_shared, x)
+#define KVM_MASK_RT0x03e0
+
+static bool kvm_patching_worked = true;
+
+static inline void kvm_patch_ins(u32 *inst, u32 new_inst)
+{
+ *inst = new_inst;
+ flush_icache_range((ulong)inst, (ulong)inst + 4);
+}
+
+static void kvm_map_magic_page(void *data)
+{
+ kvm_hypercall2(KVM_HC_PPC_MAP_MAGIC_PAGE,
+ KVM_MAGIC_PAGE, /* Physical Address */
+ KVM_MAGIC_PAGE); /* Effective Address */
+}
+
+static void kvm_check_ins(u32 *inst)
+{
+ u32 _inst = *inst;
+ u32 inst_no_rt = _inst ~KVM_MASK_RT;
+ u32 inst_rt = _inst KVM_MASK_RT;
+
+ switch (inst_no_rt) {
+ }
+
+ switch (_inst) {
+ }
+}
+
+static void kvm_use_magic_page(void)
+{
+ u32 *p;
+ u32 *start, *end;
+ u32 tmp;
+
+ /* Tell the host to map the magic page to -4096 on all CPUs */
+ on_each_cpu(kvm_map_magic_page, NULL, 1);
+
+ /* Quick self-test to see if the mapping works */
+ if (__get_user(tmp, (u32*)KVM_MAGIC_PAGE)) {
+ kvm_patching_worked = false;
+ return;
+ }
+
+ /* Now loop through all code and find instructions */
+ start = (void*)_stext;
+ end = (void*)_etext;
+
+ for (p = start; p end; p++)
+ kvm_check_ins(p);
+
+ printk(KERN_INFO KVM: Live patching for a fast VM %s\n,
+kvm_patching_worked ? worked : failed);
+}
Rather than have the guest loop through every instruction in its text,
why can't you use the existing cputable self-patching mechanism? The
kernel already uses that in a number of places to patch itself at
runtime in fast paths... see Documentation/powerpc/cpu_features.txt for
some background.
Since we already know (at build time) the location of code that needs
patching, we don't need to scan at all. (I also shudder to think of the
number of page faults this scan will incur.)
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
--
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 01/27] KVM: PPC: Introduce shared page
:
+ kvmppc_e500_tlb_uninit(vcpu_e500);
uninit_vcpu:
kvm_vcpu_uninit(vcpu);
free_vcpu:
@@ -131,6 +137,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
+ free_page((unsigned long)vcpu-arch.shared);
kvmppc_e500_tlb_uninit(vcpu_e500);
kvm_vcpu_uninit(vcpu);
kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
Why not put all this in a common function like kvm_arch_vcpu_init()?
There are layers of shared code inside arch/powerpc/kvm: e.g. powerpc.c
- booke.c - 44x.c...
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
--
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
[PATCH 0/4] fix PowerPC 440 Bamboo platform emulation
These patches get the PowerPC Bamboo platform working again. I've re-written two of the patches based on feedback from qemu-devel. Note that this platform still only works in conjunction with KVM, since the PowerPC 440 MMU is still not accurately emulated by TCG. -- 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
[PATCH 2/4] ppc4xx: correct SDRAM controller warning message condition
The message Truncating memory to %d MiB to fit SDRAM controller limits should be displayed only when a user chooses an amount of RAM which can't be represented by the PPC 4xx SDRAM controller (e.g. 129MB, which would only be valid if the controller supports a bank size of 1MB). Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/ppc4xx_devs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c index b15db81..be130c4 100644 --- a/hw/ppc4xx_devs.c +++ b/hw/ppc4xx_devs.c @@ -684,7 +684,7 @@ ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks, } ram_size -= size_left; -if (ram_size) +if (size_left) printf(Truncating memory to %d MiB to fit SDRAM controller limits.\n, (int)(ram_size 20)); -- 1.7.2 -- 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
[PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses
We can't use the return value of load_uimage() for the kernel because it
can't account for BSS size, and the PowerPC kernel does not relocate
blobs before zeroing BSS.
Instead, we now load at the fixed addresses chosen by u-boot (the normal
firmware for the board).
Signed-off-by: Hollis Blanchard hol...@penguinppc.org
---
hw/ppc440_bamboo.c | 39 ++-
1 files changed, 18 insertions(+), 21 deletions(-)
This fixes a critical bug in PowerPC 440 Bamboo board emulation.
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index d471d5d..34ddf45 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -27,6 +27,11 @@
#define BINARY_DEVICE_TREE_FILE bamboo.dtb
+/* from u-boot */
+#define KERNEL_ADDR 0x100
+#define FDT_ADDR 0x180
+#define RAMDISK_ADDR 0x190
+
static int bamboo_load_device_tree(target_phys_addr_t addr,
uint32_t ramsize,
target_phys_addr_t initrd_base,
@@ -98,10 +103,8 @@ static void bamboo_init(ram_addr_t ram_size,
uint64_t elf_lowaddr;
target_phys_addr_t entry = 0;
target_phys_addr_t loadaddr = 0;
-target_long kernel_size = 0;
-target_ulong initrd_base = 0;
target_long initrd_size = 0;
-target_ulong dt_base = 0;
+int success;
int i;
/* Setup CPU. */
@@ -118,15 +121,15 @@ static void bamboo_init(ram_addr_t ram_size,
/* Load kernel. */
if (kernel_filename) {
-kernel_size = load_uimage(kernel_filename, entry, loadaddr, NULL);
-if (kernel_size 0) {
-kernel_size = load_elf(kernel_filename, NULL, NULL, elf_entry,
- elf_lowaddr, NULL, 1, ELF_MACHINE, 0);
+success = load_uimage(kernel_filename, entry, loadaddr, NULL);
+if (success 0) {
+success = load_elf(kernel_filename, NULL, NULL, elf_entry,
+ elf_lowaddr, NULL, 1, ELF_MACHINE, 0);
entry = elf_entry;
loadaddr = elf_lowaddr;
}
/* XXX try again as binary */
-if (kernel_size 0) {
+if (success 0) {
fprintf(stderr, qemu: could not load kernel '%s'\n,
kernel_filename);
exit(1);
@@ -135,26 +138,20 @@ static void bamboo_init(ram_addr_t ram_size,
/* Load initrd. */
if (initrd_filename) {
-initrd_base = kernel_size + loadaddr;
-initrd_size = load_image_targphys(initrd_filename, initrd_base,
- ram_size - initrd_base);
+initrd_size = load_image_targphys(initrd_filename, RAMDISK_ADDR,
+ ram_size - RAMDISK_ADDR);
if (initrd_size 0) {
-fprintf(stderr, qemu: could not load initial ram disk '%s'\n,
-initrd_filename);
+fprintf(stderr, qemu: could not load ram disk '%s' at %x\n,
+initrd_filename, RAMDISK_ADDR);
exit(1);
}
}
/* If we're loading a kernel directly, we must load the device tree too. */
if (kernel_filename) {
-if (initrd_base)
-dt_base = initrd_base + initrd_size;
-else
-dt_base = kernel_size + loadaddr;
-
-if (bamboo_load_device_tree(dt_base, ram_size,
-initrd_base, initrd_size, kernel_cmdline) 0) {
+if (bamboo_load_device_tree(FDT_ADDR, ram_size, RAMDISK_ADDR,
+initrd_size, kernel_cmdline) 0) {
fprintf(stderr, couldn't load device tree\n);
exit(1);
}
@@ -163,7 +160,7 @@ static void bamboo_init(ram_addr_t ram_size,
/* Set initial guest state. */
env-gpr[1] = (1620) - 8;
-env-gpr[3] = dt_base;
+env-gpr[3] = FDT_ADDR;
env-nip = entry;
/* XXX we currently depend on KVM to create some initial TLB entries.
*/
}
--
1.7.2
--
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
[PATCH 1/4] Fix make install with a cross toolchain
We must be able to use a non-native strip executable, but not all
versions of 'install' support the --strip-program option (e.g.
OpenBSD). Accordingly, we can't use 'install -s', and we must run strip
separately.
Signed-off-by: Hollis Blanchard hol...@penguinppc.org
Cc: blauwir...@gmail.com
---
Makefile.target |5 -
configure |4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 8a9c427..00bf6f9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -326,7 +326,10 @@ clean:
install: all
ifneq ($(PROGS),)
- $(INSTALL) -m 755 $(STRIP_OPT) $(PROGS) $(DESTDIR)$(bindir)
+ $(INSTALL) -m 755 $(PROGS) $(DESTDIR)$(bindir)
+ifneq ($(STRIP),)
+ $(STRIP) $(patsubst %,$(DESTDIR)$(bindir)/%,$(PROGS))
+endif
endif
# Include automatically generated dependency files
diff --git a/configure b/configure
index a20371c..146dac0 100755
--- a/configure
+++ b/configure
@@ -80,6 +80,7 @@ make=make
install=install
objcopy=objcopy
ld=ld
+strip=strip
helper_cflags=
libs_softmmu=
libs_tools=
@@ -125,6 +126,7 @@ cc=${cross_prefix}${cc}
ar=${cross_prefix}${ar}
objcopy=${cross_prefix}${objcopy}
ld=${cross_prefix}${ld}
+strip=${cross_prefix}${strip}
# default flags for all hosts
QEMU_CFLAGS=-fno-strict-aliasing $QEMU_CFLAGS
@@ -2227,7 +2229,7 @@ if test $debug = yes ; then
echo CONFIG_DEBUG_EXEC=y $config_host_mak
fi
if test $strip_opt = yes ; then
- echo STRIP_OPT=-s $config_host_mak
+ echo STRIP=${strip} $config_host_mak
fi
if test $bigendian = yes ; then
echo HOST_WORDS_BIGENDIAN=y $config_host_mak
--
1.7.2
--
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
[PATCH 3/4] ppc4xx: don't unregister RAM at reset
The PowerPC 4xx SDRAM controller emulation unregisters RAM in its reset callback. However, qemu_system_reset() is now called at initialization time, so all RAM is unregistered before starting the guest (!). Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/ppc4xx_devs.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) This fixes a critical bug in PowerPC 440 Bamboo board emulation. diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c index be130c4..7f698b8 100644 --- a/hw/ppc4xx_devs.c +++ b/hw/ppc4xx_devs.c @@ -619,7 +619,6 @@ static void sdram_reset (void *opaque) /* We pre-initialize RAM banks */ sdram-status = 0x; sdram-cfg = 0x0080; -sdram_unmap_bcr(sdram); } void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks, -- 1.7.2 -- 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] loader: pad kernel size when loaded from a uImage
On Sun, Aug 1, 2010 at 5:36 AM, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Sat, Jul 31, 2010 at 12:56:42AM +0200, Edgar E. Iglesias wrote: On Thu, Jul 29, 2010 at 06:48:24PM -0700, Hollis Blanchard wrote: The kernel's BSS size is lost by mkimage, which only considers file size. As a result, loading other blobs (e.g. device tree, initrd) immediately after the kernel location can result in them being zeroed by the kernel's BSS initialization code. Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/loader.c | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/hw/loader.c b/hw/loader.c index 79a6f95..35bc25a 100644 --- a/hw/loader.c +++ b/hw/loader.c @@ -507,6 +507,13 @@ int load_uimage(const char *filename, target_phys_addr_t *ep, ret = hdr-ih_size; + /* The kernel's BSS size is lost by mkimage, which only considers file + * size. We don't know how big it is, but we do know we can't place + * anything immediately after the kernel. The padding seems like it should + * be proportional to overall file size, but we also make sure it's at + * least 4-byte aligned. */ + ret += (hdr-ih_size / 16) ~0x3; Maybe it's only me, but it feels a bit akward to push down this kind of knowledge down the abstraction layers. Does it work for you to have your caller of load_uimage apply whatever resizing magic needed for your kernel and arch? Ayway, IMO the conventions of where to pass blobs from the bootloader to the loaded image are an agreement between the bootloader and the loaded code. The formats or mechanisms to load the image should need to be involved that much. For example in this particular case, other archs (e.g, MicroBlaze) might not need any magic. The MicroBlaze linux kernel moves cmdline and device tree blobs into safe areas prior to .bss initialization. Are you claiming that's the common case? FWIW, PowerPC and ARM don't seem to. I wouldn't expect such logic except in reaction to a specific bug (i.e. a qemu/firmware loader bug). The load_uimage() interface claims to report the size of the kernel it loaded. If you argue that it shouldn't try to do that (and indeed you could argue it's not *possible* to do that accurately), that logic should be completely removed. The current behavior is worse than not knowing at all: callers *think* they know, but it's guaranteed to be wrong. Of course, if you do want to remove the size, then callers are left with even less information than they had before. In that case, you tell me: where should I hardcode initrd loading? Anyways, you don't even use load_uimage() in microblaze, and if you did, you wouldn't be obligated to use the size return value, so fixing this issue for everybody else doesn't limit you at all. -Hollis -- 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] loader: pad kernel size when loaded from a uImage
On Mon, Aug 2, 2010 at 11:57 AM, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Mon, Aug 02, 2010 at 10:59:11AM -0700, Hollis Blanchard wrote: On Sun, Aug 1, 2010 at 5:36 AM, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Sat, Jul 31, 2010 at 12:56:42AM +0200, Edgar E. Iglesias wrote: On Thu, Jul 29, 2010 at 06:48:24PM -0700, Hollis Blanchard wrote: The kernel's BSS size is lost by mkimage, which only considers file size. As a result, loading other blobs (e.g. device tree, initrd) immediately after the kernel location can result in them being zeroed by the kernel's BSS initialization code. Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/loader.c | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/hw/loader.c b/hw/loader.c index 79a6f95..35bc25a 100644 --- a/hw/loader.c +++ b/hw/loader.c @@ -507,6 +507,13 @@ int load_uimage(const char *filename, target_phys_addr_t *ep, ret = hdr-ih_size; + /* The kernel's BSS size is lost by mkimage, which only considers file + * size. We don't know how big it is, but we do know we can't place + * anything immediately after the kernel. The padding seems like it should + * be proportional to overall file size, but we also make sure it's at + * least 4-byte aligned. */ + ret += (hdr-ih_size / 16) ~0x3; Maybe it's only me, but it feels a bit akward to push down this kind of knowledge down the abstraction layers. Does it work for you to have your caller of load_uimage apply whatever resizing magic needed for your kernel and arch? Ayway, IMO the conventions of where to pass blobs from the bootloader to the loaded image are an agreement between the bootloader and the loaded code. The formats or mechanisms to load the image should need to be involved that much. For example in this particular case, other archs (e.g, MicroBlaze) might not need any magic. The MicroBlaze linux kernel moves cmdline and device tree blobs into safe areas prior to .bss initialization. Are you claiming that's the common case? FWIW, PowerPC and ARM don't seem to. I wouldn't expect such logic except in reaction to a specific bug (i.e. a qemu/firmware loader bug). I'm not trying to claim it's the common case, but it exists. It exists and will remain unaffected by this patch, while the common case will be improved. The load_uimage() interface claims to report the size of the kernel it loaded. If you argue that it shouldn't try to do that (and indeed you The way I understand it, it reports the size of what got loaded. The difference between what got loaded and the size of the loaded file in memory is a subtlety that is not at all clear from the code, and that is precisely why I propose centralizing the logic to handle it. It would be very difficult for load_uimage to figure out what memory areas are beeing touched prior to .bss init (or the point where the passed blob is used). could argue it's not *possible* to do that accurately), that logic Right, its very hard for it to guess what memory areas are safe. should be completely removed. The current behavior is worse than not knowing at all: callers *think* they know, but it's guaranteed to be wrong. Of course, if you do want to remove the size, then callers are left with even less information than they had before. In that case, you I think returning the size of the loaded image has a value, for example for archs that move away the blobs before touching any memory outside their image. Bootloaders for those archs can put some blobs right after the loaded image. You mean the one architecture, which by the way doesn't even use this API? That doesn't seem like a strong argument to me. Anyways, it's just as much work to relocate an initrd from a padded address as it is from a closer address, so there is no downside. The fact remains that the current API is broken by design, or to be charitable violates the principle of least surprise. With the exception of microblaze, everybody who calls load_uimage() must understand the nuances of the return value and adjust it (or ignore it) accordingly. Why wouldn't we consolidate that logic? tell me: where should I hardcode initrd loading? Not sure, but I'd guess somewhere close to where you are calling load_uimage from (it wasn't clear to me where that was). Sorry, let me rephrase. At what address should I hardcode my initrd? What about my device tree? As a followup, why not lower, or higher? Also, how can I know in the code if I chose wrong, what will the user-visible failure be, and how difficult will that be to debug? In summary, this patch protects users and developers. If I move it to be PowerPC-specific, it will protect only PowerPC users and developers, which is clearly a much smaller number. Debating whether theoretically *all* users and developers would benefit from
Re: [PATCH] PPC4xx: don't unregister RAM at reset
On Mon, Aug 2, 2010 at 1:41 AM, Alexander Graf ag...@suse.de wrote: On 30.07.2010, at 03:48, Hollis Blanchard wrote: The PowerPC 4xx SDRAM controller emulation unregisters RAM in its reset callback. However, qemu_system_reset() is now called at initialization time, so RAM is unregistered before starting the guest. So the registration should be moved to reset now, no? How is the reset different from boot? How did a reset work before? As far as I can tell, no other platform unregisters and re-registers memory at reset, so that is a difference between reset and boot. Maybe I don't understand your other question. Before qemu_system_reset() was called at initialization time, memory was not unregistered, and therefore the platform had memory and could boot. -Hollis -- 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] loader: pad kernel size when loaded from a uImage
On Mon, Aug 2, 2010 at 12:56 PM, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Mon, Aug 02, 2010 at 12:33:54PM -0700, Hollis Blanchard wrote: You mean the one architecture, which by the way doesn't even use this API? That doesn't seem like a strong argument to me. Anyways, it's Are we looking at the same code? I don't know. Grep for load_uimage in qemu. 4 archs use it, PPC, ARM, m68k and MB. I see the following: 1 75 hw/an5206.c an5206_init kernel_size = load_uimage(kernel_filename, entry, NULL, NULL); 2233 hw/arm_boot.c arm_load_kernel kernel_size = load_uimage(info-kernel_filename, entry, NULL, 3 50 hw/dummy_m68k.c dummy_m68k_init kernel_size = load_uimage(kernel_filename, entry, NULL, NULL); 4 14 hw/loader.h uint64_t int load_uimage(const char *filename, target_phys_addr_t *ep, 5277 hw/mcf5208.c mcf5208evb_init kernel_size = load_uimage(kernel_filename, entry, NULL, NULL); 6121 hw/ppc440_bamboo.c bamboo_init kernel_size = load_uimage(kernel...ename, entry, loadaddr, NULL); 7235 hw/ppce500_mpc8544ds.c mpc8544ds_init kernel_size = load_uimage(kernel...ename, entry, loadaddr, NULL); That makes 2x ColdFire, ARM, M68K, 2x PowerPC. hw/petalogix_s3adsp1800_mmu.c is the only MicroBlaze I can see, and it only loads ELF and binary kernels, not uImages. Of those archs, only 2 actually use the return value of load_uimage to decide where to place blobs. PPC and MB. MB doesn't want any magic applied to the return value. That leaves us with _ONE_ single arch that needs magic that IMO is broken. You are trying to guess the size of the loaded image's .bss area by adding a 16th of the uimage size? Accounting for BSS hardly counts as magic, I think. :) just as much work to relocate an initrd from a padded address as it is from a closer address, so there is no downside. The fact remains that the current API is broken by design, or to be charitable violates the principle of least surprise. With the exception of microblaze, everybody who calls load_uimage() must understand the nuances of the return value and adjust it (or ignore it) accordingly. Why wouldn't we consolidate that logic? I don't see how guessing that the .bss area is a 16th of the loaded image makes this call any less confusing. I agree it's arbitrary, but it's only arbitrary in one place. It's also well-commented (IMHO), which is more than can be said for the current code. tell me: where should I hardcode initrd loading? Not sure, but I'd guess somewhere close to where you are calling load_uimage from (it wasn't clear to me where that was). Sorry, let me rephrase. At what address should I hardcode my initrd? What about my device tree? As a followup, why not lower, or higher? You should be putting them at the same addresses as uboot puts them. Fine. It's arbitrary in u-boot too, but at least it will be consistent. -Hollis -- 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
[PATCH] KVM: PPC: initialize IVORs in addition to IVPR
Developers can now tell at a glace the exact type of the premature interrupt,
instead of just knowing that there was some interrupt.
Signed-off-by: Hollis Blanchard hol...@penguinppc.org
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -466,15 +466,19 @@ int kvmppc_handle_exit(struct kvm_run *r
/* Initial guest state: 16MB mapping 0 - 0, PC = 0, MSR = 0, R1 = 16MB */
int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
{
+ int i;
+
vcpu-arch.pc = 0;
vcpu-arch.msr = 0;
kvmppc_set_gpr(vcpu, 1, (1620) - 8); /* -8 for the callee-save LR
slot */
vcpu-arch.shadow_pid = 1;
- /* Eye-catching number so we know if the guest takes an interrupt
-* before it's programmed its own IVPR. */
+ /* Eye-catching numbers so we know if the guest takes an interrupt
+* before it's programmed its own IVPR/IVORs. */
vcpu-arch.ivpr = 0x;
+ for (i = 0; i BOOKE_IRQPRIO_MAX; i++)
+ vcpu-arch.ivor[i] = 0x7700 | i * 4;
kvmppc_init_timing_stats(vcpu);
--
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
[PATCH] KVM: PPC: fix compilation of dump tlbs debug function
Signed-off-by: Hollis Blanchard hol...@penguinppc.org
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -47,6 +47,7 @@
#ifdef DEBUG
void kvmppc_dump_tlbs(struct kvm_vcpu *vcpu)
{
+ struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
struct kvmppc_44x_tlbe *tlbe;
int i;
--
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
[PATCH] PPC4xx: don't unregister RAM at reset
The PowerPC 4xx SDRAM controller emulation unregisters RAM in its reset callback. However, qemu_system_reset() is now called at initialization time, so RAM is unregistered before starting the guest. Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/ppc4xx_devs.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c index be130c4..7f698b8 100644 --- a/hw/ppc4xx_devs.c +++ b/hw/ppc4xx_devs.c @@ -619,7 +619,6 @@ static void sdram_reset (void *opaque) /* We pre-initialize RAM banks */ sdram-status = 0x; sdram-cfg = 0x0080; -sdram_unmap_bcr(sdram); } void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks, -- 1.7.1.1 -- 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
[PATCH] loader: pad kernel size when loaded from a uImage
The kernel's BSS size is lost by mkimage, which only considers file size. As a result, loading other blobs (e.g. device tree, initrd) immediately after the kernel location can result in them being zeroed by the kernel's BSS initialization code. Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/loader.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/hw/loader.c b/hw/loader.c index 79a6f95..35bc25a 100644 --- a/hw/loader.c +++ b/hw/loader.c @@ -507,6 +507,13 @@ int load_uimage(const char *filename, target_phys_addr_t *ep, ret = hdr-ih_size; + /* The kernel's BSS size is lost by mkimage, which only considers file +* size. We don't know how big it is, but we do know we can't place +* anything immediately after the kernel. The padding seems like it should +* be proportional to overall file size, but we also make sure it's at +* least 4-byte aligned. */ + ret += (hdr-ih_size / 16) ~0x3; + out: if (data) qemu_free(data); -- 1.7.1.1 -- 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 on 440GP
On Fri, Jan 22, 2010 at 12:04 PM, Corey Minyard miny...@acm.org wrote: Here's how far I can get now: r...@xilinx-ml507:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 64 -M bambo o -kernel uImage.bamboo -L . -append -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.50 monitor - type 'help' for more information (qemu) info cpus * CPU #0: nip=0x (qemu) info registers NIP LR CTR XER MSR HID0 0300 HF idx 0 TB 0bb4 DECR GPR00 00f8 GPR04 GPR08 GPR12 GPR16 GPR20 GPR24 GPR28 CR [ - - - - - - - - ] RES FPR00 FPR04 FPR08 FPR12 FPR16 FPR20 FPR24 FPR28 FPSCR SRR0 SRR1 SDR1 101d23e0 (qemu) x/10x 0 : 0x 0x 0x 0x 0010: 0x 0x 0x 0x 0020: 0x 0x (qemu) So the ROM doesn't seem to be set up properly, though bamboo.dtb is in the current directory. I'm wondering if it is something bad about the memory setup. I was just given an Ebony (440GP) board, and I can verify your results. Did you manage to make any more progress? Unfortunately I will be traveling for a couple weeks... Also, I don't suppose you have access to any other 440 variants? I believe the 440GP is the only one to use the 440x4 core, while the others use 440x5. -Hollis -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest
On Tue, Feb 2, 2010 at 3:44 AM, Liu Yu yu@freescale.com wrote: Old method prematurely sets ESR and DEAR. Move this part after we decide to inject interrupt, which is more like hardware behave. Signed-off-by: Liu Yu yu@freescale.com Acked-by: Hollis Blanchard hol...@penguinppc.org -- 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] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest
On Mon, Jan 25, 2010 at 3:32 AM, Liu Yu-B13201 b13...@freescale.com wrote: -Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Friday, January 22, 2010 7:33 PM To: Liu Yu-B13201 Cc: hol...@penguinppc.org; kvm-ppc@vger.kernel.org; k...@vger.kernel.org Subject: Re: [PATCH] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest On 22.01.2010, at 12:27, Liu Yu-B13201 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf Sent: Friday, January 22, 2010 7:13 PM To: Liu Yu-B13201 Cc: hol...@penguinppc.org; kvm-ppc@vger.kernel.org; k...@vger.kernel.org Subject: Re: [PATCH] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest On 22.01.2010, at 11:54, Liu Yu wrote: Old method prematurely sets ESR and DEAR. Move this part after we decide to inject interrupt, and make it more like hardware behave. Signed-off-by: Liu Yu yu@freescale.com --- arch/powerpc/kvm/booke.c | 24 ++-- arch/powerpc/kvm/emulate.c | 2 -- 2 files changed, 14 insertions(+), 12 deletions(-) @@ -286,15 +295,12 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu, break; case BOOKE_INTERRUPT_DATA_STORAGE: - vcpu-arch.dear = vcpu-arch.fault_dear; - vcpu-arch.esr = vcpu-arch.fault_esr; kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DATA_STORAGE); kvmppc_booke_queue_data_storage(vcpu, vcpu-arch.fault_esr, vcpu-arch.fault_dear); kvmppc_account_exit(vcpu, DSI_EXITS); r = RESUME_GUEST; break; case BOOKE_INTERRUPT_INST_STORAGE: - vcpu-arch.esr = vcpu-arch.fault_esr; kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_INST_STORAGE); kvmppc_booke_queue_inst_storage(vcpu, vcpu-arch.fault_esr); Not sure if this is redundant, as we already have fault_esr. Or should we ignore what hareware is and create a new esr to guest? On Book3S I take the SRR1 we get from the host as inspiration of what to pass to the guest as SRR1. I think we should definitely be able to inject a fault that we didn't get in that exact form from the exit path. I'm also not sure if something could clobber fault_esr if another interrupt takes precedence. Say a #MC. No as far as I know. And if yes, the clobber could as well happen before we copy it. Hollis, what do you think we should do here? I'm torn, and in some ways it's not that important right now. However, I think it makes sense to add something like vcpu-queued_esr as a separate field from vcpu-fault_esr. The use case I'm thinking of is a debugger wanting to invoke guest kernel to provide a translation for an address not currently present in the TLB (i.e. not currently visible to the debugger). -Hollis -- 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 on 440GP
On Fri, Jan 22, 2010 at 7:27 AM, Corey Minyard miny...@acm.org wrote:
Corey Minyard wrote:
I'm playing around with KVM on an ebony board (440GP), just trying to get
it to work, really. I followed the instructions at
http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of the
kvm kernel repository. When I try to run kvm, qemu appears to abort and
actually logs me off.
Doing a little debugging, I found that qemu_memalign() is calling abort
because posix_memalign() is failing. I haven't done any more debugging than
that.
Well, I discovered that the default memory is 128M, and that's too much
memory for a VM running on a machine with 128M. I fixed that problem, and
now it's doing something, though no console so not sure what.
I guess my questions below and the patch still apply.
-corey
Since I already had to fix a kernel issue to get it the kernel code to
initialize since the platform was reported as ppc440gp, not ppc440, I'm
wondering how hard it's going to be to get this working. Does anyone have
this working at all? Should I back up to a previous version? Any help
would be appreciated.
Thanks,
-corey
Here's the change I made to get kvm in the kernel to initialize:
Index: kvm/arch/powerpc/kvm/44x.c
===
--- kvm.orig/arch/powerpc/kvm/44x.c
+++ kvm/arch/powerpc/kvm/44x.c
@@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
{
int r;
- if (strcmp(cur_cpu_spec-platform, ppc440) == 0)
+ if (strncmp(cur_cpu_spec-platform, ppc440, 6) == 0)
r = 0;
else
r = -ENOTSUPP;
Thanks! The patch looks good to me. It's unfortunate that 440GP is
reported is ppc440gp, while every other 440 variant is reported is
ppc440, but that's just how it goes I guess. It shouldn't be too
difficult to get things working, since the cores are more or less the
same. There has been a little accidental build breakage introduced in
the 440 code recently (work to support the Book S KVM port), but
it's all been simple stuff.
As for console, you probably want to use qemu's -nographic or at
least -serial stdio options.
-Hollis
--
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 on 440GP
On Fri, Jan 22, 2010 at 9:27 AM, Alexander Graf ag...@suse.de wrote: On 22.01.2010, at 18:23, Corey Minyard wrote: Hollis Blanchard wrote: As for console, you probably want to use qemu's -nographic or at least -serial stdio options. Thanks for the info. However, -serial stdio doesn't seem to work. I get: r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo -kernel uImage.bamboo -L . -append -m 64 -serial stdio chardev: opening backend stdio failed qemu: could not open serial device 'stdio': Success Haven't seen that one. :( Does the same thing happen if you remove --enable-kvm? If so, it sounds like an issue for qemu-de...@nongnu.org. (No code will actually run like that, since qemu is missing 440 MMU emulation, but it's an easy way to identify the culprit.) BookE KVM uses virtio console, no? I think that was explained on the wiki too. Sure doesn't. Book E SoCs typically contain NS16550-compatible UARTs, so qemu's normal serial emulation works just fine. -Hollis -- 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 7/9] KVM: PPC: Emulate trap SRR1 flags properly
On Fri, Jan 8, 2010 at 11:32 AM, Alexander Graf ag...@suse.de wrote:
On 08.01.2010, at 20:29, Hollis Blanchard wrote:
On Thu, Jan 7, 2010 at 5:58 PM, Alexander Graf ag...@suse.de wrote:
Book3S needs some flags in SRR1 to get to know details about an interrupt.
One such example is the trap instruction. It tells the guest kernel that
a program interrupt is due to a trap using a bit in SRR1.
This patch implements above behavior, making WARN_ON behave like WARN_ON.
... for Book S. It already works properly for Book E, thankyouverymuch. ;)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 338baf9..e283e44 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -82,8 +82,9 @@ static void kvmppc_booke_queue_irqprio(struct kvm_vcpu
*vcpu,
set_bit(priority, vcpu-arch.pending_exceptions);
}
-void kvmppc_core_queue_program(struct kvm_vcpu *vcpu)
+void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
{
+ /* BookE does flags in ESR, so ignore those we get here */
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
}
Actually, I think Book E prematurely sets ESR, since it's done before
the program interrupt is actually delivered. Architecturally, I'm not
sure if it's a problem, but philosophically I've always wanted it to
work the way you've just implemented for Book S.
Anyways, since we can't test changes at the moment (Yu, can you?), I'd
settle for a comment to the effect that Book E code *should* do this,
but doesn't (rather than the comment above that says it's ok).
Hm, can't you just write up a patch that removes the comment I put in, does
the ESR setting in the function and do an #ifdef in emulate.c?
That way we can incrementally improve things. This series is really about
Book3S. Improving BookE should go in a different patch.
Yes, but I'd rather minimize the behavioral changes as long as we can't test it.
-Hollis
--
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 2/3] Improve DEC handling
On Mon, Dec 21, 2009 at 6:22 AM, Alexander Graf ag...@suse.de wrote:
We treated the DEC interrupt like an edge based one. This is not true for
Book3s. The DEC keeps firing until mtdec is issued again and thus clears
the interrupt line.
That's not quite right. The decrementer keeps firing until the top bit
is cleared, i.e. with mtdec. However, not *every* mtdec clears it.
(Also, I'm pretty sure this varies between Book 3S implementations,
e.g. 970 behaves differently than POWERn. I don't remember specific
values of n though, and I could be misremembering...)
So is this the failure mode?
- a decrementer interrupt is delivered
- guest does *not* issue mtdec to clear it (ppc64's lazy interrupt disabling?)
- guest expects a second decrementer interrupt, but KVM doesn't deliver one
In that case, it seems like the real fix would be something like this:
void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
{
unsigned long dec_nsec;
pr_debug(mtDEC: %x\n, vcpu-arch.dec);
#ifdef CONFIG_PPC64
/* POWER4+ triggers a dec interrupt if the value is 0 */
if (vcpu-arch.dec 0x8000) {
hrtimer_try_to_cancel(vcpu-arch.dec_timer);
kvmppc_core_queue_dec(vcpu);
+ /* keep queuing interrupts until guest clears high MSR bit */
+ hrtimer_start(vcpu-arch.dec_timer, ktime_set(0, 100),
+ HRTIMER_MODE_REL);
return;
}
#endif
-Hollis
--
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 2/3] Improve DEC handling
On Mon, Dec 21, 2009 at 10:13 AM, Hollis Blanchard
hol...@penguinppc.org wrote:
void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
{
unsigned long dec_nsec;
pr_debug(mtDEC: %x\n, vcpu-arch.dec);
#ifdef CONFIG_PPC64
/* POWER4+ triggers a dec interrupt if the value is 0 */
if (vcpu-arch.dec 0x8000) {
hrtimer_try_to_cancel(vcpu-arch.dec_timer);
kvmppc_core_queue_dec(vcpu);
+ /* keep queuing interrupts until guest clears high MSR bit */
+ hrtimer_start(vcpu-arch.dec_timer, ktime_set(0, 100),
+ HRTIMER_MODE_REL);
return;
}
#endif
Of course, removing the hardcoded 100-ns timer would be better, and
indeed we can do that. What we *really* want is to key off of MSR[EE]
changes (there's no point in queuing anything until then). So why not
move your AGGRESSIVE_DEC check into Book 3S's kvmppc_set_msr()?
-Hollis
--
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] Change PowerPC KVM maintainer
On Sun, Dec 20, 2009 at 1:24 PM, Alexander Graf ag...@suse.de wrote: Progress on KVM for Embedded PowerPC has stalled, but for Book3S there's quite a lot of work to do and going on. So in agreement with Hollis and Avi, we should switch maintainers for PowerPC. I'll still demand Acks from Hollis for code that changes BookE parts when I can't say for sure if the change is ok. Signed-off-by: Alexander Graf ag...@suse.de Acked-by: Hollis Blanchard hol...@penguinppc.org -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM-PPC: Fix mtsrin in book3s_64 mmu
On Sat, Dec 19, 2009 at 9:07 AM, Alexander Graf ag...@suse.de wrote: We were shifting the Ks/Kp/N bits one bit too far on mtsrin. It took me some time to figure that out, so I also put in some debugging and a comment explaining the conversion. This fixes current OpenBIOS boot on PPC64 KVM. Signed-off-by: Alexander Graf ag...@suse.de Acked-by: Hollis Blanchard hol...@penguinppc.org -- 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 00/27] Add KVM support for Book3s_64 (PPC64) hosts v5
On Sun, 2009-10-25 at 15:01 +0200, Avi Kivity wrote:
On 10/23/2009 02:33 AM, Hollis Blanchard wrote:
On Wed, 2009-10-21 at 17:03 +0200, Alexander Graf wrote:
KVM for PowerPC only supports embedded cores at the moment.
While it makes sense to virtualize on small machines, it's even more fun
to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
This patchset implements KVM support for Book3s_64 hosts and guest support
for Book3s_64 and G3/G4.
Acked-by: Hollis Blanchardholl...@us.ibm.com
Avi, please apply these patches
I still need acks for the arch/powerpc/{kernel,mm} bits, simple as they
are, from the powerpc maintainers.
OK, BenH says they're on his todo list.
In the meantime, please apply patch #2, because it fixes the broken qemu
build.
--
Hollis Blanchard
IBM Linux Technology Center
--
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 00/27] Add KVM support for Book3s_64 (PPC64) hosts v5
On Mon, 2009-10-26 at 18:06 -0500, Olof Johansson wrote: Not sure which patch in the series this is needed for since I applied them all, but I got: CC arch/powerpc/kvm/timing.o arch/powerpc/kvm/timing.c:205: error: 'THIS_MODULE' undeclared here (not in a function) Signed-off-by: Olof Johansson o...@lixom.net diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c index 2aa371e..7037855 100644 --- a/arch/powerpc/kvm/timing.c +++ b/arch/powerpc/kvm/timing.c @@ -23,6 +23,7 @@ #include linux/seq_file.h #include linux/debugfs.h #include linux/uaccess.h +#include linux/module.h #include asm/time.h #include asm-generic/div64.h For some reason, I'm not seeing this build break, but the patch is obviously correct. Acked-by: Hollis Blanchard holl...@us.ibm.com -- Hollis Blanchard IBM Linux Technology Center -- 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 00/27] Add KVM support for Book3s_64 (PPC64) hosts v5
On Wed, 2009-10-21 at 17:03 +0200, Alexander Graf wrote: KVM for PowerPC only supports embedded cores at the moment. While it makes sense to virtualize on small machines, it's even more fun to do so on big boxes. So I figured we need KVM for PowerPC64 as well. This patchset implements KVM support for Book3s_64 hosts and guest support for Book3s_64 and G3/G4. Acked-by: Hollis Blanchard holl...@us.ibm.com Avi, please apply these patches, and one more (unrelated) to fix the Book E build that I will send in just a moment. -- Hollis Blanchard IBM Linux Technology Center -- 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
[PATCH] kvmppc: Fix BUILD_BUG_ON condition
The old BUILD_BUG_ON implementation didn't work with __builtin_constant_p().
Fixing that revealed this test had been inverted for a long time without
anybody noticing...
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/arch/powerpc/kvm/timing.h b/arch/powerpc/kvm/timing.h
--- a/arch/powerpc/kvm/timing.h
+++ b/arch/powerpc/kvm/timing.h
@@ -48,7 +48,7 @@ static inline void kvmppc_set_exit_type(
static inline void kvmppc_account_exit_stat(struct kvm_vcpu *vcpu, int type)
{
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ BUILD_BUG_ON(!__builtin_constant_p(type));
switch (type) {
case EXT_INTR_EXITS:
vcpu-stat.ext_intr_exits++;
--
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: linux-next: tree build failure
On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
Hollis Blanchard holl...@us.ibm.com 15.10.09 00:57
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
build, and we still need to fix it.
My perspective is that it just uncovered already existing brokenness. And
honestly, I won't be able to get to look into this within the next days. (And
btw., when I run into issues with other people's code changes, quite
frequently I'm told to propose a patch, so I'm also having some
philosophical problem understanding why I can't simply expect the same
when people run into issues with changes I made, especially in cases like
this where it wasn't me introducing the broken code.) So, if this can wait
for a couple of days, I can try to find time to look into this. Otherwise, I'd
rely on someone running into the actual issue to implement a solution.
Sorry, I thought it was clear, but to be more explicit: I propose the
following patch, which replaces the current BUILD_BUG_ON implementation
with Rusty's version.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -677,18 +677,19 @@ struct sysinfo {
char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
};
-/* Force a compilation error if condition is true */
-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
-
-/* Force a compilation error if condition is constant and true */
-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
-
-/* Force a compilation error if condition is true, but also produce a
- result (of value 0 and type size_t), so the expression can be used
- e.g. in a structure initializer (or where-ever else comma expressions
- aren't permitted). */
-#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
-#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+/* If it's a constant, catch it at compile time, otherwise at link time. */
+extern int __build_bug_on_failed;
+#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
+#define BUILD_BUG_ON(condition) \
+ do {
\
+ ((void)sizeof(char[1 - 2*!!(condition)]));
\
+ if (condition) __build_bug_on_failed = 1;
\
+ } while(0)
+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
+#endif
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
--
Hollis Blanchard
IBM Linux Technology Center
--
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: linux-next: tree build failure
On Tue, 2009-10-20 at 11:42 +1030, Rusty Russell wrote: On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote: On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: My perspective is that it just uncovered already existing brokenness. Sorry, I thought it was clear, but to be more explicit: I propose the following patch, which replaces the current BUILD_BUG_ON implementation with Rusty's version. OK, I switched my brain back on. Yeah, I agree: we may still want BUILD_OR_RUNTIME_BUG_ON one day, but I like this. It's just missing the giant comment that it needs :) /** * BUILD_BUG_ON - break compile if a condition is true. * @cond: the condition which the compiler should know is false. * * If you have some code which relies on certain constants being equal, or * other compile-time-evaluated condition, you should use BUILD_BUG_ON to * detect if someone changes it. * * The implementation uses gcc's reluctance to create a negative array, but * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments * to inline functions). So as a fallback we use the optimizer; if it can't * prove the condition is false, it will cause a link error on the undefined * __build_bug_on_failed. This error is less neat, and can be harder to * track down. */ Do you want to put together a signed-off patch Rusty? It's your code, so I don't feel comfortable doing that. Once we have that, can we remove the mysterious MAYBE_BUILD_BUG_ON statements introduced in previous patches? (Does it BUG or doesn't it??) -- Hollis Blanchard IBM Linux Technology Center -- 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: linux-next: tree build failure
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote: Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and also exposes the bug in kvmppc_account_exit_stat(). So to recap: original: built but didn't work Jan's: doesn't build Rusty's: builds and works Where do you want to go from here? Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the build, and we still need to fix it. -- Hollis Blanchard IBM Linux Technology Center -- 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: linux-next: tree build failure
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2009-10-05 at 07:58 +0100, Jan Beulich wrote:
Hollis Blanchard holl...@us.ibm.com 02.10.09 17:48
On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
The one Rusty suggested the other day may help here. I don't like it
as a drop-in replacement for BUILD_BUG_ON() though (due to it
deferring the error generated to the linking stage), I'd rather view
this as an improvement to MAYBE_BUILD_BUG_ON() (which should
then be used here).
Can you be more specific?
I have no idea what Rusty suggested where. I can't even guess what
I'm attaching Rusty's response I was referring to.
MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
Agreed - but presumably better than just deleting the bogus instances
altogether...
Jan
email message attachment
Forwarded Message
From: Rusty Russell ru...@rustcorp.com.au
To: Jan Beulich jbeul...@novell.com
Cc: linux-ker...@vger.kernel.org
Subject: Re: [PATCH] fix BUILD_BUG_ON() and a couple of bogus uses
of it
Date: Wed, 23 Sep 2009 10:27:00 +0930
On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
gcc permitting variable length arrays makes the current construct
used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
if the controlling expression isn't really constant. Instead, this
patch makes it so that a bit field gets used here. Consequently, those
uses where the condition isn't really constant now also need fixing.
Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
if the expression is compile time constant (__builtin_constant_p()
yields true), the array is still deemed of variable length by gcc, and
hence the whole expression doesn't have the intended effect.
Signed-off-by: Jan Beulich jbeul...@novell.com
We used to use an undefined symbol here; diagnostics are worse but it
catches
more stuff.
Perhaps a hybrid is the way to go?
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
#else
/* If it's a constant, catch it at compile time, otherwise at link time. */
extern int __build_bug_on_failed;
#define BUILD_BUG_ON(condition) \
do {\
((void)sizeof(char[1 - 2*!!(condition)])); \
if (condition) __build_bug_on_failed = 1; \
} while(0)
#endif
Thanks,
Rusty.
--
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 15/27] Add mfdec emulation
On Tue, 2009-09-29 at 10:18 +0200, Alexander Graf wrote:
We support setting the DEC to a certain value right now. Doing that basically
triggers the CPU local timer.
But there's also an mfdec command that enabled the OS to read the decrementor.
This is required at least by all desktop and server PowerPC Linux kernels. It
can't really hurt to allow embedded ones to do it as well though.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/emulate.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 7737146..50d411d 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -66,12 +66,14 @@
void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
{
+ unsigned long nr_jiffies;
+
if (vcpu-arch.tcr TCR_DIE) {
/* The decrementer ticks at the same rate as the timebase, so
* that's how we convert the guest DEC value to the number of
* host ticks. */
- unsigned long nr_jiffies;
+ vcpu-arch.dec_jiffies = mftb();
nr_jiffies = vcpu-arch.dec / tb_ticks_per_jiffy;
mod_timer(vcpu-arch.dec_timer,
get_jiffies_64() + nr_jiffies);
@@ -211,6 +213,15 @@ int kvmppc_emulate_instruction(struct kvm_run *run,
struct kvm_vcpu *vcpu)
/* Note: SPRG4-7 are user-readable, so we don't get
* a trap. */
+ case SPRN_DEC:
+ {
+ u64 jd = mftb() - vcpu-arch.dec_jiffies;
+ vcpu-arch.gpr[rt] = vcpu-arch.dec - jd;
+#ifdef DEBUG_EMUL
+ printk(KERN_INFO mfDEC: %x - %llx = %lx\n,
vcpu-arch.dec, jd, vcpu-arch.gpr[rt]);
+#endif
+ break;
+ }
default:
emulated = kvmppc_core_emulate_mfspr(vcpu,
sprn, rt);
if (emulated == EMULATE_FAIL) {
mftb() doesn't exist for ppc32, so we'll need to use the get_tb()
wrapper instead.
--
Hollis Blanchard
IBM Linux Technology Center
--
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 02/27] Pass PVR in sregs
On Tue, 2009-09-29 at 10:17 +0200, Alexander Graf wrote:
Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.
KVM on BookE always virtualizes the host CPU. On Book3s we go a step further
and take the PVR from userspace that tells us what kind of CPU we are supposed
to virtualize, because we support Book3s_32 and Book3s_64 guests.
In order to get that information, we use the sregs ioctl, because we don't
want to reset the guest CPU on every normal register set.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index bb2de6a..b82bd68 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,6 +46,8 @@ struct kvm_regs {
};
struct kvm_sregs {
+ __u64 pvr;
+ char pad[1016];
};
struct kvm_fpu {
Architecturally, PVR is 32 bits, even for PPC64. Is there a reason you
want it to be 64 bits here? (I can understand just picking 64 for
registers that could be either size, but that's not this case.)
--
Hollis Blanchard
IBM Linux Technology Center
--
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 25/27] Fix trace.h
On Tue, 2009-09-29 at 10:18 +0200, Alexander Graf wrote: It looks like the variable pc is defined. At least the current code always failed on me stating that pc is already defined somewhere else. Let's use _pc instead, because that doesn't collide. Is this the right approach? Does it break on 440 too? If not, why not? Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/kvm/trace.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h index 67f219d..a8e8400 100644 --- a/arch/powerpc/kvm/trace.h +++ b/arch/powerpc/kvm/trace.h @@ -12,8 +12,8 @@ * Tracepoint for guest mode entry. */ TRACE_EVENT(kvm_ppc_instr, - TP_PROTO(unsigned int inst, unsigned long pc, unsigned int emulate), - TP_ARGS(inst, pc, emulate), + TP_PROTO(unsigned int inst, unsigned long _pc, unsigned int emulate), + TP_ARGS(inst, _pc, emulate), TP_STRUCT__entry( __field(unsigned int, inst) @@ -23,7 +23,7 @@ TRACE_EVENT(kvm_ppc_instr, TP_fast_assign( __entry-inst = inst; - __entry-pc = pc; + __entry-pc = _pc; __entry-emulate= emulate; ), After much digging, I managed to actually enable CONFIG_TRACEPOINTS. However, I still don't get any build errors from this code. Maybe you could paste the full gcc output? -- Hollis Blanchard IBM Linux Technology Center -- 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] Use Little Endian for Dirty Bitmap
On Mon, 2009-07-27 at 12:38 +0200, Alexander Graf wrote: We currently use host endian long types to store information in the dirty bitmap. This works reasonably well on Little Endian targets, because the u32 after the first contains the next 32 bits. On Big Endian this breaks completely though, forcing us to be inventive here. So Ben suggested to always use Little Endian, which looks reasonable. We only have dirty bitmap implemented in Little Endian targets so far and since PowerPC would be the first Big Endian platform, we can just as well switch to Little Endian always with little effort without breaking existing targets. Signed-off-by: Alexander Graf ag...@suse.de --- virt/kvm/kvm_main.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 17d8688..3482ad1 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -48,6 +48,7 @@ #include asm/io.h #include asm/uaccess.h #include asm/pgtable.h +#include asm-generic/bitops/le.h #ifdef KVM_COALESCED_MMIO_PAGE_OFFSET #include coalesced_mmio.h @@ -1656,8 +1657,8 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn) unsigned long rel_gfn = gfn - memslot-base_gfn; /* avoid RMW */ - if (!test_bit(rel_gfn, memslot-dirty_bitmap)) - set_bit(rel_gfn, memslot-dirty_bitmap); + if (!generic_test_le_bit(rel_gfn, memslot-dirty_bitmap)) + generic___set_le_bit(rel_gfn, memslot-dirty_bitmap); } } I don't think I've ever exercised the dirty bitmap code, and I don't really have an opinion. Avi? -- Hollis Blanchard IBM Linux Technology Center -- 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 01/23] Pass PVR in sregs
Hi Avi, would you apply this patch? Looks like the corresponding qemu
patch went in a while ago, so the qemu build has been broken for some
time.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
--
Hollis Blanchard
IBM Linux Technology Center
On Thu, 2009-07-16 at 15:29 +0200, Alexander Graf wrote:
Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.
KVM on BookE always virtualizes the host CPU. On Book3s we go a step further
and take the PVR from userspace that tells us what kind of CPU we are supposed
to virtualize, because we support Book3s_32 and Book3s_64 guests.
In order to get that information, we use the sregs ioctl, because we don't
want to reset the guest CPU on every normal register set.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index bb2de6a..b82bd68 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,6 +46,8 @@ struct kvm_regs {
};
struct kvm_sregs {
+ __u64 pvr;
+ char pad[1016];
};
struct kvm_fpu {
--
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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Wed, 2009-09-02 at 15:40 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote: KVM for PowerPC only supports embedded cores at the moment. While it makes sense to virtualize on small machines, it's even more fun to do so on big boxes. So I figured we need KVM for PowerPC64 as well. This patchset implements KVM support for Book3s_64 hosts and guest support for Book3s_64 and G3/G4. To really make use of this, you will also need a modified version of qemu that can deal with KVM on desktop cores. I will send out patches for those later, but want to get feedback on the kernel side first. In the meanwhile, use the qemu version from http://www.powerkvm.org/powerkvm.git which already includes all required patches to run G3/G4 and G5 guests. The git pull request is good when the series is good to pull or for testing, but for review patches are nice :-) Yeah, I actually went looking for the v3 patchset last week, and gave up trying to extract it from git... -- Hollis Blanchard IBM Linux Technology Center -- 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 4/5] kvmppc: Translate eaddr for fsl_booke mmu
On Tue, 2009-08-04 at 17:36 +0800, Liu Yu wrote:
Signed-off-by: Liu Yu yu@freescale.com
---
target-ppc/helper.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 6eca2e5..07e56a4 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -22,6 +22,7 @@
#include string.h
#include inttypes.h
#include signal.h
+#include linux/kvm.h
#include cpu.h
#include exec-all.h
@@ -1325,8 +1326,20 @@ static always_inline int check_physical (CPUState
*env, mmu_ctx_t *ctx,
cpu_abort(env, MPC8xx MMU model is not implemented\n);
break;
case POWERPC_MMU_BOOKE_FSL:
-/* XXX: TODO */
-cpu_abort(env, BookE FSL MMU model not implemented\n);
+if (kvm_enabled()) {
+struct kvm_translation tr;
+
+/* For now we only debug guest kernel */
+tr.linear_address = eaddr;
+ret = kvm_vcpu_ioctl(env, KVM_TRANSLATE, tr);
+if (ret 0)
+return ret;
+
+ctx-raddr = tr.physical_address;
+} else {
+/* XXX: TODO */
+cpu_abort(env, BookE FSL MMU model not implemented\n);
+}
break;
default:
cpu_abort(env, Unknown or invalid MMU model\n);
One objection: the comment is a little obscure. I think what you're
really saying is in Linux guests, kernel addresses should always be
covered by TLB1, which means for those addresses we can expect this
ioctl to succeed. However, since you need to handle failures anyways, I
think you should remove the comment entirely.
Second, (and this isn't an objection but rather a question) do you have
any better ideas for struct kvm_translation? It only really makes sense
for x86. We don't need to stick with it.
--
Hollis Blanchard
IBM Linux Technology Center
--
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 BookE and SPRGs
On Fri, 2009-07-10 at 19:17 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-10 at 17:15 +0800, Liu Yu-B13201 wrote: Sounds reasonable. There are some old patchset which implemented the binary patch as Ben described. http://marc.info/?l=kvm-ppcm=122154653905212w=2 http://marc.info/?l=kvm-ppcm=122154657905306w=2 Interesting. Any reason why that wasn't merged ? Basically because we ran out of manpower to maintain it. We didn't want to push PV changes into upstream Linux, useful only to us, and then disappear. -- Hollis Blanchard IBM Linux Technology Center -- 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 BookE and SPRGs
On Fri, 2009-07-10 at 18:10 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-10 at 16:31 +1000, Benjamin Herrenschmidt wrote: I was roaming through kernel usage of SPRGs and noticed a small detail in kvmppc for BookE ... any reason why in OP_31_XOP_MTSPR, you open coded the emulation of SPRG0..3, but 4...7 are handled in kvmppc_core_emulate_mtspr() ? It occurs to me that in fact for both MTSPR and MFSPR, the code should be moved into kvmppc_core_emulate_mtspr() and kvmppc_core_emulate_mfspr() for consistency. Also, from looking at the FSL BookE code, it seems that there is such a thing as SPRG9 (and so I suppose there must be an SPRG8 somewhere too), shouldn't we handle it too ? BTW. That leads me to another question (CC'ing Avi there too), which is what is the policy vs. para-virtualization ? IE. Are we ok with adding paravirt tricks to speed things up ? Yes, that's fine. We would rather not *require* paravirtualization though. A prime example I have in mind that could possibly help a lot here is to have a shared page mapped at -4K (at the top of the address space) when the guest is in supervisor mode only that hosts part of the current VCPU supervisor register state. ... The cost of course is an additional TLB entry for mapping that -4K page (but only when running guest kernel code). It was a net win when Christian implemented it last year. While the first access may miss in the TLB, these register accesses tend to come in bunches (i.e. the guest interrupt vectors). -- Hollis Blanchard IBM Linux Technology Center -- 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 01/23] Pass PVR in sregs
On Wed, 2009-07-08 at 10:28 +0800, Liu Yu-B13201 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf Sent: Wednesday, July 08, 2009 7:23 AM To: Hollis Blanchard Cc: Avi Kivity; kvm-ppc@vger.kernel.org; a...@arndb.de; kw...@redhat.com Subject: Re: [PATCH 01/23] Pass PVR in sregs On 08.07.2009, at 00:50, Hollis Blanchard wrote: The PVR register is basically the equivalent of cpuid. It might make more sense to exit to qemu to handle those accesses. Today, PVR reads are emulated in-kernel. I actually use it in 970.c to find out which guest MMU to choose from. So even if we were to do it in userspace, we'd still need the information what CPU to create in the guest on the kernel side. Which in turn means we don't win anything from leaving the PVR emulation to userspace. Hmm, I don't remember where arch-vcpu.pvr is being set at all for 440 and e500... It used to be in some creation code - either general kvm or vcpu. But some recent patch removed vcpu-arch.pvr and made emulate.c do an mfspr(SPRN_PVR). Yes. Since the demand to emulate PVR for 440 and e500 is still vague. Directly return the real value can simplify the code, and latter patches can easily change it. The same thing goes for PIR. By the way, I don't like that PVR patch you sent to Avi (and he committed). It's my own fault for not reading more closely, but in the future could you send me patches that touch code which isn't e500-specific? -- Hollis Blanchard IBM Linux Technology Center -- 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 01/23] Pass PVR in sregs
On Tue, 2009-07-07 at 18:40 +0300, Avi Kivity wrote:
On 07/07/2009 05:17 PM, Alexander Graf wrote:
Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.
KVM on BookE always virtualizes the host CPU. On PPC64 we go a step further
and take the PVR from userspace that tells us what kind of CPU we are
supposed
to virtualize, because we support PPC32 and PPC64 guests.
In order to get that information, we use the sregs ioctl, because we don't
want to reset the guest CPU on every normal register set.
Signed-off-by: Alexander Grafag...@suse.de
---
arch/powerpc/include/asm/kvm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index bb2de6a..96b02cd 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,6 +46,7 @@ struct kvm_regs {
};
struct kvm_sregs {
+ __u64 pvr;
};
You can only do that if existing userspace never calls KVM_SET_SREGS.
Hollis?
It doesn't.
Also, make sure to reserve a bunch of space in there so you if you
forget something you can add it later.
Agreed.
The PVR register is basically the equivalent of cpuid. It might make
more sense to exit to qemu to handle those accesses. Today, PVR reads
are emulated in-kernel.
Hmm, I don't remember where arch-vcpu.pvr is being set at all for 440
and e500...
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: ppc: beyond ARRAY_SIZE of vcpu_44x-guest_tlb
On Wed, 2009-05-20 at 00:50 +0200, Roel Kluin wrote:
Do not go beyond ARRAY_SIZE of vcpu_44x-guest_tlb
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
index 4a16f47..6093289 100644
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -439,7 +439,7 @@ int kvmppc_44x_emul_tlbwe(struct kvm_vcpu *vcpu, u8 ra,
u8 rs, u8 ws)
unsigned int gtlb_index;
gtlb_index = vcpu-arch.gpr[ra];
- if (gtlb_index KVM44x_GUEST_TLB_SIZE) {
+ if (gtlb_index = KVM44x_GUEST_TLB_SIZE) {
printk(%s: index %d\n, __func__, gtlb_index);
kvmppc_dump_vcpu(vcpu);
return EMULATE_FAIL;
Acked-by: Hollis Blanchard holl...@us.ibm.com
Thanks.
--
Hollis Blanchard
IBM Linux Technology Center
--
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 04/04] qemu-kvm: other archs should maintain memory mappingalso.
On Mon, 2009-05-04 at 11:25 +0200, Jes Sorensen wrote: Avi Kivity wrote: Jes Sorensen wrote: +int destroy_region_works = 0; Global name, prefix with kvm_. Does it actually need to be global? Gone, now local to qemu-kvm-x86.c. I moved the initializer into kvm_arch_create_context() instead. The header depends on target_phys_addr_t, so it must include whatever defines it. Added an #include cpu-all.h which defines it. Missing other archs... Instead of duplicating this for every arch, you can have a #define that tells you if you want non-trivial arch definitions, and supply the trivial definitions in qemu-kvm.h. Done, I also added a PPC header file - which may or may not be wanted at this point. You can just cut it out if you don't think it should be added. I don't understand the code being moved, but I guess I don't want it, so your patch is fine with me. (Wtf are those magic addresses? And not a single comment?? Aren't we better than this?) -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Wed, 2009-04-29 at 11:31 +0300, Avi Kivity wrote: Hollis Blanchard wrote: Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. For reference, the actual error is about a hundred instances of e.g. /home/hollisb/source/qemu-kvm.git/vl.c:3393: undefined reference to `kvm_allowed' -- Hollis Blanchard IBM Linux Technology Center -- 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
[PATCH 1/5] [libkvm] Rename config-powerpc to config-ppc
Apparently $(ARCH) now holds the qemu meaning, rather than the KVM meaning. Signed-off-by: Hollis Blanchard holl...@us.ibm.com --- kvm/libkvm/config-powerpc.mak |4 kvm/libkvm/config-ppc.mak |4 2 files changed, 4 insertions(+), 4 deletions(-) delete mode 100644 kvm/libkvm/config-powerpc.mak create mode 100644 kvm/libkvm/config-ppc.mak diff --git a/kvm/libkvm/config-powerpc.mak b/kvm/libkvm/config-powerpc.mak deleted file mode 100644 index 091da37..000 --- a/kvm/libkvm/config-powerpc.mak +++ /dev/null @@ -1,4 +0,0 @@ - -LIBDIR := /lib - -libkvm-$(ARCH)-objs := libkvm-powerpc.o diff --git a/kvm/libkvm/config-ppc.mak b/kvm/libkvm/config-ppc.mak new file mode 100644 index 000..091da37 --- /dev/null +++ b/kvm/libkvm/config-ppc.mak @@ -0,0 +1,4 @@ + +LIBDIR := /lib + +libkvm-$(ARCH)-objs := libkvm-powerpc.o -- 1.6.0.6 -- 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
[PATCH 2/5] [qemu-kvm] Fix warning when__ia64__ is not defined.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com --- kvm/libkvm/kvm-common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kvm/libkvm/kvm-common.h b/kvm/libkvm/kvm-common.h index 96361e8..591fb53 100644 --- a/kvm/libkvm/kvm-common.h +++ b/kvm/libkvm/kvm-common.h @@ -22,7 +22,7 @@ #define KVM_MAX_NUM_MEM_REGIONS 1u #define MAX_VCPUS 64 #define LIBKVM_S390_ORIGIN (0UL) -#elif __ia64__ +#elif defined(__ia64__) #define KVM_MAX_NUM_MEM_REGIONS 32u #define MAX_VCPUS 256 #else -- 1.6.0.6 -- 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
[PATCH 3/5] [qemu-kvm] Fix missing prototype warning.
As far as I can see, kvm_destroy_memory_region_works() has nothing to do with KVM_CAP_DEVICE_ASSIGNMENT, so move the prototype outside that ifdef block. Signed-off-by: Hollis Blanchard holl...@us.ibm.com --- kvm/libkvm/libkvm.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kvm/libkvm/libkvm.h b/kvm/libkvm/libkvm.h index ce6f054..c23d37b 100644 --- a/kvm/libkvm/libkvm.h +++ b/kvm/libkvm/libkvm.h @@ -739,6 +739,7 @@ int kvm_assign_irq(kvm_context_t kvm, int kvm_deassign_irq(kvm_context_t kvm, struct kvm_assigned_irq *assigned_irq); #endif +#endif /*! * \brief Determines whether destroying memory regions is allowed @@ -748,7 +749,6 @@ int kvm_deassign_irq(kvm_context_t kvm, * \param kvm Pointer to the current kvm_context */ int kvm_destroy_memory_region_works(kvm_context_t kvm); -#endif #ifdef KVM_CAP_DEVICE_DEASSIGNMENT /*! -- 1.6.0.6 -- 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
[PATCH 4/5] [qemu-kvm] Use CAP_IRQ_ROUTING in kvm_get_irq_route_gsi()
This fixes a build break when KVM_IOAPIC_NUM_PINS is not defined.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
kvm/libkvm/libkvm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kvm/libkvm/libkvm.c b/kvm/libkvm/libkvm.c
index 0610e3f..ba0a5d1 100644
--- a/kvm/libkvm/libkvm.c
+++ b/kvm/libkvm/libkvm.c
@@ -1406,6 +1406,7 @@ int kvm_commit_irq_routes(kvm_context_t kvm)
int kvm_get_irq_route_gsi(kvm_context_t kvm)
{
+#ifdef KVM_CAP_IRQ_ROUTING
if (kvm-max_used_gsi = KVM_IOAPIC_NUM_PINS) {
if (kvm-max_used_gsi = kvm_get_gsi_count(kvm))
return kvm-max_used_gsi + 1;
@@ -1413,6 +1414,9 @@ int kvm_get_irq_route_gsi(kvm_context_t kvm)
return -ENOSPC;
} else
return KVM_IOAPIC_NUM_PINS;
+#else
+ return -ENOSYS;
+#endif
}
#ifdef KVM_CAP_DEVICE_MSIX
--
1.6.0.6
--
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
[PATCH 5/5] patch add_powerpc_kvm_headers.diff
---
kvm/kernel/arch/powerpc/include/asm/kvm.h | 102 +++
kvm/kernel/arch/powerpc/include/asm/kvm_44x.h | 108 +++
kvm/kernel/arch/powerpc/include/asm/kvm_asm.h | 100 ++
kvm/kernel/arch/powerpc/include/asm/kvm_e500.h | 107 +++
kvm/kernel/arch/powerpc/include/asm/kvm_host.h | 232
kvm/kernel/arch/powerpc/include/asm/kvm_para.h | 77
kvm/kernel/arch/powerpc/include/asm/kvm_ppc.h | 137 ++
7 files changed, 863 insertions(+), 0 deletions(-)
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm.h
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm_44x.h
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm_asm.h
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm_e500.h
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm_host.h
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm_para.h
create mode 100644 kvm/kernel/arch/powerpc/include/asm/kvm_ppc.h
diff --git a/kvm/kernel/arch/powerpc/include/asm/kvm.h
b/kvm/kernel/arch/powerpc/include/asm/kvm.h
new file mode 100644
index 000..c4f1ed1
--- /dev/null
+++ b/kvm/kernel/arch/powerpc/include/asm/kvm.h
@@ -0,0 +1,102 @@
+#ifndef KVM_UNIFDEF_H
+#define KVM_UNIFDEF_H
+
+#ifdef __i386__
+#ifndef CONFIG_X86_32
+#define CONFIG_X86_32 1
+#endif
+#endif
+
+#ifdef __x86_64__
+#ifndef CONFIG_X86_64
+#define CONFIG_X86_64 1
+#endif
+#endif
+
+#if defined(__i386__) || defined (__x86_64__)
+#ifndef CONFIG_X86
+#define CONFIG_X86 1
+#endif
+#endif
+
+#ifdef __ia64__
+#ifndef CONFIG_IA64
+#define CONFIG_IA64 1
+#endif
+#endif
+
+#ifdef __PPC__
+#ifndef CONFIG_PPC
+#define CONFIG_PPC 1
+#endif
+#endif
+
+#ifdef __s390__
+#ifndef CONFIG_S390
+#define CONFIG_S390 1
+#endif
+#endif
+
+#endif
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2007
+ *
+ * Authors: Hollis Blanchard holl...@us.ibm.com
+ */
+
+#ifndef __LINUX_KVM_POWERPC_H
+#define __LINUX_KVM_POWERPC_H
+
+#include linux/types.h
+
+struct kvm_regs {
+ __u64 pc;
+ __u64 cr;
+ __u64 ctr;
+ __u64 lr;
+ __u64 xer;
+ __u64 msr;
+ __u64 srr0;
+ __u64 srr1;
+ __u64 pid;
+
+ __u64 sprg0;
+ __u64 sprg1;
+ __u64 sprg2;
+ __u64 sprg3;
+ __u64 sprg4;
+ __u64 sprg5;
+ __u64 sprg6;
+ __u64 sprg7;
+
+ __u64 gpr[32];
+};
+
+struct kvm_sregs {
+};
+
+struct kvm_fpu {
+ __u64 fpr[32];
+};
+
+struct kvm_debug_exit_arch {
+};
+
+/* for KVM_SET_GUEST_DEBUG */
+struct kvm_guest_debug_arch {
+};
+
+#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/kvm/kernel/arch/powerpc/include/asm/kvm_44x.h
b/kvm/kernel/arch/powerpc/include/asm/kvm_44x.h
new file mode 100644
index 000..956f252
--- /dev/null
+++ b/kvm/kernel/arch/powerpc/include/asm/kvm_44x.h
@@ -0,0 +1,108 @@
+#ifndef KVM_UNIFDEF_H
+#define KVM_UNIFDEF_H
+
+#ifdef __i386__
+#ifndef CONFIG_X86_32
+#define CONFIG_X86_32 1
+#endif
+#endif
+
+#ifdef __x86_64__
+#ifndef CONFIG_X86_64
+#define CONFIG_X86_64 1
+#endif
+#endif
+
+#if defined(__i386__) || defined (__x86_64__)
+#ifndef CONFIG_X86
+#define CONFIG_X86 1
+#endif
+#endif
+
+#ifdef __ia64__
+#ifndef CONFIG_IA64
+#define CONFIG_IA64 1
+#endif
+#endif
+
+#ifdef __PPC__
+#ifndef CONFIG_PPC
+#define CONFIG_PPC 1
+#endif
+#endif
+
+#ifdef __s390__
+#ifndef CONFIG_S390
+#define CONFIG_S390 1
+#endif
+#endif
+
+#endif
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors: Hollis Blanchard holl...@us.ibm.com
+ */
+
+#ifndef __ASM_44X_H__
+#define __ASM_44X_H__
+
+#include linux/kvm_host.h
+
+#define PPC44x_TLB_SIZE 64
+
+/* If the guest is expecting it, this can be as large as we like; we'd just
+ * need
Re: [Qemu-devel] [PATCH 4/7] kvm: Add sanity checks to slot management
On Wed, 2009-04-29 at 12:38 +0200, Jan Kiszka wrote: Liu Yu-B13201 wrote: -Original Message- From: qemu-devel-bounces+yu.liu=freescale@nongnu.org [mailto:qemu-devel-bounces+yu.liu=freescale@nongnu.org] On Behalf Of Jan Kiszka Sent: Sunday, April 12, 2009 1:20 AM To: qemu-de...@nongnu.org Subject: [Qemu-devel] [PATCH 4/7] kvm: Add sanity checks to slot management Fail loudly if we run out of memory slot. Make sure that dirty log start/stop works with consistent memory regions by reporting invalid parameters. This reveals several inconsistencies in the vga code, patch to fix them follows later in this series. And, for simplicity reasons, also catch and report unaligned memory regions passed to kvm_set_phys_mem (KVM works on page basis). Commit d3f8d37fe2d0c24ec8bac9c94d5b0e2dc09c0d2a hurts kvm/powerpc The alignment check in kvm_set_phys_mem prevents pci controller and mpic initializing mmio regions. What is the alignment of those regions then? None? And do regions of different types overlap even on the same page? Maybe the check reveals some deeper conflict /wrt KVM. Can you point me to the involved code files? These PCI controllers make separate calls to cpu_register_physical_memory() for separate callbacks. Reading ppce500_pci_init(), for example: 0xe0008000 - CFGADDR (4 bytes) 0xe0008004 - CFGDATA (4 bytes) 0xe0008c00 - other registers The loop in cpu_register_physical_memory_offset() handles subpage registration. However, kvm_set_phys_mem() is called outside that loop, so it gets the non-page-aligned addresses. -- Hollis Blanchard IBM Linux Technology Center -- 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/7] kvm: Add sanity checks to slot management
On Wed, 2009-04-29 at 19:30 +0200, Jan Kiszka wrote:
Hollis Blanchard wrote:
On Wed, 2009-04-29 at 12:38 +0200, Jan Kiszka wrote:
Liu Yu-B13201 wrote:
-Original Message-
From: qemu-devel-bounces+yu.liu=freescale@nongnu.org
[mailto:qemu-devel-bounces+yu.liu=freescale@nongnu.org]
On Behalf Of Jan Kiszka
Sent: Sunday, April 12, 2009 1:20 AM
To: qemu-de...@nongnu.org
Subject: [Qemu-devel] [PATCH 4/7] kvm: Add sanity checks to
slot management
Fail loudly if we run out of memory slot.
Make sure that dirty log start/stop works with consistent
memory regions
by reporting invalid parameters. This reveals several
inconsistencies in
the vga code, patch to fix them follows later in this series.
And, for simplicity reasons, also catch and report unaligned memory
regions passed to kvm_set_phys_mem (KVM works on page basis).
Commit d3f8d37fe2d0c24ec8bac9c94d5b0e2dc09c0d2a hurts kvm/powerpc
The alignment check in kvm_set_phys_mem prevents pci controller and mpic
initializing mmio regions.
What is the alignment of those regions then? None? And do regions of
different types overlap even on the same page? Maybe the check reveals
some deeper conflict /wrt KVM. Can you point me to the involved code files?
These PCI controllers make separate calls to
cpu_register_physical_memory() for separate callbacks. Reading
ppce500_pci_init(), for example:
0xe0008000 - CFGADDR (4 bytes)
0xe0008004 - CFGDATA (4 bytes)
0xe0008c00 - other registers
The loop in cpu_register_physical_memory_offset() handles subpage
registration. However, kvm_set_phys_mem() is called outside that loop,
so it gets the non-page-aligned addresses.
Half-blind shot:
diff --git a/kvm-all.c b/kvm-all.c
index 32cd636..c2c760e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -583,6 +583,9 @@ void kvm_set_phys_mem(target_phys_addr_t start_addr,
int err;
if (start_addr ~TARGET_PAGE_MASK) {
+if (flags = IO_MEM_UNASSIGNED) {
+return;
+}
fprintf(stderr, Only page-aligned memory slots supported\n);
abort();
}
If it works, it likely needs a cleaner approach to handle all cases.
I don't understand the point. kvm_set_phys_mem() already works without
this new abort() check.
--
Hollis Blanchard
IBM Linux Technology Center
--
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/7] kvm: Add sanity checks to slot management
On Wed, 2009-04-29 at 12:38 -0500, Anthony Liguori wrote: Hollis Blanchard wrote: On Wed, 2009-04-29 at 12:38 +0200, Jan Kiszka wrote: What is the alignment of those regions then? None? And do regions of different types overlap even on the same page? Maybe the check reveals some deeper conflict /wrt KVM. Can you point me to the involved code files? These PCI controllers make separate calls to cpu_register_physical_memory() for separate callbacks. Reading ppce500_pci_init(), for example: 0xe0008000 - CFGADDR (4 bytes) 0xe0008004 - CFGDATA (4 bytes) 0xe0008c00 - other registers That's goofy. If the single device owns the entire region, it should region the entire region instead of relying on subpage functionality. If just requires a switch() on the address to dispatch to the appropriate functions. It should be easy enough to fix. There are two cases that share this code path: 1) same driver registers multiple regions in the same page 2) different drivers register regions in the same page This is case 1, and as you say, we could add a switch statement to handle it. I did not look closely to see how many other callers fall into this category. However, are you suggesting that case 2 is also goofy and will never work with KVM? It works in qemu today. As long as case 2 works, case 1 will work too, so why change anything? -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Some of the bigger problems: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. * The headers in kvm/kernel/arch/foo seem to be the important ones, but they have odd ifdefs at the top and I'm not sure how they should be generated. * make -C kvm/kernel sync doesn't even come close to working. There are a host of other issues and confusing issues, even with a fresh checkout. In general it seems like the mess that was kvm-userspace has been rearranged, and as a consequence is even worse than before. How am I supposed to create kvm/kernel/arch/powerpc/include/asm/*? Just cp from a Linux tree, or must I add funny ifdefs somehow? Here's one patch that I think will be needed: Set kvm_arch=powerpc for PPC builds. The name of the Linux arch directory is powerpc, not ppc. Signed-off-by: Hollis Blanchard holl...@us.ibm.com diff --git a/configure b/configure index fc0fb9b..257cf02 100755 --- a/configure +++ b/configure @@ -816,6 +816,9 @@ case $cpu in i386 | x86_64) kvm_arch=x86 ;; +ppc) + kvm_arch=powerpc + ;; *) kvm_arch=$cpu ;; -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Tue, 2009-04-28 at 17:20 -0500, Anthony Liguori wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. Since it's a safe bet that some version of this code will probably be submitted to qemu-devel, I figured I'd try a build test... and discovered that qemu-kvm.git was released a little prematurely. -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Tue, 2009-04-28 at 17:28 -0500, Anthony Liguori wrote: Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? The more people who notice when the PowerPC build breaks, the better. -- Hollis Blanchard IBM Linux Technology Center -- 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: [Lguest] powerpc64 port anyone?
On Wed, 2009-04-22 at 18:03 +0400, Wartan Hachaturow wrote: On 4/22/09, Rusty Russell ru...@rustcorp.com.au wrote: Well, I think the x86_64 port is dead; nothing has been done on it in over a year. POWER could be done, but you'd have to know a lot about POWER (or learn a lot about POWER). As far as I understand, major issues would be to make lguest 64-bit, and invent a POWER replacement for your creative use of i386 segmentation. I need to refresh my memories on power memory management :) Probably, a powerpc32 would be easier for a start -- and benefit those lacking PowerVM :) Probably easier, yeah. It looks like powerpc is currently missing any kind of software virtualization: kvm is x86, XenPPC seems to be dead, and so is OpenVZ's powerpc port. KVM supports embedded PowerPC (440 and e500 at the moment), and there has been some work to port it to ppc64 cores like 970 (without using the hardware extensions, since these are unavailable on shipping systems). If you're interested, you should check out the trees at http://powerkvm.org . What hardware do you have available? Qemu has made great progress in PowerPC target support in the last 6 months, and that can be very convenient even when you have real hardware. -- Hollis Blanchard IBM Linux Technology Center -- 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: Fwd: Upstream QEMU vs kvm modified for ARM implementation
On Tue, 2009-04-07 at 14:30 -0400, Christoffer Dall wrote: A few questions regarding the upstream version: - Apart from issues like SMP, are you aware of any specific problems with the upstream version that we should be aware of? I don't know the full status off the top of my head (you might ask on qemu-devel), but many of them don't matter on non-x86 platforms. For example, I think qemu still doesn't support x86's in-kernel APIC emulation... but that's irrelevant for us. - Does the upstream QEMU code use the libkvm code as well or is all the logic placed in kvm-all.c and in the target specific kvm.c files? The latter. libkvm has a questionable future. - Is compiling against a patched kernel (as opposed to using a module) and doing sync-headers from custom source supported in the upstream version? I have only used a real kernel build. I've had nothing but trouble with the kvm-userspace/kernel directory. Also, for technical reasons, the 440/e500 KVM build doesn't work as a module (we assume we will not take a TLB miss when handling guest exits). Any specific tag of the QEMU git repository you recommend working from, or would the latest commit usually be trustworthy? :) The latest is fairly trustworthy. There is a relatively high patch rate, but most of it is in areas that don't affect us. Regarding the design of things, why was it necessary to hijack all interrupt vectors in the kernel. We are wondering if it wouldn't be sufficient to hijack synchronous interrupts and let QEMU take care of all I/O, timer interrupts etc. Are we missing something here? We would love to do that, but the biggest problem is that the host interrupt handlers don't know about guest state. PowerPC hardware does not switch the stack pointer for you; it's a software decision. When the host kernel sees the interrupt occurred in user mode, it switches the stack pointer to the top of the kernel stack. (If the interrupt occurred in kernel mode, the stack pointer is just decremented, preserving the kernel call stack.) When we run the guest, we run it in user mode. Since that's done via ioctl, there are frames from the ioctl path on the kernel stack. So if a host handler sees came from user mode and resets the kernel stack, we will clobber the ioctl stack frames. Anyways, the really high-level overview of our async handler path is that we restore host kernel register state then re-invoke the interrupt, so the host handlers will deal with it anyways. Note that (in general) with KVM, Qemu only handles IO. KVM handles all core emulation, including instructions, the MMU, and the decrementer (PowerPC's in-core timer interrupt source). -- Hollis Blanchard IBM Linux Technology Center -- 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 Port
On Sun, 2009-04-05 at 00:11 +0530, kvm port wrote: ok, so these are a few steps to begin (a) add a QEMUMachine for my h/w in qemu As an alternative, you could start exercising KVM kernel code using kvm-userspace/test before qemu is ready. (b) Add arch support in kvm I have a few questions (a) qemu starts in user space, how would I configure my linux. Should the linux run in Hypervisor state and the apps run in user state, and nothing runs in guest state [ there are 3 states in my processor] Are there only 3, or are there two independent dimensions (hypervisor/guest, user/supervisor)? If there are only 3, you'll need to figure out how to isolate guest kernel and guest userspace from each other. (b) qemu starts the VM and somehow ( i dont know yet, how?) , starts my code in processor guest state Why are you asking us? You are the processor expert... :) Qemu calls into KVM via an ioctl, and processor-specific KVM code (that's you) somehow jumps into guest mode. -- Hollis Blanchard IBM Linux Technology Center -- 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: MMU tricks for NetBSD guests
On Fri, 2009-04-03 at 00:52 +0200, Alexander Graf wrote: That sounds a lot like what I imlemented for real mode on 970. I assume the PID is similar to a full SLB context and AS=1/AS=0 is just another bit that could as well be in the PID? Mostly... however, when an interrupt occurs, AS is set to 0 and PID remains unchanged. Also, AS can have different settings for instruction and data fetches. (I've been abbreviating as MSR[AS], but technically I should be writing MSR[IS] for instructions or MSR[DS] for data). So what we do on 970[1] is we treat real mode as yet another vsid. 970 translates EA - VA - RA. It looks like booke does the same, with the VSID coming from the PID. Exactly -- Book E uses AS | PID to provide the VSID, while Book S uses the SLB. The Book E way is much simpler, and also avoids the effective address collision problem we ran into on 970, because AS/PID don't depend on the EA. -- Hollis Blanchard IBM Linux Technology Center -- 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: PowerPC KVM build directions
On Thu, 2009-04-02 at 10:52 +0800, Liu Yu-B13201 wrote: Since KVM supports a NetBSD 4.0 guest (I think) and 8544/e500 emulation is already present in qemu -- theoretically the first part should work...but I recall Liu mentioning that there might be some OS specific quirks present in the port...and that was what I my question was hinting at earlier.. There must be a lot of differences between Linux and NetBSD. So the design of kvmppc may not be careful considerate. The main trick is to hijack the system interrupts. You should check if this part of code cater to NetBSD. Context switch needs to be taken care as well. At least there is one thing I can point out. See comments in the file booke_interrupts.S line 195. :-) Liu, you're talking about BSD as the *host*. Rahul is asking about BSD as the guest. Rahul, one major quirk we exploit is that Linux does not use the MSR[AS] bit at all. One way that bit could be used is to give 32-bit userspace a separate 4GB address space from the kernel. Instead, Linux puts both kernel and userspace into the same 4GB address space (with Linux mappings above 0xc000 and user mappings below). If NetBSD uses MSR[AS]=1 for userspace (which I think is what the hardware architects envisioned), you're going to have a lot of MMU fun. Another potential issue could be the initial environment (described earlier as option 2) not being what BSD expects. Do you use u-boot? You can see the initial environment set up in kvm_arch_vcpu_setup() in KVM and mpc8544ds_init() in Qemu. Does NetBSD use flattened device trees at all? KVM (Qemu) supplies a stripped-down device tree to the guest so that the guest won't try to access IO devices not currently emulated by qemu. If BSD has a hardcoded device configuration system (e.g. we built for 8544, therefore we always have the following SoC devices) that will be an issue. As a concrete example, qemu doesn't emulate the TSEC ethernet controller. You need to either convince your guest not to try to use the TSEC (and use e1000 or some other qemu-supported device instead), or add just enough TSEC emulation to qemu to make your guest happy. That could be as simple as always reporting link down so the guest doesn't try to use it. Please keep us posted about any issues you encounter. Also, documenting the hurdles and how you overcame them might be an interesting conference paper, if you're into that sort of thing. :) -- Hollis Blanchard IBM Linux Technology Center -- 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
NetBSD and device trees
(I'll address the MMU issue in a separate mail.) On Thu, 2009-04-02 at 11:56 -0700, Rahul Kulkarni wrote: Another potential issue could be the initial environment (described earlier as option 2) not being what BSD expects. Do you use u-boot? You can see the initial environment set up in kvm_arch_vcpu_setup() in KVM and mpc8544ds_init() in Qemu. Rahul Yes..I will look into those functions..We do use uboot..Are you hinting to go with option 1? If you use u-boot then you might not have much work to do (option 2 will probably work for you with few changes). Does NetBSD use flattened device trees at all? KVM (Qemu) supplies a stripped-down device tree to the guest so that the guest won't try to access IO devices not currently emulated by qemu. If BSD has a hardcoded device configuration system (e.g. we built for 8544, therefore we always have the following SoC devices) that will be an issue. Rahul The device config is hardcoded our NetBSD code base(more so because of the embedded nature it's a preferred way) but since I see NetBSD supported on Qemu..I would think there is a support available for a flattened device tree to be passed in from qemu..I'll look at x86 implementations. Really quick history: Traditionally, desktop/server PowerPC had Open Firmware (IEEE1275). Open Firmware provides runtime services (sometimes including IP stack, disk drivers, filesystems, etc), and those services allow the kernel to retrieve a device tree describing the physical topology of the system. The runtime services (callbacks) are relatively high overhead for embedded systems, so traditionally embedded PowerPC systems used something simpler (ppcboot/u-boot, redboot, CFE, homebrew, etc). These systems usually hardcoded the expected set of IO devices at build time. However, in recent years Linux developers have found that the flexibility granted by the device tree is invaluable, even without the runtime services. So they developed a flat device tree data structure (flat because it's a contiguous in-memory format representing a tree), and had firmware (especially u-boot) pass that tree to the kernel as a binary blob. The takeaway here is that the flat device tree is so far mostly a PowerPC Linux specific concept. Although the idea is beginning to catch on with architectures and kernels, I expect that NetBSD doesn't know anything about it, and x86 Linux doesn't either. So since PowerPC NetBSD has build-time tables describing the hardware it will try to use. I see the following options: 1) Teach NetBSD about flat device trees. Probably a lot of work. 2) Emulate more 85xx hardware in qemu. Maybe an easy to medium amount of work, depending on the complexity and number of the IO devices. 3) Build a special NetBSD kernel with modified tables appropriate for qemu. Probably the easiest/quickest way, but if your long-term goal is to run unmodified NetBSD kernels built for real hardware, this is only a prototyping step. If you have more than one person playing with this, #2 could be done in conjunction with #3, until you've emulated all the necessary devices. Also, if you do #2, you could actually use qemu (without KVM) as a development environment on normal x86 Linux or Windows workstations (I think virtual prototyping or virtual platforms is the buzzword these days). This might be a benefit for your internal software development processes. If there is interest (or maybe even existing work) in the NetBSD community for flat device tree support, you may be able to team up with other developers to tackle problem #1. To find out, I would post to devicetree-disc...@ozlabs.org asking if they've heard of NetBSD work, and also NetBSD/PowerPC mailing lists to see if they've heard of device tree work. -- Hollis Blanchard IBM Linux Technology Center -- 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
MMU tricks for NetBSD guests
On Thu, 2009-04-02 at 11:56 -0700, Rahul Kulkarni wrote: Rahul, one major quirk we exploit is that Linux does not use the MSR[AS] bit at all. One way that bit could be used is to give 32-bit userspace a separate 4GB address space from the kernel. Instead, Linux puts both kernel and userspace into the same 4GB address space (with Linux mappings above 0xc000 and user mappings below). If NetBSD uses MSR[AS]=1 for userspace (which I think is what the hardware architects envisioned), you're going to have a lot of MMU fun. Rahul The NetBSD port for e500/85xx which we have uses the MSR[AS] (IS/DS) for user/kernel address space separation which keep the address spaces split. So that's a major problem to start with. How do we get creative with this to provide guest mappings is something, which has to be explored. Let me know if you have any thoughts.. OK, so this is going to be a fun one if you like this sort of thing. (I like this sort of thing, but unfortunately don't have any time I can commit to it.) I haven't thought through the details all the way, but at a high level here are my thoughts: First, to understand the architecture and the shortcut we're using today, read http://www.linux-kvm.org/page/PowerPC_Book_E_MMU . Now if you don't have the AS shortcut (which you don't), the key observation is that the guest is really is a collection of 4GB address spaces, and those are identified by 9-bit AS|PID. (By the way, does NetBSD use PID1 and PID2? I sure hope not... :) You can treat the 2^9 guest spaces as separate host spaces. When the guest uses a space, reserve a host space for it, and then map guest AS| PID to the host spaces. So for example: * Guest creates a new process and gives it PID 7. * KVM reserves a new host PID. Let's say host PID 23 is available. * Guest creates a mapping (tlbwe) for PID 7, EA 0xc, RA 0x0. * Host intercepts this (it's a privilege violation because guest is running with MSR[PR]=1). * Host already translates real address from guest physical to host physical. Let's say guest physical 0 corresponds to host physical 128M. * Your new code: host *also* translates guest PID (7) to host PID (23). * Resulting shadow mapping: PID 23, EA 0xc000, RA 0x0200. You'll probably want all shadow mappings to have AS=1. In that case, you would treat guest AS=0 PID=7 as a separate host address space from guest AS=1 PID=7. gAS|gPID 0|7 would be hAS|hPID 1|23, and gAS|gPID 1|7 would be hAS|hPID 1|24. In other words, each guest task (PID) will consume two host address spaces (two different host PIDs, one for each guest AS value). Alexander Graf has already done something like this for his 970 work, so he might be able to provide more details or issues to be aware of in a scheme like this. It would be easier to whiteboard, but obviously that's not really an option... -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm/e500: fix bugs
On Mon, 2009-03-16 at 12:35 +0800, Liu Yu wrote: Hollis, Finally I found the reason for unstable kvm in SMP. Congratulations. :) do you think the modification is OK? They look fine to me, as far as I understand the e500 MMU. ;) Feel free to send to Avi. -- Hollis Blanchard IBM Linux Technology Center -- 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-userspace for powerpc is broken
On Mon, 2009-03-16 at 18:17 +0800, Liu Yu-B13201 wrote: 44x code was backported to qemu.git and e500 code was directly submmited to qemu.git. There is no support in kvm-userspace/qemu so far, and it's broken now. I took a quick look, and found that the qemu.git uses kvm.h, while kvm-userspace/qemu uses qemu-kvm.h instead. Does anyone know how to fix this correctly? I abandoned kvm-userspace as soon as I got upstream qemu working... I just didn't have the development bandwidth to try to maintain both. If you want to work on kvm-userspace, just remember that nobody will send that code to upstream qemu for you; you will *also* need to send it to qemu yourself. (As a side note, I'm not sure what the state of KVM PPC is in upstream qemu right now... probably needs testing again.) -- Hollis Blanchard IBM Linux Technology Center -- 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 5/5] kvm/powerpc: flat device tree files for MPC8544DS
On Thu, 2009-02-26 at 18:35 +0800, Liu Yu wrote:
mpc8544ds.dts is copied from kerenl.
Non-supported devices has been removed.
Signed-off-by: Liu Yu yu@freescale.com
---
pc-bios/mpc8544ds.dtb | Bin 0 - 12288 bytes
pc-bios/mpc8544ds.dts | 122
+
2 files changed, 122 insertions(+), 0 deletions(-)
create mode 100644 pc-bios/mpc8544ds.dtb
create mode 100644 pc-bios/mpc8544ds.dts
diff --git a/pc-bios/mpc8544ds.dts b/pc-bios/mpc8544ds.dts
new file mode 100644
index 000..872152d
--- /dev/null
+++ b/pc-bios/mpc8544ds.dts
@@ -0,0 +1,122 @@
+/*
+ * MPC8544 DS Device Tree Source
+ *
+ * Copyright 2007, 2008 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = MPC8544DS;
+ compatible = MPC8544DS, MPC85xxDS;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,8...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
It might be helpful to comment that these properties are overwritten at
runtime.
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x0;// Filled by U-Boot
+ };
Filled by qemu
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
+
+ ranges = 0x0 0xe000 0x10;
+ reg = 0xe000 0x1000; // CCSRBAR 1M
+ bus-frequency = 0;// Filled out by uboot.
Not filled by anybody...
Anyways, these are minor cosmetic issues; I'd be happy if the patch were
committed in its current form.
Acked-by: Hollis Blanchard holl...@us.ibm.com
--
Hollis Blanchard
IBM Linux Technology Center
--
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 5/6] kvm/powerpc: Add MPC85xx board support
On Thu, 2009-01-22 at 18:14 +0800, Liu Yu wrote:
All MPC85xx boards use E500v1/v2 core.
This patch add emulation of a virtual MPC85xx board,
so that any MPC85xx host could run this emulation.
Only tested it on MPC8544DS and MPC8572DS hosts,
but it should work on other MPC85xx boards.
Signed-off-by: Liu Yu yu@freescale.com
...
+struct board {
+const char *model;
+const char *compatible;
+};
+
+#define BOARD_DEF(_model, _compatible) \
+{\
+.model = _model, \
+.compatible = _compatible, \
+}
+
+/* Supported host boards */
+static const struct board mpc85xx_table[] = {
+BOARD_DEF(MPC8544DS,MPC8544DS), /* MPC8544DS */
+BOARD_DEF(fsl,MPC8572DS,fsl,MPC8572DS), /* MPC8572DS */
+BOARD_DEF(fsl,mpc8536ds,fsl,mpc8536ds), /* MPC8536DS */
+BOARD_DEF(MPC8548CDS, MPC8548CDS),/* MPC8548CDS */
+BOARD_DEF(MPC8555CDS, MPC8555CDS),/* MPC8555CDS */
+BOARD_DEF(MPC8541CDS, MPC8541CDS),/* MPC8541CDS */
+BOARD_DEF(MPC8540ADS, MPC8540ADS),/* MPC8540ADS */
+BOARD_DEF(MPC8560ADS, MPC8560ADS),/* MPC8560ADS */
+BOARD_DEF(MPC8568EMDS, MPC8568EMDS), /* MPC8568EMDS */
+};
+
+#define BOARDS_NUM (sizeof(mpc85xx_table)/sizeof(struct board))
...
+static void *mpc85xx_load_device_tree(void *addr,
+ uint32_t ramsize,
+ target_phys_addr_t initrd_base,
+ target_phys_addr_t initrd_size,
+ const char *kernel_cmdline)
+{
...
+if (kvm_enabled()) {
+ FILE *fp;
+ char *model;
+ char const *compatible = NULL;
+ struct dirent *dirp;
+ DIR *dp;
+ int i;
+ char buf[128];
+
+ if ((fp = fopen(/proc/cpuinfo, r)) == NULL) {
+ printf(Can't open file /proc/cpuinfo\n);
+ goto out;
+ }
+ while (fgets(buf, 128, fp) != NULL) {
+ if (strncmp(buf, model, 5) == 0) {
+ model = buf + 9;
+ break;
+ }
+ }
+ fclose(fp);
+
+ for (i = 0; i BOARDS_NUM; i++) {
+ if (strncmp(model, mpc85xx_table[i].model,
+ strlen(mpc85xx_table[i].model)) == 0) {
+ compatible = mpc85xx_table[i].compatible;
+ }
+ }
+
+ if (compatible == NULL) {
+ printf(Unknow host board!\n);
+ goto out;
+ }
+
+ ret = qemu_devtree_setprop_string(fdt, /, compatible, compatible);
+ if (ret 0)
+ fprintf(stderr, couldn't set /compatible = %s\n, compatible);
+
+ if ((dp = opendir(/proc/device-tree/cpus/)) == NULL) {
+ printf(Can't open directory /proc/device-tree/cpus/\n);
+ goto out;
+ }
+
+ buf[0] = '\0';
+ while ((dirp = readdir(dp)) != NULL) {
+ if (strncmp(dirp-d_name, PowerPC, 7) == 0) {
+ sprintf(buf, /proc/device-tree/cpus/%s, dirp-d_name);
+ break;
+ }
+ }
+ closedir(dp);
+ if (buf[0] == '\0') {
+ printf(Unknow host!\n);
+ goto out;
+ }
+ path = buf + 17;
I don't think you should do this at all. As long as the core is known,
it doesn't matter what the host board is. You *always* emulate the
MPC8544DS board (that's what your device tree says). You should be able
to emulate a MPC8544DS on *any* e500v2 host board or chip.
For comparison, on 440 we have tested with Sequoia (440EPx) and Bamboo
(440EP) hosts, but qemu always emulates a Bamboo guest. The chips aren't
the same, but that's irrelevant because the core is (440 x5).
The rest of this patch looks good.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] kvm/powerpc: Add emulation for MPC85xx in KVM mode
On Thu, 2009-01-22 at 18:14 +0800, Liu Yu wrote: This patch set enable another KVM PowerPC platform E500. Like the 440 core, the MMU and a few other bits are not currently emulated in Qemu itself, so right now it's only functional in conjunction with KVM. The emulation of MPC85xx boards (which use E500 as its core) can be run on any MPC85xx hosts. The code has been tested on MPC8544DS and MPC8572DS. Patch 1: enable the MPIC for MPC85xx platform Patch 2: add emulation of freescale PCI controller for MPC85xx platform Patch 3: add IRQ support for E500 core Patch 4: extern one function for MPC85xx code use Patch 5: add MPC85xx board emulation Patch 6: flat device tree of MPC85xx Patches 1-4: Acked-by: Hollis Blanchard holl...@us.ibm.com I've posted some comments on patches 5 and 6. Aurelian, would you mind reviewing patches 1-3? -- Hollis Blanchard IBM Linux Technology Center -- 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 9/9] powerpc/kvm: Add MPC85xx board support
On Tue, 2009-01-20 at 11:09 +0800, Liu Yu wrote:
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Saturday, January 17, 2009 2:10 AM
To: Liu Yu-B13201
Cc: qemu-de...@nongnu.org; kvm-ppc@vger.kernel.org
Subject: RE: [PATCH 9/9] powerpc/kvm: Add MPC85xx board support
Hmm, I have no idea why I didn't see this patch. Maybe it got
caught in
a spam filter.
I should have cc to you...
On Fri, 2009-01-16 at 16:22 +0800, Liu Yu wrote:
-Original Message-
From: Liu Yu-B13201
Sent: Thursday, January 15, 2009 8:34 PM
To: qemu-de...@nongnu.org
Cc: kvm-ppc@vger.kernel.org; Liu Yu-B13201
Subject: [PATCH 9/9] powerpc/kvm: Add MPC85xx board support
MPC85xx adopts E500 core.
This patch hopes to support all MPC85xx boards.
Signed-off-by: Liu Yu yu@freescale.com
--- /dev/null
+++ b/hw/ppce500_mpc85xx.c
+static void mpc85xx_init(ram_addr_t ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
+ const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename,
+ const char *cpu_model)
+{
+PCIBus *pci_bus;
+CPUState *env;
+uint64_t elf_entry;
+uint64_t elf_lowaddr;
+target_ulong entry=0;
+target_ulong loadaddr=UIMAGE_LOAD_BASE;
+target_long kernel_size=0;
+target_ulong dt_base=DTB_LOAD_BASE;
+target_ulong initrd_base=INITRD_LOAD_BASE;
+target_long initrd_size=0;
+void *fdt;
+int i=0;
+unsigned int pci_irq_nrs[4] = {1, 2, 3, 4};
+qemu_irq *irqs, *mpic, *pci_irqs;
+SerialState * serial[2];
+
+/* Setup CPU */
+env = ppce500_init(ram_size);
+
+/* MPIC */
+irqs = qemu_mallocz(sizeof(qemu_irq) * MPIC_OUTPUT_NB);
+irqs[MPIC_OUTPUT_INT] = ((qemu_irq
*)env-irq_inputs)[PPCE500_INPUT_INT];
+irqs[MPIC_OUTPUT_CINT] = ((qemu_irq
*)env-irq_inputs)[PPCE500_INPUT_CINT];
+mpic = mpic_init(MPC85xx_MPIC_REGS_BASE, 1, irqs, NULL);
+
+/* Serial */
+if (serial_hds[0])
+ serial[0] = serial_mm_init(MPC85xx_SERIAL0_REGS_BASE,
+ 0, mpic[12+26], 399193,
+ serial_hds[0], 1);
+
+if (serial_hds[1])
+ serial[0] = serial_mm_init(MPC85xx_SERIAL1_REGS_BASE,
+ 0, mpic[12+26], 399193,
+ serial_hds[0], 1);
+
+/* PCI */
+pci_irqs = qemu_malloc(sizeof(qemu_irq) * 4);
+pci_irqs[0] = mpic[pci_irq_nrs[0]];
+pci_irqs[1] = mpic[pci_irq_nrs[1]];
+pci_irqs[2] = mpic[pci_irq_nrs[2]];
+pci_irqs[3] = mpic[pci_irq_nrs[3]];
+pci_bus = ppce500_pci_init(pci_irqs, MPC85xx_PCI_REGS_BASE);
+if (!pci_bus)
+ printf(couldn't create PCI controller!\n);
+
+isa_mmio_init(MPC85xx_PCI_IO, MPC85xx_PCI_IOLEN);
+
+/* Register mem */
+cpu_register_physical_memory(0, ram_size, 0);
Hollis, I didn't see the memeory register like this in 440 code.
Is that a bug?
RAM is allocated in vl.c (see the call to qemu_vmalloc()), so it looks
like you're actually allocating twice the amount of memory you should
be.
It's odd.
I cannot make it work without cpu_register_physical_memory() which
ultimately call kvm_set_phys_mem().
But qemu_vmalloc() seems just to call mmap().
Did I miss anything?
OK, I was *really* confused on this one for a while... you're correct,
you must call cpu_register_physical_memory().
On 4xx, that is done by the memory controller emulation
(sdram_set_bcr()). Since you aren't using that code, you do need to call
it yourself.
--
Hollis Blanchard
IBM Linux Technology Center
--
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 9/9] powerpc/kvm: Add MPC85xx board support
Hmm, I have no idea why I didn't see this patch. Maybe it got caught in
a spam filter.
On Fri, 2009-01-16 at 16:22 +0800, Liu Yu wrote:
-Original Message-
From: Liu Yu-B13201
Sent: Thursday, January 15, 2009 8:34 PM
To: qemu-de...@nongnu.org
Cc: kvm-ppc@vger.kernel.org; Liu Yu-B13201
Subject: [PATCH 9/9] powerpc/kvm: Add MPC85xx board support
MPC85xx adopts E500 core.
This patch hopes to support all MPC85xx boards.
Signed-off-by: Liu Yu yu@freescale.com
--- /dev/null
+++ b/hw/ppce500_mpc85xx.c
+static void mpc85xx_init(ram_addr_t ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
+ const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename,
+ const char *cpu_model)
+{
+PCIBus *pci_bus;
+CPUState *env;
+uint64_t elf_entry;
+uint64_t elf_lowaddr;
+target_ulong entry=0;
+target_ulong loadaddr=UIMAGE_LOAD_BASE;
+target_long kernel_size=0;
+target_ulong dt_base=DTB_LOAD_BASE;
+target_ulong initrd_base=INITRD_LOAD_BASE;
+target_long initrd_size=0;
+void *fdt;
+int i=0;
+unsigned int pci_irq_nrs[4] = {1, 2, 3, 4};
+qemu_irq *irqs, *mpic, *pci_irqs;
+SerialState * serial[2];
+
+/* Setup CPU */
+env = ppce500_init(ram_size);
+
+/* MPIC */
+irqs = qemu_mallocz(sizeof(qemu_irq) * MPIC_OUTPUT_NB);
+irqs[MPIC_OUTPUT_INT] = ((qemu_irq
*)env-irq_inputs)[PPCE500_INPUT_INT];
+irqs[MPIC_OUTPUT_CINT] = ((qemu_irq
*)env-irq_inputs)[PPCE500_INPUT_CINT];
+mpic = mpic_init(MPC85xx_MPIC_REGS_BASE, 1, irqs, NULL);
+
+/* Serial */
+if (serial_hds[0])
+ serial[0] = serial_mm_init(MPC85xx_SERIAL0_REGS_BASE,
+ 0, mpic[12+26], 399193,
+ serial_hds[0], 1);
+
+if (serial_hds[1])
+ serial[0] = serial_mm_init(MPC85xx_SERIAL1_REGS_BASE,
+ 0, mpic[12+26], 399193,
+ serial_hds[0], 1);
+
+/* PCI */
+pci_irqs = qemu_malloc(sizeof(qemu_irq) * 4);
+pci_irqs[0] = mpic[pci_irq_nrs[0]];
+pci_irqs[1] = mpic[pci_irq_nrs[1]];
+pci_irqs[2] = mpic[pci_irq_nrs[2]];
+pci_irqs[3] = mpic[pci_irq_nrs[3]];
+pci_bus = ppce500_pci_init(pci_irqs, MPC85xx_PCI_REGS_BASE);
+if (!pci_bus)
+ printf(couldn't create PCI controller!\n);
+
+isa_mmio_init(MPC85xx_PCI_IO, MPC85xx_PCI_IOLEN);
+
+/* Register mem */
+cpu_register_physical_memory(0, ram_size, 0);
Hollis, I didn't see the memeory register like this in 440 code.
Is that a bug?
RAM is allocated in vl.c (see the call to qemu_vmalloc()), so it looks
like you're actually allocating twice the amount of memory you should
be.
--
Hollis Blanchard
IBM Linux Technology Center
--
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/9] powerpc/kvm: Enable mpic for E500 platform
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)? You mean test powerpc mac99? No. It doesn't sound like mac99 works right now anyways, so that may not be possible to test. 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. 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. [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 -- 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
[Fwd: [Qemu-devel] [PATCH] Guest debugging support for KVM]
FWIW, I'm not working on this, so this might be a good feature to add to
your to-do list Yu. :) After qemu merge and large page support, of
course.
Given the performance issues incurred by full virtualization on e500 and
440, I think full guest debugging is probably the most attractive
use-case for KVM on those cores. In other words, even if it's
significantly slower than native, KVM could still be valuable as a
development tool.
(Of course, if you want to go for paravirt guests to make KVM on
e500/440 perform well, don't let me stop you... I just think debug
support would be easier for now. :)
--
Hollis Blanchard
IBM Linux Technology Center
---BeginMessage---
[ Also available via git://git.kiszka.org/qemu.git queue/gdb ]
This is a backport of the guest debugging support for the KVM
accelerator that is now part of the KVM tree. It implements the reworked
KVM kernel API for guest debugging (KVM_CAP_SET_GUEST_DEBUG) which is
not yet part of any mainline kernel but will probably be 2.6.30 stuff.
So far supported is x86, but PPC is expected to catch up soon.
Core features are:
- unlimited soft-breakpoints via code patching
- hardware-assisted x86 breakpoints and watchpoints
Open issues: Writing soft breakpoints to BIOS code. cpu_memory_rw_debug
does not work here. Suggestion to fix this cleanly are welcome.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure |4 +
exec.c| 10 ++-
gdbstub.c | 29 +++--
gdbstub.h |7 ++
kvm-all.c | 172 +
kvm.h | 41 +
target-i386/kvm.c | 172 +
7 files changed, 423 insertions(+), 12 deletions(-)
diff --git a/configure b/configure
index a8ea55a..afbe1e0 100755
--- a/configure
+++ b/configure
@@ -479,11 +479,11 @@ case $cpu in
ARCH_CFLAGS=-march=z900
;;
i386)
- ARCH_CFLAGS=-m32
+ ARCH_CFLAGS=-m32 -DCONFIG_X86
ARCH_LDFLAGS=-m32
;;
x86_64)
- ARCH_CFLAGS=-m64
+ ARCH_CFLAGS=-m64 -DCONFIG_X86
ARCH_LDFLAGS=-m64
;;
esac
diff --git a/exec.c b/exec.c
index d6fa977..89f457a 100644
--- a/exec.c
+++ b/exec.c
@@ -1458,9 +1458,13 @@ void cpu_single_step(CPUState *env, int enabled)
#if defined(TARGET_HAS_ICE)
if (env-singlestep_enabled != enabled) {
env-singlestep_enabled = enabled;
-/* must flush all the translated code to avoid inconsistancies */
-/* XXX: only flush what is necessary */
-tb_flush(env);
+if (kvm_enabled())
+kvm_update_guest_debug(env, 0);
+else {
+/* must flush all the translated code to avoid inconsistancies */
+/* XXX: only flush what is necessary */
+tb_flush(env);
+}
}
#endif
}
diff --git a/gdbstub.c b/gdbstub.c
index a3ff07a..0bcd5d5 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -38,6 +38,7 @@
#define MAX_PACKET_LENGTH 4096
#include qemu_socket.h
+#include kvm.h
enum {
@@ -1389,13 +1390,6 @@ void gdb_register_coprocessor(CPUState * env,
}
}
-/* GDB breakpoint/watchpoint types */
-#define GDB_BREAKPOINT_SW0
-#define GDB_BREAKPOINT_HW1
-#define GDB_WATCHPOINT_WRITE 2
-#define GDB_WATCHPOINT_READ 3
-#define GDB_WATCHPOINT_ACCESS4
-
#ifndef CONFIG_USER_ONLY
static const int xlat_gdb_type[] = {
[GDB_WATCHPOINT_WRITE] = BP_GDB | BP_MEM_WRITE,
@@ -1409,6 +1403,9 @@ static int gdb_breakpoint_insert(target_ulong addr,
target_ulong len, int type)
CPUState *env;
int err = 0;
+if (kvm_enabled())
+return kvm_insert_breakpoint(gdbserver_state-c_cpu, addr, len, type);
+
switch (type) {
case GDB_BREAKPOINT_SW:
case GDB_BREAKPOINT_HW:
@@ -1440,6 +1437,9 @@ static int gdb_breakpoint_remove(target_ulong addr,
target_ulong len, int type)
CPUState *env;
int err = 0;
+if (kvm_enabled())
+return kvm_remove_breakpoint(gdbserver_state-c_cpu, addr, len, type);
+
switch (type) {
case GDB_BREAKPOINT_SW:
case GDB_BREAKPOINT_HW:
@@ -1469,6 +1469,11 @@ static void gdb_breakpoint_remove_all(void)
{
CPUState *env;
+if (kvm_enabled()) {
+kvm_remove_all_breakpoints(gdbserver_state-c_cpu);
+return;
+}
+
for (env = first_cpu; env != NULL; env = env-next_cpu) {
cpu_breakpoint_remove_all(env, BP_GDB);
#ifndef CONFIG_USER_ONLY
@@ -1509,6 +1514,8 @@ static int gdb_handle_packet(GDBState *s, const char
*line_buf)
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
s-c_cpu-eip = addr;
+if (kvm_enabled())
+kvm_put_registers(s-c_cpu);
#elif defined (TARGET_PPC)
s-c_cpu-nip = addr;
#elif defined (TARGET_SPARC)
@@ -1550,6 +1557,8 @@ static int gdb_handle_packet(GDBState *s, const char
*line_buf)
addr
Re: [PATCH 7/9] powerpc/kvm: Add E500 core emulation
On Thu, 2009-01-15 at 20:34 +0800, Liu Yu wrote:
Signed-off-by: Liu Yu yu@freescale.com
---
Makefile.target |1 +
hw/ppce500.c| 49 +
hw/ppce500.h| 44
3 files changed, 94 insertions(+), 0 deletions(-)
create mode 100644 hw/ppce500.c
create mode 100644 hw/ppce500.h
diff --git a/Makefile.target b/Makefile.target
index 2079fcb..223d294 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -651,6 +651,7 @@ OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o
ppc405_uc.o ppc405_boards.o
OBJS+= ppc440.o ppc440_bamboo.o
# PowerPC E500 boards
OBJS+= ppce500_pci.o
+OBJS+= ppce500.o
ifdef FDT_LIBS
OBJS+= device_tree.o
LIBS+= $(FDT_LIBS)
diff --git a/hw/ppce500.c b/hw/ppce500.c
new file mode 100644
index 000..856cce2
--- /dev/null
+++ b/hw/ppce500.c
@@ -0,0 +1,49 @@
+/*
+ * Qemu PowerPC E500 core emualtion
emulation
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Yu Liu, yu@freescale.com
+ *
+ * This file is derived from hw/ppc440.c
+ * the copyright for that material belongs to the original owners.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include hw.h
+#include pc.h
+#include hw/isa.h
+#include ppce500.h
+#include sysemu.h
+
+#define bytes_to_mb(a) (a20)
Doesn't look like this is used.
+CPUState *ppce500_init(ram_addr_t *ram_size)
+{
+int i;
+ram_addr_t tmp_ram_size;
+CPUState *env;
+int ram_stick_sizes[] = {51220, 25620, 12820, 6420}; /* in bytes
*/
+
+/* Setup Memory */
+tmp_ram_size = *ram_size;
+
+for (i=0; i(sizeof(ram_stick_sizes)/sizeof(ram_stick_sizes[0])); i++)
+ while ((tmp_ram_size/ram_stick_sizes[i]) 0)
+ tmp_ram_size -= ram_stick_sizes[i];
+
+if (tmp_ram_size)
+ *ram_size -= tmp_ram_size;
Since you said you don't actually have a memory controller you're
emulating, I think you should completely remove all this ram_size stuff.
Once you do that, this whole function becomes just cpu_ppc_init(), so
you can just call that instead.
+env = cpu_ppc_init(e500v2_v30);
+if (!env) {
+ fprintf(stderr, Unable to initilize CPU!\n);
initialize
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] powerpc/kvm: Add MPC85xx platform support
On Thu, 2009-01-15 at 20:34 +0800, Liu Yu wrote: This patchset enable the support of MPC85xx platform in qemu/kvm. patch 1,2: bug fix patch 3: enable mpic for E500 core. patch 4: enable E500 mmu in kvm mode. patch 5: add E500 pci controller emulation. patch 6: add E500 irq support patch 7: add E500 core emulation patch 8: extern one function for E500 code use patch 9: add MPC85xx boards emulation. (In case it was unclear to any of the Qemu folks, this is another KVM PowerPC platform. Like the 440 core, the MMU and a few other bits are not currently emulated in Qemu itself, so right now it's only functional in conjunction with KVM.) Looks pretty good, Yu. :) Patches 1, 2, 4, 8: Acked-by: Hollis Blanchard holl...@us.ibm.com I've either commented on the other patches, or they're in areas of qemu with which I'm not too familiar. By the way, I think you forgot patch 9, which will tie it all together by emulating an 85xx SoC? -- Hollis Blanchard IBM Linux Technology Center -- 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
[PATCH 03 of 16] kvm: ppc: small cosmetic changes to Book E DTLB miss handler
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -290,6 +290,7 @@ int kvmppc_handle_exit(struct kvm_run *r
struct kvmppc_44x_tlbe *gtlbe;
unsigned long eaddr = vcpu-arch.fault_dear;
int gtlb_index;
+ gpa_t gpaddr;
gfn_t gfn;
/* Check the guest TLB. */
@@ -305,8 +306,8 @@ int kvmppc_handle_exit(struct kvm_run *r
}
gtlbe = vcpu_44x-guest_tlb[gtlb_index];
- vcpu-arch.paddr_accessed = tlb_xlate(gtlbe, eaddr);
- gfn = vcpu-arch.paddr_accessed PAGE_SHIFT;
+ gpaddr = tlb_xlate(gtlbe, eaddr);
+ gfn = gpaddr PAGE_SHIFT;
if (kvm_is_visible_gfn(vcpu-kvm, gfn)) {
/* The guest TLB had a mapping, but the shadow TLB
@@ -315,13 +316,14 @@ int kvmppc_handle_exit(struct kvm_run *r
* b) the guest used a large mapping which we're faking
* Either way, we need to satisfy the fault without
* invoking the guest. */
- kvmppc_mmu_map(vcpu, eaddr, vcpu-arch.paddr_accessed,
gtlbe-tid,
+ kvmppc_mmu_map(vcpu, eaddr, gpaddr, gtlbe-tid,
gtlbe-word2, get_tlb_bytes(gtlbe),
gtlb_index);
kvmppc_account_exit(vcpu, DTLB_VIRT_MISS_EXITS);
r = RESUME_GUEST;
} else {
/* Guest has mapped and accessed a page which is not
* actually RAM. */
+ vcpu-arch.paddr_accessed = gpaddr;
r = kvmppc_emulate_mmio(run, vcpu);
kvmppc_account_exit(vcpu, MMIO_EXITS);
}
--
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
[PATCH 04 of 16] kvm: ppc: change kvmppc_mmu_map() parameters
Passing just the TLB index will ease an e500 implementation.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -55,7 +55,6 @@ extern void kvmppc_emulate_dec(struct kv
/* Core-specific hooks */
extern void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gpa_t gpaddr,
- u64 asid, u32 flags, u32 max_bytes,
unsigned int gtlb_idx);
extern void kvmppc_mmu_priv_switch(struct kvm_vcpu *vcpu, int usermode);
extern void kvmppc_mmu_switch_pid(struct kvm_vcpu *vcpu, u32 pid);
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -269,15 +269,19 @@ void kvmppc_mmu_destroy(struct kvm_vcpu
* Caller must ensure that the specified guest TLB entry is safe to insert into
* the shadow TLB.
*/
-void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gpa_t gpaddr, u64 asid,
-u32 flags, u32 max_bytes, unsigned int gtlb_index)
+void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 gvaddr, gpa_t gpaddr,
+unsigned int gtlb_index)
{
struct kvmppc_44x_tlbe stlbe;
struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
+ struct kvmppc_44x_tlbe *gtlbe = vcpu_44x-guest_tlb[gtlb_index];
struct kvmppc_44x_shadow_ref *ref;
struct page *new_page;
hpa_t hpaddr;
gfn_t gfn;
+ u32 asid = gtlbe-tid;
+ u32 flags = gtlbe-word2;
+ u32 max_bytes = get_tlb_bytes(gtlbe);
unsigned int victim;
/* Select TLB entry to clobber. Indirectly guard against races with the
TLB
@@ -448,10 +452,8 @@ int kvmppc_44x_emul_tlbwe(struct kvm_vcp
}
if (tlbe_is_host_safe(vcpu, tlbe)) {
- u64 asid;
gva_t eaddr;
gpa_t gpaddr;
- u32 flags;
u32 bytes;
eaddr = get_tlb_eaddr(tlbe);
@@ -462,10 +464,7 @@ int kvmppc_44x_emul_tlbwe(struct kvm_vcp
eaddr = ~(bytes - 1);
gpaddr = ~(bytes - 1);
- asid = (tlbe-word0 PPC44x_TLB_TS) | tlbe-tid;
- flags = tlbe-word2 0x;
-
- kvmppc_mmu_map(vcpu, eaddr, gpaddr, asid, flags, bytes,
gtlb_index);
+ kvmppc_mmu_map(vcpu, eaddr, gpaddr, gtlb_index);
}
KVMTRACE_5D(GTLB_WRITE, vcpu, gtlb_index, tlbe-tid, tlbe-word0,
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -316,8 +316,7 @@ int kvmppc_handle_exit(struct kvm_run *r
* b) the guest used a large mapping which we're faking
* Either way, we need to satisfy the fault without
* invoking the guest. */
- kvmppc_mmu_map(vcpu, eaddr, gpaddr, gtlbe-tid,
- gtlbe-word2, get_tlb_bytes(gtlbe),
gtlb_index);
+ kvmppc_mmu_map(vcpu, eaddr, gpaddr, gtlb_index);
kvmppc_account_exit(vcpu, DTLB_VIRT_MISS_EXITS);
r = RESUME_GUEST;
} else {
@@ -364,8 +363,7 @@ int kvmppc_handle_exit(struct kvm_run *r
* b) the guest used a large mapping which we're faking
* Either way, we need to satisfy the fault without
* invoking the guest. */
- kvmppc_mmu_map(vcpu, eaddr, gpaddr, gtlbe-tid,
- gtlbe-word2, get_tlb_bytes(gtlbe),
gtlb_index);
+ kvmppc_mmu_map(vcpu, eaddr, gpaddr, gtlb_index);
} else {
/* Guest mapped and leaped at non-RAM! */
kvmppc_booke_queue_irqprio(vcpu,
BOOKE_IRQPRIO_MACHINE_CHECK);
--
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 07/10] Add kvmppc_mmu_dtlb/itlb_miss for booke
On Thu, 2008-12-18 at 20:22 +0800, Liu Yu wrote:
When itlb or dtlb miss happens, E500 needs to update some mmu registers.
So that the auto-load mechanism can work on E500 when write a tlb entry.
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm_ppc.h |2 ++
arch/powerpc/kvm/44x_tlb.c |8
arch/powerpc/kvm/booke.c |2 ++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index f4b041b..82547c8 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -63,6 +63,8 @@ extern int kvmppc_mmu_dtlb_index(struct kvm_vcpu *vcpu,
gva_t eaddr);
extern int kvmppc_mmu_itlb_index(struct kvm_vcpu *vcpu, gva_t eaddr);
extern gpa_t kvmppc_mmu_xlate(struct kvm_vcpu *vcpu, unsigned int gtlb_index,
gva_t eaddr);
+extern void kvmppc_mmu_dtlb_miss(struct kvm_vcpu *vcpu);
+extern void kvmppc_mmu_itlb_miss(struct kvm_vcpu *vcpu);
extern struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm,
unsigned int id);
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
index e67b731..4a16f47 100644
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -232,6 +232,14 @@ int kvmppc_mmu_dtlb_index(struct kvm_vcpu *vcpu, gva_t
eaddr)
return kvmppc_44x_tlb_index(vcpu, eaddr, vcpu-arch.pid, as);
}
+void kvmppc_mmu_itlb_miss(struct kvm_vcpu *vcpu)
+{
+}
+
+void kvmppc_mmu_dtlb_miss(struct kvm_vcpu *vcpu)
+{
+}
+
static void kvmppc_44x_shadow_release(struct kvmppc_vcpu_44x *vcpu_44x,
unsigned int stlb_index)
{
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index a73b395..933c406 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -295,6 +295,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
kvmppc_booke_queue_irqprio(vcpu,
BOOKE_IRQPRIO_DTLB_MISS);
vcpu-arch.dear = vcpu-arch.fault_dear;
vcpu-arch.esr = vcpu-arch.fault_esr;
+ kvmppc_mmu_dtlb_miss(vcpu);
kvmppc_account_exit(vcpu, DTLB_REAL_MISS_EXITS);
r = RESUME_GUEST;
break;
@@ -337,6 +338,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
if (gtlb_index 0) {
/* The guest didn't have a mapping for it. */
kvmppc_booke_queue_irqprio(vcpu,
BOOKE_IRQPRIO_ITLB_MISS);
+ kvmppc_mmu_itlb_miss(vcpu);
kvmppc_account_exit(vcpu, ITLB_REAL_MISS_EXITS);
break;
}
I don't think you've supplied an implementation of these hooks for e500.
Does it build with this patch series applied?
--
Hollis Blanchard
IBM Linux Technology Center
--
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/4] IBM PowerPC 440EP Bamboo reference board emulation
On Tue, 2008-12-16 at 11:47 +0100, Aurelien Jarno wrote: On Mon, Dec 15, 2008 at 06:17:32PM -0600, Hollis Blanchard wrote: Since most IO devices are integrated into the 440EP chip, Bamboo support mostly entails implementing the -kernel, -initrd, and -append options. These options are implemented by loading the guest as if u-boot had done it, i.e. loading a flat device tree, updating it to hold initrd addresses, ram size, and command line, and passing the FDT address in r3. Since we use it with KVM, we enable the virtio block driver and include hooks necessary for KVM support. Signed-off-by: Hollis Blanchard holl...@us.ibm.com --- Made comment more specific. --- Makefile |2 +- Makefile.target |2 +- hw/boards.h |1 + hw/ppc440_bamboo.c | 190 pc-bios/bamboo.dtb | Bin 0 - 3163 bytes pc-bios/bamboo.dts | 234 ++ I guess the .dtb file is generated from the .dts. Could you give us more details about that? When the tools need to generate the dtb file are installed on the build machine, we may want to generate the .dtb during the build process. The dtb file (device tree binary) is generated from the dts (device tree source) by a tool called dtc, the device tree compiler.[1] dtc is available in major distributions: in Fedora the package name is dtc; in Debian it is device-tree-compiler (available in testing and unstable). [1] http://git.jdl.com/gitweb/?p=dtc.git;a=summary -- Hollis Blanchard IBM Linux Technology Center -- 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/4] PowerPC 440EP SoC emulation
On Tue, 2008-12-16 at 11:45 +0100, Aurelien Jarno wrote: On Mon, Dec 15, 2008 at 06:17:31PM -0600, Hollis Blanchard wrote: Wire up the system-on-chip devices present on 440EP chips. This patch is a little unusual in that qemu doesn't actually emulate the 440 core, but we use this board code with KVM (which does). If/when 440 core emulation is supported, the kvm_enabled() hack can be removed. What are the mains differences between 405 and 440 cores? Would it be easy to add support for 440 core in QEMU? It's been a while since I programmed for the 405, but from memory: Unlike the 405, the 440 is a Book E core. The biggest difference is that there is no real mode; MMU translation is always active. MSR[IR] and DR have been replaced with IS and DS, and those address space bits contribute to the 41-bit virtual address (32-bit effective, 8-bit PID like 405, 1-bit AS). The TLB organization is pretty much the same as 405 (64-entry fully associative), though the data in each entry has changed a little. Fixed interrupt vectors have been replaced with programmable ones, via the IVPR base register and 16 IVOR registers, indicating the offset of each vector from IVPR. There is a Application Note that more fully lists the software differences: https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440GP/PPC440GP_AN2020_SWC405GP.pdf Because the MMU is always on, tlbia doesn't exist any more. There are a few other minor instruction and register changes. As I've mentioned, most 440 peripherals are the same or similar to 405, which is definitely helpful. -- Hollis Blanchard IBM Linux Technology Center -- 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 06/11] E500 instructions emulation
On Tue, 2008-12-16 at 18:18 +0800, Liu Yu wrote:
+static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
+{
+ vcpu-arch.pc = vcpu-arch.srr0;
+ kvmppc_set_msr(vcpu, vcpu-arch.srr1);
+}
Actually, right now I'm wondering why rfi emulation isn't in
the shared
emulation code. Do you see any core-specific issues there? Same with
wrtee* and m*msr.
Heh, I was curious why you split them.
If you're curious about anything, just ask!
--
Hollis Blanchard
IBM Linux Technology Center
--
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
[PATCH 2/8] Rename ppc405_sdram_init() to ppc4xx_sdram_init()
The SDRAM controller is shared across almost all 405 and 440 embedded
processors, with some slight differences such as the sizes supported for each
memory bank.
Rename only; no functional changes.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
hw/ppc405_uc.c |4 ++--
hw/ppc4xx.h |2 +-
hw/ppc4xx_devs.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ppc405_uc.c b/hw/ppc405_uc.c
index 7e7fb38..9275416 100644
--- a/hw/ppc405_uc.c
+++ b/hw/ppc405_uc.c
@@ -2230,7 +2230,7 @@ CPUState *ppc405cr_init (target_phys_addr_t ram_bases[4],
pic = ppcuic_init(env, irqs, 0x0C0, 0, 1);
*picp = pic;
/* SDRAM controller */
-ppc405_sdram_init(env, pic[14], 1, ram_bases, ram_sizes, do_init);
+ppc4xx_sdram_init(env, pic[14], 1, ram_bases, ram_sizes, do_init);
offset = 0;
for (i = 0; i 4; i++)
offset += ram_sizes[i];
@@ -2588,7 +2588,7 @@ CPUState *ppc405ep_init (target_phys_addr_t ram_bases[2],
*picp = pic;
/* SDRAM controller */
/* XXX 405EP has no ECC interrupt */
-ppc405_sdram_init(env, pic[17], 2, ram_bases, ram_sizes, do_init);
+ppc4xx_sdram_init(env, pic[17], 2, ram_bases, ram_sizes, do_init);
offset = 0;
for (i = 0; i 2; i++)
offset += ram_sizes[i];
diff --git a/hw/ppc4xx.h b/hw/ppc4xx.h
index 8c2878a..3b98662 100644
--- a/hw/ppc4xx.h
+++ b/hw/ppc4xx.h
@@ -48,7 +48,7 @@ enum {
qemu_irq *ppcuic_init (CPUState *env, qemu_irq *irqs,
uint32_t dcr_base, int has_ssr, int has_vr);
-void ppc405_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
+void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
target_phys_addr_t *ram_bases,
target_phys_addr_t *ram_sizes,
int do_init);
diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c
index c6be2d6..2d27e23 100644
--- a/hw/ppc4xx_devs.c
+++ b/hw/ppc4xx_devs.c
@@ -846,7 +846,7 @@ static void sdram_reset (void *opaque)
sdram_unmap_bcr(sdram);
}
-void ppc405_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
+void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
target_phys_addr_t *ram_bases,
target_phys_addr_t *ram_sizes,
int do_init)
--
1.5.6.5
--
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
[PATCH 1/8] Move PPC4xx SDRAM controller emulation from ppc405_uc.c to ppc4xx_devs.c
The SDRAM controller is shared across almost all 405 and 440 embedded
processors, with some slight differences such as the sizes supported for each
memory bank.
Code movement only; no functional changes.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
I think all device emulation should move from ppc405_uc.c to ppc4xx_devs.c,
since it is shared between all 4xx SoCs (405 and 440). At the moment, the SDRAM
controller is the only piece I have code for, so I'm only moving it.
(I can only guess uc means microcontroller; the file should be renamed as
well.)
---
hw/ppc405.h |5 -
hw/ppc405_uc.c | 341 --
hw/ppc4xx.h |5 +
hw/ppc4xx_devs.c | 341 ++
4 files changed, 346 insertions(+), 346 deletions(-)
diff --git a/hw/ppc405.h b/hw/ppc405.h
index e032170..eebcef3 100644
--- a/hw/ppc405.h
+++ b/hw/ppc405.h
@@ -66,11 +66,6 @@ void ppc4xx_pob_init (CPUState *env);
/* OPB arbitrer */
void ppc4xx_opba_init (CPUState *env, ppc4xx_mmio_t *mmio,
target_phys_addr_t offset);
-/* SDRAM controller */
-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);
/* Peripheral controller */
void ppc405_ebc_init (CPUState *env);
/* DMA controller */
diff --git a/hw/ppc405_uc.c b/hw/ppc405_uc.c
index 25bcfd8..7e7fb38 100644
--- a/hw/ppc405_uc.c
+++ b/hw/ppc405_uc.c
@@ -401,347 +401,6 @@ void ppc4xx_opba_init (CPUState *env, ppc4xx_mmio_t *mmio,
/* XXX: TODO */
/*/
-/* SDRAM controller */
-typedef struct ppc4xx_sdram_t ppc4xx_sdram_t;
-struct ppc4xx_sdram_t {
-uint32_t addr;
-int nbanks;
-target_phys_addr_t ram_bases[4];
-target_phys_addr_t ram_sizes[4];
-uint32_t besr0;
-uint32_t besr1;
-uint32_t bear;
-uint32_t cfg;
-uint32_t status;
-uint32_t rtr;
-uint32_t pmit;
-uint32_t bcr[4];
-uint32_t tr;
-uint32_t ecccfg;
-uint32_t eccesr;
-qemu_irq irq;
-};
-
-enum {
-SDRAM0_CFGADDR = 0x010,
-SDRAM0_CFGDATA = 0x011,
-};
-
-/* XXX: TOFIX: some patches have made this code become inconsistent:
- * there are type inconsistencies, mixing target_phys_addr_t, target_ulong
- * and uint32_t
- */
-static uint32_t sdram_bcr (target_phys_addr_t ram_base,
- target_phys_addr_t ram_size)
-{
-uint32_t bcr;
-
-switch (ram_size) {
-case (4 * 1024 * 1024):
-bcr = 0x;
-break;
-case (8 * 1024 * 1024):
-bcr = 0x0002;
-break;
-case (16 * 1024 * 1024):
-bcr = 0x0004;
-break;
-case (32 * 1024 * 1024):
-bcr = 0x0006;
-break;
-case (64 * 1024 * 1024):
-bcr = 0x0008;
-break;
-case (128 * 1024 * 1024):
-bcr = 0x000A;
-break;
-case (256 * 1024 * 1024):
-bcr = 0x000C;
-break;
-default:
-printf(%s: invalid RAM size PADDRX \n, __func__, ram_size);
-return 0x;
-}
-bcr |= ram_base 0xFF80;
-bcr |= 1;
-
-return bcr;
-}
-
-static always_inline target_phys_addr_t sdram_base (uint32_t bcr)
-{
-return bcr 0xFF80;
-}
-
-static target_ulong sdram_size (uint32_t bcr)
-{
-target_ulong size;
-int sh;
-
-sh = (bcr 17) 0x7;
-if (sh == 7)
-size = -1;
-else
-size = (4 * 1024 * 1024) sh;
-
-return size;
-}
-
-static void sdram_set_bcr (uint32_t *bcrp, uint32_t bcr, int enabled)
-{
-if (*bcrp 0x0001) {
-/* Unmap RAM */
-#ifdef DEBUG_SDRAM
-printf(%s: unmap RAM area PADDRX ADDRX \n,
- __func__, sdram_base(*bcrp), sdram_size(*bcrp));
-#endif
-cpu_register_physical_memory(sdram_base(*bcrp), sdram_size(*bcrp),
- IO_MEM_UNASSIGNED);
-}
-*bcrp = bcr 0xFFDEE001;
-if (enabled (bcr 0x0001)) {
-#ifdef DEBUG_SDRAM
-printf(%s: Map RAM area PADDRX ADDRX \n,
- __func__, sdram_base(bcr), sdram_size(bcr));
-#endif
-cpu_register_physical_memory(sdram_base(bcr), sdram_size(bcr),
- sdram_base(bcr) | IO_MEM_RAM);
-}
-}
-
-static void sdram_map_bcr (ppc4xx_sdram_t *sdram)
-{
-int i;
-
-for (i = 0; i sdram-nbanks; i++) {
-if (sdram-ram_sizes[i] != 0) {
-sdram_set_bcr(sdram-bcr[i],
- sdram_bcr(sdram-ram_bases[i], sdram-ram_sizes[i]),
- 1);
-} else {
-sdram_set_bcr(sdram-bcr[i], 0x, 0);
-}
-}
-}
-
-static void sdram_unmap_bcr (ppc4xx_sdram_t *sdram)
-{
-int i;
-
-for (i = 0; i sdram-nbanks; i++) {
-#ifdef DEBUG_SDRAM
-printf
[PATCH 4/8] kvm: sync vcpu state during initialization
Currently on x86, qemu initializes CPUState but KVM ignores it and does its
own vcpu initialization. However, PowerPC KVM needs to be able to set the
initial register state to support the -kernel and -append options.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
kvm-all.c | 15 +++
kvm.h |1 +
vl.c | 11 +++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index dad80df..11034df 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -141,6 +141,21 @@ err:
return ret;
}
+int kvm_sync_vcpus(void)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+int ret;
+
+ret = kvm_arch_put_registers(env);
+if (ret)
+return ret;
+}
+
+return 0;
+}
+
/*
* dirty pages logging control
*/
diff --git a/kvm.h b/kvm.h
index ac464ab..efce145 100644
--- a/kvm.h
+++ b/kvm.h
@@ -31,6 +31,7 @@ struct kvm_run;
int kvm_init(int smp_cpus);
int kvm_init_vcpu(CPUState *env);
+int kvm_sync_vcpus(void);
int kvm_cpu_exec(CPUState *env);
diff --git a/vl.c b/vl.c
index c3a8d8f..0a02151 100644
--- a/vl.c
+++ b/vl.c
@@ -5456,6 +5456,17 @@ int main(int argc, char **argv, char **envp)
machine-init(ram_size, vga_ram_size, boot_devices, ds,
kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
+/* Set KVM's vcpu state to qemu's initial CPUState. */
+if (kvm_enabled()) {
+int ret;
+
+ret = kvm_sync_vcpus();
+if (ret 0) {
+fprintf(stderr, failed to initialize vcpus\n);
+exit(1);
+}
+}
+
/* init USB devices */
if (usb_enabled) {
for(i = 0; i usb_devices_index; i++) {
--
1.5.6.5
--
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
[PATCH 5/8] Implement device tree support needed for Bamboo emulation
To implement the -kernel, -initrd, and -append options, 4xx board emulation
must load the guest kernel as if firmware had loaded it. Where u-boot would be
the firmware, we must load the flat device tree into memory and set key fields
such as /chosen/bootargs.
This patch introduces a dependency on libfdt for flat device tree support.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
Makefile.target |4 ++
configure | 18 +
device_tree.c | 114 +++
device_tree.h | 26
libfdt_env.h| 41
5 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 device_tree.c
create mode 100644 device_tree.h
create mode 100644 libfdt_env.h
diff --git a/Makefile.target b/Makefile.target
index 8229b4f..d80ce2c 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -655,6 +655,10 @@ OBJS+= heathrow_pic.o grackle_pci.o ppc_oldworld.o
OBJS+= unin_pci.o ppc_chrp.o
# PowerPC 4xx boards
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
+ifdef FDT_LIBS
+OBJS+= device_tree.o
+LIBS+= $(FDT_LIBS)
+endif
# virtio support
OBJS+= virtio.o virtio-blk.o virtio-balloon.o
endif
diff --git a/configure b/configure
index 455dbef..562f113 100755
--- a/configure
+++ b/configure
@@ -119,6 +119,7 @@ kvm=yes
kerneldir=
aix=no
blobs=yes
+fdt=yes
# OS specific
targetos=`uname -s`
@@ -966,6 +967,18 @@ if $cc $ARCH_CFLAGS -o $TMPE $TMPC /dev/null 2
/dev/null ; then
iovec=yes
fi
+##
+# fdt probe
+if test $fdt = yes ; then
+fdt=no
+cat $TMPC EOF
+int main(void) { return 0; }
+EOF
+ if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lfdt 2 /dev/null ; then
+fdt=yes
+ fi
+fi
+
# Check if tools are available to build documentation.
if [ -x `which texi2html 2/dev/null` ] \
[ -x `which pod2man 2/dev/null` ]; then
@@ -1061,6 +1074,7 @@ echo vde support $vde
echo AIO support $aio
echo Install blobs $blobs
echo KVM support $kvm
+echo fdt support $kvm
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
@@ -1350,6 +1364,10 @@ fi
if test $iovec = yes ; then
echo #define HAVE_IOVEC 1 $config_h
fi
+if test $fdt = yes ; then
+ echo #define HAVE_FDT 1 $config_h
+ echo FDT_LIBS=-lfdt $config_mak
+fi
# XXX: suppress that
if [ $bsd = yes ] ; then
diff --git a/device_tree.c b/device_tree.c
new file mode 100644
index 000..2238682
--- /dev/null
+++ b/device_tree.c
@@ -0,0 +1,114 @@
+/*
+ * Functions to help device tree manipulation using libfdt.
+ * It also provides functions to read entries from device tree proc
+ * interface.
+ *
+ * Copyright 2008 IBM Corporation.
+ * Authors: Jerone Young jyou...@us.ibm.com
+ * Hollis Blanchard holl...@us.ibm.com
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include stdio.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include unistd.h
+#include stdlib.h
+
+#include config.h
+#include qemu-common.h
+#include sysemu.h
+#include device_tree.h
+
+#include libfdt.h
+
+void *load_device_tree(const char *filename_path, void *load_addr)
+{
+int dt_file_size;
+int dt_file_load_size;
+int new_dt_size;
+int ret;
+void *dt_file = NULL;
+void *fdt;
+
+dt_file_size = get_image_size(filename_path);
+if (dt_file_size 0) {
+printf(Unable to get size of device tree file '%s'\n,
+filename_path);
+goto fail;
+}
+
+/* First allocate space in qemu for device tree */
+dt_file = qemu_mallocz(dt_file_size);
+if (dt_file == NULL) {
+printf(Unable to allocate memory in qemu for device tree\n);
+goto fail;
+}
+
+dt_file_load_size = load_image(filename_path, dt_file);
+
+/* Second we place new copy of 2x size in guest memory
+ * This give us enough room for manipulation.
+ */
+new_dt_size = dt_file_size * 2;
+
+fdt = load_addr;
+ret = fdt_open_into(dt_file, fdt, new_dt_size);
+if (ret) {
+printf(Unable to copy device tree in memory\n);
+goto fail;
+}
+
+/* Check sanity of device tree */
+if (fdt_check_header(fdt)) {
+printf (Device tree file loaded into memory is invalid: %s\n,
+filename_path);
+goto fail;
+}
+/* free qemu memory with old device tree */
+qemu_free(dt_file);
+return fdt;
+
+fail:
+qemu_free(dt_file);
+return NULL;
+}
+
+int qemu_devtree_setprop(void *fdt, const char *node_path,
+ const char *property, uint32_t *val_array, int size)
+{
+int offset;
+
+offset = fdt_path_offset(fdt, node_path);
+if (offset 0)
+return offset;
+
+return fdt_setprop(fdt, offset, property, val_array, size);
+}
+
+int qemu_devtree_setprop_cell(void *fdt, const char *node_path
[PATCH 7/8] PowerPC 440EP SoC emulation
Wire up the system-on-chip devices present on 440EP chips.
This patch is a little unusual in that qemu doesn't actually emulate the 440
core, but we use this board code with KVM (which does). If/when 440 core
emulation is supported, the kvm_enabled() hack can be removed.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
Makefile.target |1 +
hw/ppc440.c | 103 +++
hw/ppc440.h | 20 +++
3 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 hw/ppc440.c
create mode 100644 hw/ppc440.h
diff --git a/Makefile.target b/Makefile.target
index cbff562..ef2d25f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -655,6 +655,7 @@ OBJS+= heathrow_pic.o grackle_pci.o ppc_oldworld.o
OBJS+= unin_pci.o ppc_chrp.o
# PowerPC 4xx boards
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
+OBJS+= ppc440.o
ifdef FDT_LIBS
OBJS+= device_tree.o
LIBS+= $(FDT_LIBS)
diff --git a/hw/ppc440.c b/hw/ppc440.c
new file mode 100644
index 000..00d82e4
--- /dev/null
+++ b/hw/ppc440.c
@@ -0,0 +1,103 @@
+/*
+ * Qemu PowerPC 440 chip emulation
+ *
+ * Copyright 2007 IBM Corporation.
+ * Authors:
+ * Jerone Young jyou...@us.ibm.com
+ * Christian Ehrhardt ehrha...@linux.vnet.ibm.com
+ * Hollis Blanchard holl...@us.ibm.com
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include hw.h
+#include isa.h
+#include ppc.h
+#include ppc4xx.h
+#include ppc440.h
+#include ppc405.h
+#include sysemu.h
+#include kvm.h
+
+#define PPC440EP_PCI_CONFIG 0xeec0
+#define PPC440EP_PCI_INTACK 0xeed0
+#define PPC440EP_PCI_SPECIAL0xeed0
+#define PPC440EP_PCI_REGS 0xef40
+#define PPC440EP_PCI_IO 0xe800
+#define PPC440EP_PCI_IOLEN 0x0001
+
+#define PPC440EP_SDRAM_NR_BANKS 4
+
+static const unsigned int ppc440ep_sdram_bank_sizes[] = {
+25620, 12820, 6420, 3220, 1620, 820, 0
+};
+
+CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus **pcip,
+const unsigned int pci_irq_nrs[4], int do_init)
+{
+target_phys_addr_t ram_bases[PPC440EP_SDRAM_NR_BANKS];
+target_phys_addr_t ram_sizes[PPC440EP_SDRAM_NR_BANKS];
+CPUState *env;
+ppc4xx_mmio_t *mmio;
+qemu_irq *pic;
+qemu_irq *irqs;
+qemu_irq *pci_irqs;
+
+env = cpu_ppc_init(440EP);
+if (!env kvm_enabled()) {
+/* XXX Since qemu doesn't yet emulate 440, we just say it's a 405.
+ * Since KVM doesn't use qemu's CPU emulation it seems to be working
+ * OK. */
+env = cpu_ppc_init(405);
+}
+if (!env) {
+fprintf(stderr, Unable to initialize CPU!\n);
+exit(1);
+}
+
+ppc_dcr_init(env, NULL, NULL);
+
+/* interrupt controller */
+irqs = qemu_mallocz(sizeof(qemu_irq) * PPCUIC_OUTPUT_NB);
+irqs[PPCUIC_OUTPUT_INT] = ((qemu_irq *)env-irq_inputs)[PPC40x_INPUT_INT];
+irqs[PPCUIC_OUTPUT_CINT] = ((qemu_irq
*)env-irq_inputs)[PPC40x_INPUT_CINT];
+pic = ppcuic_init(env, irqs, 0x0C0, 0, 1);
+
+/* SDRAM controller */
+memset(ram_bases, 0, sizeof(ram_bases));
+memset(ram_sizes, 0, sizeof(ram_sizes));
+*ram_size = ppc4xx_sdram_adjust(*ram_size, PPC440EP_SDRAM_NR_BANKS,
+ram_bases, ram_sizes,
+ppc440ep_sdram_bank_sizes);
+/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
+ppc4xx_sdram_init(env, pic[14], PPC440EP_SDRAM_NR_BANKS, ram_bases,
+ ram_sizes, do_init);
+
+/* PCI */
+pci_irqs = qemu_malloc(sizeof(qemu_irq) * 4);
+pci_irqs[0] = pic[pci_irq_nrs[0]];
+pci_irqs[1] = pic[pci_irq_nrs[1]];
+pci_irqs[2] = pic[pci_irq_nrs[2]];
+pci_irqs[3] = pic[pci_irq_nrs[3]];
+*pcip = ppc4xx_pci_init(env, pci_irqs,
+PPC440EP_PCI_CONFIG,
+PPC440EP_PCI_INTACK,
+PPC440EP_PCI_SPECIAL,
+PPC440EP_PCI_REGS);
+if (!*pcip)
+printf(couldn't create PCI controller!\n);
+
+isa_mmio_init(PPC440EP_PCI_IO, PPC440EP_PCI_IOLEN);
+
+/* MMIO -- most miscellaneous devices live above 0xef60. */
+mmio = ppc4xx_mmio_init(env, 0xef60);
+
+if (serial_hds[0])
+ppc405_serial_init(env, mmio, 0x300, pic[0], serial_hds[0]);
+
+if (serial_hds[1])
+ppc405_serial_init(env, mmio, 0x400, pic[1], serial_hds[1]);
+
+return env;
+}
diff --git a/hw/ppc440.h b/hw/ppc440.h
new file mode 100644
index 000..b6843eb
--- /dev/null
+++ b/hw/ppc440.h
@@ -0,0 +1,20 @@
+/*
+ * Qemu PowerPC 440 board emualtion
+ *
+ * Copyright 2007 IBM Corporation.
+ * Authors: Jerone Young jyou...@us.ibm.com
+ * Christian Ehrhardt ehrha...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the GNU GPL licence version 2 or later
+ *
+ */
+
+#ifndef QEMU_PPC440_H
+#define QEMU_PPC440_H
+
+#include hw.h
[PATCH 8/8] IBM PowerPC 440EP Bamboo reference board emulation
Since most IO devices are integrated into the 440EP chip, Bamboo support
mostly entails implementing the -kernel, -initrd, and -append options.
These options are implemented by loading the guest as if u-boot had done it,
i.e. loading a flat device tree, updating it to hold initrd addresses, ram
size, and command line, and passing the FDT address in r3.
Since we use it with KVM, we enable the virtio block driver and include hooks
necessary for KVM support.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
Makefile |2 +-
Makefile.target |2 +-
hw/boards.h |1 +
hw/ppc440_bamboo.c | 190
pc-bios/bamboo.dtb | Bin 0 - 3163 bytes
pc-bios/bamboo.dts | 234 ++
target-ppc/machine.c |1 +
7 files changed, 428 insertions(+), 2 deletions(-)
create mode 100644 hw/ppc440_bamboo.c
create mode 100644 pc-bios/bamboo.dtb
create mode 100644 pc-bios/bamboo.dts
diff --git a/Makefile b/Makefile
index 01f0121..85523d7 100644
--- a/Makefile
+++ b/Makefile
@@ -222,7 +222,7 @@ common de-ch es fo fr-ca hu ja mk nl-be
pt sl tr
ifdef INSTALL_BLOBS
BLOBS=bios.bin vgabios.bin vgabios-cirrus.bin ppc_rom.bin \
video.x openbios-sparc32 openbios-sparc64 pxe-ne2k_pci.bin \
-pxe-rtl8139.bin pxe-pcnet.bin pxe-e1000.bin
+pxe-rtl8139.bin pxe-pcnet.bin pxe-e1000.bin bamboo.dtb
else
BLOBS=
endif
diff --git a/Makefile.target b/Makefile.target
index ef2d25f..c4d0f05 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -655,7 +655,7 @@ OBJS+= heathrow_pic.o grackle_pci.o ppc_oldworld.o
OBJS+= unin_pci.o ppc_chrp.o
# PowerPC 4xx boards
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
-OBJS+= ppc440.o
+OBJS+= ppc440.o ppc440_bamboo.o
ifdef FDT_LIBS
OBJS+= device_tree.o
LIBS+= $(FDT_LIBS)
diff --git a/hw/boards.h b/hw/boards.h
index a7b8126..bff1cf0 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -38,6 +38,7 @@ extern QEMUMachine core99_machine;
extern QEMUMachine heathrow_machine;
extern QEMUMachine ref405ep_machine;
extern QEMUMachine taihu_machine;
+extern QEMUMachine bamboo_machine;
/* mips_r4k.c */
extern QEMUMachine mips_machine;
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
new file mode 100644
index 000..0a3b6e4
--- /dev/null
+++ b/hw/ppc440_bamboo.c
@@ -0,0 +1,190 @@
+/*
+ * Qemu PowerPC 440 board emulation
+ *
+ * Copyright 2007 IBM Corporation.
+ * Authors:
+ * Jerone Young jyou...@us.ibm.com
+ * Christian Ehrhardt ehrha...@linux.vnet.ibm.com
+ * Hollis Blanchard holl...@us.ibm.com
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include config.h
+#include qemu-common.h
+#include net.h
+#include hw.h
+#include pci.h
+#include virtio-blk.h
+#include boards.h
+#include sysemu.h
+#include ppc440.h
+#include kvm.h
+#include kvm_ppc.h
+#include device_tree.h
+
+#define BINARY_DEVICE_TREE_FILE bamboo.dtb
+
+static void *bamboo_load_device_tree(void *addr,
+ uint32_t ramsize,
+ target_phys_addr_t initrd_base,
+ target_phys_addr_t initrd_size,
+ const char *kernel_cmdline)
+{
+void *fdt = NULL;
+#ifdef HAVE_FDT
+uint32_t mem_reg_property[] = { 0, 0, ramsize };
+char *path;
+int pathlen;
+int ret;
+
+pathlen = snprintf(NULL, 0, %s/%s, bios_dir, BINARY_DEVICE_TREE_FILE) +
1;
+path = qemu_malloc(pathlen);
+if (path == NULL)
+return NULL;
+
+snprintf(path, pathlen, %s/%s, bios_dir, BINARY_DEVICE_TREE_FILE);
+
+fdt = load_device_tree(path, addr);
+free(path);
+if (fdt == NULL)
+goto out;
+
+/* Manipulate device tree in memory. */
+
+ret = qemu_devtree_setprop(fdt, /memory, reg, mem_reg_property,
+ sizeof(mem_reg_property));
+if (ret 0)
+fprintf(stderr, couldn't set /memory/reg\n);
+
+ret = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-start,
+initrd_base);
+if (ret 0)
+fprintf(stderr, couldn't set /chosen/linux,initrd-start\n);
+
+ret = qemu_devtree_setprop_cell(fdt, /chosen, linux,initrd-end,
+(initrd_base + initrd_size));
+if (ret 0)
+fprintf(stderr, couldn't set /chosen/linux,initrd-end\n);
+
+ret = qemu_devtree_setprop_string(fdt, /chosen, bootargs,
+ kernel_cmdline);
+if (ret 0)
+fprintf(stderr, couldn't set /chosen/bootargs\n);
+
+if (kvm_enabled())
+kvmppc_fdt_update(fdt);
+
+out:
+#endif
+
+return fdt;
+}
+
+static void bamboo_init(ram_addr_t ram_size, int vga_ram_size,
+const char *boot_device, DisplayState *ds,
+const char *kernel_filename,
+const char
Re: [Qemu-devel] [PATCH 3/6] Enable KVM for ppcemb.
On Thu, 2008-12-11 at 16:54 -0600, Hollis Blanchard wrote: I don't know that kvm_ppc.c is a very information name for this sort of stuff. Since this is really host specific, not target specific, why not move it out of target-ppc. I could combine kvm_ppc.c into target-ppc/kvm.c. However, they're really two different things, and I thought it would cause the least confusion if they were logically separate. Most of it is hooks required by common code, and then some of it isn't. (I'm thinking about e.g. IA64 doing a copy/paste, and then wondering which functions they actually need to implement.) Regardless, I will still need a kvm_ppc.h, so kvm_ppc.c seemed like a good place to match. Any further thoughts on this issue? It's the only issue I still have unresolved from the initial reviews. -- Hollis Blanchard IBM Linux Technology Center -- 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: sync vcpu state during initialization
On Thu, 2008-12-11 at 15:24 -0600, Anthony Liguori wrote: Hollis Blanchard wrote: Currently on x86, qemu initializes CPUState but KVM ignores it and does its own vcpu initialization. However, PowerPC KVM needs to be able to set the initial register state to support the -kernel and -append options. Signed-off-by: Hollis Blanchard holl...@us.ibm.com Segv's x86 when using -enable-kvm. qemu.git already segvs on x86 with --enable-kvm unless you specify a -cpu option. (I'd call that a bug.) Maybe you forgot that on this run? When I use -cpu coreduo (for some strange reason core2duo is not recognized), I don't segfault. -- Hollis Blanchard IBM Linux Technology Center -- 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
[PATCH 2/6] kvm: sync vcpu state during initialization
Currently on x86, qemu initializes CPUState but KVM ignores it and does its
own vcpu initialization. However, PowerPC KVM needs to be able to set the
initial register state to support the -kernel and -append options.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
kvm-all.c | 15 +++
kvm.h |1 +
vl.c | 11 +++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index dad80df..11034df 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -141,6 +141,21 @@ err:
return ret;
}
+int kvm_sync_vcpus(void)
+{
+CPUState *env;
+
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+int ret;
+
+ret = kvm_arch_put_registers(env);
+if (ret)
+return ret;
+}
+
+return 0;
+}
+
/*
* dirty pages logging control
*/
diff --git a/kvm.h b/kvm.h
index ac464ab..efce145 100644
--- a/kvm.h
+++ b/kvm.h
@@ -31,6 +31,7 @@ struct kvm_run;
int kvm_init(int smp_cpus);
int kvm_init_vcpu(CPUState *env);
+int kvm_sync_vcpus(void);
int kvm_cpu_exec(CPUState *env);
diff --git a/vl.c b/vl.c
index c3a8d8f..0a02151 100644
--- a/vl.c
+++ b/vl.c
@@ -5456,6 +5456,17 @@ int main(int argc, char **argv, char **envp)
machine-init(ram_size, vga_ram_size, boot_devices, ds,
kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
+/* Set KVM's vcpu state to qemu's initial CPUState. */
+if (kvm_enabled()) {
+int ret;
+
+ret = kvm_sync_vcpus();
+if (ret 0) {
+fprintf(stderr, failed to initialize vcpus\n);
+exit(1);
+}
+}
+
/* init USB devices */
if (usb_enabled) {
for(i = 0; i usb_devices_index; i++) {
--
1.5.6.5
--
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
