Re: [Qemu-devel] [PATCH 07/24] qcow2: add bitmaps extension

29.01.2017 00:29, Max Reitz wrote: On 23.01.2017 13:10, Vladimir Sementsov-Ogievskiy wrote: Add bitmap extension as specified in docs/specs/qcow2.txt. For now, just mirror extension header into Qcow2 state and check constraints. For now, disable image resize if it has bitmaps. It will be fixed

[Qemu-devel] [PATCH] sd: sdhci: check data length during dma_memory_read

From: Prasad J Pandit While doing multi block SDMA transfer in routine 'sdhci_sdma_transfer_multi_blocks', the 's->fifo_buffer' starting index 'begin' and data length 's->data_count' could end up to be same. This could lead to an OOB access issue. Correct transfer data

[Qemu-devel] [Bug 1027525] Re: Unable to insert cd media located on ro nfs mount

[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1027525 Title: Unable to

[Qemu-devel] [Bug 1163065] Re: target-i386 cpu_get_phys_page_debug checks bits in wrong order

[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1163065 Title:

[Qemu-devel] [Bug 1186935] Re: [1.5] QEMU monitor gets overlapped by GTK menu bar

[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1186935 Title: [1.5] QEMU

[Qemu-devel] [PATCH Risu 2/2] risu_ppc64: Compare FPSCR flags

When running FP operations, FPSCR flag must be compared to make sure that any exception will behave consistently. Signed-off-by: Jose Ricardo Ziviani --- risu_reginfo_ppc64le.c | 5 + 1 file changed, 5 insertions(+) diff --git a/risu_reginfo_ppc64le.c

[Qemu-devel] [PATCH Risu 1/2] risu_ppc64: Fix Risu to run under qemu linux user

Qemu linux-user doesn't fill uc_mcontext completely like full emul. does. For instance, uc->uc_mcontext.regs->nip is an invalid so this commit replaces it by uc->uc_mcontext.gp_regs[PT_NIP] Signed-off-by: Jose Ricardo Ziviani --- risu_ppc64le.c | 2 +-

[Qemu-devel] [PATCH Risu 0/2] PPC64 improvements

This patchset contains a fix necessary to run Risu under linux-user, that is due to the fact that linux-user doesn't fully implement ucontext struct. It also contains an small improvement to validate FPSRC flag for floating-point operations. Jose Ricardo Ziviani (2): risu_ppc64: Fix Risu to

Re: [Qemu-devel] [PATCH v8 00/25] Remaining MTTCG Base patches and ARM enablement

Alex Bennée writes: > Hi, > > All of the changes in this revision are addressing comments from v7 > posted last week. A new pre-cursor patch was added: > > cputlb and arm/sparc targets: convert mmuidx flushes from varg to > bitmap > > To change the cputlb API to use a bitmap instead of

Re: [Qemu-devel] [PATCH v8 08/25] tcg: drop global lock during TCG code execution

Alex Bennée writes: > From: Jan Kiszka > > This finally allows TCG to benefit from the iothread introduction: Drop > the global mutex while running pure TCG CPU code. Reacquire the lock > when entering MMIO or PIO emulation, or when leaving the TCG loop. > > We have to

Re: [Qemu-devel] [RFC/RFT PATCH 0/7] cpu-exec: simplify cpu_exec and remove some icount special cases

Hi, Your series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [RFC/RFT PATCH 0/7] cpu-exec: simplify cpu_exec and remove some icount special cases Message-id: 20170129210910.6333-1-pbonz...@redhat.com === TEST SCRIPT BEGIN

[Qemu-devel] [PATCH 6/7] cpu-exec: unify icount_decr and tcg_exit_req

The icount interrupt flag and tcg_exit_req serve almost the same purpose, let's make them completely the same. The former TB_EXIT_REQUESTED and TB_EXIT_ICOUNT_EXPIRED cases are unified, since we can distinguish them from the value of the interrupt flag. Signed-off-by: Paolo Bonzini

[Qemu-devel] [PATCH 4/7] cpu-exec: avoid repeated sigsetjmp on interrupts

The sigsetjmp only needs to be prepared once for the whole execution of cpu_exec. This patch takes care of the "== 0" side, using a nested loop so that cpu_handle_interrupt goes straight back to cpu_handle_exception without doing another sigsetjmp. Signed-off-by: Paolo Bonzini

[Qemu-devel] [PATCH 5/7] cpu-exec: remove outermost infinite loop

Reorganize the sigsetjmp so that the restart case falls through to cpu_handle_exception and the execution loop. Signed-off-by: Paolo Bonzini --- cpu-exec.c | 58 +++--- 1 file changed, 27 insertions(+), 31 deletions(-)

[Qemu-devel] [PATCH 7/7] cpu-exec: centralize exiting to the main loop

The cpu->exit_request check in cpu_loop_exec_tb is unnecessary, because cpu->tcg_exit_req is always set after cpu->exit_request. So let the TB exit and we will pick up the exit request later in cpu_handle_interrupt. Likewise, use cpu->exit_request to set EXCP_INTERRUPT when the instruction

[Qemu-devel] [PATCH 3/7] cpu-exec: avoid cpu_loop_exit in cpu_handle_interrupt

The siglongjmp goes straight back to the beginning of cpu_exec's outermost loop. We do not need a non-local jump; we can simply leave the inner TB execution loop whose structure now becomes clearer, too. Signed-off-by: Paolo Bonzini --- cpu-exec.c | 23

[Qemu-devel] [PATCH 1/7] cpu-exec: fix jmp_first out-of-bounds access with icount

When icount is active, tb_add_jump is surprisingly called with an out of bounds basic block index. I have no idea how that can work (it overwrites jmp_first so at least it doesn't cause an immediate segv), but it does not seem like a good idea. Clear *last_tb for all TB_EXIT_ICOUNT_EXPIRED

[Qemu-devel] [RFC/RFT PATCH 0/7] cpu-exec: simplify cpu_exec and remove some icount special cases

The series includes three parts: 1-2: fix two bugs, the first one pretty bad, the second seems to be theoretical only. 3-5: simplify cpu_exec. This builds on Sergey's conversion of cpu_exec to a simple top-down logic, making the phases clearer and saving on the cost of siglongjmp in the

[Qemu-devel] [PATCH 2/7] cpu-exec: tighten barrier on TCG_EXIT_REQUESTED

This seems to have worked just fine so far on weakly-ordered architectures, but I don't see anything that prevents the reordering from: store 1 to exit_request store 1 to tcg_exit_req load tcg_exit_req store 0 to

Re: [Qemu-devel] [PATCH v8 07/25] tcg: rename tcg_current_cpu to tcg_current_rr_cpu

Alex Bennée writes: > ..and make the definition local to cpus. In preparation for MTTCG the > concept of a global tcg_current_cpu will no longer make sense. However > we still need to keep track of it in the single-threaded case to be able > to exit quickly when required. > >

Re: [Qemu-devel] [PATCH v8 06/25] tcg: add kick timer for single-threaded vCPU emulation

Alex Bennée writes: > Currently we rely on the side effect of the main loop grabbing the > iothread_mutex to give any long running basic block chains a kick to > ensure the next vCPU is scheduled. As this code is being re-factored and > rationalised we now do it explicitly here. > >

Re: [Qemu-devel] [PATCH v8 04/25] tcg: move TCG_MO/BAR types into own file

Alex Bennée writes: > We'll be using the memory ordering definitions to define values for > both the host and guest. To avoid fighting with circular header > dependencies just move these types into their own minimal header. > > Signed-off-by: Alex Bennée > Reviewed-by:

Re: [Qemu-devel] [PATCH 00/17] aio_context_acquire/release pushdown, part 2

On 20/01/2017 17:43, Paolo Bonzini wrote: > This series pushes down aio_context_acquire/release to the point > where we can actually reason on using different fine-grained mutexes. > > The main infrastructure is introduced in patch 1. The new API aio_co_wake > starts a coroutine with

Re: [Qemu-devel] [PATCH RFC 3/6] arm: kvm64: Check if kvm supports cross type vCPU

On 29 January 2017 at 11:53, Andrew Jones wrote: > On Mon, Jan 16, 2017 at 05:26:58PM +0800, Shannon Zhao wrote: >> From: Shannon Zhao >> +memset(id_regitsers, 0, ARM_CPU_ID_MAX * sizeof(struct kvm_one_reg)); >> + >> +id_regitsers[0].id =

Re: [Qemu-devel] [PATCH v8 05/25] tcg: add options for enabling MTTCG

Alex Bennée writes: > From: KONRAD Frederic > > We know there will be cases where MTTCG won't work until additional work > is done in the front/back ends to support. It will however be useful to > be able to turn it on. > > As a result MTTCG will default to off unless

Re: [Qemu-devel] [PATCH 22/24] block/dirty-bitmap: deep release dirty bitmaps

On 23.01.2017 13:10, Vladimir Sementsov-Ogievskiy wrote: > Remove persistent bitmap from its storage on bdrv_release_dirty_bitmap. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/dirty-bitmap.c | 21 ++--- > include/block/block_int.h

Re: [Qemu-devel] [PATCH 21/24] qcow2-bitmap: refcounts

On 23.01.2017 13:10, Vladimir Sementsov-Ogievskiy wrote: > Calculate refcounts for qcow2 bitmaps. It is needed for qcow2's qemu-img > check implementation. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/qcow2-bitmap.c | 80 >

Re: [Qemu-devel] [PATCH 18/24] qmp: add x-debug-block-dirty-bitmap-sha256

On 23.01.2017 13:10, Vladimir Sementsov-Ogievskiy wrote: > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/dirty-bitmap.c | 5 + > blockdev.c | 29 + > include/block/dirty-bitmap.h | 2 ++ >

Re: [Qemu-devel] [PATCH v7 2/7] trace: Make trace_get_vcpu_event_count() inlinable

Lluís Vilanova writes: > Richard Henderson writes: >> On 01/13/2017 12:48 PM, Lluís Vilanova wrote: >>> @@ -237,7 +237,7 @@ char *trace_opt_parse(const char *optarg); >>> * >>> * Return the number of known vcpu-specific events >>> */ >>> -uint32_t trace_get_vcpu_event_count(void); >>> +static

Re: [Qemu-devel] Towards an ivshmem 2.0?

On 2017-01-29 15:00, Marc-André Lureau wrote: > Hi > > On Sun, Jan 29, 2017 at 12:44 PM Jan Kiszka > wrote: > > >> Of course, I'm careful with investing much time into expanding the > >> existing, for Jailhouse possibly sufficient design if

Re: [Qemu-devel] Towards an ivshmem 2.0?

Hi On Sun, Jan 29, 2017 at 12:44 PM Jan Kiszka wrote: > >> Of course, I'm careful with investing much time into expanding the > >> existing, for Jailhouse possibly sufficient design if there no real > >> interest in continuing the ivshmem support in QEMU - because of > >>

Re: [Qemu-devel] [PATCH] migrate: Migration aborts abruptly for machine "none"

On Sun, Jan 29, 2017 at 6:33 PM, Greg Kurz wrote: > On Sun, 29 Jan 2017 01:06:47 +0530 > Ashijeet Acharya wrote: > >> On Sun, Jan 29, 2017 at 12:11 AM, Greg Kurz wrote: >> > On Thu, 26 Jan 2017 14:46:52 +0530 >> > Ashijeet Acharya

Re: [Qemu-devel] [PATCH] migrate: Migration aborts abruptly for machine "none"

On Sun, 29 Jan 2017 01:06:47 +0530 Ashijeet Acharya wrote: > On Sun, Jan 29, 2017 at 12:11 AM, Greg Kurz wrote: > > On Thu, 26 Jan 2017 14:46:52 +0530 > > Ashijeet Acharya wrote: > > > >> Migration of a "none" machine with

Re: [Qemu-devel] [RFC PATCH v2 0/6] translate: [tcg] Generic translation framework

Alex Bennée writes: > Lluís Vilanova writes: >> Lluís Vilanova writes: >> >>> This series proposes a generic (target-agnostic) instruction translation >>> framework. >> >>> It basically provides a generic main loop for instruction disassembly, which >>> calls

Re: [Qemu-devel] [PATCH RFC 4/6] target: arm: Add a generic type cpu

On Mon, Jan 16, 2017 at 05:26:59PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > Add a generic type cpu, it's useful for migration when running on > different hardwares. How are the cpu parameters and features chosen for this generic version? Shouldn't some of

Re: [Qemu-devel] Towards an ivshmem 2.0?

On 2017-01-17 10:59, Stefan Hajnoczi wrote: On Mon, Jan 16, 2017 at 02:10:17PM +0100, Jan Kiszka wrote: On 2017-01-16 13:41, Marc-André Lureau wrote: > On Mon, Jan 16, 2017 at 12:37 PM Jan Kiszka > wrote: > So, this is our proposal.

Re: [Qemu-devel] [PATCH RFC 3/6] arm: kvm64: Check if kvm supports cross type vCPU

On Mon, Jan 16, 2017 at 05:26:58PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > If user requests a specific type vCPU which is not same with the > physical ones and if kvm supports cross type vCPU, we set the > KVM_ARM_VCPU_CROSS bit and set the CPU ID registers.

Re: [Qemu-devel] Towards an ivshmem 2.0?

On 2017-01-27 20:36, Markus Armbruster wrote: > Jan Kiszka writes: > >> On 2017-01-23 15:19, Markus Armbruster wrote: >>> Jan Kiszka writes: >>> Hi, some of you may know that we are using a shared memory device similar to ivshmem in