Attaching config file mentioned in previous comment.
** Attachment added: "windows8_throwaway_VM.conf"
https://bugs.launchpad.net/qemu/+bug/1288620/+attachment/4049965/+files/windows8_throwaway_VM.conf
** Summary changed:
- memory leak with default NIC model
+ memory leak with config file
*
I have been able to consistently reproduce the bug again, and have run
QEMU with Valgrind until OOM. It is unrelated to networking; it is
caused by loading a config file.
I ran QEMU from Git commit 7f6613cedc59fa849105668ae971dc31004bca1c
under valgrind via...
valgrind qemu-system-x86_64 -readco
From: Peter Maydell
To avoid C undefined behaviour when patching generated code,
provide wrappers tcg_patch8/16/32/64 which use the usual memcpy
trick, and use them in the i386 backend.
Signed-off-by: Peter Maydell
Signed-off-by: Richard Henderson
---
tcg/i386/tcg-target.c | 12 ++--
Signed-off-by: Richard Henderson
---
tcg/sparc/tcg-target.c | 57 --
tcg/sparc/tcg-target.h | 2 +-
2 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 152335c..44d8995 100644
--- a
Signed-off-by: Richard Henderson
---
tcg/aarch64/tcg-target.c | 38 --
tcg/aarch64/tcg-target.h | 1 +
2 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index 661a5af..2614201 100644
--- a/tcg/
Here's where I think we should go with the cleanup that Peter started.
I've only converted a couple of the backends as examples. It's not 100%
mechanical, since one has to be aware of the change in the semantics of
pointer arithmetic (e.g. s->code_ptr - s->code_buf).
Taking Sparc as an example,
Signed-off-by: Richard Henderson
---
tcg/ppc/tcg-target.c | 55 ++--
tcg/ppc/tcg-target.h | 1 +
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index dc2c2df..36f261b 100644
--- a/tcg/pp
To be defined by the tcg backend based on the elemental unit of the ISA.
During the transition, allow TCG_TARGET_ITYPE_SIZE to be undefined, which
allows us to default tcg_itype to the current uint8_t.
Signed-off-by: Richard Henderson
---
include/exec/exec-all.h | 2 +-
tcg/i386/tcg-target.h
From: Peter Maydell
Avoid stores to unaligned addresses in TCG code generation, by using the
usual memcpy() approach. (Using bswap.h would drag a lot of QEMU baggage
into TCG, so it's simpler just to do direct memcpy() here.)
Signed-off-by: Peter Maydell
Signed-off-by: Richard Henderson
---
t
Signed-off-by: Richard Henderson
---
tcg/ppc64/tcg-target.c | 46 --
tcg/ppc64/tcg-target.h | 1 +
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/tcg/ppc64/tcg-target.c b/tcg/ppc64/tcg-target.c
index 06e440f..0920cae 100644
--- a/tcg/
From: Peter Maydell
The code which patches x86 jump instructions assumes it can do an
unaligned write of a uint32_t. This is actually safe on x86, but it's
still undefined behaviour. We have infrastructure for doing efficient
unaligned accesses which doesn't engage in undefined behaviour, so
use
On Sat, Mar 29, 2014 at 12:22:58AM +0100, Max Reitz wrote:
> On 26.03.2014 13:06, Stefan Hajnoczi wrote:
> >From: Jeff Cody
> >
> >This test checks for proper bounds checking of some VDI input
> >headers. The following is checked:
> >
> >1. Max image size (1024TB) with the appropriate Blocks In I
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
This avoids a possible division by zero.
Convert s->tracks to unsigned as well because it feels better than
surviving just because the results of calculations with s->tracks are
converted to unsigned anyway.
Signed-off-by: Kevin Wol
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
The first test case would cause a huge memory allocation, leading to a
qemu abort; the second one to a too small malloc() for the catalog
(smaller than s->catalog_size), which causes a read-only out-of-bounds
array access and on big e
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
Chunk length and sectorcount are used for decompression buffers as well
as the bdrv_pread() count argument. Ensure that they have reasonable
values so neither memory allocation nor conversion from uint64_t to int
will cause problems.
Signed-off-by: St
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
Even with a limit of 64k snapshots, each snapshot could have a filename
and an ID with up to 64k, which would still lead to pretty large
allocations, which could potentially lead to qemu aborting. Limit the
total size of the snapshot
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
This avoids an unbounded allocation.
Signed-off-by: Kevin Wolf
---
block/qcow2-snapshot.c | 4
block/qcow2.c | 4 +---
block/qcow2.h | 4
tests/qemu-iotests/080 | 15 ++
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
For the L1 table to loaded for an internal snapshot, the code allocated
only enough memory to hold the currently active L1 table. If the
snapshot's L1 table is actually larger than the current one, this leads
to a buffer overflow.
Si
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
The qcow2 code assumes that s->snapshots is non-NULL if s->nb_snapshots
!= 0. By having the initialisation of both fields separated in
qcow2_open(), any error occuring in between would cause the error path
to dereference NULL in qcow2
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
bs->total_sectors is not the highest possible sector number that could
be involved in a copy on write operation: VM state is after the end of
the virtual disk. This resulted in wrong values for the number of
sectors to be copied (n).
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
Limiting the size of a single request to INT_MAX not only fixes a
direct integer overflow in bdrv_check_request() (which would only
trigger bad behaviour with ridiculously huge images, as in close to
2^64 bytes), but can also prevent
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
From: Jeff Cody
This test checks for proper bounds checking of some VDI input
headers. The following is checked:
1. Max image size (1024TB) with the appropriate Blocks In Image
value (0x3fff) is detected as valid.
2. Image size exceeding ma
On 03/28/2014 09:13 AM, Andreas Färber wrote:
> +#ifndef __LITTLE_ENDIAN__
> #define TCG_TARGET_WORDS_BIGENDIAN
> +#endif
> #define TCG_TARGET_NB_REGS 32
>
Please let's just replace TCG_TARGET_WORDS_BIGENDIAN with HOST_WORDS_BIGENDIAN
throughout and be done with it.
r~
On 26.03.2014 13:06, Stefan Hajnoczi wrote:
Both compressed and uncompressed I/O is buffered. dmg_open() calculates
the maximum buffer size needed from the metadata in the image file.
There is currently a buffer overflow since ->lengths[] is accounted
against the maximum compressed buffer size
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
Use the right types instead of signed int:
size_t new_size;
This is a byte count for g_realloc() that is calculated from uint32_t
and size_t values.
uint32_t chunk_count;
Use the same type as s->n_chunks, which is used together with
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
The DMG metadata is stored as uint64_t, so use the same type for
sector_num. int was a particularly poor choice since it is only 32-bit
and would truncate large values.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
block/dmg.c | 6 +
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
It is not necessary to check errno for EINTR and the block layer does
not produce short reads. Therefore we can drop the loop that attempts
to read a compressed chunk.
The loop is buggy because it incorrectly adds the transferred bytes
twice:
do {
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
When a terminator is reached the base for offsets and sectors is stored.
The following records that are processed will use this base value.
If the first record we encounter is a terminator, then calculating the
base values would result in out-of-bounds
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
Clean up the mix of tabs and spaces, as well as the coding style
violations in block/dmg.c. There are no semantic changes since this
patch simply reformats the code.
This patch is necessary before we can make meaningful changes to this
file, due to th
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
The size in bytes is assigned to an int later, so check that instead of
the number of entries.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Max Reitz
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Max Reitz
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
In order to avoid integer overflows.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 11 ++-
block/qcow2.h | 6 +++---
2 files changed, 9 insertions(+), 8 deletions(-)
Reviewed-by: Max Reitz
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
If the size becomes larger than what qcow2_open() would accept, fail the
growing operation.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 4
block/qcow2.c | 4 +---
block/qcow2.h | 9 +
3
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
This ensures that the checks catch all invalid cluster indexes
instead of returning the refcount of a wrong cluster.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Rev
On 28.03.2014 18:06, Stefan Hajnoczi wrote:
From: Kevin Wolf
free_cluster_index is only correct if update_refcount() was called from
an allocation function, and even there it's brittle because it's used to
protect unfinished allocations which still have a refcount of 0 - if it
moves in the wron
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
len could become negative and would pass the check then. Nothing bad
happened because bdrv_pread() happens to return an error for negative
length values, but make variables for sizes unsigned anyway.
This patch also changes the behav
On 26.03.2014 13:05, Stefan Hajnoczi wrote:
From: Kevin Wolf
This avoids an unbounded allocation.
Signed-off-by: Kevin Wolf
---
block/qcow2.c | 16
tests/qemu-iotests/080 | 18 ++
tests/qemu-iotests/080.out | 11 +++
3 files chang
On 28.03.2014 18:38, Prasad Joshi wrote:
Signed-off-by: Prasad Joshi
---
block/qcow2.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..10eccf9 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -506,6 +506,7 @@ static int qcow2_open(BlockDri
On 28/03/14 2:04 PM, Noonan, Steven wrote:
On 3/28/14, 10:51 AM, "Paolo Bonzini" wrote:
Il 28/03/2014 18:41, Laurent Desnogues ha scritto:
+ gcc_flags="-fstack-protector-strong -fstack-protector-all"
+ for flag in $gcc_flags; do
+if compile_prog "-Werror $flag" "" ; then
+ QEMU_CFL
On Fri, 28 Mar 2014 11:57:17 +0100
Greg Kurz wrote:
> From: Rusty Russell
>
> virtio data structures are defined as "target endian", which assumes
> that's a fixed value. In fact, that actually means it's platform-specific.
> The OASIS virtio 1.0 spec will fix this, by making all little endian
On 28.03.2014 20:34, Alex Bennée wrote:
@@ -2575,6 +2579,8 @@ static inline int
tcg_gen_code_common(TCGContext *s, uint64_t target_pc,
the_end:
/* Generate TB finalization at the end of block */
tcg_out_tb_finalize(s);
+
+tcg_write_perfmap(gen_code_buf, s->code_ptr - gen_code
* arei.gong...@huawei.com (arei.gong...@huawei.com) wrote:
> From: ChenLiang
>
> Reducing data copy can reduce cpu overhead.
>
> Signed-off-by: ChenLiang
> Signed-off-by: Gonglei
> Reviewed-by: Juan Quintela
> ---
> arch_init.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
Avoid stores to unaligned addresses in TCG code generation, by using the
usual memcpy() approach. (Using bswap.h would drag a lot of QEMU baggage
into TCG, so it's simpler just to do direct memcpy() here.)
Signed-off-by: Peter Maydell
---
tcg/tcg.c | 6 +++---
1 file changed, 3 insertions(+), 3
On 3/28/2014 7:02 AM, Thomas Huth wrote:
> On Fri, 28 Mar 2014 18:25:02 +0800
> Alexander Graf wrote:
>
>>
>>
>>> Am 28.03.2014 um 16:16 schrieb Thomas Huth :
>>>
>>> An easy way to fix this for Book III-S is to change the mask to
>>> 0x001EF801 (just like the mask for mtmsrd), but I am afraid
On 28 March 2014 14:22, Peter Maydell wrote:
> Initialize the dbs->in_cancel flag in dma_bdrv_io(), since qemu_aio_get()
> does not return zero-initialized memory. Spotted by the clang sanitizer
> (which complained when the value loaded in dma_complete() was not valid
> for a bool type); this migh
On Fri, 28 Mar 2014 18:59:22 +0100
Andreas Färber wrote:
> Am 28.03.2014 11:57, schrieb Greg Kurz:
> > From: Rusty Russell
> >
> > virtio data structures are defined as "target endian", which assumes
> > that's a fixed value. In fact, that actually means it's platform-specific.
> > The OASIS v
On Fri, 28 Mar 2014 18:14:55 +
Peter Maydell wrote:
> On 28 March 2014 18:04, Greg Kurz wrote:
> > Ok, I am now convinced. Let's make struct VirtIODevice* be the
> > first argument for all helpers and kill the AddressSpace* one.
> > Unless you envision we could end up with different address
On 03/28/2014 11:18 AM, Peter Maydell wrote:
> On 28 March 2014 18:06, Richard Henderson wrote:
>> On 03/28/2014 08:29 AM, Peter Maydell wrote:
>>> Peter Maydell (3):
>>> exec-all.h: Use stl_p to avoid undefined behaviour patching x86 jumps
>>> tcg: Avoid stores to unaligned addresses
>>> tc
On 03/28/2014 09:09 AM, Peter Maydell wrote:
> +for (i = 0; i < maxidx; i++) {
> +hostaddr[i] = tlb_vaddr_to_host(env,
> +vaddr + TARGET_PAGE_SIZE * i,
> +1, cpu_mmu_index(env
Am 28.03.2014 10:55, schrieb Stefan Hajnoczi:
> test-rfifolock and test-vmstate only build on POSIX hosts. Exclude them
> if building for Windows.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/Makefi
On 28 March 2014 18:06, Richard Henderson wrote:
> On 03/28/2014 08:29 AM, Peter Maydell wrote:
>> Peter Maydell (3):
>> exec-all.h: Use stl_p to avoid undefined behaviour patching x86 jumps
>> tcg: Avoid stores to unaligned addresses
>> tcg: Avoid undefined behaviour patching code at unalig
On 28 March 2014 18:04, Greg Kurz wrote:
> Ok, I am now convinced. Let's make struct VirtIODevice* be the
> first argument for all helpers and kill the AddressSpace* one.
> Unless you envision we could end up with different address spaces
> accross multiple virtio devices
Well, any one virtio dev
From: Peter Maydell
Make qemu_log_mask() a macro which only calls the function to
do the actual work if the logging is enabled. This avoids making
a function call in possible fast paths where logging is disabled.
Signed-off-by: Peter Maydell
diff --git a/include/qemu/log.h b/include/qemu/log.h
Implement the auxiliary fault status registers AFSR0_EL1 and
AFSR1_EL1. These are present on v7 and later, and have IMPDEF
behaviour; we choose to RAZ/WI for all cores.
Signed-off-by: Peter Maydell
---
target-arm/helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/target-arm/he
On 03/28/2014 08:29 AM, Peter Maydell wrote:
> Peter Maydell (3):
> exec-all.h: Use stl_p to avoid undefined behaviour patching x86 jumps
> tcg: Avoid stores to unaligned addresses
> tcg: Avoid undefined behaviour patching code at unaligned addresses
Reviewed-by: Richard Henderson
r~
On Fri, 28 Mar 2014 17:43:07 +
Peter Maydell wrote:
> On 28 March 2014 17:37, Greg Kurz wrote:
> > And while we are at it, since we pass &address_space_memory to all
> > occurences of virtio_*_phys() and I don't see why we would change
> > that, maybe we can also move that into the helpers.
The AArch64 usermode 'any' CPU type was accidentally specified
with the ARM_FEATURE_THUMB2EE bit set. This is incorrect since
ARMv8 removes Thumb2EE completely. Since we never implemented
Thumb2EE anyway having the feature bit set was fairly harmless
for user-mode, but the correct thing is to not s
Am 28.03.2014 11:57, schrieb Greg Kurz:
> From: Rusty Russell
>
> virtio data structures are defined as "target endian", which assumes
> that's a fixed value. In fact, that actually means it's platform-specific.
> The OASIS virtio 1.0 spec will fix this, by making all little endian.
>
> We need
On 03/28/2014 08:46 AM, Peter Lieven wrote:
> this patch tries to optimize zero write requests
> by automatically using bdrv_write_zeroes if it is
> supported by the format.
>
> This significantly speeds up file system initialization and
> should speed zero write test used to test backend storage
On 28 March 2014 15:49, Andreas Färber wrote:
> CPU address spaces touching load and store helpers as well as the
> movement of (almost) all fields from CPU_COMMON to CPUState have led to
> a noticeable increase of CPU() usage in "hot" paths for both TCG and KVM.
>
> While CPU()'s OBJECT_CHECK() m
Amos Kong writes:
> Signed-off-by: Amos Kong
> ---
> vl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/vl.c b/vl.c
> index 2355227..596ecfa 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -449,6 +449,7 @@ static QemuOptsList qemu_object_opts = {
> },
> };
>
> +#ifdef CONFIG_TPM
>
The code which patches x86 jump instructions assumes it can do an
unaligned write of a uint32_t. This is actually safe on x86, but it's
still undefined behaviour. We have infrastructure for doing efficient
unaligned accesses which doesn't engage in undefined behaviour, so
use it.
This is technical
Add U suffix to avoid shifting left into the sign bit, which
is undefined behaviour.
Signed-off-by: Peter Maydell
---
hw/ide/ahci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index bfe633f..50327ff 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide
Il 28/03/2014 15:52, Andreas Färber ha scritto:
I do wonder if it wouldn't make more sense to simply
#define CPU(obj) ((CPUState *)obj)
which would catch all uses of CPU() while still allowing to change it to
#define CPU(obj) dynamic_cast(obj)
or so in the future without touching dozens of places
this patch tries to optimize zero write requests
by automatically using bdrv_write_zeroes if it is
supported by the format.
This significantly speeds up file system initialization and
should speed zero write test used to test backend storage
performance.
I ran the following 2 tests on my internal
Implement the DC ZVA instruction, which clears a block of memory.
The fast path obtains a pointer to the underlying RAM via the TCG TLB
data structure so we can do a direct memset(), with fallback to a
simple byte-store loop in the slow path.
Signed-off-by: Peter Maydell
---
include/exec/softmmu
For the A64 instruction set, the only FP/Neon disable trap
is the CPACR FPEN bits, which may indicate "enabled", "disabled"
or "disabled for EL0". Add a bit to the AArch64 tb flags indicating
whether FP/Neon access is currently enabled and make the decoder
emit code to raise exceptions on use of FP
Hi everybody,
I didn't see anything on the list about that.
I get this bug in the current git.
I configured qemu with the following command line:
./configure --target-list=ppc-softmmu
I ran QEMU with the following command line:
./ppc-softmmu/qemu-system-ppc --M mpc8544ds
I get this segfault:
On 28 March 2014 12:13, Michael S. Tsirkin wrote:
> The following changes since commit 7f6613cedc59fa849105668ae971dc31004bca1c:
>
> target-mips: fix MTHC1 and MFHC1 when FPU in FR=0 mode (2014-03-25 23:36:35
> +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/sc
The ARM946 model currently uses the c5_data and c5_insn fields in the CPU
state struct to store the contents of its access permission registers.
This is confusing and a good source of bugs because for all the MMU-based
CPUs those fields are fault status and fault address registers, which
behave com
On 3/28/2014 9:36 AM, Tom Musta wrote:
> I agree with Alex that a flags based approach could be used to support the L
> bit for
> Book III-S models and to ignore the L bit for Book III-E models. The
> question is
> which flag(s) can we use? Let me see if I can find out.
I looked at this a bit
Right now to run firmware inside the QEMU VExpress model requires
padding out the firmware image to the size of the virtual flash and
passing it in via the -pflash argument. If the firmware image is passed
without padding, then QEMU will fail. Also, when passed as a -pflash
argument, QEMU treats th
Am 28.03.2014 16:52, schrieb Peter Maydell:
> On 28 March 2014 15:49, Andreas Färber wrote:
>> CPU address spaces touching load and store helpers as well as the
>> movement of (almost) all fields from CPU_COMMON to CPUState have led to
>> a noticeable increase of CPU() usage in "hot" paths for bot
The AArch64 implementation of the set_pc method needs to be updated to
handle the possibility that the CPU is in AArch32 mode; otherwise there
are weird crashes when doing interprocessing in system emulation mode
when an interrupt occurs and we fail to resynchronize the 32-bit PC
with the TB we nee
Il 28/03/2014 18:41, Laurent Desnogues ha scritto:
> + gcc_flags="-fstack-protector-strong -fstack-protector-all"
> + for flag in $gcc_flags; do
> +if compile_prog "-Werror $flag" "" ; then
> + QEMU_CFLAGS="$QEMU_CFLAGS $flag"
> + LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag"
> + br
On Fri, 28 Mar 2014 17:07:31 +0100
Thomas Huth wrote:
> On Fri, 28 Mar 2014 11:57:25 +0100
> Greg Kurz wrote:
>
> > From: Rusty Russell
> >
> > This is based on a simpler patch by Anthony Liguouri, which only handled
> > the vring accesses. We also need some drivers to access these helpers,
All the AArch32 ID registers are visible from AArch64
(in addition to the AArch64-specific ID_AA64* registers).
Signed-off-by: Peter Maydell
---
target-arm/helper.c | 73 -
1 file changed, 44 insertions(+), 29 deletions(-)
diff --git a/target-
On 20 March 2014 19:21, Michael Roth wrote:
> Could it be as simple as this?:
>
> diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py
> index 9734ab0..a70482e 100644
> --- a/scripts/qapi-commands.py
> +++ b/scripts/qapi-commands.py
> @@ -99,7 +99,7 @@ bool has_%(argname)s = false;
>
Eric Blake writes:
> On 03/28/2014 06:04 AM, Markus Armbruster wrote:
>> Amos Kong writes:
>>
>
>> Taking a step back: quite a few command line options make sense only in
>> certain build configurations. We deal with that in several different
>> ways:
>>
>> 1. Target-specific options: qemu-op
Implement the DAIF system register which is a view of the
DAIF bits in PSTATE. To avoid needing a readfn, we widen
the daif field in CPUARMState to uint64_t.
Signed-off-by: Peter Maydell
Reviewed-by: Peter Crosthwaite
---
target-arm/cpu.h| 2 +-
target-arm/helper.c | 20 +++
On 28 March 2014 13:16, Richard Henderson wrote:
> Just the one unaligned related patch to sneek in under the wire.
>
>
> r~
>
>
>
> The following changes since commit 9c5793c5036c7608ff2c87846c6d11f904c08b58:
>
> Merge remote-tracking branch 'remotes/afaerber/tags/ppc-for-2.0' into
> staging (
Peter Maydell writes:
> On 28 March 2014 16:43, Alex Bennée wrote:
>> The current exec and cpu flags only show information when we enter a
>> TranslationBlock. The blocks will then chain together until there is a
>> reason to exit which can make things harder to follow. This new option
>> disab
Hello,
On Mon, Jan 13, 2014 at 9:36 PM, Steven Noonan wrote:
> The -fstack-protector flag family is useful for ensuring safety and for
> debugging, but has a performance impact. Here are some boot time comparisons
> of
> the various versions of -fstack-protector using qemu-system-arm on an x86_6
Implement a subset of the Cortex-A57's implementation defined system
registers. We provide RAZ/WI or reads-as-constant/writes-ignored
implementations of the various control and syndrome reigsters.
We do not implement registers which provide direct access to and
manipulation of the L1 cache, since Q
On 28 March 2014 17:37, Greg Kurz wrote:
> And while we are at it, since we pass &address_space_memory to all
> occurences of virtio_*_phys() and I don't see why we would change
> that, maybe we can also move that into the helpers. Thoughts ?
In the longer term I'm hoping that references to
&addr
Eric Blake writes:
> On 03/28/2014 08:55 AM, Markus Armbruster wrote:
>> Amos Kong writes:
>>
>>> All the options are defined in qemu-options.hx. If we can't find a
>>> matched option definition by group name of option table, then the
>>> group name doesn't match with defined option name, it's
On 28 March 2014 16:43, Alex Bennée wrote:
> The current exec and cpu flags only show information when we enter a
> TranslationBlock. The blocks will then chain together until there is a
> reason to exit which can make things harder to follow. This new option
> disables the chaining for debugging
On Fri, Mar 28, 2014 at 5:19 PM, Paolo Bonzini wrote:
> From: Steven Noonan
>
> The -fstack-protector flag family is useful for ensuring safety and for
> debugging, but has a performance impact. Here are some boot time comparisons
> of
> the various versions of -fstack-protector using qemu-syste
Am 26.03.2014 14:42, schrieb Paolo Bonzini:
> QOM casts are only typesafe inasmuch as we know that the argument is
> a QOM object. If it is not, the accesses to fields in Object can
> access invalid memory and thus cause a segfault.
>
> Using a QOM cast in ENV_GET_CPU is useless and harmful. Use
Signed-off-by: Prasad Joshi
---
block/qcow2.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..10eccf9 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -506,6 +506,7 @@ static int qcow2_open(BlockDriverState *bs, QDict *options,
int flags,
On Fri, 28 Mar 2014 18:21:43 +0100
Andreas Färber wrote:
> Am 28.03.2014 18:13, schrieb Greg Kurz:
> > On Fri, 28 Mar 2014 11:57:56 +0100
> > Greg Kurz wrote:
> >> @@ -519,8 +521,8 @@ static void virtio_scsi_push_event(VirtIOSCSI *s,
> >> SCSIDevice *dev,
> >>
> >> evt = req->resp.event;
>
The current A32/T32 decoder bases its "is VFP/Neon enabled?" check
on the FPSCR.EN bit. This is correct if EL1 is AArch32, but for
an AArch64 EL1 the logic is different: it must act as if FPSCR.EN
is always set. Instead, trapping must happen according to CPACR
bits for cp10/cp11; these cover all of
From: Rob Herring
Implement AArch64 views of ESR_EL1 and FAR_EL1, and make the 32 bit
DFSR, DFAR, IFAR share state with them as architecturally specified.
The IFSR doesn't share state with any AArch64 register visible at EL1,
so just rename the state field without widening it to 64 bits.
Signed-
For exceptions taken to AArch64, if a coprocessor/system register
access fails due to a trap or enable bit then the syndrome information
must include details of the failing instruction (crn/crm/opc1/opc2
fields, etc). Make the decoder construct the syndrome information
at translate time so it can b
These patches fix various cases in the x86 backend and the runtime
TB-jump-patching code where we cast an unaligned pointer to a uint32_t*
and store into it. Unaligned accesses are OK on x86 hardware, of
course, but this is still undefined behaviour in C, and the clang
sanitizer complains.
Sent ou
This patch is here to pave the way for the JSON include directive which
will need to do include loop detection.
Signed-off-by: Benoit Canet
---
Makefile | 12 ++--
scripts/qapi-commands.py |6 +-
scripts/qa
The new directive in the form { 'include': 'path/to/file.json' } will trigger
the
parsing of path/to/file.json.
The directive will be replaced by the result of the parsing.
This will allow for easy modularisation of qapi JSON descriptions files.
Signed-off-by: Benoit Canet
---
docs/qapi-code-g
In case of exception str(e) with e being the exception is more detailled.
Signed-off-by: Benoit Canet
Reviewed-by: Eric Blake
---
tests/qapi-schema/test-qapi.py |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/qapi-schema/test-qapi.py b/tests/qapi-schema/test-qap
On Fri, 28 Mar 2014 11:57:25 +0100
Greg Kurz wrote:
> From: Rusty Russell
>
> This is based on a simpler patch by Anthony Liguouri, which only handled
> the vring accesses. We also need some drivers to access these helpers,
> eg. for data which contains headers.
>
> Signed-off-by: Rusty Russe
On Fri, 28 Mar 2014 11:57:56 +0100
Greg Kurz wrote:
> From: Rusty Russell
>
> Note that st*_raw and ld*_raw are effectively replaced by st*_p and ld*_p.
>
> Signed-off-by: Rusty Russell
> Reviewed-by: Anthony Liguori
> [ use per-device needs_byteswap flag,
> fix missing tswap32 in virtio_s
1 - 100 of 217 matches
Mail list logo
