Re: [Qemu-devel] [PATCH v8 0/6] Initial support for keycodemapdb GIT submodule

On Mon, 10/02 11:52, Programmingkid wrote: > > > On Oct 2, 2017, at 6:11 AM, qemu-devel-requ...@gnu.org wrote: > > > > Message: 21 > > Date: Mon, 2 Oct 2017 10:56:27 +0100 > > From: "Daniel P. Berrange" > > To: qemu-devel@nongnu.org > > Cc: Fam Zheng , Gerd

Re: [Qemu-devel] [PATCH RFC 0/6] xen: xen-domid-restrict improvements

On Tue, 10/03 18:24, Ian Jackson wrote: > no-re...@patchew.org writes ("Re: [Qemu-devel] [PATCH RFC 0/6] xen: > xen-domid-restrict improvements"): > > This series seems to have some coding style problems. See output below for > > more information: > > Thanks for this automatic mail. I have

Re: [Qemu-devel] [PATCH v2 0/5] block: Avoid copy-on-read assertions

On Tue, 10/03 21:22, Eric Blake wrote: > On 10/03/2017 09:16 PM, no-re...@patchew.org wrote: > > Hi, > > > > This series failed automatic build test. Please find the testing commands > > and > > their output below. If you have docker installed, you can probably > > reproduce it > > locally. > >

Re: [Qemu-devel] [PATCH v4 2/2] vl: Deprecate auto-loading of qemu.conf

Eduardo Habkost writes: > In case there were options set in the default config file, print > a warning so users can update their scripts. > > If somebody wants to keep the config file as-is, avoid the > warning and use a command-line that will work in future QEMU > versions,

Re: [Qemu-devel] [PATCH v3 2/2] qemu-options: Deprecate -nodefconfig

Eduardo Habkost writes: > Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we > have no default config files that would be disabled using > -nodefconfig. Update documentation and document -nodefconfig as > deprecated. > > Cc: Markus Armbruster

Re: [Qemu-devel] [PATCH] macio: add missing registers to VMStateDescription

On Sat, Sep 30, 2017 at 05:49:35PM +0100, Mark Cave-Ayland wrote: > Commit 4f7265f "ppc/ide/macio: Add missing registers" added two extra macio > registers but forgot to add them to the corresponding VMStateDescription. > > The version number is bumped accordingly, although this will have little

Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to receive updated RTAS region

On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote: > On 29/09/17 21:52, Nikunj A Dadhania wrote: > > David Gibson writes: > > > >> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote: > >>> Receive updates from SLOF about the updated

Re: [Qemu-devel] [PATCH v5 2/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls

On Tue, Oct 03, 2017 at 11:21:27AM +0530, Aravinda Prasad wrote: > > > On Friday 29 September 2017 12:19 PM, David Gibson wrote: > > I don't suppose there's a way to stop your mailer from inserting > > spaces after the commas in the subject line, > > Not sure how to stop the mailer from doing

Re: [Qemu-devel] [PATCH] qom: add helpers REGISTER_STATIC_TYPE[S]()

On Tue, Oct 03, 2017 at 06:37:37PM +0200, Igor Mammedov wrote: > On Tue, 3 Oct 2017 12:37:22 -0300 > Eduardo Habkost wrote: > > > On Tue, Oct 03, 2017 at 05:01:39PM +0200, Igor Mammedov wrote: > > > On Tue, 3 Oct 2017 11:25:01 -0300 > > > Eduardo Habkost

[Qemu-devel] [PATCH v1 1/5] machine: Add a valid_cpu_types property

This patch add a MachineClass element that can be set in the machine C code to specify a list of supported CPU types. If the supported CPU types are specified the user enter CPU (by -cpu at runtime) is checked against the supported types and QEMU exits if they aren't supported. Signed-off-by:

[Qemu-devel] [PATCH v1 0/5] Add a valid_cpu_types property

There are numorous QEMU machines that only have a single or a handful of valid CPU options. To simplyfy the management of specificying which CPU is/isn't valid let's create a property that can be set in the machine init. We can then check to see if the user supplied CPU is in that list or not. I

[Qemu-devel] [PATCH v1 4/5] xilinx_zynq: : Specify the valid CPUs

List all possible valid CPU options. Signed-off-by: Alistair Francis --- hw/arm/xilinx_zynq.c | 5 + 1 file changed, 5 insertions(+) diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c index 1836a4ed45..de1e0bbce1 100644 --- a/hw/arm/xilinx_zynq.c +++

[Qemu-devel] [PATCH] usb: fix typo CONFIG_LIBUSB -> CONFIG_USB_LIBUSB

A previous commit (4e5ee5b21c) broke USB pass-through by introducing a typo in a configuration variable. Signed-off-by: Thomas Jansen

Re: [Qemu-devel] [RFH PATCH 00/10] i386: hvf: miscellaneous cleanups

> On 3 Oct 2017, at 15:45, Paolo Bonzini wrote: > > Alex (both of them), Sergio, anyone else who can help? Very interested in this (and thanks!) but it will be a while before I have a sensible number of cycles available to play with this one again. -- Alex Bligh

[Qemu-devel] [PULL 5/5] aio: fix assert when remove poll during destroy

After iothread is enabled internally inside QEMU with GMainContext, we may encounter this warning when destroying the iothread: (qemu-system-x86_64:19925): GLib-CRITICAL **: g_source_remove_poll: assertion '!SOURCE_DESTROYED (source)' failed The problem is that g_source_remove_poll() does not

[Qemu-devel] [PULL 0/5] Block patches

The following changes since commit d147f7e815f97cb477e223586bcb80c316ae10ea: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2017-10-03 16:27:24 +0100) are available in the git repository at: git://github.com/stefanha/qemu.git tags/block-pull-request for you

[Qemu-devel] [PULL 4/5] iothread: delay the context release to finalize

From: Peter Xu When gcontext is used with iothread, the context will be destroyed during iothread_stop(). That's not good since sometimes we would like to keep the resources until iothread is destroyed, but we may want to stop the thread before that point. Delay the

[Qemu-devel] [PULL 2/5] iothread: provide helpers for internal use

From: Peter Xu IOThread is a general framework that contains IO loop environment and a real thread behind. It's also good to be used internally inside qemu. Provide some helpers for it to create iothreads to be used internally. Put all the internal used iothreads into the

[Qemu-devel] [PULL 1/5] qom: provide root container for internal objs

From: Peter Xu We have object_get_objects_root() to keep user created objects, however no place for objects that will be used internally. Create such a container for internal objects. CC: Andreas Färber CC: Markus Armbruster CC: Paolo

[Qemu-devel] [PATCH v1 5/5] raspi: : Specify the valid CPUs

List all possible valid CPU options. Signed-off-by: Alistair Francis --- hw/arm/raspi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c index 5941c9f751..555db0f258 100644 --- a/hw/arm/raspi.c +++ b/hw/arm/raspi.c @@ -158,6

Re: [Qemu-devel] [PATCH v1 1/5] machine: Add a valid_cpu_types property

On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote: > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote: >> This patch add a MachineClass element that can be set in the machine C >> code to specify a list of supported CPU types. If the supported CPU >> types

Re: [Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs

On Tue, Oct 03, 2017 at 01:05:11PM -0700, Alistair Francis wrote: > List all possible valid CPU options. > > Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as > supported because the Netduino2 Plus supports the Cortex-M4 and the > Netduino2 Plus is similar to the Netduino2. >

Re: [Qemu-devel] [PATCH v1 5/5] raspi: : Specify the valid CPUs

On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote: > List all possible valid CPU options. > > Signed-off-by: Alistair Francis > --- > > hw/arm/raspi.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c >

[Qemu-devel] [PATCH v2 2/2] qemu-options: Deprecate -nodefconfig

Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we have no default config files that would be disabled using -nodefconfig. Update documentation and document -nodefconfig as deprecated. Cc: Markus Armbruster Acked-by: Alistair Francis

Re: [Qemu-devel] [PATCH v2 2/2] qemu-options: Deprecate -nodefconfig

On Tue, Oct 03, 2017 at 06:17:30PM -0300, Eduardo Habkost wrote: > Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we > have no default config files that would be disabled using > -nodefconfig. Update documentation and document -nodefconfig as > deprecated. > > Cc: Markus

Re: [Qemu-devel] [PATCH v1 3/5] xlnx-zcu102: Specify the valid CPUs

On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote: > List all possible valid CPU options. > > Signed-off-by: Alistair Francis > --- > > hw/arm/xlnx-zcu102.c | 10 ++ > hw/arm/xlnx-zynqmp.c | 16 +--- >

[Qemu-devel] [PATCH v2 0/2] Deprecate -nodefconfig

Changes v1 -> v2: * Document at "Deprecated features" section in qemu-doc.texi (Daniel) * Remove documentation for the option from qemu-options.hx (Markus) Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we have no default config files that would be disabled using -nodefconfig.

[Qemu-devel] [PATCH v2 1/2] vl: Eliminate defconfig variable

Both -nodefconfig and -no-user-config options do the same thing today, we only need one variable to keep track of them. Suggested-by: Markus Armbruster Acked-by: Alistair Francis Reviewed-by: Markus Armbruster Signed-off-by:

Re: [Qemu-devel] [PATCH v5 6/6] tests: Add check-qobject for equality tests

On 2017-10-02 15:34, Markus Armbruster wrote: > Max Reitz writes: > >> Add a new test file (check-qobject.c) for unit tests that concern >> QObjects as a whole. >> >> Its only purpose for now is to test the qobject_is_equal() function. >> >> Signed-off-by: Max Reitz

Re: [Qemu-devel] [PATCH v1 1/5] machine: Add a valid_cpu_types property

On Tue, Oct 3, 2017 at 1:33 PM, Eduardo Habkost wrote: > On Tue, Oct 03, 2017 at 01:26:53PM -0700, Alistair Francis wrote: >> On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote: >> > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote: >>

Re: [Qemu-devel] [PATCH v1 5/5] raspi: : Specify the valid CPUs

On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote: > On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote: >> List all possible valid CPU options. >> >> Signed-off-by: Alistair Francis >> --- >> >> hw/arm/raspi.c | 6 ++ >> 1

Re: [Qemu-devel] [PATCH v1 3/5] xlnx-zcu102: Specify the valid CPUs

On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost wrote: > On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote: >> List all possible valid CPU options. >> >> Signed-off-by: Alistair Francis >> --- >> >> hw/arm/xlnx-zcu102.c |

[Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs

List all possible valid CPU options. Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as supported because the Netduino2 Plus supports the Cortex-M4 and the Netduino2 Plus is similar to the Netduino2. Signed-off-by: Alistair Francis --- RFC v2: -

Re: [Qemu-devel] [PATCH v1 1/5] machine: Add a valid_cpu_types property

On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote: > This patch add a MachineClass element that can be set in the machine C > code to specify a list of supported CPU types. If the supported CPU > types are specified the user enter CPU (by -cpu at runtime) is checked > against the

Re: [Qemu-devel] [PATCH v1 1/5] machine: Add a valid_cpu_types property

On Tue, Oct 03, 2017 at 01:26:53PM -0700, Alistair Francis wrote: > On Tue, Oct 3, 2017 at 1:23 PM, Eduardo Habkost wrote: > > On Tue, Oct 03, 2017 at 01:05:09PM -0700, Alistair Francis wrote: > >> This patch add a MachineClass element that can be set in the machine C > >>

Re: [Qemu-devel] [PATCH v10 8/9] tpm: Added support for TPM emulator

On 09/29/2017 07:10 AM, Amarnath Valluri wrote: This change introduces a new TPM backend driver that can communicate with swtpm(software TPM emulator) using unix domain socket interface. QEMU talks to TPM emulator using QEMU's socket-based chardev backend device. Swtpm uses two Unix sockets for

Re: [Qemu-devel] [PATCH] linux-user: Allow -R values up to 0xffff0000 for 32-bit ARM guests

On Tue, Oct 03, 2017 at 17:21:43 +0100, Peter Maydell wrote: > The 32-bit ARM validate_guest_space() check tests whether the > specified -R value leaves enough space for us to put the > commpage in at 0x0f00. However it was incorrectly doing > a <= check for the check against (guest_base +

Re: [Qemu-devel] qemu-system-hppa first steps

On 02.10.2017 17:36, Richard Henderson wrote: On 10/01/2017 04:27 PM, Helge Deller wrote: What I'm absolutely missing knowledge in is the emulation code in qemu to really be able to emulate the missing hppa assembler instructions. For example, the space registers, some other PSW bits, and so

Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device

On Tue, Oct 03, 2017 at 06:46:02PM +0200, Thomas Huth wrote: > The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement, > so QEMU crashes when the user tries to device_add + device_del a device > that does not have a corresponding hotplug controller. This could be > provoked for a

[Qemu-devel] [PULL 3/5] iothread: export iothread_stop()

From: Peter Xu So that internal iothread users can explicitly stop one iothread without destroying it. Since at it, fix iothread_stop() to allow it to be called multiple times. Before this patch we may call iothread_stop() more than once on single iothread, while that may

Re: [Qemu-devel] [PATCH 3/3] blockjob: expose manual-cull property

On 10/03/2017 01:43 PM, Jeff Cody wrote: > On Tue, Oct 03, 2017 at 11:59:28AM -0400, John Snow wrote: >> >> >> On 10/03/2017 11:57 AM, Paolo Bonzini wrote: >>> On 03/10/2017 05:15, John Snow wrote: For drive-backup and blockdev-backup, expose the manual-cull property, having it default

Re: [Qemu-devel] [PATCH v5 4/6] target/ppc: Handle NMI guest exit

On Thu, Sep 28, 2017 at 04:08:10PM +0530, Aravinda Prasad wrote: > Memory error such as bit flips that cannot be corrected > by hardware are passed on to the kernel for handling. > If the memory address in error belongs to guest then > the guest kernel is responsible for taking suitable action. >

Re: [Qemu-devel] [PATCH v5 6/6] migration: Block migration while handling machine check

On Thu, Sep 28, 2017 at 04:08:31PM +0530, Aravinda Prasad wrote: > Block VM migration requests until the machine check > error handling is complete as (i) these errors are > specific to the source hardware and is irrelevant on > the target hardware, (ii) these errors cause data > corruption and

Re: [Qemu-devel] [PATCH v5 5/6] ppc: spapr: Enable FWNMI capability

On Thu, Sep 28, 2017 at 04:08:21PM +0530, Aravinda Prasad wrote: > Enable the KVM capability KVM_CAP_PPC_FWNMI so that > the KVM causes guest exit with NMI as exit reason > when it encounters a machine check exception on the > address belonging to a guest. Without this capability > enabled, KVM

[Qemu-devel] [PATCH v2 2/5] block: Uniform handling of 0-length bdrv_get_block_status()

Handle a 0-length block status request up front, with a uniform return value claiming the area is not allocated. Most callers don't pass a length of 0 to bdrv_get_block_status() and friends; but it definitely happens with a 0-length read when copy-on-read is enabled. While we could audit all

[Qemu-devel] [PATCH v2 1/5] qemu-io: Add -C for opening with copy-on-read

Make it easier to enable copy-on-read during iotests, by exposing a new bool option to main and open. Signed-off-by: Eric Blake Reviewed-by: Jeff Cody Reviewed-by: Kevin Wolf Reviewed-by: John Snow Reviewed-by: Stefan

[Qemu-devel] [PATCH v2 0/5] block: Avoid copy-on-read assertions

During my quest to switch block status to be byte-based, John forced me to evaluate whether we have a situation during copy-on-read where we could exceed BDRV_REQUEST_MAX_BYTES [1]. Sure enough, we have a number of pre-existing bugs in the copy-on-read code. Fix those, along with adding a test.

[Qemu-devel] [PATCH v2 3/5] block: Add blkdebug hook for copy-on-read

Make it possible to inject errors on writes performed during a read operation due to copy-on-read semantics. Signed-off-by: Eric Blake Reviewed-by: Jeff Cody Reviewed-by: Kevin Wolf Reviewed-by: John Snow Reviewed-by:

[Qemu-devel] [PATCH v2 5/5] iotests: Add test 197 for covering copy-on-read

Add a test for qcow2 copy-on-read behavior, including exposure for the just-fixed bugs. The copy-on-read behavior is always to a qcow2 image, but the test is careful to allow running with most image protocol/format combos as the backing file being copied from (luks being the exception, as it is

[Qemu-devel] [PATCH v2 4/5] block: Perform copy-on-read in loop

Improve our braindead copy-on-read implementation. Pre-patch, we have multiple issues: - we create a bounce buffer and perform a write for the entire request, even if the active image already has 99% of the clusters occupied, and really only needs to copy-on-read the remaining 1% of the clusters

[Qemu-devel] [PATCH v2 1/4] blockjob: add persistent property

Add a persistent (manually reap) property to block jobs that forces them to linger in the block job list (visible to QMP queries) until the user explicitly dismisses them via QMP. The reap command itself is implemented in the next commit, and the feature is exposed to drive-backup and

[Qemu-devel] [PATCH v2 4/4] iotests: test manual job reaping

RFC: The error returned by a job creation command when that device already has a job attached has become misleading; "Someone should do something about that!" Signed-off-by: John Snow --- tests/qemu-iotests/056 | 227 +

[Qemu-devel] [PATCH v2 0/4] blockjobs: add explicit job reaping

For jobs that complete when a monitor isn't looking, there's no way to tell what the job's final return code was. We need to allow jobs to remain in the list until queried for reliable management. V2: - Added tests! - Changed property name (Jeff, Paolo) RFC: The next version will add tests for

[Qemu-devel] [PATCH v2 3/4] blockjob: expose persistent property

For drive-backup and blockdev-backup, expose the persistent property, having it default to false. There are no universal creation parameters, so it must be added to each job type that it makes sense for individually. Signed-off-by: John Snow --- blockdev.c | 10

[Qemu-devel] [PATCH v2 2/4] qmp: add block-job-reap command

For jobs that have finished (either completed or canceled), allow the user to dismiss the job's status reports via block-job-reap. Signed-off-by: John Snow --- block/trace-events | 1 + blockdev.c | 14 ++ qapi/block-core.json | 21

[Qemu-devel] [PATCH v5 08/23] block: Switch bdrv_co_get_block_status() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal function (no semantic change); and as with its public counterpart, rename to bdrv_co_block_status() to make the compiler enforce that we catch all uses. For now,

[Qemu-devel] [PATCH v5 03/23] block: Make bdrv_round_to_clusters() signature more useful

In the process of converting sector-based interfaces to bytes, I'm finding it easier to represent a byte count as a 64-bit integer at the block layer (even if we are internally capped by SIZE_MAX or even INT_MAX for individual transactions, it's still nicer to not have to worry about

[Qemu-devel] [PATCH v5 00/23] make bdrv_get_block_status byte-based

There are patches floating around to add NBD_CMD_BLOCK_STATUS, but NBD wants to report status on byte granularity (even if the reporting will probably be naturally aligned to sectors or even much higher levels). I've therefore started the task of converting our block status code to report at a

[Qemu-devel] [PATCH v5 02/23] block: Add flag to avoid wasted work in bdrv_is_allocated()

Not all callers care about which BDS owns the mapping for a given range of the file. In particular, bdrv_is_allocated() cares more about finding the largest run of allocated data from the guest perspective, whether or not that data is consecutive from the host perspective, and whether or not the

[Qemu-devel] [PATCH v5 06/23] qemu-img: Switch get_block_status() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Continue by converting an internal function (no semantic change), and simplifying its caller accordingly. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-devel] [PATCH v5 04/23] qcow2: Switch is_zero_sectors() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal function (no semantic change), and rename it to is_zero() in the process. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-devel] [PATCH v5 01/23] block: Allow NULL file for bdrv_get_block_status()

Not all callers care about which BDS owns the mapping for a given range of the file. This patch merely simplifies the callers by consolidating the logic in the common call point, while guaranteeing a non-NULL file to all the driver callbacks, for no semantic change. The only caller that does not

[Qemu-devel] [PATCH v5 07/23] block: Convert bdrv_get_block_status() to bytes

We are gradually moving away from sector-based interfaces, towards byte-based. In the common case, allocation is unlikely to ever use values that are not naturally sector-aligned, but it is possible that byte-based values will let us be more precise about allocation at the end of an unaligned

[Qemu-devel] [PATCH v5 13/23] qemu-img: Simplify logic in img_compare()

As long as we are querying the status for a chunk smaller than the known image size, we are guaranteed that a successful return will have set pnum to a non-zero size (pnum is zero only for queries beyond the end of the file). Use that to slightly simplify the calculation of the current chunk size

[Qemu-devel] [PATCH v5 12/23] block: Convert bdrv_get_block_status_above() to bytes

We are gradually moving away from sector-based interfaces, towards byte-based. In the common case, allocation is unlikely to ever use values that are not naturally sector-aligned, but it is possible that byte-based values will let us be more precise about allocation at the end of an unaligned

[Qemu-devel] [PATCH v5 17/23] qemu-img: Change check_empty_sectors() to byte-based

Continue on the quest to make more things byte-based instead of sector-based. Signed-off-by: Eric Blake Reviewed-by: John Snow --- v4-v5: no change v3: new patch --- qemu-img.c | 27 +++ 1 file changed, 15 insertions(+), 12

[Qemu-devel] [PATCH v5 05/23] block: Switch bdrv_make_zero() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Change the internal loop iteration of zeroing a device to track by bytes instead of sectors (although we are still guaranteed that we iterate by steps that are sector-aligned).

[Qemu-devel] [PATCH v5 14/23] qemu-img: Speed up compare on pre-allocated larger file

Compare the following images with all-zero contents: $ truncate --size 1M A $ qemu-img create -f qcow2 -o preallocation=off B 1G $ qemu-img create -f qcow2 -o preallocation=metadata C 1G On my machine, the difference is noticeable for pre-patch speeds, with more than an order of magnitude in

[Qemu-devel] [PATCH v5 22/23] block: Relax bdrv_aligned_preadv() assertion

Now that bdrv_is_allocated accepts non-aligned inputs, we can remove the TODO added in commit d6a644bb. Signed-off-by: Eric Blake Reviewed-by: John Snow --- v4-v5: no change v3: new patch [Kevin] --- block/io.c | 8 ++-- 1 file changed, 2

[Qemu-devel] [PATCH v5 09/23] block: Switch BdrvCoGetBlockStatusData to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal type (no semantic change), and rename it to match the corresponding public function rename. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-devel] [PATCH v5 19/23] qemu-img: Change img_rebase() to be byte-based

In the continuing quest to make more things byte-based, change the internal iteration of img_rebase(). We can finally drop the TODO assertion added earlier, now that the entire algorithm is byte-based and no longer has to shift from bytes to sectors. Most of the change is mechanical

[Qemu-devel] [PATCH v5 16/23] qemu-img: Drop redundant error message in compare

If a read error is encountered during 'qemu-img compare', we were printing the "Error while reading offset ..." message twice; this was because our helper function was awkward, printing output on some but not all paths. Fix it to consistently report errors on all paths, so that the callers do not

[Qemu-devel] [PATCH v5 10/23] block: Switch bdrv_common_block_status_above() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal function (no semantic change). Signed-off-by: Eric Blake Reviewed-by: Fam Zheng Reviewed-by: John Snow

[Qemu-devel] [PATCH v5 18/23] qemu-img: Change compare_sectors() to be byte-based

In the continuing quest to make more things byte-based, change compare_sectors(), renaming it to compare_buffers() in the process. Note that one caller (qemu-img compare) only cares about the first difference, while the other (qemu-img rebase) cares about how many consecutive sectors have the

[Qemu-devel] [PATCH v5 11/23] block: Switch bdrv_co_get_block_status_above() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal type (no semantic change), and rename it to match the corresponding public function rename. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-devel] [PATCH v5 20/23] qemu-img: Change img_compare() to be byte-based

In the continuing quest to make more things byte-based, change the internal iteration of img_compare(). We can finally drop the TODO assertions added earlier, now that the entire algorithm is byte-based and no longer has to shift from bytes to sectors. Most of the change is mechanical

[Qemu-devel] [PATCH v5 15/23] qemu-img: Add find_nonzero()

During 'qemu-img compare', when we are checking that an allocated portion of one file is all zeros, we don't need to waste time computing how many additional sectors after the first non-zero byte are also non-zero. Create a new helper find_nonzero() to do the check for a first non-zero sector,

[Qemu-devel] [PATCH v5 21/23] block: Align block status requests

Any device that has request_alignment greater than 512 should be unable to report status at a finer granularity; it may also be simpler for such devices to be guaranteed that the block layer has rounded things out to the granularity boundary (the way the block layer already rounds all other I/O

[Qemu-devel] [PATCH v5 23/23] qemu-io: Relax 'alloc' now that block-status doesn't assert

Previously, the alloc command required that input parameters be sector-aligned and clamped to 32 bits, because the underlying bdrv_is_allocated used a 32-bit parameter and asserted aligned inputs. But now that we have fixed block status to report a 64-bit bytes value, and to properly round

Re: [Qemu-devel] [PATCH v2 0/5] block: Avoid copy-on-read assertions

On 10/03/2017 09:16 PM, no-re...@patchew.org wrote: > Hi, > > This series failed automatic build test. Please find the testing commands and > their output below. If you have docker installed, you can probably reproduce > it > locally. > > 195 [not run] not suitable for this image

[Qemu-devel] [PATCH v4 1/2] config: qemu_config_parse() return number of config groups

Change qemu_config_parse() to return the number of config groups in success and -EINVAL on error. This will allow callers of qemu_config_parse() to check if something was really loaded from the config file. All existing callers of qemu_config_parse() and qemu_read_config_file() only check if the

[Qemu-devel] [PATCH v4 0/2] vl: Deprecate auto-loading of qemu.conf

This missed v2.9 and v2.10. Let's try again: we can include this on v2.11, and remove the default config file in QEMU 2.13 or 2.14. Changes v3 -> v4: * Use warn_report() instead of error_report("warning: ...") (Eric Blake) * Document as a deprecated feature in qemu-doc.texi * Updated Subject

[Qemu-devel] [PATCH v4 2/2] vl: Deprecate auto-loading of qemu.conf

In case there were options set in the default config file, print a warning so users can update their scripts. If somebody wants to keep the config file as-is, avoid the warning and use a command-line that will work in future QEMU versions, they can use: $QEMU -no-user-config -readconfig

[Qemu-devel] [PATCH v3 2/2] qemu-options: Deprecate -nodefconfig

Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we have no default config files that would be disabled using -nodefconfig. Update documentation and document -nodefconfig as deprecated. Cc: Markus Armbruster Acked-by: Alistair Francis

[Qemu-devel] [PATCH v3 0/2] Deprecate -nodefconfig

Changes v2 -> v3: * Move documentation to the right section of qemu-doc.texi Changes v1 -> v2: * Document at "Deprecated features" section in qemu-doc.texi (Daniel) * Remove documentation for the option from qemu-options.hx (Markus) Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf

[Qemu-devel] [PATCH v3 1/2] vl: Eliminate defconfig variable

Both -nodefconfig and -no-user-config options do the same thing today, we only need one variable to keep track of them. Suggested-by: Markus Armbruster Acked-by: Alistair Francis Reviewed-by: Markus Armbruster Signed-off-by:

[Qemu-devel] [PATCH] Revert: checkpatch: check trace-events code style

Commit c3e5875afc0f ("checkpatch: check trace-events code style") introduces a regression as reported: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg05820.html Bareword found where operator expected at ./scripts/checkpatch.pl line 1350, near "s/($hex[.:\/ ])+$hex//gr" syntax error at

Re: [Qemu-devel] [PATCH v1 4/5] xilinx_zynq: : Specify the valid CPUs

On 10/03/2017 05:05 PM, Alistair Francis wrote: > List all possible valid CPU options. > > Signed-off-by: Alistair Francis Reviewed-by: Philippe Mathieu-Daudé > --- > > hw/arm/xilinx_zynq.c | 5 + > 1 file changed, 5 insertions(+) > > diff

Re: [Qemu-devel] [PULL 44/50] scripts: let checkpatch.pl process an entire GIT branch

On Tue, 19 Sep 2017 14:29:33 +0200 Paolo Bonzini wrote: > From: "Daniel P. Berrange" > > Currently before submitting a series, devs should run checkpatch.pl > across each patch to be submitted. This can be automated using a > command such as: > >

[Qemu-devel] [PULL 2/3] vfio/pci: Add virtual capabilities quirk infrastructure

If the hypervisor needs to add purely virtual capabilties, give us a hook through quirks to do that. Note that we determine the maximum size for a capability based on the physical device, if we insert a virtual capability, that can change. Therefore if maximum size is smaller after added virt

[Qemu-devel] [PULL 0/3] VFIO updates 2017-10-03

The following changes since commit d147f7e815f97cb477e223586bcb80c316ae10ea: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2017-10-03 16:27:24 +0100) are available in the git repository at: git://github.com/awilliam/qemu-vfio.git

[Qemu-devel] [ANNOUNCE] QEMU 2.10.1 Stable released

Hi everyone, I am pleased to announce that the QEMU v2.10.1 stable release is now available: You can grab the tarball from our download page here: https://www.qemu.org/download/#source v2.10.1 is now tagged in the official qemu.git repository, and the stable-2.10 branch has been updated

Re: [Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs

On 10/03/2017 05:05 PM, Alistair Francis wrote: > List all possible valid CPU options. > > Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as > supported because the Netduino2 Plus supports the Cortex-M4 and the > Netduino2 Plus is similar to the Netduino2. > > Signed-off-by:

[Qemu-devel] [PULL 1/3] vfio/pci: Do not unwind on error

If vfio_add_std_cap() errors then going to out prepends irrelevant errors for capabilities we haven't attempted to add as we unwind our recursive stack. Just return error. Fixes: 7ef165b9a8d9 ("vfio/pci: Pass an error object to vfio_add_capabilities") Signed-off-by: Alex Williamson

[Qemu-devel] [PULL 3/3] vfio/pci: Add NVIDIA GPUDirect Cliques support

NVIDIA has defined a specification for creating GPUDirect "cliques", where devices with the same clique ID support direct peer-to-peer DMA. When running on bare-metal, tools like NVIDIA's p2pBandwidthLatencyTest (part of cuda-samples) determine which GPUs can support peer-to-peer based on chipset

Re: [Qemu-devel] [PATCH v1 5/5] raspi: : Specify the valid CPUs

On 10/03/2017 06:36 PM, Alistair Francis wrote: > On Tue, Oct 3, 2017 at 1:39 PM, Eduardo Habkost wrote: >> On Tue, Oct 03, 2017 at 01:05:18PM -0700, Alistair Francis wrote: >>> List all possible valid CPU options. >>> >>> Signed-off-by: Alistair Francis

Re: [Qemu-devel] [PATCH for-2.10 0/3] qdev/vfio: defer DEVICE_DEL to avoid races with libvirt

Quoting Michael Roth (2017-07-26 20:30:52) > This series was motivated by the discussion in this thread: > > https://www.redhat.com/archives/libvir-list/2017-June/msg01370.html > > The issue this series addresses is that when libvirt unplugs a VFIO PCI > device, > it may attempt to bind the

Re: [Qemu-devel] [Qemu-trivial] [PATCH] hw/block/onenand: Remove dead code block

On 03/10/2017 11:57, Thomas Huth wrote: > The condition of the for-loop makes sure that b is always smaller > than s->blocks, so the "if (b >= s->blocks)" statement is completely > superfluous here. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1715007 > Signed-off-by: Thomas Huth

[Qemu-devel] [PULL 4/6] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

From: Greg Kurz On a server-class ppc host, this capability depends on the KVM type, ie, HV or PR. If both KVM are present in the kernel, we will always get the HV specific value, even if we explicitely requested PR on the command line. This can have an impact if we're using

[Qemu-devel] [Bug 1321684] Re: block_stream command stalls

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

  1   2   3   >