sadly) 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
---
hw/intc/arm_gic.c | 12
trace-events | 8 +++
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
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 i
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
Mentor Graphics Emul
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
record as the CPU index. Trace
analysis tools may need to be aware of this special case.
Signed-off-by: Hollis Blanchard
---
v2: use get_cpu_index() helper function
---
memory.c | 32
trace-events | 8
2 files changed, 24 insertions(+), 16 deletion
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
Reviewed-by: Stefan Haj
On 02/18/2016 10:49 AM, Alistair Francis wrote:
On Thu, Feb 18, 2016 at 10:23 AM, Hollis Blanchard
wrote:
On 02/17/2016 01:04 PM, Alistair Francis wrote:
+static void generic_loader_reset(DeviceState *dev)
+{
+GenericLoaderState *s = GENERIC_LOADER(dev);
+
+if (s->
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, &s->data,
+ s->data_len);
+}
+}
What happens if I accidentally make "data-len" bigger than
sizeof(s->data)? I think s
record as the CPU index. Trace
analysis tools may need to be aware of this special case.
Signed-off-by: Hollis Blanchard
---
memory.c | 48
trace-events | 8
2 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/memory.c
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
---
It took many hou
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
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
---
memory.c | 44
trace-events
; while we're editing the tracepoint definitions.
Signed-off-by: Hollis Blanchard
---
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.html.
---
memory.c | 36 +
The simple tracing backend has supported strings for more than three years
(62bab73213ba885426a781eb2741670b9f3cae36).
Signed-off-by: Hollis Blanchard
---
docs/tracing.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/docs/tracing.txt b/docs/tracing.txt
index 3853a6a..f2f553b 100644
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? (
any noticeable effect.
Signed-off-by: Hollis Blanchard
---
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 @@ int trace_record_start(TraceBu
ent. Compounding 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 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/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
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.
Signe
The simple tracing backend has supported strings for more than three years
(62bab73213ba885426a781eb2741670b9f3cae36).
Signed-off-by: Hollis Blanchard
---
docs/tracing.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/docs/tracing.txt b/docs/tracing.txt
index 3853a6a..f2f553b 100644
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
---
memory.c | 12 ++--
trace-events | 4 ++--
2 files changed, 8 inser
On 11/06/2015 03:15 AM, Peter Maydell wrote:
On 6 November 2015 at 11:12, Stefan Hajnoczi 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
output like this:
memory_region_ops_write
ed 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 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
part.
> The type cast to 'unsigned' catches negative values of op
> (which should never happen).
>
> This is a modification of Hollis Blanchard's patch.
>
> Cc: Hollis Blanchard
> Cc: Blue Swirl
> Signed-off-by: Stefan Weil
> ---
> tcg/tcg.c | 2 +-
>
TCGOpcode is an enum, which apparently can be unsigned.
Signed-off-by: Hollis Blanchard
---
% ./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 function
PATH
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
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 inside rather than inside /usr/include. It
seems like adding -Ikerneldir/arch/foo/include will always
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 rather than inside
/usr/include. It seems like adding -Ikerneldir/arch/foo/include will
always be a problem, since it will always be used to
re the other 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 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 help manage patch su
On Thu, Aug 5, 2010 at 7:39 PM, 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, August 05, 2010 8:22 AM
>>
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-
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
---
hw/ppc4xx_devs.c |1 -
1 files changed, 0
Signed-off-by: Hollis Blanchard
---
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_
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
Cc: blauwir...@gmail
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.
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 uImage.bamb
On Mon, Aug 2, 2010 at 12:56 PM, Edgar E. Iglesias
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,
On Mon, Aug 2, 2010 at 1:41 AM, Alexander Graf 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
On Mon, Aug 2, 2010 at 11:57 AM, Edgar E. Iglesias
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
>> wrote:
>> > On Sat, Jul 31, 2010 at 12:56:42AM +0200, Edgar E. Iglesias wrote:
>> &g
On Sun, Aug 1, 2010 at 5:36 AM, Edgar E. Iglesias
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
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
---
h
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
---
hw/ppc4xx_devs.c |1 -
1 files changed, 0 insertions
From: Hollis Blanchard
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 suppo
From: Hollis Blanchard
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'
Signed
On Wed, Apr 21, 2010 at 5:36 AM, Alexander Graf 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
On Tue, Jan 26, 2010 at 10:14 PM, Liu Yu wrote:
> So that the following registers init could be flushed back to kvm.
>
> Signed-off-by: Liu Yu
Acked-by: Hollis Blanchard
Thanks Yu.
-Hollis
rror
>
> Signed-off-by: Alexander Graf
Acked-by: Hollis Blanchard
p_state':
/home/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 wrote:
> Hollis Blanchard wrote:
>> Unbreaks PowerPC and S390 KVM builds.
>
> What breaks pr
Unbreaks PowerPC and S390 KVM builds.
Signed-off-by: Hollis Blanchard
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 = env->mp_st
Signed-off-by: Hollis Blanchard
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 the line "unsubs
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
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
Acked-by: Hol
*and* string should be returned to the client, right? The
client can localize based on errno, and in addition optionally provide
the server-provided string to the user.
--
Hollis Blanchard
IBM Linux Technology Center
pport
> happen
> to do the same thing.
Thanks for pursuing this Aurelien.
Although patches that replace cpu_to_* with TARGET_WORDS_BIGENDIAN usage
make me cringe, these patches do indeed seem to fix BE/BE host/target
behavior right now.
--
Hollis Blanchard
IBM Linux Technology Center
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:
> > > >
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:
> > On Tue, 04 Mar 2008 01:30:15 +0100, Aurelien Jarno wrote:
> >
> > > This patches fixes endianness issues in the e1000 nic emulation, which
&g
7;t have
patches for these at this time.
Fix endianness conversion in rtl8139.c.
PCI data is always in LE format, so convert from LE at the interface to
"qemu endianness" internally, then convert again on the way back out.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
t, and post here when you
> start working on a particular 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
tually I believe this is also working 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
On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote:
>
> Hollis Blanchard wrote:
> > A comment to explain why the icache needs flushing only in the KVM
> case
> > would be useful. Other than that I'm fine with it.
> >
> > Signed-off-by: Hollis Blanc
ex,
> IO_MEM_NB_ENTRIES);
> } else {
> if (io_index >= IO_MEM_NB_ENTRIES)
> return -1;
Bad indentation.
I didn't check the rest of your patches for this, so you should skim
them...
--
Hollis Blanchard
IBM Linux Technology Center
ah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.64&r2=1.65
tlbwe and tlbre do not use PID; 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_bo
t to build a single binary
> with just the features 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
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 Center
es over C files, that are being used now.
Really? Take a look at ppc_prep_init()...
I would love to see machine definition done in python.
--
Hollis Blanchard
IBM Linux Technology Center
73 matches
Mail list logo
