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
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
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: kvm@vger.kernel.org; kvm-...@vger.kernel.org; ag
, 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
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
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
, 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
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
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 in
the body of a message to majord
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 in
the body of a message to majord
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
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
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
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
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
, 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
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
, 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
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
-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
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
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
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
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
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
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
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
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
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
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
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
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org embedded hypervisor
working group. Bear in mind that other hypervisors are already
implementing the documented ABI, so if you have concerns,
On Sun, May 9, 2010 at 8:26 AM, Roel Kluin roel.kl...@gmail.com wrote:
An index of KVM44x_GUEST_TLB_SIZE is already one too large.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Acked-by: Hollis Blanchard hol...@penguinppc.org
Thanks Roel.
-Hollis
--
To unsubscribe from this list: send
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:
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
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
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:
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
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
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
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
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
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
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
For the record, we've discussed more by IRC, and I think revised
patches will be forthcoming.
-Hollis
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
| 45 ---
arch/powerpc/kvm/booke.c | 5
arch/powerpc/kvm/emulate.c | 3 ++
4 files changed, 35 insertions(+), 19 deletions(-)
Acked-by: Hollis Blanchard hol...@penguinppc.org
--
To unsubscribe from this list: send the line
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
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
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 in
the body of a message to majord...@vger.kernel.org
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
.
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 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
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
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
/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
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
/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
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
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
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
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
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
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
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
);
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
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
= 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
))
+ 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
))
+ 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
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
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
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
://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
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
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
.
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
now relies on a totally
qemu upstream implementation of kvm, and does not need it anymore.
Anyway, I'm providing this patch separatedly, so that if it breaks
for whenever reason, we can identify a bisection point easily
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Hollis Blanchard
thought about implementing an
in-kernel PIC for PowerPC. (That will make more sense as an optimization
once the processors with hypervisor support start hitting the market.)
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
) {
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
On Monday 11 May 2009 17:17:53 Anthony Liguori wrote:
Hollis Blanchard wrote:
On Mon, 2009-05-11 at 12:54 -0500, Anthony Liguori wrote:
For future ppcemb's, do you know if there is an equivalent of a PF exit
type? Does the hardware squirrel away the faulting address somewhere
in some circumstances) and instruction decode. That said, I'm
willing to agree that this overhead is probably negligible compared to
the IOp itself... Ahmdal's Law again.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
a software managed TLB. There's
no page table lookup like there is on x86.
To clarify, software-managed TLBs are only found in embedded PowerPC.
Server and classic PowerPC use hash tables, which are a third MMU type.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list
they avoid both
conditionals in the above psuedocode.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
space (not even ia64 does).
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, to restate my point: the build error is not the biggest problem
with this patch. The bigger problems are all the other issues I've
repeatedly described. The build break is the icing on the cake.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line
On Sat, 2009-05-02 at 10:52 +0300, Avi Kivity wrote:
Hollis Blanchard wrote:
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
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 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
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
This reverts commit 9dc99a28236161a5a1b4c58f1e9c4ec6179cb976.
Aside from the other issues discussed on kvm-devel, this commit breaks the
PowerPC build.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
Bad mailing list address on my previous mail.
cache-utils.h | 14
.
I'll send patches separately.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
These patches fix a number of issues with PowerPC builds of qemu-kvm.git.
However, even after applying these patches it still doesn't build, due to
confusion with KVM_UPSTREAM and CONFIG_KVM.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
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
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
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
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
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
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
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
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
1 - 100 of 329 matches
Mail list logo
