Re: [Qemu-devel] Peripheral timer, ptimer and stm32

On 19 July 2014 23:22, Andrew Hankins wrote: > Also I'm interested in contributing the STM32 implementation upstream - is > this something that the qemu project is interested in? In general, yes, especially if you're going to hang around and help deal with bugs/issues in the M profile emulation,

[Qemu-devel] Peripheral timer, ptimer and stm32

Hi all, First post on the mailing list. I'm working on a branch of qemu which includes support STM32 chipset and I'm current adding support for a peripheral timers. I'm trying to re-use the general purpose ptimer but I'm having a couple of issues with the

[Qemu-devel] [PATCH 0/2] qemu-img: Allow source cache mode specification

Currently, qemu-img does not allow setting the cache mode for source images. However, it reads images generally only once, therefore a full writeback cache unnecessarily clutters the host cache. In case the user finds this undesirable, there has to be a way of disabling that cache. This series firs

[Qemu-devel] [PATCH 2/2] qemu-img: Allow cache mode specification for amend

qemu-img amend may extensively modify the target image, depending on the options to be amended (e.g. conversion to qcow2 compat level 0.10 from 1.1 for an image with many unallocated zero clusters). Therefore it makes sense to allow the user to specify the cache mode to be used. Signed-off-by: Max

[Qemu-devel] [PATCH 1/2] qemu-img: Allow source cache mode specification

Many qemu-img subcommands only read the source file(s) once. For these use cases, a full write-back cache is unnecessary and mainly clutters host cache memory. Though this is generally no concern as cache memory is freely available and can be scaled by the host OS, it may become a concern with thin

[Qemu-devel] [PATCH] pci: Don't deliver MSI/MSI-X messages if bus master support is off

From: Jan Kiszka The spec says (and real HW confirms this) that, if the bus master bit is 0, the device will not generate any PCI accesses. MSI and MSI-X messages fall among these. Signed-off-by: Jan Kiszka --- hw/pci/msi.c | 4 hw/pci/msix.c | 4 2 files changed, 8 insertions(+) d

Re: [Qemu-devel] [PATCH 4/4] block: vpc - use block layer ops in vpc_create, instead of posix calls

On 18.07.2014 22:54, Jeff Cody wrote: Use the block layer to create, and write to, the image file in the VPC .bdrv_create() operation. This has a couple of benefits: Images can now be created over protocols, and host raw file optimizations (such as nocow) do not need to be handled in the image f

Re: [Qemu-devel] [PATCH 3/4] block: use the standard 'ret' instead of 'result'

On 18.07.2014 22:54, Jeff Cody wrote: Most QEMU code uses 'ret' for function return values. The VDI driver uses a mix of 'result' and 'ret'. This cleans that up, switching over to the standard 'ret' usage. Signed-off-by: Jeff Cody --- block/vdi.c | 36 ++-- 1

Re: [Qemu-devel] [PATCH 2/4] block: vdi - use block layer ops in vdi_create, instead of posix calls

On 18.07.2014 22:53, Jeff Cody wrote: Use the block layer to create, and write to, the image file in the VDI .bdrv_create() operation. This has a couple of benefits: Images can now be created over protocols, and host raw file optimizations (such as nocow) do not need to be handled in the image f

Re: [Qemu-devel] [PATCH 1/4] block: allow bdrv_unref() to be passed NULL pointers

On 18.07.2014 22:53, Jeff Cody wrote: If bdrv_unref() is passed a NULL BDS pointer, it is safe to exit with no operation. This will allow cleanup code to blindly call bdrv_unref() on a BDS that has been initialized to NULL. Signed-off-by: Jeff Cody --- block.c | 3 +++ 1 file changed, 3 ins

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

Paolo, On 19 Jul 2014, at 11:53, Paolo Bonzini wrote: >>> No, the old one is _always_ the correct one. >>> >>> The pxe-* ROMs must be 128k, the efi-* ROMs must be 256k. >> >> On 12.04 >> # ls -la /usr/share/qemu/pxe-virtio.rom >> -rw-r--r-- 1 root root 63488 Jun 12 23:23 /usr/share/qemu/pxe-vi

Re: [Qemu-devel] i686 guest failing to start at 50a2c45 (and earlier versions of 2.1-rc) with pc-i440fx-2.1

Il 19/07/2014 12:31, Andrey Korolyov ha scritto: > Nevermind, that was a result from wrong config generation (1 vcpu and > 12 topology cores in the config, probably libvirt folks may be > interested for checking this because libvirt allows such configuration > for now). Still a regression... Paol

Re: [Qemu-devel] [Bug 1344320] [NEW] qemu-aarch64 cannot execute glibc

On 18 July 2014 21:30, Andreas Schwab wrote: > qemu: uncaught target signal 4 (Illegal instruction) - core dumped > Illegal instruction > $ objdump -d > /daten/build/build-root/home/abuild/rpmbuild/BUILD/glibc-2.19.90/cc-base/elf/ld-linux-aarch64.so.1 > | grep ' 4828:' > 4828: d53be040

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

Il 19/07/2014 10:43, Alex Bligh ha scritto: > Paolo, > > On 19 Jul 2014, at 08:30, Paolo Bonzini wrote: > >> Il 19/07/2014 09:10, Alex Bligh ha scritto: > Looks like your source and destination machines have different > iPXE ROMs. This could be a packaging problem in your distro. >>> >>

Re: [Qemu-devel] i686 guest failing to start at 50a2c45 (and earlier versions of 2.1-rc) with pc-i440fx-2.1

On Fri, Jul 18, 2014 at 11:58 PM, Andrey Korolyov wrote: > Hello, > > 2.0 model works fine > > 2.1 crashes with following: > > /tmp/buildd/qemu-2.0.92+rev1/hw/i386/smbios.c:825: smbios_get_tables: > Assertion `smbios_smp_sockets >= 1' failed > > Not sure if bisect will help much, but the commit wh

[Qemu-devel] [PATCH] Show length mismatch error is hex

When live migrate fails due to a section length mismatch we currently see an error message like: Length mismatch: :00:03.0/virtio-net-pci.rom: 1 in != 2 The section lengths are in fact in hex, so this should read Length mismatch: :00:03.0/virtio-net-pci.rom: 0x1 in != 0x2

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

On 19 Jul 2014, at 09:54, Peter Maydell wrote: > On 19 July 2014 09:43, Alex Bligh wrote: >> Whilst (per below) your workaround gets past the issue for this ROM, >> I'm confused about the numbers in the error message, as 64k and >> 128k do not equal 10,000 or 20,000: >> Length mismatch: :00

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

On 19 July 2014 09:43, Alex Bligh wrote: > Whilst (per below) your workaround gets past the issue for this ROM, > I'm confused about the numbers in the error message, as 64k and > 128k do not equal 10,000 or 20,000: > Length mismatch: :00:03.0/virtio-net-pci.rom: 1 in != 2 0x1 he

Re: [Qemu-devel] is there a limit on the number of in-flight I/O operations?

The Saturday 19 Jul 2014 à 09:23:50 (+0200), Paolo Bonzini wrote : > Il 19/07/2014 08:27, Chris Friesen ha scritto: > > Does it track in-flight operations though? Or just how many operations > > can be requested in a given amount of time? > > It should track in flight operations. However, I'm no

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

Paolo, On 19 Jul 2014, at 08:30, Paolo Bonzini wrote: > Il 19/07/2014 09:10, Alex Bligh ha scritto: Looks like your source and destination machines have different iPXE ROMs. This could be a packaging problem in your distro. >> >> This is Ubuntu 12.04 to Ubuntu 14.04. I think the 14.0

[Qemu-devel] nic is lost, in the virtual machine running

Hi all： Problem description. 1. /usr/bin/qemu-system-x86_64 -machine accel=kvm -name a58970a2-10aa-4973-9261-7384b2f53221 -S -machine pc-0.14,accel=kvm,usb=off -m 4096 -smp 4,sockets=1,cores=4,threads=1 -uuid f3a2217f-ae5c-461b-a922-d37a3a98edc6 -no-user-config -nodefaults -chardev socket,id=

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

Il 19/07/2014 09:10, Alex Bligh ha scritto: >>> Looks like your source and destination machines have different >>> iPXE ROMs. This could be a packaging problem in your distro. > > This is Ubuntu 12.04 to Ubuntu 14.04. I think the 14.04 one is > correct, and don't want to run with a non-standard q

Re: [Qemu-devel] is there a limit on the number of in-flight I/O operations?

Il 19/07/2014 08:27, Chris Friesen ha scritto: > Does it track in-flight operations though? Or just how many operations > can be requested in a given amount of time? It should track in flight operations. However, I'm not sure it supports the iops=0 case properly, since I do not see anything in t

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

Paolo, On 19 Jul 2014, at 06:51, Paolo Bonzini wrote: >> Restoring the machine with the command line [2] (merely adding -machine >> pc-1.0 which is not the default for qemu-2.0) produces the error: >> Length mismatch: vga.vram: 100 in != 80 >> qemu: warning: error while loading state fo