[Qemu-devel] [PATCH 3/3] pseries: Improve tracing of CPU compatibility negotiation

This makes some improvements to the debug tracepoints around the negotiation of CPU compatibility mode during CAS. The traces are reorganized to emphasise what the inputs and outputs of the process are, then distinguish the internal state of the two possible negotiation paths (current and pre-2.8

[Qemu-devel] [PATCH 1/3] pseries: Split CAS PVR negotiation out into a separate function

Guests of the qemu machine type go through a feature negotiation process known as "client architecture support" (CAS) during early boot. This does a number of things, one of which is finding a CPU compatibility mode which can be supported by both guest and host. In fact the CPU negotiation is

[Qemu-devel] [PATCH 0/3] pseries: Reverse behaviour change for older machine types

152ef80 "pseries: Rewrite CAS PVR compatibility logic" incorrectly introduced a guest-visible behaviour change into existing versioned machine type. Patch 2/2 corrects this change, while 1/2 is a preliminary clean up to make that easier. Unfortunately, this bug is already in the released

Re: [Qemu-devel] [PATCH v10] migration: spapr: migrate pending_events of spapr state

On Mon, May 15, 2017 at 10:26:46PM -0500, Michael Roth wrote: > Quoting Daniel Henrique Barboza (2017-05-15 08:10:52) > > From: Jianjun Duan > > > > In racing situations between hotplug events and migration operation, > > a rtas hotplug event could have not yet be

[Qemu-devel] [PATCH 2/3] pseries: Restore PVR negotiation logic for pre-2.9 machine types

"pseries" guests go through a hypervisor<->guest feature negotiation during early boot. Part of this is finding a CPU compatibility mode which works for both. In 152ef80 "pseries: Rewrite CAS PVR compatibility logic" this logic was changed to strongly prefer architecture defined CPU

Re: [Qemu-devel] [Qemu-ppc] [RFC 1/2] pseries: Split CAS PVR negotiation out into a separate function

On Wed, May 17, 2017 at 05:56:57PM +0200, Greg Kurz wrote: > On Wed, 17 May 2017 16:35:46 +1000 > David Gibson wrote: > > > Guests of the qemu machine type go through a feature negotiation process > > known as "client architecture support" (CAS) during early boot.

Re: [Qemu-devel] [RFC 0/2] pseries: Correct behaviour change for older machine types

On Wed, May 17, 2017 at 10:52:05AM +0200, Andrea Bolognani wrote: > On Wed, 2017-05-17 at 16:35 +1000, David Gibson wrote: > > 152ef80 "pseries: Rewrite CAS PVR compatibility logic" incorrectly > > introduced a guest-visible behaviour change into existing versioned > > machine type.  Patch 2/2

Re: [Qemu-devel] [Qemu-ppc] [PATCH v10] migration: spapr: migrate pending_events of spapr state

On Wed, May 17, 2017 at 05:31:44PM -0300, Daniel Henrique Barboza wrote: > > > On 05/16/2017 09:04 AM, Daniel Henrique Barboza wrote: > > > > > > On 05/16/2017 01:25 AM, David Gibson wrote: > > > On Mon, May 15, 2017 at 10:10:52AM -0300, Daniel Henrique Barboza wrote: > > > > From: Jianjun

Re: [Qemu-devel] (no subject)

Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] (no subject) Type: series Message-id: 536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log --oneline $BASE.. | wc

Re: [Qemu-devel] (no subject)

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. Subject: [Qemu-devel] (no subject) Type: series Message-id: 536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local === TEST SCRIPT

[Qemu-devel] (no subject)

>From 836daaff38940535548043f2e8f2e3df7a62d473 Mon Sep 17 00:00:00 2001 From: John Bradley Date: Wed, 17 May 2017 18:57:21 +0100 Subject: [PATCH] [PATCH] Add code to connect with https://github.com/flypie/GDummyPanel The code uses GNU Sockets & Windows sockets as on MINGW

Re: [Qemu-devel] [RFC PATCH v1 6/6] spapr: Fix migration of Radix guests

On Wed, May 17, 2017 at 05:20:31PM +1000, David Gibson wrote: > On Wed, May 17, 2017 at 12:45:39PM +0530, Bharata B Rao wrote: > > On Wed, May 17, 2017 at 05:00:49PM +1000, David Gibson wrote: > > > On Wed, May 17, 2017 at 09:19:22AM +0530, Bharata B Rao wrote: > > > > Fix migration of radix

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 00/16] Vhost-pci for inter-VM communication

On 05/17/2017 02:22 PM, Jason Wang wrote: On 2017年05月17日 14:16, Jason Wang wrote: On 2017年05月16日 15:12, Wei Wang wrote: Hi: Care to post the driver codes too? OK. It may take some time to clean up the driver code before post it out. You can first have a check of the draft at the

Re: [Qemu-devel] [Bug 1691379] [NEW] NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

On 17.05.2017 19:58, Kamil Rytarowski wrote: > On 17.05.2017 10:10, Thomas Huth wrote: >> On 17.05.2017 09:52, Utkarsh Anand wrote: >>> Public bug reported: >>> >>> I successfully installed the NetBSD evbmips64el port on gxemul but was >>> unable to install it on qemu. Trying to boot it on qemu

Re: [Qemu-devel] [PATCH v3 0/5] mc146818rtc: fix Windows VM clock faster

On 05/10/2017 05:53 PM, Paolo Bonzini wrote: On 10/05/2017 10:32, guangrong.x...@gmail.com wrote: From: Xiao Guangrong Changelog in v3: Thanks to Paolo's the elaborate review comments, this version simplifies the logic of periodic_timer_update() significantly

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

On 17.05.2017 18:26, Aurelien Jarno wrote: > On 2017-05-17 17:35, Thomas Huth wrote: >> Currently we only present the plain z900 feature bits to the guest, >> but QEMU already emulates some additional features (but not all of >> the next CPU generation, so we can not use the next CPU level as >>

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

On 17.05.2017 18:49, David Hildenbrand wrote: > On 17.05.2017 17:35, Thomas Huth wrote: >> Currently we only present the plain z900 feature bits to the guest, >> but QEMU already emulates some additional features (but not all of >> the next CPU generation, so we can not use the next CPU level as

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote: > Also available at > > https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0 > > Following suggestions split my original patch up. This the largest monolithic > chunk is >

[Qemu-devel] [PATCH 1/1] Improve Cocoa modifier key handling

On May 13, 2017, at 11:58 AM, qemu-devel-requ...@nongnu.org wrote: I had two problems with QEMU on macOS: 1) Sometimes when alt-tabbing to QEMU it would act as if the 'a' key was pressed so I'd get 'a'. 2) Using Sikuli to programatically send keys to the QEMU window text

Re: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes

On Wed, May 17, 2017 at 03:29:33PM -0700, no-re...@patchew.org wrote: > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Message-id: 1495057396-13387-1-git-send-email-...@redhat.com > Subject: [Qemu-devel] [PULL 00/13] pci, virtio, vhost:

Re: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 1495057396-13387-1-git-send-email-...@redhat.com Subject: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

On Wed, May 17, 2017 at 05:00:29PM -0500, Eric Blake wrote: > On 05/17/2017 04:25 PM, Eduardo Habkost wrote: > > Currently there's no way for QMP clients to get a list of device types > > that are really usable with -device. This information would be useful > > for management software and test

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

On 05/17/2017 04:25 PM, Eduardo Habkost wrote: > Currently there's no way for QMP clients to get a list of device types > that are really usable with -device. This information would be useful > for management software and test scripts (like the device-crash-test > script I have submitted

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

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. Message-id: 20170517212547.4767-1-ehabk...@redhat.com Subject: [Qemu-devel] [RFC] qmp: Return 'user_creatable' &

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

On 05/17/2017 04:25 PM, John Bradley wrote: > Well unfortunately Eric. I don't understand your "top posted" slang. To learn what top-posting is: http://lmgtfy.com/?q=what+is+top-posting and why we don't like it on technical lists: http://www.caliburn.nl/topposting.html Or more humorously: A:

[Qemu-devel] [PULL 06/13] pc: add 2.10 machine type

From: Peter Xu CC: "Michael S. Tsirkin" CC: Paolo Bonzini CC: Richard Henderson CC: Eduardo Habkost Signed-off-by: Peter Xu Reviewed-by: Eduardo Habkost

[Qemu-devel] [PULL 13/13] exec: abstract address_space_do_translate()

From: Peter Xu This function is an abstraction helper for address_space_translate() and address_space_get_iotlb_entry(). It does the lookup of address into memory region section, then does proper IOMMU translation if necessary. Refactor the two existing functions to use it.

Re: [Qemu-devel] [Qemu-block] [PATCH 07/18] throttle-groups: only start one coroutine from drained_begin

On Thu 11 May 2017 04:41:57 PM CEST, Paolo Bonzini wrote: > Starting all waiting coroutines from bdrv_drain_all is unnecessary; > throttle_group_co_io_limits_intercept calls schedule_next_request as > soon as the coroutine restarts, which in turn will restart the next > request if possible. > > If

[Qemu-devel] [PULL 09/13] acpi-defs: clean up open brace usage

patchew has been saying: ERROR: open brace '{' following struct go on the same line Fix up acpi-defs.h to follow this rule. Signed-off-by: Michael S. Tsirkin --- include/hw/acpi/acpi-defs.h | 34 -- 1 file changed, 12 insertions(+), 22

[Qemu-devel] [PULL 11/13] virtio: allow broken device to notify guest

From: Greg Kurz According to section 2.1.2 of the virtio-1 specification: "The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET, the device MUST send a device configuration change

[Qemu-devel] [PULL 08/13] ACPI: don't call acpi_pcihp_device_plug_cb on xen

From: Bruce Rogers Commit f0c9d64a exposed the issue that with a xenfv machine using pci passthrough, acpi pci hotplug code was being executed by mistake. Guard calls to acpi_pcihp_device_plug_cb (and corresponding acpi_pcihp_device_unplug_cb) with a check for xen_enabled().

[Qemu-devel] [PULL 12/13] pci: deassert intx when pci device unrealize

From: "Herongguang (Stephen)" If a pci device is not reset by VM (by writing into config space) and unplugged by VM, after that when VM reboots, qemu may assert: pcibus_reset: Assertion `bus->irq_count[i] == 0' failed Cc: qemu-sta...@nongnu.org Signed-off-by:

[Qemu-devel] [PULL 02/13] hw/arm/virt: generate 64-bit addressable ACPI objects

From: Ard Biesheuvel Our current ACPI table generation code limits the placement of ACPI tables to 32-bit addressable memory, in order to be able to emit the root pointer (RSDP) and root table (RSDT) using table types from the ACPI 1.0 days. Since ARM was not

[Qemu-devel] [PULL 07/13] iommu: Don't crash if machine is not PC_MACHINE

From: Eduardo Habkost Currently it's possible to crash QEMU using "-device *-iommu" and "-machine none": $ qemu-system-x86_64 -machine none -device amd-iommu qemu/hw/i386/amd_iommu.c:1140:amdvi_realize: Object 0x55627dafbc90 is not an instance of type

[Qemu-devel] [PULL 03/13] hw/virtio: fix vhost user fails to startup when MQ

From: Zhiyong Yang Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together to cause failures of new connection when negotiating to set MQ. (one queue pair works well). Because there exist some bugs in qemu code when introducing VHOST_USER_PROTOCOL_F_REPLY_ACK

[Qemu-devel] [PULL 10/13] Revert "hw/pci: disable pci-bridge's shpc by default"

From: Marcel Apfelbaum This reverts commit dc0ae767700c156894e36fab89a745a2dc4173de. Disabling the shpc controller has an undesired side effect. The PCI bridge remains with no attached devices at boot time, and the guest operating systems do not allocate any resources for it,

[Qemu-devel] [PULL 05/13] pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 during firmware boot

From: Igor Mammedov Since 2.7 commit (b2a575a Add optionrom compatible with fw_cfg DMA version) regressed migration during firmware exection time by abusing fwcfg.dma_enabled property to decide loading dma version of option rom AND by mistake disabling DMA for 2.6 and

[Qemu-devel] [PULL 04/13] libvhost-user: fix crash when rings aren't ready

From: Marc-André Lureau Calling libvhost-user functions like vu_queue_get_avail_bytes() when the queue doesn't yet have addresses will result in the crashes like the following: Program received signal SIGSEGV, Segmentation fault. 0x55c414112ce4 in

[Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes

This includes the previous pull request which still does not appear to be in - not rebased so merging twice will not cause conflicts. Note that patch 08 makes checkpatch complain, patch 9 fixes that. The following changes since commit 76d20ea0f1b26ebd5da2f5fb2fdf3250cde887bb: Merge

[Qemu-devel] [PULL 01/13] hw/acpi-defs: replace leading X with x_ in FADT field names

From: Ard Biesheuvel At the request of Michael, replace the leading capital X in the FADT field name Xfacs and Xdsdt with lower case x + underscore. Cc: Michael S. Tsirkin Signed-off-by: Ard Biesheuvel Reviewed-by: Laszlo

Re: [Qemu-devel] [PULL 0/9] pci, virtio, vhost: fixes

On Mon, May 15, 2017 at 04:04:33PM +0300, Michael S. Tsirkin wrote: > On Mon, May 15, 2017 at 01:58:40PM +0100, Stefan Hajnoczi wrote: > > On Wed, May 10, 2017 at 10:07:58PM +0300, Michael S. Tsirkin wrote: > > > The following changes since commit > > > 76d20ea0f1b26ebd5da2f5fb2fdf3250cde887bb: >

Re: [Qemu-devel] [PATCH V2] Revert "hw/pci: disable pci-bridge's shpc by default"

On Thu, May 11, 2017 at 01:25:29PM +0300, Marcel Apfelbaum wrote: > This reverts commit dc0ae767700c156894e36fab89a745a2dc4173de. > > Disabling the shpc controller has an undesired side effect. > The PCI bridge remains with no attached devices at boot time, > and the guest operating systems do

Re: [Qemu-devel] [PATCH] Add BCM2835 devices to Arm hardware.

On 05/17/2017 04:05 PM, John Bradley via Qemu-devel wrote: >>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001 > From: John Bradley > Date: Wed, 17 May 2017 18:57:21 +0100 > Subject: [PATCH] Add BCM2835 devices to Arm hardware. > The subject line is

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

On Wed, May 17, 2017 at 02:28:25PM -0700, no-re...@patchew.org wrote: [...] > CC qmp.o > CC hmp.o > /var/tmp/patchew-tester-tmp-3wn9eneh/src/qmp.c: In function > ‘qom_list_types_tramp’: > /var/tmp/patchew-tester-tmp-3wn9eneh/src/qmp.c:452:22: error: ‘DeviceClass > {aka struct

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

Well unfortunately Eric. I don't understand your "top posted" slang. As for his "intent", it is quite irrelevant as I have gone over the code line by line and what every he intended to do, he has succeed, as far as I can tell , in matching you standards, to such an extent that I am happy that

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

Hi, This series failed build test on s390x host. Please find the details below. Message-id: 20170517212547.4767-1-ehabk...@redhat.com Type: series Subject: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types === TEST SCRIPT BEGIN === #!/bin/bash # Testing

[Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

Currently there's no way for QMP clients to get a list of device types that are really usable with -device. This information would be useful for management software and test scripts (like the device-crash-test script I have submitted recently). Interestingly, the "info qdm" HMP command provides

Re: [Qemu-devel] [PATCH] Add BCM2835 devices to Arm hardware.

On 05/17/2017 04:05 PM, John Bradley via Qemu-devel wrote: >>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001 > From: John Bradley > Date: Wed, 17 May 2017 18:57:21 +0100 > Subject: [PATCH] Add BCM2835 devices to Arm hardware. > > Signed-off-by: John

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

On 05/17/2017 03:53 PM, John Bradley wrote: > Andrew Baumann has and others have release the code under GNU General Public > License version 2 (GPLv2), the same as QEMU that allows me to added it to > QEMU as it is under the same license, by signing it off this is what I am > certifying. See

[Qemu-devel] [PATCH] Add BCM2835 devices to Arm hardware.

>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001 From: John Bradley Date: Wed, 17 May 2017 18:57:21 +0100 Subject: [PATCH] Add BCM2835 devices to Arm hardware. Signed-off-by: John Bradley --- hw/arm/bcm2835.c | 114

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

Andrew Baumann has and others have release the code under GNU General Public License version 2 (GPLv2), the same as QEMU that allows me to added it to QEMU as it is under the same license, by signing it off this is what I am certifying.  John BradleyTel: 07896 839635Skype: flypie125 125B Grove

Re: [Qemu-devel] [PATCH 0/3] block: fix 'savevm' hang with -object iothread

- Original Message - > From: "Stefan Hajnoczi" > To: qemu-devel@nongnu.org > Cc: "Kevin Wolf" , "Paolo Bonzini" , > "Fam Zheng" , "Stefan > Hajnoczi" , qemu-bl...@nongnu.org > Sent:

Re: [Qemu-devel] [PATCH 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()

> I'm surprised at how many separate hangs we actually had! Note that I have seen quite a few before, though I am not sure about the details and the reproducibility. The release/acquire was hidden behind RFifoLock contention callbacks instead of BDRV_POLL_WHILE. Paolo > > > > Signed-off-by:

Re: [Qemu-devel] [PATCH 6/6] spapr: fix migration of ICP objects from/to older QEMU

On Wed, 17 May 2017 14:18:16 +1000 David Gibson wrote: > On Mon, May 15, 2017 at 06:11:27PM +0200, Cédric Le Goater wrote: > > >>> +int smt = kvmppc_smt_threads(); > > >>> +int nr_servers = DIV_ROUND_UP(max_cpus * smt, smp_threads); > > >> > > >> may

Re: [Qemu-devel] [Qemu-ppc] [PATCH v10] migration: spapr: migrate pending_events of spapr state

On 05/16/2017 09:04 AM, Daniel Henrique Barboza wrote: On 05/16/2017 01:25 AM, David Gibson wrote: On Mon, May 15, 2017 at 10:10:52AM -0300, Daniel Henrique Barboza wrote: From: Jianjun Duan In racing situations between hotplug events and migration operation, a

Re: [Qemu-devel] [PATCH 3/3] migration: avoid recursive AioContext locking in save_vmstate()

On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote: > AioContext was designed to allow nested acquire/release calls. It uses > a recursive mutex so callers don't need to worry about nesting...or so > we thought. > > BDRV_POLL_WHILE() is used to wait for block I/O requests. It releases > the

Re: [Qemu-devel] [PATCH 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()

On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote: > Calling aio_poll() directly may have been fine previously, but this is > the future, man! lol > The difference between an aio_poll() loop and > BDRV_POLL_WHILE() is that BDRV_POLL_WHILE() releases the AioContext > around aio_poll(). > > This

Re: [Qemu-devel] [PATCH 1/3] block: count bdrv_co_rw_vmstate() requests

On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote: > Call bdrv_inc/dec_in_flight() for vmstate reads/writes. This seems > unnecessary at first glance because vmstate reads/writes are done > synchronously while the guest is stopped. But we need the bdrv_wakeup() > in bdrv_dec_in_flight() so the main

Re: [Qemu-devel] [PATCH 2/2] postcopy: Require RAMBlocks that are whole pages

"Dr. David Alan Gilbert (git)" wrote: > From: "Dr. David Alan Gilbert" > > It turns out that it's legal to create a VM with RAMBlocks that aren't > a multiple of the pagesize in use; e.g. a 1025M main memory using > 2M host pages. That breaks postcopy's

Re: [Qemu-devel] [PATCH 1/2] migration: Fix non-multiple of page size migration

"Dr. David Alan Gilbert (git)" wrote: > From: "Dr. David Alan Gilbert" > > Unfortunately it's legal to create a VM with a RAM size that's > not a multiple of the underlying host page or huge page size. > Recently I'd changed things to always send host

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

On 05/17/2017 01:34 PM, John Bradley wrote: > This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann) Top-posting is not nice on technical lists. > 0xabu (Andrew Baumann) > 0xabu has 3 repositories available. Follow their code on GitHub. | | Using github requires the use of

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

On 05/17/2017 02:27 PM, Eric Blake wrote: > On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote: >> Also available at >> >> https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0 > > This content belongs... > >> >> Following

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann) | | | | || | | | || 0xabu (Andrew Baumann) 0xabu has 3 repositories available. Follow their code on GitHub. | | | |  John BradleyTel: 07896 839635Skype: flypie125 125B Grove

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote: > Also available at > > https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0 This content belongs... > > Following suggestions split my original patch up. This the largest

[Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

Also available at https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0 Following suggestions split my original patch up. This the largest monolithic chunk is additional BCM device support from Markus Armbruster. >From

[Qemu-devel] [PULL 3/3] ramblock: add new hmp command "info ramblock"

From: Peter Xu To dump information about ramblocks. It looks like: (qemu) info ramblock Block NamePSize Offset Used Total /objects/mem2 MiB 0x 0x8000 0x8000

[Qemu-devel] [PULL 2/3] utils: provide size_to_str()

From: Peter Xu Moving the algorithm from print_type_size() into size_to_str() so that other component can also leverage it. With that, refactor print_type_size(). The assert() in that logic is removed though, since even UINT64_MAX would not overflow. Signed-off-by: Peter Xu

[Qemu-devel] [PULL 0/3] hmp queue

it tags/pull-hmp-20170517 for you to fetch changes up to be9b23c4a539090da30b482015ee660850e8bb5f: ramblock: add new hmp command "info ramblock" (2017-05-17 17:31:16 +0100) ---

[Qemu-devel] [PULL 1/3] ramblock: add RAMBLOCK_FOREACH()

From: Peter Xu So that it can simplifies the iterators. Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Peter Xu Message-Id: <1494562661-9063-2-git-send-email-pet...@redhat.com> Signed-off-by: Dr. David Alan Gilbert

Re: [Qemu-devel] [Bug 1691379] [NEW] NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

On 17.05.2017 10:10, Thomas Huth wrote: > On 17.05.2017 09:52, Utkarsh Anand wrote: >> Public bug reported: >> >> I successfully installed the NetBSD evbmips64el port on gxemul but was >> unable to install it on qemu. Trying to boot it on qemu takes me to the >> 'db>' prompt. Here's the output and

Re: [Qemu-devel] [PATCH 13/17] qdev: use appropriate getter/setters type

Marc-André Lureau writes: > Based on underlying property type, use the appropriate getters/setters. How did you find the ones that need changing? > Signed-off-by: Marc-André Lureau > --- > hw/i386/acpi-build.c | 12 ++-- >

Re: [Qemu-devel] [PATCH v2] ui: egl-headless requires dmabuf support

On 05/17/2017 09:27 AM, Gerd Hoffmann wrote: Reported-by: Thomas Huth Signed-off-by: Gerd Hoffmann Reviewed-by: Philippe Mathieu-Daudé --- vl.c | 4 ++-- ui/Makefile.objs | 2 +- 2 files changed, 3 insertions(+), 3

Re: [Qemu-devel] [PATCH v2] .gdbinit: load QEMU sub-commands when gdb starts

On 05/17/2017 09:40 AM, Stefan Hajnoczi wrote: The scripts/qemu-gdb.py file is not easily discoverable. Add a .gdbinit file so GDB either loads qemu-gdb.py automatically or prints a message informing the user how to enable them (some systems disable ./.gdbinit loading for security reasons).

Re: [Qemu-devel] [PATCH v4 2/3] net/rocker: Plug memory leak in pci_rocker_init()

Hi Mao, On 05/17/2017 08:12 AM, Mao Zhongyi wrote: pci_rocker_init() leaks a World when the name more than 9 chars, then return a negative value directly, doesn't make a correct cleanup. So add a new goto label to fix it. Cc: jasow...@redhat.com Cc: j...@resnulli.us Cc: f4...@amsat.org Cc:

[Qemu-devel] [PATCH 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()

Calling aio_poll() directly may have been fine previously, but this is the future, man! The difference between an aio_poll() loop and BDRV_POLL_WHILE() is that BDRV_POLL_WHILE() releases the AioContext around aio_poll(). This allows the IOThread to run fd handlers or BHs to complete the request.

[Qemu-devel] [PATCH 1/3] block: count bdrv_co_rw_vmstate() requests

Call bdrv_inc/dec_in_flight() for vmstate reads/writes. This seems unnecessary at first glance because vmstate reads/writes are done synchronously while the guest is stopped. But we need the bdrv_wakeup() in bdrv_dec_in_flight() so the main loop sees request completion. Besides, it's cleaner to

[Qemu-devel] [PATCH 0/3] block: fix 'savevm' hang with -object iothread

The 'savevm' command hangs when -object iothread is used. See patches for details, but basically the vmstate read/write code didn't conform to the latest block layer locking rules. Stefan Hajnoczi (3): block: count bdrv_co_rw_vmstate() requests block: use BDRV_POLL_WHILE() in

[Qemu-devel] [PATCH 3/3] migration: avoid recursive AioContext locking in save_vmstate()

AioContext was designed to allow nested acquire/release calls. It uses a recursive mutex so callers don't need to worry about nesting...or so we thought. BDRV_POLL_WHILE() is used to wait for block I/O requests. It releases the AioContext temporarily around aio_poll(). This gives IOThreads a

Re: [Qemu-devel] [PATCH v4 4/4] fsdev: QMP interface for throttling

On 05/17/2017 11:29 AM, Greg Kurz wrote: >> >> First point: is fsdev a Linux-only feature, or can it be compiled on >> BSD? If it is Linux-only, then compiling a stub for Windows will still >> leave BSD broken, and your #ifdef is wrong. Fixing compilation on mingw >> is nice, but not the only

Re: [Qemu-devel] [PATCH v1] target/s390x: Add support for the TEST BLOCK instruction

On 17.05.2017 18:05, Thomas Huth wrote: > On 16.05.2017 21:06, Richard Henderson wrote: >> On 05/16/2017 02:28 AM, Thomas Huth wrote: >>> +void HELPER(testblock)(CPUS390XState *env, uint64_t addr) >>> +{ >>> +CPUState *cs = CPU(s390_env_get_cpu(env)); >>> +int i; >>> + >>> +addr =

Re: [Qemu-devel] [PATCH 2/5] migration: Create block capability

Eric Blake wrote: > On 05/17/2017 10:38 AM, Juan Quintela wrote: >> Create one capability for block migration and one parameter for >> incremental block migration. >> >> Signed-off-by: Juan Quintela >> >> --- >> >> @@ -1207,6 +1242,26 @@ void

Re: [Qemu-devel] [PATCH] Memory: use memory address space for cpu-memory

> > If cpu-memory address space is same as memory address space, > > use memory address space for cpu-memory address space. > > > > any memory region change causeaddress space to rebuild PhysPageMap, > > rebuilding PhysPageMap is very expensive. > > > > removing cpu-memory address space reduces

[Qemu-devel] [PATCH 2/2] postcopy: Require RAMBlocks that are whole pages

From: "Dr. David Alan Gilbert" It turns out that it's legal to create a VM with RAMBlocks that aren't a multiple of the pagesize in use; e.g. a 1025M main memory using 2M host pages. That breaks postcopy's atomic placement of pages, so disallow it. Signed-off-by: Dr. David

[Qemu-devel] [PATCH 1/2] migration: Fix non-multiple of page size migration

From: "Dr. David Alan Gilbert" Unfortunately it's legal to create a VM with a RAM size that's not a multiple of the underlying host page or huge page size. Recently I'd changed things to always send host sized pages, and that breaks if we have say a 1025MB guest on 2MB

[Qemu-devel] [PATCH 0/2] Migration+huge page fixes

From: "Dr. David Alan Gilbert" Hi, The attached patch-pair fix migration in the case where you are using huge pages but you have a RAM size which is not a multiple of the huge page size. It's unfortunately legal so there might be VMs out there that already have it, and it

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

On 17.05.2017 17:35, Thomas Huth wrote: > Currently we only present the plain z900 feature bits to the guest, > but QEMU already emulates some additional features (but not all of > the next CPU generation, so we can not use the next CPU level as > default yet). Since newer Linux kernels are

Re: [Qemu-devel] [PATCH 6/6] spec/vhost-user spec: Add IOMMU support

On Thu, May 11, 2017 at 02:32:46PM +0200, Maxime Coquelin wrote: > This patch specifies and implements the master/slave communication > to support device IOTLB in slave. > > The vhost_iotlb_msg structure introduced for kernel backends is > re-used, making the design close between the two

Re: [Qemu-devel] [PATCH 3/6] vhost: Update rings information for IOTLB earlier

On Fri, May 12, 2017 at 01:21:18PM +0200, Maxime Coquelin wrote: > > > On 05/11/2017 07:33 PM, Michael S. Tsirkin wrote: > > On Thu, May 11, 2017 at 02:32:43PM +0200, Maxime Coquelin wrote: > > > Vhost-kernel backend need to receive IOTLB entries for rings > > > information early, but vhost-user

Re: [Qemu-devel] [Qemu-ppc] [RFC 2/2] pseries: Restore PVR negotiation logic for pre-2.9 machine types

On Wed, 17 May 2017 16:35:47 +1000 David Gibson wrote: > "pseries" guests go through a hypervisor<->guest feature negotiation during > early boot. Part of this is finding a CPU compatibility mode which works > for both. > > In 152ef80 "pseries: Rewrite CAS PVR

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

On 2017-05-17 17:35, Thomas Huth wrote: > Currently we only present the plain z900 feature bits to the guest, > but QEMU already emulates some additional features (but not all of > the next CPU generation, so we can not use the next CPU level as > default yet). Since newer Linux kernels are

Re: [Qemu-devel] [PATCH v8 0/3] ramblock: add hmp command "info ramblock"

* Peter Xu (pet...@redhat.com) wrote: > v8: Queued for HMP > - patch 1: add r-b for Dave > - patch 2: use "uint64_t" for size_to_str() parameter, remove assert() > since it's useless now [Dave] > - drop patch 4 > > v7: > - patch 1: removed Dave's r-b since the patch conflicted during rebase

Re: [Qemu-devel] [PATCH v4 4/4] fsdev: QMP interface for throttling

On Wed, 17 May 2017 10:28:33 -0500 Eric Blake wrote: > On 05/17/2017 09:53 AM, Pradeep Jagadeesh wrote: > > >>> +#ifdef _WIN64 > >>> + > >>> +void qmp_fsdev_set_io_throttle(IOThrottle *arg, Error **errp) > >>> +{ > >>> + return; > >>> +} > >>> + > >>> +IOThrottleList

Re: [Qemu-devel] [PATCH 08/17] qapi: update the qobject visitor to use QUInt

Markus Armbruster writes: > On the subject: there is no such thing as "QUInt". I guess you mean > "uint type" (like in PATCH 06's subject). Could also say "QNUM_U64". > > Apropos subject: humor me, and start your subjects with a capital > letter, like this: > > qapi:

Re: [Qemu-devel] [PATCH 3/5] migration: Remove use of old MigrationParams

Eric Blake wrote: > On 05/17/2017 10:38 AM, Juan Quintela wrote: >> We have change in the previous patch to use migration capabilities for >> it. Notice that we continue using the old command line flags from >> migrate command from the time being. Remove the set_params method

[Qemu-devel] [PATCH 2/2] migration: Make savevm.c target independent

It only needed TARGET_PAGE_SIZE/BITS/BITS_MIN values, so just export them from exec.h Signed-off-by: Juan Quintela --- Makefile.target| 2 +- exec.c | 9 + include/exec/target_page.h | 2 ++ migration/Makefile.objs| 2 +-

Re: [Qemu-devel] [PATCH 9/9] migration: migration.h was not needed

* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: > * Juan Quintela (quint...@redhat.com) wrote: > > This files don't use any function from migration.h, so drop it. > > > > Signed-off-by: Juan Quintela > > Acked-by: Dr. David Alan Gilbert Oops, I

[Qemu-devel] [PATCH 1/2] exec: Create include for target_page_size()

That is the only function that we need from exec.c, and having to include the whole sysemu.h for this. Signed-off-by: Juan Quintela --- exec.c | 1 + include/exec/target_page.h | 20 include/sysemu/sysemu.h| 1 -

Re: [Qemu-devel] [PATCH 5/9] migration: Move qjson.h to migration/

* Juan Quintela (quint...@redhat.com) wrote: > It is only used for migration code. > > Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert > --- > migration/qjson.c| 2 +- > {include/migration =>

[Qemu-devel] [PATCH 0/2] Make migration/ram.c target independent

Hi Only reason that ram.c is compiled by target is because it use TARGET_PAGE_BITS. As we already have a function to export TARGET_PAGE_SIZE, do the same. After this, we can make it target independent. Please, review. Later, Juan. Juan Quintela (2): exec: Create include for

Re: [Qemu-devel] [PATCH v1] target/s390x: Add support for the TEST BLOCK instruction

On 16.05.2017 21:06, Richard Henderson wrote: > On 05/16/2017 02:28 AM, Thomas Huth wrote: >> +void HELPER(testblock)(CPUS390XState *env, uint64_t addr) >> +{ >> +CPUState *cs = CPU(s390_env_get_cpu(env)); >> +int i; >> + >> +addr = get_address(env, 0, 0, addr) & ~0xfffULL; >> +for

  1   2   3   >