[Qemu-devel] [PATCH v21 05/10] docs: block replication's description

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- docs/block-replication.txt |

[Qemu-devel] [PATCH v21 06/10] auto complete active commit

From: Wen Congyang Auto complete mirror job in background to prevent from blocking synchronously Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie --- block/mirror.c| 13 + blockdev.c

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

thanks. this is a good idea. env->fullwr is reseted after the TB is retranslated. On Wed, Jul 6, 2016 at 2:55 AM, Richard Henderson wrote: > On 07/05/2016 02:41 PM, Michael Rolnik wrote: > >> right it accesses CPU registers but from helper context. >> the flow is as follows

Re: [Qemu-devel] [PATCH] qom/object: fix comment typo

Would any maintainer pick this one? On 06/14/2016 03:27 PM, Changlong Xie wrote: Signed-off-by: Changlong Xie --- include/qom/object.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/qom/object.h b/include/qom/object.h index

[Qemu-devel] [PATCH v21 03/10] Backup: export interfaces for extra serialization

Normal backup(sync='none') workflow: step 1. NBD peformance I/O write from client to server qcow2_co_writev bdrv_co_writev ... bdrv_aligned_pwritev notifier_with_return_list_notify -> backup_do_cow bdrv_driver_pwritev // write new contents step 2. drive-backup

[Qemu-devel] 答复： Re: [PATCH 2/2 V4] hmp: show all of snapshot info on every block dev in output of 'info snapshots'

>>> Max Reitz 2016/7/6 星期三 上午 1:26 >>> >On 04.07.2016 11:31, Lin Ma wrote: >> Currently, the output of 'info snapshots' shows fully available snapshots. >> It's opaque, hides some snapshot information to users. It's not convenient >> if users want to know more about all of

[Qemu-devel] [PATCH v21 10/10] support replication driver in blockdev-add

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie Reviewed-by: Eric Blake

[Qemu-devel] [PATCH v21 09/10] tests: add unit test case for replication

Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie --- tests/.gitignore | 1 + tests/Makefile.include | 4 + tests/test-replication.c | 557 +++ 3 files changed, 562 insertions(+)

[Qemu-devel] [PATCH v21 04/10] Link backup into block core

From: Wen Congyang Some programs that add a dependency on it will use the block layer directly. Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by:

[Qemu-devel] [PATCH v21 02/10] Backup: clear all bitmap when doing block checkpoint

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- block/backup.c |

[Qemu-devel] [PATCH v21 08/10] Implement new driver for block replication

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- block/Makefile.objs | 1 +

[Qemu-devel] [PATCH v21 00/10] Block replication for continuous checkpoints

Block replication is a very important feature which is used for continuous checkpoints(for example: COLO). You can get the detailed information about block replication from here: http://wiki.qemu.org/Features/BlockReplication Usage: Please refer to docs/block-replication.txt You can get the

[Qemu-devel] [PATCH v21 01/10] unblock backup operations in backing file

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie --- block.c | 17 + 1 file changed, 17 insertions(+) diff --git a/block.c b/block.c index f4648e9..f7e7e43 100644 --- a/block.c

[Qemu-devel] [PATCH v2 0/3] Rework spapr: Better handling of ibm, pa-features TM bit

Here's version 2. Changes v1 -> v2: Patch 2/3: spapr: Set ibm, pa-features HTM from KVM_CAP_PPC_HTM * Improve readability of HTM bit set code. * Move the test for KVM into kvmppc_get_htm_support(). Sam Bobroff (3): spapr: Disable ibm, pa-features HTM bit Add KVM_CAP_PPC_HTM to

[Qemu-devel] [PATCH v2 2/3] Add KVM_CAP_PPC_HTM to linux/kvm.h

Signed-off-by: Sam Bobroff --- linux-headers/linux/kvm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h index e60e21b..37cb3e8 100644 --- a/linux-headers/linux/kvm.h +++ b/linux-headers/linux/kvm.h @@ -866,6

[Qemu-devel] [PATCH v2 1/3] spapr: Disable ibm, pa-features HTM bit

There are a few issues with our handling of the ibm,pa-features HTM bit: - We don't support transactional memory in PR KVM, so don't tell the OS that we do. - In full emulation we have a minimal implementation of HTM that always fails, so for performance reasons lets not tell the OS that we

[Qemu-devel] [PATCH v2 3/3] spapr: Set ibm, pa-features HTM from KVM_CAP_PPC_HTM

Advertise HTM support in ibm, pa-features if KVM indicates support when queried via a new capability (KVM_CAP_PPC_HTM). If KVM returns false for the capability (which may indicate that the host kernel doesn't support the capability itself) attempt to determine availability using a fallback method

Re: [Qemu-devel] [RFC PATCH v0 2/5] cpu: Optionally use arch_id instead of cpu_index in cpu vmstate_register()

On Tue, 5 Jul 2016 18:13:22 +0530 Bharata B Rao wrote: > On Tue, Jul 05, 2016 at 09:15:51AM +0200, Igor Mammedov wrote: > > On Tue, 5 Jul 2016 10:12:49 +0530 > > Bharata B Rao wrote: > > > > > Introduce

Re: [Qemu-devel] [PATCH] main-loop: check return value before using

cc Paolo again, because failed to deliver in 'git send-email' On 07/06/2016 11:03 AM, Cao jin wrote: pointer 'qemu_aio_context' should be checked first before it is used. qemu_bh_new() will use it. Also add extra newlines to make code well separated and easier to read. Signed-off-by: Cao jin

Re: [Qemu-devel] [PATCH 2/3] Add KVM_CAP_PPC_HTM to linux/kvm.h

On Wed, Jul 06, 2016 at 02:41:52PM +1000, Sam Bobroff wrote: > On Tue, Jul 05, 2016 at 04:05:58PM +1000, David Gibson wrote: > > On Tue, Jul 05, 2016 at 03:19:23PM +1000, Sam Bobroff wrote: > > > Signed-off-by: Sam Bobroff > > > > Ok, so the usual procedure for updates

Re: [Qemu-devel] [PATCH 2/3] Add KVM_CAP_PPC_HTM to linux/kvm.h

On Tue, Jul 05, 2016 at 04:05:58PM +1000, David Gibson wrote: > On Tue, Jul 05, 2016 at 03:19:23PM +1000, Sam Bobroff wrote: > > Signed-off-by: Sam Bobroff > > Ok, so the usual procedure for updates to linux-headers is this: >1. Get the change merged on the kernel

Re: [Qemu-devel] [PATCH 7/7] ast2400: add a memory controller device model

On Mon, 2016-07-04 at 14:18 +0200, Cédric Le Goater wrote: > The uboot in the previous release of the SDK was using a hardcoded > value for memory size. This is not true anymore, the value is now > retrieved from the memory controller. > > Below is a model for this device, only supporting unlock

Re: [Qemu-devel] [PATCH RFC] spapr: by-pass SLOF when -kernel is provided

On 06/07/16 11:35, David Gibson wrote: > On Tue, Jul 05, 2016 at 04:42:37PM +0200, Laurent Vivier wrote: >> As device-tree is now fully built by QEMU, we don't need SLOF >> anymore if the kernel is provided on the command line. >> >> In this case, don't load SLOF and boot directly into the >>

[Qemu-devel] [PATCH] main-loop: check return value before using

pointer 'qemu_aio_context' should be checked first before it is used. qemu_bh_new() will use it. Also add extra newlines to make code well separated and easier to read. Signed-off-by: Cao jin --- main-loop.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)

Re: [Qemu-devel] [PATCH v9 02/13] mptsas: change .realize function name

Hi, I guess this one is suitable for trivial tree, so CC them On 06/20/2016 02:13 PM, Cao jin wrote: All the other devices` .realize function name are xxx_realize, except this one. cc: Michael S. Tsirkin cc: Marcel Apfelbaum cc: Paolo Bonzini

[Qemu-devel] [PATCH v2] balloon: Fix failure of updating guest memory status

After live migration, 'guest-stats' can't get the expected memory status in the guest. This issue is caused by commit 4eae2a657d. The value of 's->stats_vq_elem' will be NULL after live migration, and the check in the function 'balloon_stats_poll_cb()' will prevent the 'virtio_notify()' from

Re: [Qemu-devel] [PATCH v3 01/32] blockdev: prepare iSCSI block driver for dynamic loading

On Tue, 07/05 11:24, Colin Lord wrote: > This commit moves the initialization of the QemuOptsList qemu_iscsi_opts > struct out of block/iscsi.c in order to allow the iscsi module to be > dynamically loaded. > > Signed-off-by: Colin Lord > --- > block/iscsi.c | 36

Re: [Qemu-devel] [PATCH RFC] spapr: by-pass SLOF when -kernel is provided

On Tue, Jul 05, 2016 at 04:42:37PM +0200, Laurent Vivier wrote: > As device-tree is now fully built by QEMU, we don't need SLOF > anymore if the kernel is provided on the command line. > > In this case, don't load SLOF and boot directly into the > kernel. > > This saves at least 5 seconds on the

Re: [Qemu-devel] [PULL 18/43] block: Switch discard length bounds to byte-based

On 07/05/2016 09:50 AM, Kevin Wolf wrote: > From: Eric Blake > > Sector-based limits are awkward to think about; in our on-going > quest to move to byte-based interfaces, convert max_discard and > discard_alignment. Rename them, using 'pdiscard' as an aid to > track which

Re: [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer

On 06/21/2016 11:54 PM, Fam Zheng wrote: > On Mon, 06/20 17:39, Eric Blake wrote: >> We have max_transfer documented in BlockLimits, but while we >> honor it during pwrite_zeroes, we were blindly ignoring it >> during pwritev and preadv, leading to multiple drivers having >> to implement

Re: [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification handler for aer resume

Hi Alex, Due to weekend and holiday in my country, there were zero regular working hours between your emails. I wish you had a good time. The following code will be modified. 1. vfio_pci_ioctl add a flag in vfio_device_info for workable_state support return workable_state in "struct

Re: [Qemu-devel] [SeaBIOS] [PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL

On 07/06/16 00:19, Laszlo Ersek wrote: > On 06/22/16 08:53, Haozhong Zhang wrote: > > OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL > > for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file > > "etc/msr_feature_control" to advise bits that should be set in >

Re: [Qemu-devel] [PATCH] quorum: Only compile when supported

On Tue, 07/05 10:35, Daniel P. Berrange wrote: > > Can you backup and explain more detail what the actual problem you're trying > to solve is. IIUC, it is related to module loading, but I'm not seeing exactly > what it is. This patch originated when I was researching all drivers' block_init

Re: [Qemu-devel] Login and Password Request

On Tue, 07/05 20:49, Shiv Arora wrote: > Hi Developers Hi Shiv, > > I use the qemu command to up my virtual OS. But after that command executes > it ask for > > localhost.localdomain.localdomain login: > Password: > > I don`t want to add the login and password manually as i have to launch >

Re: [Qemu-devel] [PATCH v2 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

Ping ... Liang > -Original Message- > From: Li, Liang Z > Sent: Wednesday, June 29, 2016 6:32 PM > To: m...@redhat.com > Cc: linux-ker...@vger.kernel.org; virtualizat...@lists.linux-foundation.org; > k...@vger.kernel.org; qemu-devel@nongnu.org; virtio-dev@lists.oasis- > open.org;

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

On 07/05/2016 02:41 PM, Michael Rolnik wrote: right it accesses CPU registers but from helper context. the flow is as follows 1. there is a write to [0x: 0x0100) region 2. tlb_fill is called, it does the following a. sets env->fullwr b. calls cpu_loop_exit_restore. c. the whole

Re: [Qemu-devel] [PATCH v2 5/6] qemu-iotests: Test setting WCE with qdev

On 07/05/2016 08:57 AM, Max Reitz wrote: >> I'm not sure yet what the conclusion is. Change query-block to include >> anonymous BBs that are owned by devices? A new query command? Add the >> information to info qtree and whatever the QMP version of it is (if it >> even exists)? > > Well, since

Re: [Qemu-devel] [PATCH v4 3/9] target-avr: adding a sample AVR board

On 5 July 2016 at 23:22, Michael Rolnik wrote: > Peter, > > I do not understand this comment > > Exactly one of these memory regions (your main "RAM") should be > allocated via memory_region_allocate_system_memory() > [which does the vmstate_register_ram_global() for that MR].

Re: [Qemu-devel] [PATCH v1 3/2] crypto: don't open-code qcrypto_hash_supports

On 07/05/2016 10:43 AM, Daniel P. Berrange wrote: > Call the existing qcrypto_hash_supports method from > qcrypto_hash_bytesv instead of open-coding it again. > > Signed-off-by: Daniel P. Berrange > --- > crypto/hash-gcrypt.c | 3 +-- > crypto/hash-glib.c | 3 +-- >

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

On 5 July 2016 at 22:41, Michael Rolnik wrote: > right it accesses CPU registers but from helper context. > the flow is as follows > > 1. there is a write to [0x: 0x0100) region > 2. tlb_fill is called, it does the following > a. sets env->fullwr > b. calls

Re: [Qemu-devel] [PATCH v4 3/9] target-avr: adding a sample AVR board

Peter, I do not understand this comment *Exactly one of these memory regions (your main "RAM") should beallocated via memory_region_allocate_system_memory()[which does the vmstate_register_ram_global() for that MR].The idea is that every board has one-and-only-one main RAM MR.(We should

Re: [Qemu-devel] [SeaBIOS] [PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL

On 06/22/16 08:53, Haozhong Zhang wrote: > OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL > for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file > "etc/msr_feature_control" to advise bits that should be set in > MSR_IA32_FEATURE_CONTROL. If this file exists,

Re: [Qemu-devel] [Qemu-block] [PATCH v8 10/16] block: Simplify drive-mirror

On 07/05/2016 06:16 PM, Eric Blake wrote: > On 07/05/2016 02:27 PM, John Snow wrote: >> >> >> On 07/02/2016 10:58 PM, Eric Blake wrote: >>> Now that we can support boxed commands, use it to greatly >>> reduce the number of parameters (and likelihood of getting >>> out of sync) when adjusting

Re: [Qemu-devel] [Qemu-block] [PATCH v8 10/16] block: Simplify drive-mirror

On 07/05/2016 02:27 PM, John Snow wrote: > > > On 07/02/2016 10:58 PM, Eric Blake wrote: >> Now that we can support boxed commands, use it to greatly >> reduce the number of parameters (and likelihood of getting >> out of sync) when adjusting drive-mirror parameters. >> >> Signed-off-by: Eric

Re: [Qemu-devel] [Qemu-ppc] [PATCH 8/9] ppc: Add missing slbfee. instruction on ppc64 BookS processors

On Tue, 2016-07-05 at 19:23 +0200, Cédric Le Goater wrote: > > > So, I was trying today to reconciliate the powernv patchset with  > the current HEAD of qemu when I bumped into the old version of this  > patch. I checked the specs and when no slb are found, rt should  > just be 0. The machine

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

1. AT90CAN - http://www.atmel.com/images/doc7679.pdf 4. Memories Figure 4-2. Data Memory Map 29. Register Summary 2. AT90USB - http://www.atmel.com/images/doc7593.pdf 6. Atmel AVR AT90USB64/128 memories 33. Register summary in the "register summary" table

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

right it accesses CPU registers but from helper context. the flow is as follows 1. there is a write to [0x: 0x0100) region 2. tlb_fill is called, it does the following a. sets env->fullwr b. calls cpu_loop_exit_restore. c. the whole block is retranslated and instead of st it

Re: [Qemu-devel] [Qemu-block] [PATCH v3 04/32] blockdev: Move bochs probe into separate file

On 07/05/2016 05:00 PM, Max Reitz wrote: > On 05.07.2016 22:50, John Snow wrote: >> >> >> On 07/05/2016 11:49 AM, Daniel P. Berrange wrote: >>> On Tue, Jul 05, 2016 at 11:24:04AM -0400, Colin Lord wrote: This puts the bochs probe function into its own separate file as part of the

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

On 5 July 2016 at 21:31, Michael Rolnik wrote: > > As Richard says you have problems with trying to write > CPU registers from a device anyway, but please consider > trying to have some level of abstraction rather than > just having the device code reach into

Re: [Qemu-devel] [PATCH v9 09/10] target-avr: updating translate.c to use instructions translation

On 1 July 2016 at 15:47, Michael Rolnik wrote: > Signed-off-by: Michael Rolnik > --- > target-avr/Makefile.objs | 4 +- > target-avr/translate.c | 142 > --- > 2 files changed, 64 insertions(+), 82

Re: [Qemu-devel] [Qemu-block] [PATCH v3 04/32] blockdev: Move bochs probe into separate file

On 05.07.2016 22:50, John Snow wrote: > > > On 07/05/2016 11:49 AM, Daniel P. Berrange wrote: >> On Tue, Jul 05, 2016 at 11:24:04AM -0400, Colin Lord wrote: >>> This puts the bochs probe function into its own separate file as part of >>> the process of modularizing block drivers. Having the

Re: [Qemu-devel] Qemu and PCI Interrupt Link?

On 05/07/2016 20:30, Laszlo Ersek wrote: > On 07/04/16 15:14, Peter Lieven wrote: >> Hi, >> >> i noticed that newer guest kernels emit the following message at startup: >> >> ACPI: No IRQ available for PCI Interrupt Link [LNKS]. Try pci=noacpi or >> acpi=off >> >> Cmdline: >>

Re: [Qemu-devel] [Qemu-block] [PATCH v3 04/32] blockdev: Move bochs probe into separate file

On 07/05/2016 11:49 AM, Daniel P. Berrange wrote: > On Tue, Jul 05, 2016 at 11:24:04AM -0400, Colin Lord wrote: >> This puts the bochs probe function into its own separate file as part of >> the process of modularizing block drivers. Having the probe functions >> separate from the rest of the

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

So, given the 1 register block per virt-mmio "bus" then I agree that we need a "dev path" distinction between them. On 5 July 2016 at 14:22, Thomas Hanson wrote: > OK, that makes sense. I was thinking that the MMIO transport would/could > support multiple register

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

On 5 July 2016 at 21:31, Michael Rolnik wrote: > Hi Peter, > > > You're probably better off having the device in one > patch and the board model in another, rather than combining them. > > Generally, device models don't live in hw/, only board > models. Put the

[Qemu-devel] [PATCH v1 4/4] zynqmp: Connect the IPI devices

Connect the Xilinx ZynqMP Inter Processor Interrupt (IPI) devices to the ZynqMP SoC. This includes connecting the devices to each other. Signed-off-by: Alistair Francis --- hw/arm/xlnx-zynqmp.c | 102 +++

[Qemu-devel] [PATCH v1 3/4] xlnx-zynqmp-ipi: Add the IPI device

Add the Xilinx ZynqMP Inter Processor Interrupt device. Signed-off-by: Alistair Francis --- hw/intc/Makefile.objs | 1 + hw/intc/xlnx-zynqmp-ipi.c | 263 ++ include/hw/intc/xlnx-zynqmp-ipi.h | 116

Re: [Qemu-devel] [PATCH v1 0/4] Connect the Xilinx ZynqMP IPI device

On 5 July 2016 at 21:30, Alistair Francis wrote: > This patchset adds and connects the Xilinx ZynqmP IPI devices using the > register GPIO line. > > This requires adding the register GPIO API which allows registers to be > mapped to GPIOs. This GPIO is used to

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

Hi Peter, *You're probably better off having the device in onepatch and the board model in another, rather than combining them.* *Generally, device models don't live in hw/, only board models. Put the device model in the appropriate subdirectoryof hw/, which is 'misc' for

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

OK, that makes sense. I was thinking that the MMIO transport would/could support multiple register blocks and thus multiple devices. On 5 July 2016 at 13:26, Laszlo Ersek (Red Hat) wrote: > A virtio-mmio "bus" is a single-device transport. It has a fixed base > address that

[Qemu-devel] [PATCH v1 1/4] irq: Add opaque setter routine

From: Peter Crosthwaite Add a routine to set or override the opaque data of an IRQ. Qdev currently always initialises IRQ opaque as the device itself. This allows you to override to a custom opaque in the case where there is extra or different data needed.

[Qemu-devel] [PATCH v1 0/4] Connect the Xilinx ZynqMP IPI device

This patchset adds and connects the Xilinx ZynqmP IPI devices using the register GPIO line. This requires adding the register GPIO API which allows registers to be mapped to GPIOs. This GPIO is used to propergate register reads/writes to other devices and other registers. This is useful to

[Qemu-devel] [PATCH v1 2/4] register: Add GPIO API

Add GPIO functionality to the register API. This allows association and automatic connection of GPIOs to bits in registers. GPIO inputs will attach to handlers that automatically set read-only bits in registers. GPIO outputs will be updated to reflect their field value when their respective

Re: [Qemu-devel] [PATCH] block/gluster: add support to choose libgfapi logfile

On Tue, Jul 05, 2016 at 02:46:26PM +0530, Prasanna Kumar Kalever wrote: > currently all the libgfapi logs defaults to '/dev/stderr' as it was hardcoded > in a call to glfs logging api, in case if debug level is chosen to DEBUG/TRACE > gfapi logs will be huge and fill/overflow the console view. >

Re: [Qemu-devel] [Qemu-block] [PATCH v8 10/16] block: Simplify drive-mirror

On 07/02/2016 10:58 PM, Eric Blake wrote: > Now that we can support boxed commands, use it to greatly > reduce the number of parameters (and likelihood of getting > out of sync) when adjusting drive-mirror parameters. > > Signed-off-by: Eric Blake > > --- > v8: rebase, drop

Re: [Qemu-devel] [gdbstub] qemu is killed by gdb

On 5 July 2016 at 23:17, KONRAD Frederic wrote: > Hi Alon, > > Which repos/branch are you using? > If you are using mttcg (the repo you mention in [1]) this is a known bug. Hi, I use qemu releases or qemu master. I only referenced the [1] to show that this was already

Re: [Qemu-devel] [gdbstub] qemu is killed by gdb

Hi Alon, Which repos/branch are you using? If you are using mttcg (the repo you mention in [1]) this is a known bug. Thanks, Fred Le 05/07/2016 à 21:50, Alon Bar-Lev a écrit : Hello, I am aware that this was discussed many times, however, problem remains. Use case loading u-boot. 1. Run

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

On 5 July 2016 at 17:43, Tom Hanson wrote: > On 07/05/2016 10:29 AM, Peter Maydell wrote: > ... >> The virt board creates a collection of virtio-mmio transports, >> so if you create just a backend on the command line (via >> "-device virtio-scsi-device") it will be

[Qemu-devel] [gdbstub] qemu is killed by gdb

Hello, I am aware that this was discussed many times, however, problem remains. Use case loading u-boot. 1. Run qemu in debug mode: $ qemu-system-mips -M malta -nographic -m 256 -s -S 2. Run gdb: $ mips-unknown-linux-uclibceabi-gdb (gdb) target remote :1234 (gdb) load u-boot (gdb) target exec

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

On 5 July 2016 at 19:15, Michael Rolnik wrote: > Hi Richard, > > Are there more pending issues with my code? Most of the issues I raised with the board model/device level code still seem to be present. thanks -- PMM

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

A virtio-mmio "bus" is a single-device transport. It has a fixed base address that is set at board creation time. The MMIO area is 0x200 bytes in size, and hosts the virtio registers for one device that can sit on this transport. Transports can be unused. The "virt" machtype creates 32 transports

Re: [Qemu-devel] [PATCH] translate-all: Bugfix for user-mode self-modifying code in 2 page long TB

On 05/07/16 13:45, Stanislav Shmarov wrote: > In user-mode emulation Translation Block can consist of 2 guest pages. > In that case QEMU also mprotects 2 host pages that are dedicated for > guest memory, containing instructions. QEMU detects self-modifying code > with SEGFAULT signal processing. >

[Qemu-devel] [PATCH v3 4/4] x86: Set physical address bits based on host

From: "Dr. David Alan Gilbert" A special case based on the previous phys-bits property; if it's the magic value 0 then use the hosts capabilities. We can also use the value we read from the host to check the users explicitly set value and warn them if it doesn't match.

Re: [Qemu-devel] Qemu and PCI Interrupt Link?

On 07/04/16 15:14, Peter Lieven wrote: > Hi, > > i noticed that newer guest kernels emit the following message at startup: > > ACPI: No IRQ available for PCI Interrupt Link [LNKS]. Try pci=noacpi or > acpi=off > > Cmdline: > x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 2048 -cdrom >

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

I tested Laszlo's patch against this scenario and it eliminated the error. However, I'm still not convinced that it's needed. Let's start with a basic question: Does it make sense for there to be more than one MMIO "bus" on a system? After all, it's NOT a physical bus and there's only one set

Re: [Qemu-devel] [PATCH v2 5/6] x86: fix up 32 bit phys_bits case

* Daniel P. Berrange (berra...@redhat.com) wrote: > On Tue, Jul 05, 2016 at 12:29:30PM +0100, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrange (berra...@redhat.com) wrote: > > > On Mon, Jul 04, 2016 at 08:16:08PM +0100, Dr. David Alan Gilbert (git) > > > wrote: > > > > From: "Dr. David Alan

[Qemu-devel] [PATCH v3 0/4] x86: Physical address limit patches

From: "Dr. David Alan Gilbert" QEMU sets the guests physical address bits to 40; this is wrong on most hardware, and can be detected by the guest. It also stops you using really huge multi-TB VMs. Red Hat has had a patch, that Andrea wrote, downstream for a couple of years

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

On 07/05/2016 10:29 AM, Peter Maydell wrote: ... > The virt board creates a collection of virtio-mmio transports, > so if you create just a backend on the command line (via > "-device virtio-scsi-device") it will be plugged into a > virtio-bus on a virtio-mmio transport. > > You almost certainly

[Qemu-devel] [PATCH v3 1/4] x86: Allow physical address bits to be set

From: "Dr. David Alan Gilbert" Currently QEMU sets the x86 number of physical address bits to the magic number 40. This is only correct on some small AMD systems; Intel systems tend to have 36, 39, 46 bits, and large AMD systems tend to have 48. Having the value different

[Qemu-devel] [PATCH v3 2/4] x86: Mask mtrr mask based on CPU physical address limits

From: "Dr. David Alan Gilbert" The CPU GPs if we try and set a bit in a variable MTRR mask above the limit of physical address bits on the host. We hit this when loading a migration from a host with a larger physical address limit than our destination (e.g. a Xeon->i7 of

[Qemu-devel] [PATCH v3 3/4] x86: fill high bits of mtrr mask

From: "Dr. David Alan Gilbert" Fill the bits between 51..number-of-physical-address-bits in the MTRR_PHYSMASKn variable range mtrr masks so that they're consistent in the migration stream irrespective of the physical address space of the source VM in a migration.

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC] spapr: by-pass SLOF when -kernel is provided

On 05/07/2016 20:44, Greg Kurz wrote: > On Tue, 5 Jul 2016 16:42:37 +0200 > Laurent Vivier wrote: > >> As device-tree is now fully built by QEMU, we don't need SLOF >> anymore if the kernel is provided on the command line. >> >> In this case, don't load SLOF and boot

[Qemu-devel] [Bug 1599214] Re: virtlogd: qemu 2.6.0 doesn't log boot message

** Description changed: This report is related to the OpenStack Nova bug [1]. - OpenStack tries to utilize the "virtlogd" feature of qemu [2]. + OpenStack tries to utilize the "virtlogd" feature of libvirt which gets + provided by qemu with [2]. steps to reproduce: 1) launch a quest

Re: [Qemu-devel] [PATCH 1/1] Improve block job rate limiting for small bandwidth values

On 05.07.2016 20:06, Sascha Silbe wrote: > Dear Max, > > Max Reitz writes: > >> [ Good signature by key: 0x58B381CE2DC89CF99730EE643BB14202E838ACAD ] > > Feel free to drop by if you happen to be in the Stuttgart area some > time. PGP key signing, a beverage of your choice

Re: [Qemu-devel] [PATCH 1/1] Improve block job rate limiting for small bandwidth values

Dear Max, Max Reitz writes: > [ Good signature by key: 0x58B381CE2DC89CF99730EE643BB14202E838ACAD ] Feel free to drop by if you happen to be in the Stuttgart area some time. PGP key signing, a beverage of your choice and optionally some chatting about qemu and related

[Qemu-devel] [PATCH v2 5/6] tcg: introduce tb_lock_recursive()

In some cases it is useful to have a recursive lock that can be safely taken when nested in other critical regions. Rather than make all tb_locks() recursive having a separate function serves to notify the reader that it explicitly a possibility in this case. Signed-off-by: Alex Bennée

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

Posted a patch: http://lists.nongnu.org/archive/html/qemu- devel/2016-07/msg01119.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1594239 Title: After adding more scsi disks for Aarch64 virtual

[Qemu-devel] [PATCH v2 0/6] Reduce lock contention on TCG hot-path

Hi, Well this is the first re-spin of the series posted last week. I've added a bunch of additional patches to be more aggressive with avoiding bouncing locks but to be honest the numbers don't seem to make it worth it. I think the first 3 patches are ready to take if the TCG maintainers want

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC] spapr: by-pass SLOF when -kernel is provided

On 07/05/2016 04:42 PM, Laurent Vivier wrote: > As device-tree is now fully built by QEMU, we don't need SLOF > anymore if the kernel is provided on the command line. > > In this case, don't load SLOF and boot directly into the > kernel. > > This saves at least 5 seconds on the boot sequence. >

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC] spapr: by-pass SLOF when -kernel is provided

On Tue, 5 Jul 2016 16:42:37 +0200 Laurent Vivier wrote: > As device-tree is now fully built by QEMU, we don't need SLOF > anymore if the kernel is provided on the command line. > > In this case, don't load SLOF and boot directly into the > kernel. > > This saves at least 5

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores

Hi Richard, Are there more pending issues with my code? Thanks, Michael On Sat, Jul 2, 2016 at 10:56 PM, Michael Rolnik wrote: > for ADIW, SBIW instructions I modified address calculation. > > On Sat, Jul 2, 2016 at 9:20 PM, Michael Rolnik wrote: > >> Hi

Re: [Qemu-devel] [PATCH 2/2] cpu-exec: remove tb_lock from the hot-path

On 05/07/16 19:00, Alex Bennée wrote: > Sergey Fedorov writes: > >> On 05/07/16 16:42, Paolo Bonzini wrote: >>> On 05/07/2016 15:11, Alex Bennée wrote: Paolo Bonzini writes: > On 05/07/2016 13:14, Alex Bennée wrote: >> /* >> *

Re: [Qemu-devel] [PATCH v8 0/5] Add a generic loader

On Mon, Jul 4, 2016 at 5:43 AM, Christian Borntraeger wrote: > On 07/02/2016 03:07 AM, Alistair Francis wrote: >> This work is based on the original work by Li Guang with extra >> features added by Peter C and myself. >> >> The idea of this loader is to allow the user to

Re: [Qemu-devel] [PATCH 2/2 V4] hmp: show all of snapshot info on every block dev in output of 'info snapshots'

On 04.07.2016 11:31, Lin Ma wrote: > Currently, the output of 'info snapshots' shows fully available snapshots. > It's opaque, hides some snapshot information to users. It's not convenient > if users want to know more about all of snapshot information on every block > device via monitor. > >

Re: [Qemu-devel] [PATCH 0/1] Fix iotests race condition by fixing block job rate limiting

On 28.06.2016 17:28, Sascha Silbe wrote: > qemu-iotests #141 is relying on the test being able to operate on a > block job it just started before further progress is being made on > this block job. This fails regularly on some hosts because the time > slice is just 100ms and it often takes longer

Re: [Qemu-devel] [Qemu-ppc] [PATCH 8/9] ppc: Add missing slbfee. instruction on ppc64 BookS processors

On 06/07/2016 04:50 AM, Benjamin Herrenschmidt wrote: > Used to lookup SLB entries by address, for some reason it was missing. > > Signed-off-by: Benjamin Herrenschmidt > --- > target-ppc/helper.h | 1 + > target-ppc/mmu-hash64.c | 30

Re: [Qemu-devel] [PATCH 0/2] qcow2: Avoid making the L1 table too big

On 15.06.2016 17:36, Max Reitz wrote: > See https://bugs.launchpad.net/qemu/+bug/1592590 for a bug report. > > Reproducer: > > $ ./qemu-img create -f qcow2 test.qcow2 1M > Formatting 'test.qcow2', fmt=qcow2 size=1048576 encryption=off > cluster_size=65536 lazy_refcounts=off refcount_bits=16 > $

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

I haven't dug into the code for this particular aspect (yet) but it sounds like when a scsi-hd device is specified with a virtio backend but with no virtio bus specified, it is defaulting to an MMIO bus. Is this correct? A few questions: 1) Is it valid for a SCSI drive to default to an MMIO

[Qemu-devel] [PATCH] virtio-mmio: format transport base address in BusClass.get_dev_path

At the moment the following QEMU command line triggers an assertion failure (minimal reproducer by Cole): qemu-system-aarch64 \ -machine virt-2.6,accel=tcg \ -nodefaults \ -no-user-config \ -nographic -monitor stdio \ -device virtio-scsi-device,id=scsi0 \ -device

Re: [Qemu-devel] [PATCH 0/2] qcow2: Fix qcow2_get_cluster_offset()

On 20.06.2016 16:26, Max Reitz wrote: > Patch 2 fixes a wrong assertion in qcow2_get_cluster_offet(). Patch 1 > fixes wrong range limitations I encountered in qemu-io while trying to > break that wrong assertion. > > Not CC-ing qemu-stable because these issues were introduced after 2.6.0. > > >

  1   2   3   4   5   >