Re: [Qemu-devel] [PATCH v2 5/5] block: qemu-iotests: make test 019 and 086 work with spaced pathnames

On Wed, 04/09 22:41, Jeff Cody wrote: > Both tests 019 and 086 need proper quotations to work with pathnames > that contain spaces. > > Signed-off-by: Jeff Cody > --- > tests/qemu-iotests/019 | 2 +- > tests/qemu-iotests/086 | 8 > 2 files changed, 5 insertions(+), 5 deletions(-) > > d

Re: [Qemu-devel] [PATCH v2 4/5] block: qemu-iotests - fix image cleanup when using spaced pathnames

On Wed, 04/09 22:41, Jeff Cody wrote: > The _rm_test_img() function in common.rc did not quote the image > file, which left droppings in the scratch directory (and performed > a potentially unsafe rm -f). > > This adds the necessary quotes. > > Signed-off-by: Jeff Cody > --- > tests/qemu-iotest

[Qemu-devel] [PATCH 01/16] cutils: tighten qemu_parse_fd()

qemu_parse_fd() used to handle at least the following strings incorrectly: o "-2": simply let through o "2147483648": returned as LONG_MAX==INT_MAX on ILP32 (with ERANGE ignored); implementation-defined behavior on LP64 Signed-off-by: Laszlo Ersek --- util/cutils.c | 13 +

[Qemu-devel] [PATCH 07/16] pci: add Error-propagating pci_add_capability2()

... and rebase pci_add_capability() to it. Signed-off-by: Laszlo Ersek --- include/hw/pci/pci.h | 4 hw/pci/pci.c | 32 ++-- 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h index 693dd6b..8c25ae

[Qemu-devel] [PATCH 02/16] monitor: add Error-propagating monitor_handle_fd_param2()

and rebase monitor_handle_fd_param() to it. (Note that this will slightly change the behavior when the qemu_parse_fd() branch is selected and it fails: we now report (and in case of QMP, set) the error immediately, rather than allowing the caller to set its own error message (if any)). Signed-off-

[Qemu-devel] [PATCH 00/16] PCI device assignment: improve error reporting over QMP

This is for . In general, we want to propagate non-fatal (ie. non-exit()ing, non-abort()ing) errors to the QMP caller, rather than printing them on-site. The series focuses on errors raised at PCI assignment time (ie. reachable from assigned_init

[Qemu-devel] [PATCH 08/16] pci-assign: accept Error from pci_add_capability2()

Propagate any errors while adding PCI capabilities to assigned_device_pci_cap_init(). We'll continue the propagation upwards when assigned_device_pci_cap_init() becomes a leaf itself (when none of its callees will report errors internally any longer when detecting and returning them). Signed-off-b

[Qemu-devel] [PATCH 11/16] pci-assign: propagate errors from assigned_device_pci_cap_init()

Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 45 +++-- 1 file changed, 19 insertions(+), 26 deletions(-) diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index c6d1094..2de6559 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i3

[Qemu-devel] [PATCH 03/16] pci-assign: accept Error from monitor_handle_fd_param2()

Propagate any errors in monitor fd handling up to get_real_device(), and report them there. We'll continue the propagation upwards when get_real_device() becomes a leaf itself (when none of its callees will report errors internally any longer when detecting and returning an error). Signed-off-by:

[Qemu-devel] [PATCH 06/16] pci-assign: propagate Error from check_irqchip_in_kernel()

Rename check_irqchip_in_kernel() to verify_irqchip_in_kernel(), so that the name reflects our expectation better. Rather than returning a bool, make it do nothing or set an Error. Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 25 + 1 file changed, 17 insertio

[Qemu-devel] [PATCH 04/16] pci-assign: make assign_failed_examine() just format the cause

This allows us to report the entire error with one error_report() call, easing future error propagation. Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 30 +++--- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/hw/i386/kvm/pci-assign.c b/hw/i38

[Qemu-devel] [PATCH 15/16] pci-assign: propagate errors from assign_intx()

Among the callers, only assigned_initfn() should set the monitor's stored error. Other callers may run in contexts where the monitor's stored error makes no sense. For example: assigned_dev_pci_write_config() assigned_dev_update_msix() assign_intx() Signed-off-by: Laszlo Ersek --- hw/i38

[Qemu-devel] [PATCH 12/16] pci-assign: propagate errors from assigned_dev_register_msix_mmio()

The return type is also changed from "int" to "void", because it was used in a success vs. failure sense only (the caller didn't distinguish error codes from each other, and even assigned_dev_register_msix_mmio() masked mmap()'s errno values with a common -EFAULT). Signed-off-by: Laszlo Ersek ---

[Qemu-devel] [PATCH 09/16] pci-assign: assignment should fail if we can't read config space

assigned_initfn() get_real_device() read() Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index f91d4fb..e89bb6a 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i386/kvm/pci-ass

[Qemu-devel] [PATCH 10/16] pci-assign: propagate errors from get_real_device()

Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index e89bb6a..c6d1094 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i386/kv

[Qemu-devel] [PATCH 05/16] pci-assign: propagate errors from get_real_id()

get_real_id() has two thin wrappers (and no other callers), get_real_vendor_id() and get_real_device_id(); it's easiest to convert them in one fell swoop. Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 45 +++-- 1 file changed, 27 insertions(+)

[Qemu-devel] [PATCH 13/16] pci-assign: propagate errors from assigned_dev_register_regions()

Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index 3a904e8..9aa92a1 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i386/kvm/pci-assign.c @@

[Qemu-devel] [PATCH 14/16] pci-assign: propagate errors from assign_device()

Also, change the return type to "void"; the function is static (with a sole caller) and the negative errno values are not distinguished from each other. Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-)

[Qemu-devel] [PATCH 16/16] pci-assign: assigned_initfn(): set monitor error in common error handler

Signed-off-by: Laszlo Ersek --- hw/i386/kvm/pci-assign.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c index 6891729..e55421a 100644 --- a/hw/i386/kvm/pci-assign.c +++ b/hw/i386/kvm/pci-assign.c

Re: [Qemu-devel] [PATCH v2 5/6] qemu-img: Specify backing file for commit

On Tue, 04/08 14:50, Max Reitz wrote: > Introduce a new parameter for qemu-img commit which may be used to > explicitly specify the backing file unto which an image should be > committed if the backing chain has more than a single layer. > > Signed-off-by: Max Reitz > --- > qemu-img-cmds.hx | 4

[Qemu-devel] [PATCHES] add virtio input device

Hi, Here comes a bunch of patches inplementing the virtio input device for review. One patch for the virtio specification. One patch for the linux kernel. A small patch series for qemu. Please review. Note that the qemu patch series has dependencies on unmerged input layer patches (waiting

[Qemu-devel] [PATCH spec] Add virtio input device specification

Signed-off-by: Gerd Hoffmann --- content.tex | 2 + virtio-input.tex | 135 +++ 2 files changed, 137 insertions(+) create mode 100644 virtio-input.tex diff --git a/content.tex b/content.tex index c31a99e..196950d 100644 --- a/content.te

[Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices

This patch adds the virtio-input-hid base class and virtio-{keyboard,mouse,tablet} subclasses building on the base class. They are hooked up to the qemu input core and deliver input events to the guest like all other hid devices (ps/2 kbd, usb tablet, ...). Using them is as simple as adding "-devi

[Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class

This patch adds virtio-input support to qemu. It brings a abstract base class providing core support, other classes can build on it to actually implement input devices. virtio-input basically sends linux input layer events (evdev) over virtio. Signed-off-by: Gerd Hoffmann --- hw/input/Makefile

[Qemu-devel] [PATCH qemu 1/6] pci: add virtio input pci device id

Using 0x1012 because virtio id is 18 (0x12). Signed-off-by: Gerd Hoffmann --- docs/specs/pci-ids.txt | 1 + include/hw/pci/pci.h | 1 + 2 files changed, 2 insertions(+) diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt index 3c65e1a..3b0a448 100644 --- a/docs/specs/pci-ids.txt +++

Re: [Qemu-devel] QEMU: PCI bus name on PowerPC platforms

On Wed, Mar 05, 2014 at 03:33:39PM +0100, Paolo Bonzini wrote: > Il 05/03/2014 15:21, Daniel P. Berrange ha scritto: > >>alpha/typhoon.c:b = pci_register_bus(dev, "pci", > >>mips/gt64xxx_pci.c: phb->bus = pci_register_bus(dev, "pci", > >>pci-host/apb.c:phb->bus = pci_register_bus(DEVICE

[Qemu-devel] [PATCH linux] Add virtio-input driver.

virtio-input is basically evdev-events-over-virtio, so this driver isn't much more than forwarding incoming events to the linux input layer. Signed-off-by: Gerd Hoffmann --- drivers/virtio/Kconfig| 10 ++ drivers/virtio/Makefile | 1 + drivers/virtio/virtio_input.c |

[Qemu-devel] [PATCH qemu 6/6] virtio-input: evdev passthrough

This allows to assign host input devices to the guest: qemu -device virto-input-host-pci,evdev=/dev/input/event The guest gets exclusive access to the input device, so be careful with assigning the keyboard if you have only one connected to your machine. Signed-off-by: Gerd Hoffmann --- hw/inp

[Qemu-devel] [PATCH qemu 5/6] virtio-input: control device

Device for sending non-input control messages to the guest. For now this is only a single event: shutdown requests are sent as power button press to the guest. Possible other use is signaling sound volume changes to the guest (via EV_ABS / ABS_VOLUME). I expect we'll find more over time. Signed

[Qemu-devel] [PATCH qemu 2/6] pci: add virtio gpu pci device id

Using 0x1010 because virtio id is 16 (0x10). Signed-off-by: Gerd Hoffmann --- docs/specs/pci-ids.txt | 1 + include/hw/pci/pci.h | 1 + 2 files changed, 2 insertions(+) diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt index 3b0a448..69a2de9 100644 --- a/docs/specs/pci-ids.txt +++

Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/2] QEMU Monitor Instruction Disassembly Incorrect for PPC LE

On 09.04.14 21:53, Tom Musta wrote: Fix disassembly in the QEMU monitor for Little Endian codes. Also fix the comment and tighten up a flag check in the closely related disassembler code for tracing. V2: Fixed target_disas comment and bit decoding. V3: Make monitor_disas flag documentation re

Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/2] QEMU Monitor Instruction Disassembly Incorrect for PPC LE

On 10.04.14 12:12, Alexander Graf wrote: On 09.04.14 21:53, Tom Musta wrote: Fix disassembly in the QEMU monitor for Little Endian codes. Also fix the comment and tighten up a flag check in the closely related disassembler code for tracing. V2: Fixed target_disas comment and bit decoding. V

Re: [Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices

On Thu, Apr 10, 2014 at 11:07:52AM +0200, Gerd Hoffmann wrote: > This patch adds the virtio-input-hid base class and > virtio-{keyboard,mouse,tablet} subclasses building on the base class. > They are hooked up to the qemu input core and deliver input events > to the guest like all other hid devices

Re: [Qemu-devel] [PATCH qemu 6/6] virtio-input: evdev passthrough

On Thu, Apr 10, 2014 at 11:07:54AM +0200, Gerd Hoffmann wrote: > This allows to assign host input devices to the guest: > > qemu -device virto-input-host-pci,evdev=/dev/input/event > > The guest gets exclusive access to the input device, so be careful > with assigning the keyboard if you have onl

Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class

On Thu, Apr 10, 2014 at 11:07:51AM +0200, Gerd Hoffmann wrote: > This patch adds virtio-input support to qemu. It brings a abstract > base class providing core support, other classes can build on it to > actually implement input devices. > > virtio-input basically sends linux input layer events (

Re: [Qemu-devel] [PATCH v2 3/5] block: qemu-iotests - test for live migration

On Thu, Apr 10, 2014 at 02:16:46PM +0800, Fam Zheng wrote: > On Wed, 04/09 22:41, Jeff Cody wrote: > > This is an initial, simple live migration test from one > > running VM to another, using monitor commands. > > > > This is also an example on using the new common.qemu functions > > for controlli

Re: [Qemu-devel] [PATCH] iscsi: Remember to set ret for iscsi_open in error case

Am 10.04.2014 um 03:33 hat Fam Zheng geschrieben: > Signed-off-by: Fam Zheng Thanks, applied to the block branch. Kevin

[Qemu-devel] Should we have a 2.0-rc3 ?

So far I know of at least three fixes which should probably go into 2.0: * my fix for the configure stack-protector checks on MacOSX * MST's pull request updating the ACPI test blobs * MST says we need to update the hex files for ACPI too (otherwise you get a different ACPI blob depending on

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Am 09.04.2014 um 17:48 hat Markus Armbruster geschrieben: > I stumbled over this while trying to purge error_is_set() from the code. > > > Here's how we commonly use the Error API: > > Error *err = NULL; > > foo(arg, &err) > if (err) { > goto out; > } > bar(arg, &err

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 10.04.14 13:17, Peter Maydell wrote: So far I know of at least three fixes which should probably go into 2.0: * my fix for the configure stack-protector checks on MacOSX * MST's pull request updating the ACPI test blobs * MST says we need to update the hex files for ACPI too (otherw

Re: [Qemu-devel] [PATCH qemu 5/6] virtio-input: control device

On Thu, Apr 10, 2014 at 11:07:53AM +0200, Gerd Hoffmann wrote: > Device for sending non-input control messages to the guest. For now > this is only a single event: shutdown requests are sent as power button > press to the guest. > > Possible other use is signaling sound volume changes to the gues

[Qemu-devel] [PATCH] qemu-char: Allow a chardev to reconnect if disconnected

From: Huangweidong Allow a socket chardev reconnect if the connection drops while in use. Signed-off-by: Huangweidong Signed-off-by: Gonglei --- This patch is modified according to corey's patch. Some changes below: 1. IMO it's unnecessary that chardev reconnect if it fails to connect at star

Re: [Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices

On Do, 2014-04-10 at 13:55 +0300, Michael S. Tsirkin wrote: > On Thu, Apr 10, 2014 at 11:07:52AM +0200, Gerd Hoffmann wrote: > > This patch adds the virtio-input-hid base class and > > virtio-{keyboard,mouse,tablet} subclasses building on the base class. > > They are hooked up to the qemu input cor

[Qemu-devel] [RFC PATCH V3 1/7] linux-headers: Update KVM headers from v3.15

Syncup KVM related linux headers from v3.15. Signed-off-by: Pranavkumar Sawargaonkar Signed-off-by: Anup Patel --- linux-headers/asm-arm/kvm.h | 19 +- linux-headers/asm-arm64/kvm.h | 21 +-- linux-headers/linux/kvm.h | 10 ++ linux-headers/linux/psci.h| 77

[Qemu-devel] [RFC PATCH V3 2/7] kvm: Handle exit reason KVM_EXIT_SYSTEM_EVENT

In-kernel PSCI v0.2 emulation of KVM ARM/ARM64 forwards SYSTEM_OFF and SYSTEM_RESET function calls to QEMU using KVM_EXIT_SYSTEM_EVENT exit reason. This patch updates kvm_cpu_exec() to handle KVM_SYSTEM_EVENT_SHUTDOWN and KVM_SYSTEM_EVENT_RESET system-level events from QEMU-side. Signed-off-by: P

[Qemu-devel] [RFC PATCH V3 3/7] target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible

Latest linux kernel supports in-kernel emulation of PSCI v0.2 but to enable it we need to select KVM_ARM_VCPU_PSCI_0_2 feature using KVM_ARM_VCPU_INIT ioctl. Also, we can use KVM_ARM_VCPU_PSCI_0_2 feature for VCPU only when linux kernel has KVM_CAP_ARM_PSCI_0_2 capability. This patch updates kvm_

[Qemu-devel] [RFC PATCH V3 0/7] PSCI v0.2 support for KVM ARM/ARM64

Recentely patches have been posted for in-kernel emulation of PSCI v0.2 http://www.spinics.net/lists/arm-kernel/msg305467.html This patchset adds the QEMU side changes for providing PSCI v0.2 to VM. ChangeLog: V3: - Rebase this patchset against v8 patchset for in-kernel PSCI v0.2 emulation (

[Qemu-devel] [RFC PATCH V3 4/7] target-arm: Provide PSCI v0.2 constants to generic QEMU code

Provide QEMU PSCI v0.2 constants for non-KVM code; this will allow us to avoid an #ifdef in boards which set up a PSCI v0.2 node in the device tree. Signed-off-by: Pranavkumar Sawargaonkar Signed-off-by: Anup Patel --- target-arm/kvm-consts.h | 63 ++---

[Qemu-devel] [RFC PATCH V3 5/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports it

If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we need to provide PSCI v0.2 function IDs via generated DTB. This patch updates generated DTB to have PSCI v0.2 function IDs when we have in-kernel emulation PSCI v0.

[Qemu-devel] [RFC PATCH V3 7/7] target-arm: Implement kvm_arch_reset_vcpu() for KVM ARM64

To implement kvm_arch_reset_vcpu(), we simply re-init the VCPU using kvm_arm_vcpu_init() so that all registers of VCPU are set to their reset values by in-kernel KVM code. Signed-off-by: Pranavkumar Sawargaonkar Signed-off-by: Anup Patel --- target-arm/kvm64.c |4 1 file changed, 4 ins

[Qemu-devel] [RFC PATCH V3 6/7] target-arm: Common kvm_arm_vcpu_init() for KVM ARM and KVM ARM64

Introduce a common kvm_arm_vcpu_init() for doing KVM_ARM_VCPU_INIT ioctl in KVM ARM and KVM ARM64. This also helps us factor-out few common code lines from kvm_arch_init_vcpu() for KVM ARM/ARM64. Signed-off-by: Pranavkumar Sawargaonkar Signed-off-by: Anup Patel --- target-arm/kvm.c | 23 +

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

Am 10.04.2014 um 13:17 hat Peter Maydell geschrieben: > So far I know of at least three fixes which should probably > go into 2.0: > * my fix for the configure stack-protector checks on MacOSX > * MST's pull request updating the ACPI test blobs > * MST says we need to update the hex files for AC

Re: [Qemu-devel] [PATCH 01/16] cutils: tighten qemu_parse_fd()

On 04/10/2014 02:24 AM, Laszlo Ersek wrote: > qemu_parse_fd() used to handle at least the following strings incorrectly: > o "-2": simply let through > o "2147483648": returned as LONG_MAX==INT_MAX on ILP32 (with ERANGE > ignored); implementation-defined behavior on LP64 >

Re: [Qemu-devel] [PATCH qemu 6/6] virtio-input: evdev passthrough

Hi, > > +static void virtio_input_host_event(void *opaque) > > +{ > > +VirtIOInputHost *vhost = opaque; > > I'd prefer a name that does not imply > vhost infrastructure ok. > > +rc = ioctl(vhost->fd, EVIOCGVERSION, &ver); > > +if (rc < 0) { > > +error_setg(errp, "%s: is no

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream

On 08.04.14 03:26, Alexey Kardashevskiy wrote: On 03/28/2014 12:07 AM, Alexey Kardashevskiy wrote: On 03/27/2014 11:57 PM, Peter Maydell wrote: On 27 March 2014 12:49, Alexey Kardashevskiy wrote: On 03/27/2014 11:37 PM, Andreas Färber wrote: Am 27.03.2014 03:41, schrieb Alexey Kardashevskiy

Re: [Qemu-devel] [PATCH qemu 5/6] virtio-input: control device

On Do, 2014-04-10 at 14:05 +0300, Michael S. Tsirkin wrote: > On Thu, Apr 10, 2014 at 11:07:53AM +0200, Gerd Hoffmann wrote: > > Device for sending non-input control messages to the guest. For now > > this is only a single event: shutdown requests are sent as power button > > press to the guest. >

Re: [Qemu-devel] [PATCH v5 08/11] spapr-iommu: add SPAPR VFIO IOMMU device

On 07.04.14 06:07, Alexey Kardashevskiy wrote: On 04/03/2014 11:17 PM, Alexander Graf wrote: On 12.03.14 06:52, Alexey Kardashevskiy wrote: This adds SPAPR VFIO IOMMU device in order to support DMA operations for VFIO devices. Sorry if this has been mentioned before, but why exactly do you ne

Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class

On Do, 2014-04-10 at 14:06 +0300, Michael S. Tsirkin wrote: > > +void virtio_input_send(VirtIOInput *vinput, virtio_input_event > *event) > > +{ > > +VirtQueueElement elem; > > +int len; > > + > > +if (!virtqueue_pop(vinput->evt, &elem)) { > > +fprintf(stderr, "%s: virtqueue emp

Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration

On 03.04.14 15:14, Alexey Kardashevskiy wrote: This allows guests to have a different timebase origin from the host. This is needed for migration, where a guest can migrate from one host to another and the two hosts might have a different timebase origin. However, the timebase seen by the guest

Re: [Qemu-devel] [PATCH 1/8] spapr-iommu: add a bus for spapr-iommu devices

On 14.03.14 05:18, Alexey Kardashevskiy wrote: At the moment sPAPR IOMMU table is a device which participates in a migration stream. Normally QEMU uses a get_dev_path() hook from the device's bus to compose the section name and @instance_id which are used to match the section to the real device.

Re: [Qemu-devel] [PATCH 2/8] xics: add flags for interrupts

On 14.03.14 05:18, Alexey Kardashevskiy wrote: We will need soon an "allocated" flag for every interrupt to support interrupt configuration change which may happen during migration. This replaces a separate lslsi[] array with a byte in the ICSIRQState struct and defines "LSI" and "MSI" flags. N

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 04/10/2014 05:17 AM, Peter Maydell wrote: > So far I know of at least three fixes which should probably > go into 2.0: > * my fix for the configure stack-protector checks on MacOSX > * MST's pull request updating the ACPI test blobs > * MST says we need to update the hex files for ACPI too >

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 10.04.2014, at 14:44, Eric Blake wrote: > On 04/10/2014 05:17 AM, Peter Maydell wrote: >> So far I know of at least three fixes which should probably >> go into 2.0: >> * my fix for the configure stack-protector checks on MacOSX >> * MST's pull request updating the ACPI test blobs >> * MST sa

Re: [Qemu-devel] [PATCH 6/8] spapr: move interrupt allocator to xics

On 14.03.14 05:18, Alexey Kardashevskiy wrote: The current allocator returns IRQ numbers from a pool and does not support IRQs reuse in any form as it did not keep track of what it previously returned, it only had the last returned IRQ. However migration may change interrupts for devices dependi

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 04/10/2014 06:46 AM, Alexander Graf wrote: > > On 10.04.2014, at 14:44, Eric Blake wrote: > >> On 04/10/2014 05:17 AM, Peter Maydell wrote: >>> So far I know of at least three fixes which should probably >>> go into 2.0: >>> * my fix for the configure stack-protector checks on MacOSX >>> * MS

Re: [Qemu-devel] [PATCH v2 4/5] block: qemu-iotests - fix image cleanup when using spaced pathnames

On Thu, Apr 10, 2014 at 03:53:57PM +0800, Fam Zheng wrote: > On Wed, 04/09 22:41, Jeff Cody wrote: > > The _rm_test_img() function in common.rc did not quote the image > > file, which left droppings in the scratch directory (and performed > > a potentially unsafe rm -f). > > > > This adds the nece

Re: [Qemu-devel] [PATCH 8/8] xics: enable interrupt configuration reset on migration

On 14.03.14 05:18, Alexey Kardashevskiy wrote: Interrupt numbers migrate along with other properties so the initial QEMU setup will be reset by migration. Since XICS migrates as well and this includes IRQ map with all the flags saying which ones are already used, all we need is just to reset the

[Qemu-devel] qemu 2.0.0-rc2 crash

Hi, I've been playing with QEMU 2.0-rc2 and found a crash that isn't there in 1.7.1. Virtual machine is created via libvirt and when I query it with 'dommemstat' it crashes with following backtrace: Program received signal SIGSEGV, Segmentation fault. 0x7f5883655c0a in object_class_dyna

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 10.04.14 14:51, Eric Blake wrote: On 04/10/2014 06:46 AM, Alexander Graf wrote: On 10.04.2014, at 14:44, Eric Blake wrote: On 04/10/2014 05:17 AM, Peter Maydell wrote: So far I know of at least three fixes which should probably go into 2.0: * my fix for the configure stack-protector chec

Re: [Qemu-devel] [Qemu-ppc] [PATCH 5/6] target-ppc: Fix Book3S PMU SPRs

On 25.03.14 03:40, Anton Blanchard wrote: Most of the PMU SPRs were wrong on Book3S. Signed-off-by: Anton Blanchard --- target-ppc/cpu.h| 29 - target-ppc/translate_init.c | 139 +++- 2 files changed, 153 insertions(+), 15 deleti

Re: [Qemu-devel] [Qemu-ppc] [PATCH 6/6] target-ppc: Add PMC7/8 to 970

On 25.03.14 03:40, Anton Blanchard wrote: 970 CPUs have PMC7/8. Create gen_spr_970 to avoid replicating it 3 times, and simplify the existing code. Signed-off-by: Anton Blanchard Don't you think we could just combine 970, 970FX and 970MP into the same class? Alex

Re: [Qemu-devel] [PATCH 6/8] spapr: move interrupt allocator to xics

On 04/10/2014 10:51 PM, Alexander Graf wrote: > > On 14.03.14 05:18, Alexey Kardashevskiy wrote: >> The current allocator returns IRQ numbers from a pool and does not >> support IRQs reuse in any form as it did not keep track of what it >> previously returned, it only had the last returned IRQ. >>

Re: [Qemu-devel] [PATCH 6/8] spapr: move interrupt allocator to xics

On 10.04.14 15:24, Alexey Kardashevskiy wrote: On 04/10/2014 10:51 PM, Alexander Graf wrote: On 14.03.14 05:18, Alexey Kardashevskiy wrote: The current allocator returns IRQ numbers from a pool and does not support IRQs reuse in any form as it did not keep track of what it previously returned,

Re: [Qemu-devel] [RFC v2 1/6] hw/arm/virt: add a xgmac device

On Thu, Apr 10, 2014 at 1:33 AM, Eric Auger wrote: > From: Kim Phillips > > This is a hack and only serves as an example of what needs to be > done to make the next RFC - add vfio-platform support - work > for development purposes on a Calxeda Midway system. We don't want > mach-virt to always c

[Qemu-devel] [PATCH V3 2/2] hw/pci: check if pci2pci bridges implement optional limit registers

pair and pair are both optional. Do not reserve ranges if the above registers are not implemented. Signed-off-by: Marcel Apfelbaum --- src/fw/pciinit.c | 9 ++--- src/hw/pci.c | 48 src/hw/pci.h | 9 + 3 files changed, 59 i

[Qemu-devel] [SeaBIOS] [PATCH V3 0/2] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached

v2 -> v3: - Addressed Michael S. Tsirkin's comments: - I/O and Prefetchable Memory are optional. Do not allocate ranges if they are not implemented (2/2). - Note that 2/2 patch can be seen as a separate fix. However, it is related to ranges reservation. v1 -> v2: - Thanks Gerd Hoffma

[Qemu-devel] [PATCH V3 1/2] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached

If a pci-2-pci bridge supports hot-plug functionality but there are no devices connected to it, reserve IO/mem in order to be able to attach devices later. Do not waste space, use minimum allowed. Signed-off-by: Marcel Apfelbaum --- src/fw/pciinit.c | 3 +++ src/hw/pci.c | 19 ++

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 04/10/2014 02:46 PM, Alexander Graf wrote: > > On 10.04.2014, at 14:44, Eric Blake wrote: > >> On 04/10/2014 05:17 AM, Peter Maydell wrote: >>> So far I know of at least three fixes which should probably >>> go into 2.0: >>> * my fix for the configure stack-protector checks on MacOSX >>> * MS

Re: [Qemu-devel] [PATCH] target-arm: Load ELF images with the correct machine type for CPU

On 21.03.14 19:44, Peter Maydell wrote: When trying to load an ELF file specified via -kernel, we need to pass load_elf() the ELF machine type corresponding to the CPU we're booting with, not the one corresponding to the softmmu binary we happen to be running. (The two are different in the case

Re: [Qemu-devel] qemu 2.0.0-rc2 crash

On Thu, 2014-04-10 at 14:55 +0200, Marcin Gibuła wrote: > Hi, > > I've been playing with QEMU 2.0-rc2 and found a crash that isn't there > in 1.7.1. Hi Marcin, Thanks for reporting the bug! Do you have a development environment? If you do, and the reproduction is fast (and you already have a set

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

On 10.04.14 15:41, Ján Tomko wrote: On 04/10/2014 02:46 PM, Alexander Graf wrote: On 10.04.2014, at 14:44, Eric Blake wrote: On 04/10/2014 05:17 AM, Peter Maydell wrote: So far I know of at least three fixes which should probably go into 2.0: * my fix for the configure stack-protector check

Re: [Qemu-devel] [RFC v2 1/6] hw/arm/virt: add a xgmac device

On 10.04.14 15:26, Peter Crosthwaite wrote: On Thu, Apr 10, 2014 at 1:33 AM, Eric Auger wrote: From: Kim Phillips This is a hack and only serves as an example of what needs to be done to make the next RFC - add vfio-platform support - work for development purposes on a Calxeda Midway system.

[Qemu-devel] [PATCH trivial] init_paths: fix minor memory leak

Fields "name" (created with strdup in new_entry) and "pathname" (created with g_strdup_printf in new_entry) of pathelem struct should be freed before the whole struct is. Signed-off-by: Kirill Batuzov --- util/path.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/util/

Re: [Qemu-devel] [PATCH 4/4] spapr: Add support for time base offset migration

On 04/10/2014 10:34 PM, Alexander Graf wrote: > > On 03.04.14 15:14, Alexey Kardashevskiy wrote: >> This allows guests to have a different timebase origin from the host. >> >> This is needed for migration, where a guest can migrate from one host >> to another and the two hosts might have a differe

Re: [Qemu-devel] [PATCH v2 3/6] qemu-img: Implement commit like QMP

On 08.04.2014 17:14, Kevin Wolf wrote: Am 08.04.2014 um 14:50 hat Max Reitz geschrieben: qemu-img should use QMP commands whenever possible in order to ensure feature completeness of both online and offline image operations. As qemu-img itself has no access to QMP (since this would basically req

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream

On 04/10/2014 10:10 PM, Alexander Graf wrote: > > On 08.04.14 03:26, Alexey Kardashevskiy wrote: >> On 03/28/2014 12:07 AM, Alexey Kardashevskiy wrote: >>> On 03/27/2014 11:57 PM, Peter Maydell wrote: On 27 March 2014 12:49, Alexey Kardashevskiy wrote: > On 03/27/2014 11:37 PM, Andreas F

Re: [Qemu-devel] [PATCH v2 4/6] qemu-img: Enable progress output for commit

On 08.04.2014 17:34, Kevin Wolf wrote: Am 08.04.2014 um 14:50 hat Max Reitz geschrieben: Implement progress output for the commit command by querying the progress of the block job. Signed-off-by: Max Reitz Reviewed-by: Eric Blake --- qemu-img-cmds.hx | 4 ++-- qemu-img.c | 33 ++

Re: [Qemu-devel] [PATCH 1/8] spapr-iommu: add a bus for spapr-iommu devices

On 04/10/2014 10:40 PM, Alexander Graf wrote: > > On 14.03.14 05:18, Alexey Kardashevskiy wrote: >> At the moment sPAPR IOMMU table is a device which participates in >> a migration stream. Normally QEMU uses a get_dev_path() hook from >> the device's bus to compose the section name and @instance_i

Re: [Qemu-devel] [PATCH v2 2/6] block-commit: speed is an optional parameter

On 08.04.2014 17:07, Kevin Wolf wrote: Am 08.04.2014 um 14:50 hat Max Reitz geschrieben: As speed is an optional parameter for the QMP block-commit command, it should be set to 0 if not given (as it is undefined if has_speed is false), that is, the speed should not be limited. Signed-off-by: Ma

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream

On 10.04.2014, at 16:35, Alexey Kardashevskiy wrote: > On 04/10/2014 10:10 PM, Alexander Graf wrote: >> >> On 08.04.14 03:26, Alexey Kardashevskiy wrote: >>> On 03/28/2014 12:07 AM, Alexey Kardashevskiy wrote: On 03/27/2014 11:57 PM, Peter Maydell wrote: > On 27 March 2014 12:49, Alexe

Re: [Qemu-devel] [PATCH v2 5/6] qemu-img: Specify backing file for commit

On 08.04.2014 19:01, Eric Blake wrote: On 04/08/2014 06:50 AM, Max Reitz wrote: Introduce a new parameter for qemu-img commit which may be used to explicitly specify the backing file unto which an image should be s/unto/into/ I was wondering about that and asked someone about it (German as we

Re: [Qemu-devel] [PATCH 6/8] spapr: move interrupt allocator to xics

On 04/10/2014 11:26 PM, Alexander Graf wrote: > > On 10.04.14 15:24, Alexey Kardashevskiy wrote: >> On 04/10/2014 10:51 PM, Alexander Graf wrote: >>> On 14.03.14 05:18, Alexey Kardashevskiy wrote: The current allocator returns IRQ numbers from a pool and does not support IRQs reuse in an

Re: [Qemu-devel] [PATCH v2 4/5] block: qemu-iotests - fix image cleanup when using spaced pathnames

On 04/10/2014 06:53 AM, Jeff Cody wrote: >>> +++ b/tests/qemu-iotests/common.rc >>> @@ -178,10 +178,10 @@ _rm_test_img() >>> local img=$1 >> >> Since we are quoting $img, should we quote $1 as well? >> > > I believe not, because variable assignment won't undergo all the shell > expansions.

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream

On 04/11/2014 12:41 AM, Alexander Graf wrote: > > On 10.04.2014, at 16:35, Alexey Kardashevskiy wrote: > >> On 04/10/2014 10:10 PM, Alexander Graf wrote: >>> >>> On 08.04.14 03:26, Alexey Kardashevskiy wrote: On 03/28/2014 12:07 AM, Alexey Kardashevskiy wrote: > On 03/27/2014 11:57 PM,

Re: [Qemu-devel] [PATCH v2 5/6] qemu-img: Specify backing file for commit

On 10.04.2014 11:05, Fam Zheng wrote: On Tue, 04/08 14:50, Max Reitz wrote: Introduce a new parameter for qemu-img commit which may be used to explicitly specify the backing file unto which an image should be committed if the backing chain has more than a single layer. Signed-off-by: Max Reitz

Re: [Qemu-devel] [PATCH v2 4/5] block: qemu-iotests - fix image cleanup when using spaced pathnames

On 04/10/2014 08:43 AM, Eric Blake wrote: > On 04/10/2014 06:53 AM, Jeff Cody wrote: > +++ b/tests/qemu-iotests/common.rc @@ -178,10 +178,10 @@ _rm_test_img() local img=$1 >>> >>> Since we are quoting $img, should we quote $1 as well? >>> > > http://austingroupbugs.net/view.p

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Add @cpu_dt_id into migration stream

On 10 April 2014 15:35, Alexey Kardashevskiy wrote: > Then what is the purpose of many, many VMSTATE_.*_EQUAL? Often it's backwards compatibility with a previous vmstate or save/load function set which incorrectly sent data it didn't need to. > And I do not want to send configuration by the prop

Re: [Qemu-devel] [PATCH 1/8] spapr-iommu: add a bus for spapr-iommu devices

Am 10.04.2014 16:40, schrieb Alexey Kardashevskiy: > On 04/10/2014 10:40 PM, Alexander Graf wrote: >> >> Juan, is a different command line device order supposed to work with >> migration? > > > We discussed this on IRC with Paolo and the conclusion is that yes, the > order should not matter. Huh

Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class

On Thu, Apr 10, 2014 at 02:22:17PM +0200, Gerd Hoffmann wrote: > On Do, 2014-04-10 at 14:06 +0300, Michael S. Tsirkin wrote: > > > +void virtio_input_send(VirtIOInput *vinput, virtio_input_event > > *event) > > > +{ > > > +VirtQueueElement elem; > > > +int len; > > > + > > > +if (!virtq

Re: [Qemu-devel] [PATCH] qemu-char: Allow a chardev to reconnect if disconnected

On 04/10/2014 06:43 AM, arei.gong...@huawei.com wrote: > From: Huangweidong > > Allow a socket chardev reconnect if the connection drops while in use. > > Signed-off-by: Huangweidong > Signed-off-by: Gonglei > --- > This patch is modified according to corey's patch. Some changes below: > 1. IMO

  1   2   3   >