) debugged problems that ended up being caused by unexpected priorities.
Knowing that the GIC has an irq ready, but doesn't deliver to the CPU due to
priority, has also proven important.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
hw/intc/arm_gic.c | 12
trace-
On 03/23/2016 09:53 AM, Paolo Bonzini wrote:
On 23/03/2016 17:47, Hollis Blanchard wrote:
Paolo, is it true that only TB-invalidating writes go through the
io_mem_notdirty path? I'm looking at the live migration code now, and it
seems like every memory write will go through that path when
On Wed, 2016-03-23 at 17:53 +0100, Paolo Bonzini wrote:
>
> On 23/03/2016 17:47, Hollis Blanchard wrote:
> >
> > Paolo, is it true that only TB-invalidating writes go through the
> > io_mem_notdirty path? I'm looking at the live migration code now,
> > and it
>
Paolo, is it true that only TB-invalidating writes go through the
io_mem_notdirty path? I'm looking at the live migration code now, and
it seems like every memory write will go through that path when global
dirty memory logging is enabled.
--
Hollis Blanchard <hollis_blanch...@mentor.com>
On Wed, 2016-03-02 at 12:12 -0800, Hollis Blanchard wrote:
> Memory accesses to code which has previously been translated into a
> TB show up
> in the MMIO path, so that they may invalidate the TB. It's extremely
> confusing
> to mix those in with device MMIOs, so split them
as the CPU index. Trace
analysis tools may need to be aware of this special case.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
v2: use get_cpu_index() helper function
---
memory.c | 32
trace-events | 8
2 files chang
Memory accesses to code which has previously been translated into a TB show up
in the MMIO path, so that they may invalidate the TB. It's extremely confusing
to mix those in with device MMIOs, so split them into their own tracepoint.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.
On 02/18/2016 10:49 AM, Alistair Francis wrote:
On Thu, Feb 18, 2016 at 10:23 AM, Hollis Blanchard
<hollis_blanch...@mentor.com> wrote:
On 02/17/2016 01:04 PM, Alistair Francis wrote:
+static void generic_loader_reset(DeviceState *dev)
+{
+GenericLoaderState *s = GENERIC_LOAD
On 02/17/2016 01:29 PM, Hollis Blanchard wrote:
diff --git a/trace-events b/trace-events
index 756ce86..7994420 100644
--- a/trace-events
+++ b/trace-events
@@ -1630,6 +1630,8 @@ memory_region_ops_read(int cpu_index, void *mr, uint64_t
addr, uint64_t value, u
memory_region_ops_write(int
This cover letter has some useful explanation. Perhaps some of the
contents should go into a docs/ file so other people can enjoy it too? :-)
I understand the part about loading multiple files, but why would I want
to load a kernel with this loader, instead of the -kernel option?
Hollis
gt;cpu, s->addr);
+}
+
+if (s->data_len) {
+dma_memory_write((s->cpu ? s->cpu : first_cpu)->as, s->addr, >data,
+ s->data_len);
+}
+}
What happens if I accidentally make "data-len" bigger than
sizeof(s->data)? I think some
as the CPU index. Trace
analysis tools may need to be aware of this special case.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
memory.c | 48
trace-events | 8
2 files changed, 40 insertions(+), 16 deletions(-)
Memory accesses to code which has previously been translated into a TB show up
in the MMIO path, so that they may invalidate the TB. It's extremely confusing
to mix those in with device MMIOs, so split them into their own tracepoint.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.
On 02/09/2016 07:53 AM, Stefan Hajnoczi wrote:
On Mon, Feb 08, 2016 at 04:03:05PM -0800, Hollis Blanchard wrote:
-memory_region_ops_read(void *mr, uint64_t offset, uint64_t value, unsigned size) "mr %p offset
%#"PRIx64" value %#"PRIx64" size %u"
-memory_regio
effect.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
trace/simple.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/trace/simple.c b/trace/simple.c
index 3fdcc82..67ccc3c 100644
--- a/trace/simple.c
+++ b/trace/simple.c
@@ -209,6 +209,8
On 02/08/2016 07:30 AM, Stefan Hajnoczi wrote:
On Wed, Jan 13, 2016 at 03:13:02PM -0800, Hollis Blanchard wrote:
The event timestamps are host time (get_clock()). I'm correlating qemu
events with other logs (using icount), so host time is unhelpful. Could we
use cpu_get_clock() instead? (Trace
When memory_region_ops tracepoints are enabled, calculate and record the
absolute address being accessed. Otherwise, we only get offsets into the
memory region instead of addresses.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
memory.c
while we're editing the tracepoint definitions.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
As agreed in https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg01509.html
and https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg01551.ht
The simple tracing backend has supported strings for more than three years
(62bab73213ba885426a781eb2741670b9f3cae36).
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
docs/tracing.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/docs/tracing.txt b/docs/traci
the
situation, omitting "-trace file=foo" results in the directory being
littered with trace- files... could we create the file only when
tracing is activated? And maybe with a more predictable name?
--
Hollis Blanchard
Mentor Graphics Emulation Division
On 11/24/2015 11:20 PM, Stefan Hajnoczi wrote:
On Tue, Nov 17, 2015 at 04:37:48PM -0800, Hollis Blanchard wrote:
On 11/13/2015 02:23 AM, Stefan Hajnoczi wrote:
On Wed, Nov 11, 2015 at 05:09:58PM -0800, Hollis Blanchard wrote:
Recording the MemoryRegion pointers isn't helpful, especially since
On 12/09/2015 01:12 PM, Paolo Bonzini wrote:
On 09/12/2015 21:54, Hollis Blanchard wrote:
#0 trace_memory_region_ops_write (mr=0x185b620, addr=16, absaddr=738205712,
value=136, size=4)
at
/scratch1/hblancha/install/customq/qemu-2.4.0/src/trace/generated-tracers.h:7374
#1
On 12/09/2015 01:12 PM, Paolo Bonzini wrote:
On 09/12/2015 21:54, Hollis Blanchard wrote:
#0 trace_memory_region_ops_write (mr=0x185b620, addr=16, absaddr=738205712,
value=136, size=4)
at
/scratch1/hblancha/install/customq/qemu-2.4.0/src/trace/generated-tracers.h:7374
#1
On 11/13/2015 02:23 AM, Stefan Hajnoczi wrote:
On Wed, Nov 11, 2015 at 05:09:58PM -0800, Hollis Blanchard wrote:
Recording the MemoryRegion pointers isn't helpful, especially since no trace
data allows us to correlate those pointers to devices. Instead, record the
MemoryRegion name.
Signed-off
Recording the MemoryRegion pointers isn't helpful, especially since no trace
data allows us to correlate those pointers to devices. Instead, record the
MemoryRegion name.
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
memory.c | 12 ++--
trace-events | 4 +
The simple tracing backend has supported strings for more than three years
(62bab73213ba885426a781eb2741670b9f3cae36).
Signed-off-by: Hollis Blanchard <hollis_blanch...@mentor.com>
---
docs/tracing.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/docs/tracing.txt b/docs/traci
On 11/06/2015 03:15 AM, Peter Maydell wrote:
On 6 November 2015 at 11:12, Stefan Hajnoczi <stefa...@gmail.com> wrote:
On Mon, Nov 02, 2015 at 09:18:03AM -0800, Hollis Blanchard wrote:
I'm trying to use the memory_region_ops_read/write tracepoints. They produce
outpu
by MemoryRegions
0x185b1e8 and 0x1914240? Or alternatively how do I discover the full
addresses? Thanks.
--
Hollis Blanchard
Mentor Graphics Emulation Division
On Wed, Oct 13, 2010 at 11:58 AM, Stefan Weil w...@mail.berlios.de wrote:
Hollis, do you still see problems with my patch?
Or can it be committed?
I have no objection; I was just anticipating Blue's objection when I
commented previously. It's just a style question really...
-Hollis
cast to 'unsigned' catches negative values of op
(which should never happen).
This is a modification of Hollis Blanchard's patch.
Cc: Hollis Blanchard hol...@penguinppc.org
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
tcg/tcg.c | 2 +-
1 files
TCGOpcode is an enum, which apparently can be unsigned.
Signed-off-by: Hollis Blanchard hol...@penguinppc.org
---
% ./configure --target-list=ppcemb-softmmu --enable-debug
% make
...
CCppcemb-softmmu/tcg/tcg.o
cc1: warnings being treated as errors
/home/hollisb/source/qemu.git/tcg/tcg.c
in PATH
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
On 08/24/2010 05:55 PM, Hollis Blanchard wrote:
The problem seems to be that jump from /usr/include/bits/sigcontext.h
to asm/sigcontext.h inside kerneldir rather than inside
/usr/include. It seems like adding -Ikerneldir/arch/foo/include will
always be a problem, since it will always be used
On 08/25/2010 06:37 AM, Arnd Bergmann wrote:
On Wednesday 25 August 2010, Hollis Blanchard wrote:
The problem seems to be that jump from /usr/include/bits/sigcontext.h to
asm/sigcontext.h insidekerneldir rather than inside /usr/include. It
seems like adding -Ikerneldir/arch/foo/include
KVM_CFLAGS
files doesn't.
I'm wondering why this isn't causing more problems for more people. My
host is Fedora 12, FWIW, but this doesn't seem like it could at all be
related to toolchain version, for example.
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
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
On Mon, Aug 9, 2010 at 6:29 AM, Anthony Liguori anth...@codemonkey.ws wrote:
Sorry, I've got it now. In the future, please resend patches with [RESEND]
as opposed to just bumping it.
Isn't anybody using
http://patchwork.ozlabs.org/project/qemu-devel/list/ ? Tbat was
designed specifically to
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-devel@nongnu.org
Cc: kvm
I am able to run qemu with the following commandline:
/usr/local/bin/qemu-system-ppcemb -enable-kvm -kernel uImage.bamboo
-nographic -M bamboo ppc440-angstrom-linux.img
However, when I try to use virtio instead, I get this segfault:
/usr/local/bin/qemu-system-ppcemb -enable-kvm -kernel
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.
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
-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
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
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
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
From: Hollis Blanchard hollis_blanch...@mentor.com
Fixes this error during make install:
...
install -m0755 -p -s qemu-nbd qemu-img qemu-io
/opt/ppc440-angstrom-linux/usr/local/bin
strip: Unable to recognise the format of the input file
`/opt/ppc440-angstrom-linux/usr/local/bin/qemu-nbd
From: Hollis Blanchard hollis_blanch...@mentor.com
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
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
On Wed, Apr 21, 2010 at 5:36 AM, Alexander Graf ag...@suse.de wrote:
Thomas Monjalon wrote:
Alexander Graf wrote:
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
env-excp_vectors[POWERPC_EXCP_SMI]
On Tue, Jan 26, 2010 at 10:14 PM, Liu Yu yu@freescale.com wrote:
So that the following registers init could be flushed back to kvm.
Signed-off-by: Liu Yu yu@freescale.com
Acked-by: Hollis Blanchard hol...@penguinppc.org
Thanks Yu.
-Hollis
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Hollis Blanchard hol...@penguinppc.org
Hi Anthony, please apply these two patches to fix the PowerPC KVM build.
-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
Unbreaks PowerPC and S390 KVM builds.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/kvm-all.c b/kvm-all.c
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -207,26 +207,6 @@ err:
return ret;
}
-int kvm_put_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state = { .mp_state
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
--- a/target-ppc/kvm_ppc.c
+++ b/target-ppc/kvm_ppc.c
@@ -52,7 +52,6 @@ close:
fclose(f);
free:
free(path);
-out:
return ret;
}
--
To unsubscribe from this list: send
/hollisb/source/qemu-fresh.hg/kvm-all.c:212: error: 'struct
CPUPPCState' has no member named 'mp_state'
-Hollis
On Mon, Nov 9, 2009 at 2:12 PM, Jan Kiszka jan.kis...@web.de wrote:
Hollis Blanchard wrote:
Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE
On Wed, 2009-10-21 at 21:17 +0200, Alexander Graf wrote:
MP State is implemented in the generic code, so let's move the variable
it accesses to generic code as well.
Still unbreaks PPC and now even S390x w/ KVM.
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Hollis Blanchard holl
On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
Below is a patch I'm using to fix rtl8139
-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/qemu/hw/rtl8139.c b/qemu/hw/rtl8139.c
--- a/qemu/hw/rtl8139.c
+++ b/qemu/hw/rtl8139.c
@@ -2735,13 +2735,8 @@ static void rtl8139_io_writew(void *opaq
default:
DEBUG_PRINT((RTL8139: ioport write(w) addr=0x%x val=0x%04x via
target.
I'm not really familiar with the qemu development process; is this
usually how it works? People are free to break things and assume others
will fix it?
--
Hollis Blanchard
IBM Linux Technology Center
by accident: outsw() in Linux
writes big-endian data, which is incorrectly swapped in isa_mmio.c, and
then incorrectly swapped again in ne2000.c.)
--
Hollis Blanchard
IBM Linux Technology Center
for this, so you should skim
them...
--
Hollis Blanchard
IBM Linux Technology Center
; they use MMUCR[STID].
Also, IBM and Freescale Book E architectures are very different here, so I
would suggest naming these functions something more specific than
e.g. do_booke_tlbwe. You're really implementing IBM's 440
architecture here.
--
Hollis Blanchard
IBM Linux Technology Center
.
Strictly speaking, creating a library isn't required to meet that goal,
but it will enforce the modularity we need, and IMHO that is just good
coding practice.
(I'm not even talking about Anthony's points about avoiding qemu forks,
which I also agree with.)
--
Hollis Blanchard
IBM Linux Technology
you need.
Hmm, that's a good point. Is that something you think can reasonably be
accomplished with qemu today?
--
Hollis Blanchard
IBM Linux Technology Center
68 matches
Mail list logo
