On Wed, 26 Feb 2020 12:04:13 +1100
David Gibson wrote:
> On Tue, Feb 25, 2020 at 11:47:25PM +0100, Greg Kurz wrote:
> > On Tue, 25 Feb 2020 18:05:31 +0100
> > Greg Kurz wrote:
> >
> > > On Tue, 25 Feb 2020 10:37:15 +1100
> > > David Gibson wrote:
> > >
> > > > Currently we use a big switch
When combined with heavy plugins we occasionally hit the timeouts.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20200225124710.14152-17-alex.ben...@linaro.org>
diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
index 3c7421a356e..b3cff3cad1a
TCG plugins are responsible for their own memory usage and although
the plugin_exit is tied to the end of execution in this case it is
still poor practice. Ensure we delete the hash table and related data
when we are done to be a good plugin citizen.
Signed-off-by: Alex Bennée
Reviewed-by:
Peter Maydell writes:
> On Tue, 25 Feb 2020 at 17:48, Paolo Bonzini wrote:
>>
>> On 25/02/20 18:11, Peter Maydell wrote:
>> >> I assume these are not meant to be applied now, except patch 2?
>> > No, I intended them to be reviewable and applied now. Why
>> > do you think we should wait?
>>
>>
While do_gen_mem_cb does copy (via extu_tl_i64) vaddr into a new temp
this won't help if the vaddr temp gets clobbered by the actual
load/store op. To avoid this clobbering we explicitly copy vaddr
before the op to ensure it is live my the time we do the
instrumentation.
Suggested-by: Richard
Pointer authentication isn't perfect so measure the percentage of
failed checks. As we want to vary the pointer we work through a bunch
of different addresses.
Signed-off-by: Alex Bennée
Reviewed-by: Robert Foley
Reviewed-by: Richard Henderson
Message-Id:
From: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
Message-Id: <20200212130311.127515-3-ys...@users.sourceforge.jp>
Message-Id:
Although most people use the docker images this can trip up on
developer systems with actual valid cross-compilers!
Fixes: bb516dfc5b3
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20200225124710.14152-19-alex.ben...@linaro.org>
The plugin system would throw up a harmless warning when it detected
that a disassembly of an instruction didn't use all it's bytes. Fix
the riscv decoder to only load the instruction bytes it needs as it
needs them.
This drops opcode from the ctx in favour if passing the appropriately
sized
I forgot to document the lifetime of handles in the developer
documentation. Do so now.
Signed-off-by: Alex Bennée
Reviewed-by: Robert Foley
Reviewed-by: Robert Foley
Message-Id: <20200225124710.14152-11-alex.ben...@linaro.org>
diff --git a/docs/devel/tcg-plugins.rst
From: "Emilio G. Cota"
Fixes: 54cb65d8588
Reported-by: Robert Henry
Signed-off-by: Emilio G. Cota
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20200105072940.32204-1-c...@braap.org>
Cc: qemu-sta...@nongnu.org
Message-Id:
Vladimir Sementsov-Ogievskiy writes:
> 25.02.2020 15:52, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> 23.02.2020 11:55, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
> Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate
From: Chen Qun
According to the glibc function requirements, we need initialise
the variable. Otherwise there will be compilation warnings:
glib-autocleanups.h:28:3: warning: ‘out’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
g_free (*pp);
^~~~
Reported-by:
At least on ZFS this was failing as 512 was less than or equal to 512.
I suspect the reason is additional compression done by ZFS and however
qemu-img gets the actual size.
Loosen the criteria to make sure after is not bigger than before and
also dump the values in the report.
Signed-off-by:
This still seems to be a problem for Travis.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20200225124710.14152-8-alex.ben...@linaro.org>
diff --git a/.travis.yml b/.travis.yml
index 0612998958b..f4020dcc6c8 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -400,7
From: Thomas Huth
Since we can now use a s390x host on Travis, we can also build and
test the s390-ccw bios images there. For this we have to make sure
that roms/SLOF is checked out, too, and then move the generated *.img
files to the right location before running the tests.
Signed-off-by:
From: Wainer dos Santos Moschetta
This fixes the following warnings Travis has detected on the
YAML configuration:
- 'on root: missing os, using the default "linux"'
- 'on root: the key matrix is an alias for jobs, using jobs'
- 'on jobs.include.python: unexpected sequence, using the first
The following changes since commit db736e0437aa6fd7c1b7e4599c17f9619ab6b837:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2020-02-25 13:31:16 +)
are available in the Git repository at:
https://github.com/stsquad/qemu.git
Otherwise any -D settings the user may have made get ignored.
Signed-off-by: Alex Bennée
Tested-by: Laurent Vivier
Reviewed-by: Robert Foley
Message-Id: <20200225124710.14152-10-alex.ben...@linaro.org>
diff --git a/trace/control.c b/trace/control.c
index 6c775e68eba..2ffe0008184 100644
---
This is pure code motion with no functional effect.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20200225124710.14152-4-alex.ben...@linaro.org>
diff --git a/tests/rcutorture.c b/tests/rcutorture.c
index e8b2169e7dd..256d24ed5ba 100644
--- a/tests/rcutorture.c
+++
This is mainly to help with reasoning what the test is trying to do.
We can move rcu_stress_idx to a local variable as there is only ever
one updater thread. I've also added an assert to catch the case where
we end up updating the current structure to itself which is the only
way I can see the
If we have plugins enabled we still need to have built the test to be
able to run it.
Signed-off-by: Alex Bennée
Reviewed-by: Robert Foley
Message-Id: <20200225124710.14152-2-alex.ben...@linaro.org>
diff --git a/tests/tcg/aarch64/Makefile.softmmu-target
Although documented in the comments we don't display all the various
invocations we can in the usage.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20200225124710.14152-3-alex.ben...@linaro.org>
diff --git a/tests/rcutorture.c b/tests/rcutorture.c
index
Hi all,
Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047 on the ppc-for-50 branch
makes qemu-system-ppc running Mac OS 9 extremely slow. I bisected to the
result below.
Command line used:
./qemu-system-ppc -L pc-bios -M mac99,via=pmu -m 512 -boot c \
-hda 9.2.img \
-serial stdio -sdl
Best,
Max Reitz writes:
> On 25.02.20 17:48, Markus Armbruster wrote:
>> Max Reitz writes:
>>
>>> On 15.02.20 15:51, Markus Armbruster wrote:
Review of this patch led to a lengthy QAPI schema design discussion.
Let me try to condense it into a concrete proposal.
This is about the
- Original Message -
> On Wed, Feb 26, 2020 at 03:06:47PM +0800, Jason Wang wrote:
> > We turn on device IOTLB via VIRTIO_F_IOMMU_PLATFORM unconditionally on
> > platform without IOMMU support. This can lead unnecessary IOTLB
> > transactions which will damage the performance.
> >
> >
On Wed, Feb 26, 2020 at 03:06:47PM +0800, Jason Wang wrote:
> We turn on device IOTLB via VIRTIO_F_IOMMU_PLATFORM unconditionally on
> platform without IOMMU support. This can lead unnecessary IOTLB
> transactions which will damage the performance.
>
> Fixing this by check whether the device is
We turn on device IOTLB via VIRTIO_F_IOMMU_PLATFORM unconditionally on
platform without IOMMU support. This can lead unnecessary IOTLB
transactions which will damage the performance.
Fixing this by check whether the device is backed by IOMMU and disable
device IOTLB.
Reported-by: Halil Pasic
>-Original Message-
>From: Jason Wang [mailto:jasow...@redhat.com]
>Sent: Wednesday, February 26, 2020 11:03 AM
>To: Peter Maydell
>Cc: Chenqun (kuhn) ; QEMU Developers
>; QEMU Trivial ;
>Zhanghailiang ; Peter Chubb
>; qemu-arm
>Subject: Re: [PATCH] hw/net/imx_fec: write TGSR and TCSR3
** Attachment removed: "win10-real.xml"
https://bugs.launchpad.net/qemu/+bug/1863710/+attachment/5329158/+files/win10-real.xml
** Attachment added: "win10.xml"
https://bugs.launchpad.net/qemu/+bug/1863710/+attachment/5331124/+files/win10.xml
--
You received this bug notification because
> Problem with that patch is that it removes this clearing from the
> func
> that's also used to emulate ISA IDE ioports which according to their
> spec
> should clear irq on read so that function should be OK but maybe
> should
> not be called by PCI IDE code?
This might be it.
The patch I
25.02.2020 23:41, John Snow wrote:
On 2/25/20 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
25.02.2020 3:56, John Snow wrote:
This job copies the allocation map into a bitmap. It's a job because
there's no guarantee that allocation interrogation will be quick (or
won't hang), so it cannot be
Patchew URL: https://patchew.org/QEMU/20200225151210.647797-1-...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PULL 00/32] virtio, pc: fixes, features
Message-id: 20200225151210.647797-1-...@redhat.com
Type: series
===
HAXM covers below files:
include/sysemu/hax.h
target/i386/hax-*
Cc: Wenchao Wang
Cc: Hang Yuan
Signed-off-by: Colin Xu
---
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 36d94c17a654..27727e2fac13 100644
--- a/MAINTAINERS
+++
n
On Thu, 6 Feb 2020 at 11:27, Cédric Le Goater wrote:
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> Makefile.objs | 1 +
> hw/ssi/aspeed_smc.c | 17 +
> hw/ssi/trace-events | 9 +
> 3 files changed, 27 insertions(+)
> create mode
Intialize buffer_accel with this buffer_zero_avx512(), when Intel AVX512F is
available on host.
This function utilizes Intel AVX512 fundamental instructions which
is faster than its implementation with AVX2 (in my unit test, with
4K buffer, on CascadeLake SP, ~36% faster, buffer_zero_avx512()
Introduce {enable,disable}-avx512f configure option. It is by default disabled.
Only when user explicitly enable-avx512f and compiling environment supports
AVX512F, CONFIG_AVX512F_OPT will be defined.
AVX512F instruction set is available since Intel Skylake.
More info:
1) Introduce {enable,disable}-avx512f configure option
2) Implement new buffer_zero_avx512() with AVX512F instructions
Changes in v2:
1. Fixes wrong definition of CACHE_SSE2 in v1.
2. Fixes not handle <256 length case in buffer_zero_avx512() implementaion.
(Follow Richard's suggestion: handle
On 2020/2/25 下午2:22, Vikram Garhwal wrote:
Hi Jason,
Apologies for the delayed response. I tried plugging NetClientState in the CAN
which is required if we use qemu_send_packet but this will change the
underlying architecture of can-core, can-socketcan a lot. This means changes
the way CAN
'crypto_opts' forgot to free in qcow2_close(), this patch fix the bellow leak
stack:
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f0edd81f970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970)
#1 0x7f0edc6d149d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d)
#2
This series fix two small memleaks.
1. 'crypto_opts' forgot to free in qcow2_close(), do this cleanup in
qcow2_close();
2. Do free filename/format in collect_image_check() when we re-allocate it.
Pan Nengyuan (2):
block/qcow2: do free crypto_opts in qcow2_close()
qemu-img: free memory
collect_image_check() is called twice in img_check(), the filename/format will
be alloced without free the original memory.
It is not a big deal since the process will exit anyway, but seems like a clean
code and it will remove the warning spotted by asan.
Reported-by: Euler Robot
On 2020/2/25 下午6:18, Peter Maydell wrote:
On Tue, 25 Feb 2020 at 05:41, Jason Wang wrote:
On 2020/2/25 上午10:59, Chen Qun wrote:
The current code causes clang static code analyzer generate warning:
hw/net/imx_fec.c:858:9: warning: Value stored to 'value' is never read
value =
Signed-off-by: LIU Zhiwei
---
target/riscv/helper.h | 395 +++
target/riscv/insn32.decode | 127 +++
target/riscv/insn_trans/trans_rvv.inc.c | 671 +++-
target/riscv/vector_helper.c| 1308 ++-
4 files changed, 2462
On Tue, Feb 25, 2020 at 12:07:29PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/25/20 12:37 AM, David Gibson wrote:
> > Move the calculation of the Real Mode Area (RMA) size into a helper
> > function. While we're there clean it up and correct it in a few ways:
> >* Add comments making it
On Tue, Feb 25, 2020 at 11:47:25PM +0100, Greg Kurz wrote:
> On Tue, 25 Feb 2020 18:05:31 +0100
> Greg Kurz wrote:
>
> > On Tue, 25 Feb 2020 10:37:15 +1100
> > David Gibson wrote:
> >
> > > Currently we use a big switch statement in ppc_hash64_update_rmls() to
> > > work
> > > out what the
On Tue, Feb 25, 2020 at 04:58:01PM +0100, Greg Kurz wrote:
> On Tue, 25 Feb 2020 12:29:00 +0100
> Greg Kurz wrote:
>
> > On Tue, 25 Feb 2020 10:37:12 +1100
> > David Gibson wrote:
> >
> > > For the "pseries" machine, we use "virtual hypervisor" mode where we
> > > only model the CPU in
On Tue, Feb 25, 2020 at 3:59 AM Laurent Vivier wrote:
>
> Le 25/02/2020 à 00:21, Alistair Francis a écrit :
> > New y2038 safe 32-bit architectures (like RISC-V) don't support old
> > syscalls with a 32-bit time_t. The kernel defines new *_time64 versions
> > of these syscalls. Add some more
The idea is that instead of increasing the arguments to job_run all the
time, create a more general-purpose job runner that can be subclassed to
do interesting things with.
Signed-off-by: John Snow
---
tests/qemu-iotests/255| 9 +-
tests/qemu-iotests/257| 12 ++-
Instead of having somewhat reproduced it for itself.
Signed-off-by: John Snow
---
tests/qemu-iotests/040 | 51 +-
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/tests/qemu-iotests/040 b/tests/qemu-iotests/040
index 90b59081ff..579dafc797
On Tue, Feb 25, 2020 at 7:41 AM Peter Maydell wrote:
>
> Convert the documentation of deprecated features to rST.
>
> We put the whole of this document into the system manual, though
> technically a few parts of it apply to qemu-img or qemu-nbd which are
> otherwise documented in tools/.
>
> We
On 21/02/2020 19:27, Paolo Bonzini wrote:
> On 21/02/20 01:18, Alexey Kardashevskiy wrote:
>> I am not quite sure I understood the request. Write my own small
>> firmware and replace GRUB with it? The firmware from 5/5 reads first 2
>> sectors and the entire PReP, I could add there stuff if
Try "-M ppce500 -cpu e6500"
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1864704
Title:
No compatible -machine option in qemu-system-ppc64 for e6500 core
Status in QEMU:
New
Bug description:
[ ping ]
Hi Paolo, would you mind taking a quick look at this patch for
memory.c to consider
it for merge? This resolves an issue with dirty bits not being cleared
as expected.
Here's the Patchwork link: http://patchwork.ozlabs.org/patch/1240121/
Thanks for your time!
Matt
On Tue, Feb 18,
To compute screen size in centimeters we should calculate:
pixels/dpi*2.54
but not
pixels*dpi/2540
Using wrong formula we actually get 65 DPI and very small fonts.
Signed-off-by: Anton V. Boyarshinov
---
hw/display/edid-generate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Hello Igor and Paolo,
Just now I was working on some small fixes for the cubieboard machine and
rebasing my Allwinner H3 branches.
While doing some testing, I noticed that suddenly the machines were much
slower than before.
I only see this happening when I rebase to this commit:
On Tue, 25 Feb 2020 18:05:31 +0100
Greg Kurz wrote:
> On Tue, 25 Feb 2020 10:37:15 +1100
> David Gibson wrote:
>
> > Currently we use a big switch statement in ppc_hash64_update_rmls() to work
> > out what the right RMA limit is based on the LPCR[RMLS] field. There's no
> > formula for this -
On Tue, 25 Feb 2020 at 20:10, Paolo Bonzini wrote:
> The main issue with this series and Kashyap's is that if we don't manage to
> get
> everything done in 5.0 we have a mutilated qemu-doc. Then either we keep it
> mutilated or we scramble to undo the work. So I would agree to commit the
>
On Mon, 10 Feb 2020, BALATON Zoltan wrote:
This suggests the common IDE bmdma and ide-cd code is likely OK and problem
is somewhere in irq routing. What's relevant for this thread and sparc64 is
that then you should also check interrupt controller and routing if an
interrupt raised by the IDE
On Tue, 25 Feb 2020, BALATON Zoltan wrote:
On Mon, 10 Feb 2020, John Snow wrote:
It sounds like the real problem is either in the bmdma controller (or
its unique interaction with hw/ide/core.c -- which is possible) or in
the interrupt routing somewhere else.
If you have any IDE traces from a
On Tue, Feb 25, 2020 at 04:47:31PM +, Peter Maydell wrote:
> On Tue, 25 Feb 2020 at 15:12, Michael S. Tsirkin wrote:
> >
> > The following changes since commit 9a8abceb5f01d1066d3a1ac5a33aabcbaeec1860:
> >
> > Merge remote-tracking branch 'remotes/pmayd
On 2/18/20 5:07 AM, Fabian Grünbichler wrote:
> picking up on John's in-progress patch series from last summer, this is
> a stab at rebasing and adding test cases for the low-hanging fruits:
>
> - bitmap mirror mode with always/on-success/never bitmap sync mode
> - incremental mirror mode as
On 2/24/20 6:15 AM, Max Reitz wrote:
> On 12.10.19 01:39, John Snow wrote:
>> Just caught up with the discussion.
>>
>> It looks like Thomas took my 1/5; so I'll respin on top of his "[PATCH
>> 0/5] Enable more iotests during "make check-block" series to catch those
>> improvements as they
On 2/24/20 9:09 PM, kuhn.chen...@huawei.com wrote:
> From: Chen Qun
>
> Clang static code analyzer show warning:
> block/stream.c:186:9: warning: Value stored to 'ret' is never read
> ret = 0;
> ^ ~
> Reported-by: Euler Robot
> Signed-off-by: Chen Qun
> ---
> Cc: John
> On Feb 25, 2020, at 12:40 PM, Laszlo Ersek wrote:
>
> Hi Andrew,
>
> On 02/25/20 19:56, Andrew Fish wrote:
>> Laszlo,
>>
>> If I understand this correctly is it not more complicated than just size. It
>> also assumes the memory layout is the same?
>
> Yes.
>
>> The legacy BIOS used
Hi,
I need the memory access traces of an android system running on qemu.
trace_memory_region_ops_read/write in memory.c provide most of the
information I need. However, in addition to the trace information already
provided, I also need the program counter of the current instructions. What
Hello,
On Mon, 10 Feb 2020, John Snow wrote:
It sounds like the real problem is either in the bmdma controller (or
its unique interaction with hw/ide/core.c -- which is possible) or in
the interrupt routing somewhere else.
If you have any IDE traces from a hang, feel free to throw them up on a
On 2/25/20 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
> 25.02.2020 3:56, John Snow wrote:
>> This job copies the allocation map into a bitmap. It's a job because
>> there's no guarantee that allocation interrogation will be quick (or
>> won't hang), so it cannot be retrofit into
Le 25/02/2020 à 20:59, Richard Henderson a écrit :
> On 2/12/20 7:22 PM, Richard Henderson wrote:
>> Changes for v3:
>>
>> * Add TARGET_VSYSCALL_PAGE define.
>> * Move the sigsegv goto around.
>>
>> v2: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03474.html
>> v1:
Hi Andrew,
On 02/25/20 19:56, Andrew Fish wrote:
> Laszlo,
>
> If I understand this correctly is it not more complicated than just size. It
> also assumes the memory layout is the same?
Yes.
> The legacy BIOS used fixed magic address ranges, but UEFI uses dynamically
> allocated memory so
Peter Maydell writes:
> Add patterns for the new instructions in the v8.3-RCPC and
> v8.4-RCPC extensions.
>
> Signed-off-by: Peter Maydell
> ---
> This is what I used for testing the RCPC QEMU patches I sent out
> the other day. Did I get the @ section syntax here right?
Yep ;-)
Public bug reported:
Hi,
I'm trying to use qemu-system-ppc64 for emulating a QorIQ T2080 (with e6500
cores).
However, I couldn't find any -machine option that matches -cpu e6500 option,
which are listed below:
C:\Program Files\qemu>qemu-system-ppc64 -machine help
Supported machines are:
40p
Il mar 25 feb 2020, 20:50 Peter Maydell ha
scritto:
> On Tue, 25 Feb 2020 at 19:10, Paolo Bonzini wrote:
> I feel like we're working a bit at cross purposes here so maybe
> we'd benefit from just nailing down who's going to do what and
> in which order?
>
I am not going to do much more than
On 2/12/20 7:22 PM, Richard Henderson wrote:
> Changes for v3:
>
> * Add TARGET_VSYSCALL_PAGE define.
> * Move the sigsegv goto around.
>
> v2: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03474.html
> v1: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg02841.html
Ping?
On 2/25/20 11:38 AM, Peter Maydell wrote:
> @@ -705,6 +706,7 @@ static void aarch64_max_initfn(Object *obj)
>
> u = cpu->isar.id_mmfr4;
> u = FIELD_DP32(u, ID_MMFR4, AC2, 1); /* ACTLR2, HACTLR2 */
> +t = FIELD_DP32(t, ID_MMFR4, CNP, 1); /* TTCNP */
>
On Tue, 25 Feb 2020 at 19:10, Paolo Bonzini wrote:
> This could go in independently. It would make Kashyap's series
> conflict, but I have already rebased it on top.
I'm happy to collect up 'docs' patches for pullreqs (and fix up
conflicts etc as they arise) if that helps in getting things into
The ARMv8.2-TTCNP extension allows an implementation to optimize by
sharing TLB entries between multiple cores, provided that software
declares that it's ready to deal with this by setting a CnP bit in
the TTBRn_ELx. It is mandatory from ARMv8.2 onward.
For QEMU's TLB implementation, sharing TLB
Some experimentation with newer kernels indicate that this is most
likely a KVM bug.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1863819
Title:
Il mar 25 feb 2020, 19:57 Peter Maydell ha
scritto:
> > The QAPI docs are in other manuals in docs/interop/, aren't they?
>
> Yes, but until we complete the conversion we can't get
> rid of the qemu-doc.html output, because that's where the
> HTML output from the QAPI doc generation goes.
>
Laszlo,
If I understand this correctly is it not more complicated than just size. It
also assumes the memory layout is the same? The legacy BIOS used fixed magic
address ranges, but UEFI uses dynamically allocated memory so addresses are not
fixed. While the UEFI firmware does try to keep S3
On Tue, 25 Feb 2020 at 18:28, Paolo Bonzini wrote:
>
> On 25/02/20 18:59, Peter Maydell wrote:
> > My assumption was that we would attack this by:
> > * converting chunks of the documentation which are in qemu-doc.texi
> >but which aren't in the qemu.1 manpage (basically in the way this
> >
On 25/02/20 17:56, Kashyap Chamarthy wrote:
> In v4:
> - Correctly use the 'define-man-page' rule for qemu-cpu-models.7
>[pm215]
> - Fix author attribution as per the thread:
>Message-ID:
>
>[danpb, pm215]
> - Don't reverse the existing order of the list of CPU models [pm215]
>
On 2/25/20 7:24 PM, Peter Maydell wrote:
In our KVM GICv2 realize function, we try to cope with old kernels
that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we
try to use the device control, and if that fails we fall back to
assuming that the kernel has the old style
On 2/25/20 7:22 PM, Stefan Berger wrote:
On 2/25/20 7:46 AM, Alex Bennée wrote:
At least on ZFS this was failing as 512 was less than or equal to 512.
I suspect the reason is additional compression done by ZFS and however
qemu-img gets the actual size.
Loosen the criteria to make sure after is
On Tue, Feb 25, 2020 at 04:47:31PM +, Peter Maydell wrote:
> On Tue, 25 Feb 2020 at 15:12, Michael S. Tsirkin wrote:
> >
> > The following changes since commit 9a8abceb5f01d1066d3a1ac5a33aabcbaeec1860:
> >
> > Merge remote-tracking branch 'remotes/pmayd
On 25/02/20 18:59, Peter Maydell wrote:
> My assumption was that we would attack this by:
> * converting chunks of the documentation which are in qemu-doc.texi
>but which aren't in the qemu.1 manpage (basically in the way this
>series is doing)
> * get the qapidoc generation conversion
In our KVM GICv2 realize function, we try to cope with old kernels
that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we
try to use the device control, and if that fails we fall back to
assuming that the kernel has the old style KVM_CREATE_IRQCHIP and
that it will provide a GICv2.
On 2/25/20 7:46 AM, Alex Bennée wrote:
At least on ZFS this was failing as 512 was less than or equal to 512.
I suspect the reason is additional compression done by ZFS and however
qemu-img gets the actual size.
Loosen the criteria to make sure after is not bigger than before and
also dump the
This bit traps EL1 access to tlb maintenance insns.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 85 +
1 file changed, 55 insertions(+), 30 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index ca67d6a770..20688d1a18
This bit traps EL1 access to cache maintenance insns that operate
to the point of unification. There are no longer any references to
plain aa64_cacheop_access, so remove it.
Signed-off-by: Richard Henderson
---
v4: Fix el0 fallthru (pmm).
---
target/arm/helper.c | 53
This bit traps EL1 access to cache maintenance insns that operate
to the point of coherency or persistence.
Signed-off-by: Richard Henderson
---
v4: Fix el0 fallthru (pmm).
---
target/arm/helper.c | 39 +++
1 file changed, 31 insertions(+), 8 deletions(-)
This bit traps EL1 access to the auxiliary control registers.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index
These bits trap EL1 access to various virtual memory controls.
Buglink: https://bugs.launchpad.net/bugs/1855072
Signed-off-by: Richard Henderson
---
v2: Include TTBCR.
v4: Include not_v8_cp_reginfo, lpae_cp_reginfo, CONTEXTIDR_S;
exclude not_v7_cp_reginfo (pmm).
---
target/arm/helper.c | 82
Don't merely start with v8.0, handle v7VE as well.
Notice writes from aarch32 mode, and the bits that
ought not be settable from there.
Suggested-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
These bits trap EL1 access to set/way cache maintenance insns.
Buglink: https://bugs.launchpad.net/bugs/1863685
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git
Changes for v4:
* Mask more res0 bits for HCR.
* Fixes for TVM/TRVM.
* Fixes for el0 for TPCP & TPU.
r~
Richard Henderson (7):
target/arm: Improve masking of HCR RES0 bits
target/arm: Honor the HCR_EL2.{TVM,TRVM} bits
target/arm: Honor the HCR_EL2.TSW bit
target/arm: Honor the
On Tue, 25 Feb 2020 at 17:48, Paolo Bonzini wrote:
>
> On 25/02/20 18:11, Peter Maydell wrote:
> >> I assume these are not meant to be applied now, except patch 2?
> > No, I intended them to be reviewable and applied now. Why
> > do you think we should wait?
>
> Because they remove information
On 02/24/20 16:28, Daniel P. Berrangé wrote:
> On Tue, Feb 11, 2020 at 05:39:59PM +, Alex Bennée wrote:
>>
>> wuchenye1995 writes:
>>
>>> Hi all,
>>>We found a problem with live migration of UEFI virtual machines
>>>due to size of OVMF.fd changes.
>>>Specifically, the size of
On Tue, 25 Feb 2020 at 17:46, Richard Henderson
wrote:
>
> On 2/25/20 4:01 AM, Peter Maydell wrote:
> > The set of operations this traps differs when ARMv8.4-TLBI is
> > implemented. It looks like you've applied this access fn to
> > the wider with-v8.4-TLBI set? (eg TLBI_VMALLE1 is only trapped
On 25/02/20 18:11, Peter Maydell wrote:
>> I assume these are not meant to be applied now, except patch 2?
> No, I intended them to be reviewable and applied now. Why
> do you think we should wait?
Because they remove information from qemu-doc.texi. I think it's
feasible to do a mass conversion
1 - 100 of 551 matches
Mail list logo
