There was confusion here about abstract classes and naming cpus.
We had registered a concrete class named "-rxcpu". This was put
into the default cpu fields, and matched, so basic tests worked.
However, no value for -cpu could ever match in rx_cpu_class_by_name.
Rename the base class to "rx-cpu"
This has consistency with prt_ri(). It loads all data before
beginning output. It uses exactly one call to prt() to emit
the full instruction.
Reviewed-by: Yoshinori Sato
Signed-off-by: Richard Henderson
---
target/rx/disas.c | 77 +--
1 file change
Fixes check-qtest-rx: tests/machine-none-test.
Cc: Thomas Huth
Cc: Laurent Vivier
Cc: Paolo Bonzini
Signed-off-by: Richard Henderson
---
tests/machine-none-test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 4c6d470798..80df27
The interface for tlb_fill has changed very recently.
Move the function into cpu.c so that it may be static
while assigning to the CPUClass methods.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
target/rx/cpu.c | 14 ++
target/rx/op_helper.c | 11 ---
Issue an error if no kernel, no bios, and not qtest'ing.
Fixes make check-qtest-rx: test/qom-test.
Signed-off-by: Richard Henderson
---
hw/rx/rx62n.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/rx/rx62n.c b/hw/rx/rx62n.c
index 3a8fe7b0bf..e55257c622 100644
--
From: Yoshinori Sato
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Yoshinori Sato
Message-Id: <20190516055244.95559-10-ys...@users.sourceforge.jp>
Signed-off-by: Richard Henderson
---
include/sysemu/arch_init.h | 1 +
arch_init.c
There are so many different forms of each RX instruction
that it will be very useful to be able to look at the bytes
to see on which path a bug may lie.
Reviewed-by: Yoshinori Sato
Signed-off-by: Richard Henderson
---
target/rx/disas.c | 16 +++-
1 file changed, 15 insertions(+), 1
Many of the multi-part prints have been eliminated by previous
patches. Eliminate the rest of them.
Reviewed-by: Yoshinori Sato
Signed-off-by: Richard Henderson
---
target/rx/disas.c | 75 ---
1 file changed, 39 insertions(+), 36 deletions(-)
diff -
Collected, to be used in the next patch.
Reviewed-by: Yoshinori Sato
Signed-off-by: Richard Henderson
---
target/rx/disas.c | 62 ---
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/target/rx/disas.c b/target/rx/disas.c
index ebc1a4424
- Original Message -
> From: "Alex Bennée"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, "Peter Maydell" , "Riku
> Voipio" ,
> qemu-...@nongnu.org, "Laurent Vivier"
> Sent: Friday, May 31, 2019 3:16:38 PM
> Subject: Re: [Qemu-devel] [RFC PATCH 06/11] target/arm: use the comm
On 5/30/19 2:07 PM, Michael Rolnik wrote:
> From: Sarah Harris
>
> Stubs for unimplemented instructions and helpers for instructions that need
> to interact with QEMU.
> SPM and WDR are unimplemented because they require emulation of complex
> peripherals.
> The implementation of SLEEP is very
On 5/30/19 2:07 PM, Michael Rolnik wrote:
> From: Sarah Harris
>
> AVR CPUs have a BREAK instruction which behaves differently depending on
> whether debugging is enabled.
> Since the hardware fuses that normally control this are difficult to emulate,
> and the BREAK instruction is useful for t
Jon Doron writes:
> The generic set/query packets contains implementation for varioius
> sub-commands which are required for GDB and also additional commands
> which are QEMU specific.
>
> To see which QEMU specific commands are available use the command
> gdb> maintenance packet qqemu.Supporte
Am 31.05.2019 um 13:51 hat Max Reitz geschrieben:
> On 30.05.19 00:10, Kevin Wolf wrote:
> > Am 24.05.2019 um 19:28 hat Max Reitz geschrieben:
> >> This enum indicates whether a file is stored on a rotating disk or a
> >> solid-state drive. Drivers report it via the .bdrv_get_info() callback,
> >>
31.05.2019 13:51, Stefan Hajnoczi wrote:
> On Tue, May 28, 2019 at 11:45:44AM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> We have similar padding code in bdrv_co_pwritev,
>> bdrv_co_do_pwrite_zeroes and bdrv_co_preadv. Let's combine and unify
>> it.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievsk
Jon Doron writes:
> Note: The user-mode thread-id has been correctly reported since bd88c780e6
>
> Signed-off-by: Jon Doron
Reviewed-by: Alex Bennée
> ---
> gdbstub.c | 35 +--
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/gdbstub.c b/
On Fri, 31 May 2019 08:43:05 -0500
Richard Henderson wrote:
> There was confusion here about abstract classes and naming cpus.
> We had registered a concrete class named "-rxcpu". This was put
> into the default cpu fields, and matched, so basic tests worked.
> However, no value for -cpu could e
Jon Doron writes:
> This patch series refactors the old gdbstub command packets handler
> with a new infrastructure which should ease extending and adding new
> and missing gdb command packets.
And a:
Tested-by: Alex Bennée
for the whole series. I'll see about preparing a PR next week.
>
>
Miroslav Rezanina writes:
> - Original Message -
>> From: "Alex Bennée"
>> To: "Miroslav Rezanina"
>> Cc: qemu-devel@nongnu.org, "Peter Maydell" , "Riku
>> Voipio" ,
>> qemu-...@nongnu.org, "Laurent Vivier"
>> Sent: Friday, May 31, 2019 3:16:38 PM
>> Subject: Re: [Qemu-devel] [RFC P
On Fri, 31 May 2019 13:32:29 +
Thanos Makatos wrote:
> When configuring device pass-through via VFIO to a VM, I noticed that
> QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> only RAM). That includes firmware regions like "pc.rom". Would a
> physical device ever need acc
On Fri, 31 May 2019 at 15:28, Alex Bennée wrote:
> Miroslav Rezanina writes:
> >From: "Alex Bennée"
> >> OK - so from the upstream source tree CONFIG_SEMIHOSTING is still =y
> >> (but I can see most of them are now =n). Isn't the simplest solution to
> >> fix-up your version of the default_confi
> From: Aleksandar Markovic
> Sent: Friday, April 19, 2019 8:37 PM
> To: qemu-devel@nongnu.org
> Cc: aurel...@aurel32.net; Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH 3/5] target/mips: Amend and cleanup MSA TCG tests
>
> From: Aleksandar Markovic
>
> Add missing bits and peaces of th
> From: Aleksandar Markovic
> Sent: Friday, April 19, 2019 8:38 PM
> To: qemu-devel@nongnu.org
> Cc: aurel...@aurel32.net; Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH 4/5] tests/tcg: target/mips: Add tests for MSA bit set
> instructions
>
> From: Aleksandar Markovic
>
> Add tests fo
> From: Aleksandar Markovic
> Sent: Friday, April 19, 2019 8:38 PM
> To: qemu-devel@nongnu.org
> Cc: aurel...@aurel32.net; Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH 5/5] tests/tcg: target/mips: Add README for MSA tests
>
> From: Aleksandar Markovic
>
> Add README for MSA tests. Thi
On 5/30/19 2:07 PM, Michael Rolnik wrote:
> This includes:
> - encoding of all 16 bit instructions
> - encoding of all 32 bit instructions
>
> Signed-off-by: Michael Rolnik
> ---
> target/avr/insn16.decode | 160 +++
> target/avr/insn32.decode | 10 +++
> 2 f
On 5/30/19 2:07 PM, Michael Rolnik wrote:
> From: Sarah Harris
>
> Signed-off-by: Sarah Harris
> Signed-off-by: Michael Rolnik
> ---
> +++ b/qapi/common.json
> @@ -187,7 +187,7 @@
> # Since: 3.0
> ##
> { 'enum' : 'SysEmuTarget',
> - 'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i3
The PoP (z14, 7-382) says:
Doublewords to the right of the doubleword in which the
highest-numbered facility bit is assigned for a model
may or may not be stored.
However, stack protection in certain binaries can't deal with that.
"gzip" example code:
f1b4: a7 08 00 03
While testing vector instructions, I ran into various issues with
user space binaries compiled with more recent compiler versions like
# gunzip /usr/share/man/man1/hexdump.1.gz
*** stack smashing detected ***: terminated
Turns out:
a) the STFLE instruction in semi-broken on the first invocation
On 5/30/19 11:26 AM, John Snow wrote:
>
>
> On 5/30/19 10:39 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Let's add a possibility to query dirty-bitmaps not only on root nodes.
>> It is useful when dealing both with snapshots and incremental backups.
>>
>> +++ b/block/qapi.c
>> @@ -78,6 +78,11 @@
used_stfl_bytes() is 0, before initialized via prepare_stfl() on the
first invocation. We have to move the calculation of max_bytes after
prepare_stfl().
Signed-off-by: David Hildenbrand
---
target/s390x/misc_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/s
On 5/31/19 9:23 AM, Igor Mammedov wrote:
> On Fri, 31 May 2019 08:43:05 -0500
> Richard Henderson wrote:
>
>> There was confusion here about abstract classes and naming cpus.
>> We had registered a concrete class named "-rxcpu". This was put
>> into the default cpu fields, and matched, so basic
On 5/31/19 9:56 AM, David Hildenbrand wrote:
> used_stfl_bytes() is 0, before initialized via prepare_stfl() on the
> first invocation. We have to move the calculation of max_bytes after
> prepare_stfl().
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/misc_helper.c | 3 ++-
> 1 file c
On 5/31/19 9:56 AM, David Hildenbrand wrote:
> @@ -678,7 +678,7 @@ uint32_t HELPER(stfle)(CPUS390XState *env, uint64_t addr)
>
> prepare_stfl();
> max_bytes = ROUND_UP(used_stfl_bytes, 8);
> -for (i = 0; i < count_bytes; ++i) {
> +for (i = 0; i < MIN(count_bytes, max_bytes); ++i
On 31.05.19 17:05, Richard Henderson wrote:
> On 5/31/19 9:56 AM, David Hildenbrand wrote:
>> @@ -678,7 +678,7 @@ uint32_t HELPER(stfle)(CPUS390XState *env, uint64_t addr)
>>
>> prepare_stfl();
>> max_bytes = ROUND_UP(used_stfl_bytes, 8);
>> -for (i = 0; i < count_bytes; ++i) {
>> +
On Thu, May 30, 2019 at 02:12:21PM -0400, Michael S. Tsirkin wrote:
On Wed, May 29, 2019 at 09:48:02AM +0200, Jens Freimann wrote:
On Tue, May 28, 2019 at 10:40:42PM -0400, Michael S. Tsirkin wrote:
> On Tue, May 21, 2019 at 08:49:18PM +0200, Jens Freimann wrote:
> > On Tue, May 21, 2019 at 07:3
On 5/31/19 2:46 AM, Denis Plotnikov wrote:
> The patch allows to provide a pattern file for write
> command. There was no similar ability before.
>
> Signed-off-by: Denis Plotnikov
> ---
> v5:
> * file name initiated with null to make compilers happy
>
> +static void *qemu_io_alloc_from_file(
On Fri, 31 May 2019 09:59:14 -0500
Richard Henderson wrote:
> On 5/31/19 9:23 AM, Igor Mammedov wrote:
> > On Fri, 31 May 2019 08:43:05 -0500
> > Richard Henderson wrote:
> >
> >> There was confusion here about abstract classes and naming cpus.
> >> We had registered a concrete class named "-
Paolo? Please see MST's request below. Thanks,
Alex
On Wed, 29 May 2019 12:01:14 -0400
"Michael S. Tsirkin" wrote:
> On Wed, May 29, 2019 at 07:43:56AM -0600, Alex Williamson wrote:
> > On Tue, 28 May 2019 23:30:20 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Tue, May 14, 2019 at
[jerry@jerry-n1 aarch64]$ du -b *
67108864AAVMF_CODE.fd
67108864AAVMF_VARS.fd
67108864QEMU_EFI.fd
67108864QEMU_VARS.fd
2097152 QEMU_EFI.fd.orig
786432 QEMU_VARS.fd.orig
Both files have been padded to 64MB. (if padding means filling it with
/dev/zero)
QEMU_EFI.f
> > When configuring device pass-through via VFIO to a VM, I noticed that
> > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > only RAM). That includes firmware regions like "pc.rom".
Would a
> > physical device ever need access to those?
>
> Probably not, bu
On 5/30/19 2:07 PM, Michael Rolnik wrote:
> +/* decode first instruction */
> +ctx.inst[0].cpc = pc_start;
> +decode_opc(&ctx, &ctx.inst[0]);
> +do {
> +/* set curr/next PCs */
> +cpc = ctx.inst[0].cpc;
> +npc = ctx.inst[0].npc;
> +
> +/* decode next
On Fri, 31 May 2019 15:28:07 +
Thanos Makatos wrote:
> > > When configuring device pass-through via VFIO to a VM, I noticed that
> > > QEMU tries to register (DMA_MAP) all memory regions of a guest (not
> > > only RAM). That includes firmware regions like "pc.rom".
> Would a
If a distribution wants to build QEMU without semihosting support,
it currently gets this build failure:
$ ./configure --target-list=aarch64-softmmu --without-default-devices
$ sed -i s/CONFIG_SEMIHOSTING=y/CONFIG_SEMIHOSTING=n/
default-configs/arm-softmmu.mak
$ make subdir-aarch64-softmmu
Amusingly Miroslav and myself hit this issue at the same time.
Currently there is no way to pass a CONFIG_X to sources in target/,
except via a Makefile rule (and filling with stubs).
Paolo says this is on purpose, CONFIG_X selectors are meant for
devices and we try to avoid having config-devices
Am 31.05.2019 um 16:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 31.05.2019 13:51, Stefan Hajnoczi wrote:
> > On Tue, May 28, 2019 at 11:45:44AM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> >> We have similar padding code in bdrv_co_pwritev,
> >> bdrv_co_do_pwrite_zeroes and bdrv_co_prea
Hi Dion,
Since you've got a crash dump, can you check the dmesg in the guest to see if
there's any messages?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1831225
Title:
guest migration 100% cpu
I'm quite sure that debian has done the padding procedure
https://salsa.debian.org/qemu-team/edk2/blob/debian/debian/rules#L82
** Changed in: qemu
Status: Invalid => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static uint64_t vfa64(uint64_t a, uint64_t b, float_status *s)
> +{
> +return float64_val(float64_add(make_float64(a), make_float64(b), s));
> +}
You don't need either make_float64 or float64_val.
I've been intending to strip them out entirely;
If a distribution wants to build QEMU without semihosting support,
it currently gets this build failure:
$ ./configure --target-list=mips64el-softmmu --without-default-devices
$ sed -i s/CONFIG_SEMIHOSTING=y/CONFIG_SEMIHOSTING=n/
default-configs/mips-softmmu-common.mak
$ make subdir-mips64e
31.05.2019 18:49, Kevin Wolf wrote:
> Am 31.05.2019 um 16:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 31.05.2019 13:51, Stefan Hajnoczi wrote:
>>> On Tue, May 28, 2019 at 11:45:44AM +0300, Vladimir Sementsov-Ogievskiy
>>> wrote:
We have similar padding code in bdrv_co_pwritev,
bd
Hi Alan,
Dmesg shows nothing special:
[29891577.708544] IPv6 addrconf: prefix with wrong length 48
[29891580.650637] IPv6 addrconf: prefix with wrong length 48
[29891582.013656] IPv6 addrconf: prefix with wrong length 48
[29891583.753246] IPv6 addrconf: prefix with wrong length 48
[29891585.39794
On Fri, 31 May 2019 at 16:47, Philippe Mathieu-Daudé wrote:
>
> Amusingly Miroslav and myself hit this issue at the same time.
>
> Currently there is no way to pass a CONFIG_X to sources in target/,
> except via a Makefile rule (and filling with stubs).
>
> Paolo says this is on purpose, CONFIG_X
On 16.04.19 12:02, Vladimir Sementsov-Ogievskiy wrote:
> 10.04.2019 23:20, Max Reitz wrote:
>> What bs->file and bs->backing mean depends on the node. For filter
>> nodes, both signify a node that will eventually receive all R/W
>> accesses. For format nodes, bs->file contains metadata and data,
On 31.05.19 17:54, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static uint64_t vfa64(uint64_t a, uint64_t b, float_status *s)
>> +{
>> +return float64_val(float64_add(make_float64(a), make_float64(b), s));
>> +}
>
>
> You don't need either make_float64 or float
Jerry writes:
> [jerry@jerry-n1 aarch64]$ du -b *
> 67108864AAVMF_CODE.fd
> 67108864AAVMF_VARS.fd
> 67108864QEMU_EFI.fd
> 67108864QEMU_VARS.fd
>
> 2097152 QEMU_EFI.fd.orig
> 786432 QEMU_VARS.fd.orig
>
>
> Both files have been padded to 64MB. (if padding means fi
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +void HELPER(gvec_vfa64)(void *v1, const void *v2, const void *v3,
> +CPUS390XState *env, uint32_t desc)
> +{
> +vop64_3(v1, v2, v3, env, false, vfa64, GETPC());
> +}
Given that make_float64 is banished, I guess you can pas
Hi all!
Bitmaps reopening is buggy, we may easily produce broken incremental
backup if we do temporary snapshot. Let's fix it!
v2:
01: new
02-03: test: splat into two patches, some wording
improvements and event_wait improved
04: add John's r-b
05: new
06-09: fixes: changed, splat, use pat
Since we have used .bdrv_need_rw_file_child_during_reopen_rw handler,
and have write access to file child in reopen-prepare, and we prepared
qcow2_reopen_bitmaps_rw to be called from reopening rw -> rw, we now
can simple move qcow2_reopen_bitmaps_rw() call to
qcow2_reopen_prepare() and handle error
On reopen to rw parent may need rw access to child in .prepare, for
example qcow2 needs to write IN_USE flags into stored bitmaps
(currently it is done in a hacky way after commit and don't work).
So, let's introduce such logic.
The drawback is that in worst case bdrv_reopen_set_read_only may fini
Currently reopening bitmaps to RW can't work, as qcow2 needs write
access to file child, to mark bitmaps in-image with IN_USE flag.
The possibility to write-access file child during reopen-RW was
implemented several patches ago with help of
.bdrv_need_rw_file_child_during_reopen_rw handler. Let's
Support several names to wait for, which useful, when we don't sure
which event will we get. For example when mirror fails we get
BLOCK_JOB_COMPLETE otherwise we get BLOCK_JOB_READY (and only then,
after completing block-job we get BLOCK_JOB_COMPLETE).
Also, add filtered version for convenient use
- Correct check for write access to file child, and in correct place
(only if we want to write).
- Support reopen rw -> rw (which will be used in furhter patches),
for example, !bdrv_dirty_bitmap_readonly() is not a corruption if
bitmap is marked IN_USE in the image.
- Consider unexpected bit
Firstly, no reason to optimize failure path. Then, function name is
ambiguous: it checks for readonly and similar things, but someone may
think that it will ignore normal bitmaps which was just unchanged, and
this is in bad relation with the fact that we should drop IN_USE flag
for unchanged bitmap
The function is unused, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/qcow2.h| 2 --
block/qcow2-bitmap.c | 15 +--
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/block/qcow2.h b/block/qcow2.h
index 567375e56c..88a2030f54 100644
--- a/block/q
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
readonly. But the latter don't work, as
qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
It's OK for inactivation but bad idea for reopen-ro. And this leads to
the following bug:
Assume we have persistent bitm
Two testcases with persistent bitmaps are not added here, as there are
bugs to be fixed soon.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/255 | 84 ++
tests/qemu-iotests/255.out | 17
tests/qemu-iotests/group | 1 +
3 fil
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> As far as I can see, there is only a tiny difference.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 4
> target/s390x/translate_vx.inc.c | 21 +
>
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> During migration, we would sync bitmap from ram_list.dirty_memory to
> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>
> Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
> means at the first round this sync is
- Original Message -
> From: "Peter Maydell"
> To: "Alex Bennée"
> Cc: "Miroslav Rezanina" , "QEMU Developers"
> , "Riku Voipio"
> , "qemu-arm" , "Laurent Vivier"
>
> Sent: Friday, May 31, 2019 4:38:04 PM
> Subject: Re: [Qemu-devel] [RFC PATCH 06/11] target/arm: use the common
> in
The AccelClass::opt_name is not used. Unless there is a reason
for keeping hat attribute, this patch remove it.
Git: https://github.com/wainersm/qemu
Branch: accel_del_opt_name
Travis: https://travis-ci.org/wainersm/qemu/builds/539721285
(Failed test case is not related with this change as well as
On 5/31/19 6:21 PM, Peter Maydell wrote:
> On Fri, 31 May 2019 at 16:47, Philippe Mathieu-Daudé
> wrote:
>>
>> Amusingly Miroslav and myself hit this issue at the same time.
>>
>> Currently there is no way to pass a CONFIG_X to sources in target/,
>> except via a Makefile rule (and filling with s
- Original Message -
> From: "Alex Bennée"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, "Peter Maydell" , "Riku
> Voipio" ,
> qemu-...@nongnu.org, "Laurent Vivier"
> Sent: Friday, May 31, 2019 4:28:02 PM
> Subject: Re: [Qemu-devel] [RFC PATCH 06/11] target/arm: use the comm
The AccelType type was converted to AccelClass QOM
object on b14a0b7469f, and the original data type had
a field to store the option name which in turn was
used to search an accelerator. The lookup method
(accel_find) changed too, making the option field
unnecessary but it became AccelClass::opt_na
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static int vfc64(S390Vector *v1, const S390Vector *v2, const S390Vector *v3,
> + CPUS390XState *env, bool s, bool test_equal, bool test_high,
> + uintptr_t retaddr)
> +{
> +uint8_t vxc, vec_exc = 0;
> +S390Vecto
- Original Message -
> From: "Philippe Mathieu-Daudé"
> To: "Peter Maydell"
> Cc: "QEMU Developers" , "Paolo Bonzini"
> , "Miroslav Rezanina"
> , "Richard Henderson" ,
> "Aleksandar Rikalo"
> , "qemu-arm" , "Aleksandar
> Markovic" , "Aurelien
> Jarno" , "Alex Bennée" ,
> "Samuel Or
I just noticed that it was a libvirt bug that caused the error.
-drive
file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive
file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1
\
debiantesting_VARS.fd was never removed or replaced
On Thu, May 30, 2019 at 07:06:29PM -0400, Michael S. Tsirkin wrote:
> On Thu, May 30, 2019 at 03:22:10PM -0300, Eduardo Habkost wrote:
> > On Thu, May 30, 2019 at 02:09:42PM -0400, Michael S. Tsirkin wrote:
> > > On Thu, May 30, 2019 at 07:00:23PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Mich
On 31.05.19 18:26, Max Reitz wrote:
> On 16.04.19 12:02, Vladimir Sementsov-Ogievskiy wrote:
>> 10.04.2019 23:20, Max Reitz wrote:
>>> What bs->file and bs->backing mean depends on the node. For filter
>>> nodes, both signify a node that will eventually receive all R/W
>>> accesses. For format no
Patchew URL: https://patchew.org/QEMU/20190531154735.20809-1-phi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH 0/2] target: Build with CONFIG_SEMIHOSTING
disabled
Type: series
Message-id: 201905
On Fri, 31 May 2019 at 17:54, Miroslav Rezanina wrote:
> What about CONFIG_ARM_VIRT - can we use it to introduce dependency on
> CONFIG_SEMIHOSTING or is there valid scenario of qemu build with
> CONFIG_ARM_VIRT
> enabled and CONFIG_SEMIHOSTING disabled?
Semihosting is a feature that works on al
On Fri, 31 May 2019 at 17:40, Philippe Mathieu-Daudé wrote:
> I'll see what happened to Samuel series "Support disabling TCG on ARM"
> and see if it can be salvaged:
> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02451.html
That would certainly be useful.
> I suppose in this thread:
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +static DisasJumpType op_vcdg(DisasContext *s, DisasOps *o)
> +{
> +const uint8_t fpf = get_field(s->fields, m3);
> +const uint8_t m4 = get_field(s->fields, m4);
> +const uint8_t erm = get_field(s->fields, m5);
> +const bool se = extrac
On 5/31/19 12:10 PM, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static DisasJumpType op_vcdg(DisasContext *s, DisasOps *o)
>> +{
>> +const uint8_t fpf = get_field(s->fields, m3);
>> +const uint8_t m4 = get_field(s->fields, m4);
>> +const uint8_t erm = ge
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 23 +++
> 4 files changed
On 31.05.19 19:15, Richard Henderson wrote:
> On 5/31/19 12:10 PM, Richard Henderson wrote:
>> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>>> +static DisasJumpType op_vcdg(DisasContext *s, DisasOps *o)
>>> +{
>>> +const uint8_t fpf = get_field(s->fields, m3);
>>> +const uint8_t m4 = get_f
On 31.05.19 18:53, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +static int vfc64(S390Vector *v1, const S390Vector *v2, const S390Vector *v3,
>> + CPUS390XState *env, bool s, bool test_equal, bool
>> test_high,
>> + uintptr_t retaddr)
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 23 +++
> 4 files changed
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse most of the infrastructure added for VECTOR FP ADD.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s3
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 23 +++
> 4 files changed
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse most of the infrastructure introduced for
> VECTOR FP CONVERT FROM FIXED 64-BIT and friends.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x
Hi!
20.02.2019 21:01, John Snow wrote:
> When bitmaps are persistent, they may incur a disk read or write when bitmaps
> are added or removed. For configurations like virtio-dataplane, failing to
> acquire this lock will abort QEMU when disk IO occurs.
>
> We used to acquire aio_context as part o
Interesting; I'd seen something similar - in rh
https://bugzilla.redhat.com/show_bug.cgi?id=1538078
and as well as the bogus date we'd had lots of log messages of the form:
CE: lapic increasing min_delta_ns to nsec
we were reckoning the clock jumped a bit during the migrate, and then trigger
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +for (i = 0; i < 2; i++) {
> +/* load from even element */
> +const float32 a = make_float32(s390_vec_read_element32(v2, i * 2));
I suppose.
You could also reuse vop64_2 with
static uint64_t vfll(uint64_t a, float_status *s)
{
On 31.05.19 19:33, Richard Henderson wrote:
> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>> +for (i = 0; i < 2; i++) {
>> +/* load from even element */
>> +const float32 a = make_float32(s390_vec_read_element32(v2, i * 2));
>
> I suppose.
>
> You could also reuse vop64_2 wit
On 5/31/19 12:35 PM, David Hildenbrand wrote:
> On 31.05.19 19:33, Richard Henderson wrote:
>> On 5/31/19 5:44 AM, David Hildenbrand wrote:
>>> +for (i = 0; i < 2; i++) {
>>> +/* load from even element */
>>> +const float32 a = make_float32(s390_vec_read_element32(v2, i * 2));
>
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> Very similar to VECTOR FP DIVIDE.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 3 +++
> target/s390x/vec_fpu_helper.c | 17 +++
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> We can reuse some of the infrastructure introduced for
> VECTOR FP CONVERT FROM FIXED 64-BIT and friends.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x
On 31.05.19 19:36, Richard Henderson wrote:
> On 5/31/19 12:35 PM, David Hildenbrand wrote:
>> On 31.05.19 19:33, Richard Henderson wrote:
>>> On 5/31/19 5:44 AM, David Hildenbrand wrote:
+for (i = 0; i < 2; i++) {
+/* load from even element */
+const float32 a =
On 31.05.19 12:44, David Hildenbrand wrote:
> We can reuse float64_dcmask().
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 ++
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 21 ++
> target/s390x/vec_fpu_helper.c
On 5/31/19 5:44 AM, David Hildenbrand wrote:
> +typedef uint64_t (*vop64_4_fn)(uint64_t a, uint64_t b, uint64_t c,
> + float_status *s);
> +static void vop64_4(S390Vector *v1, const S390Vector *v2, const S390Vector
> *v3,
> +const S390Vector *v4, C
101 - 200 of 241 matches
Mail list logo
