[Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

Result of doing qemu-system-ppc64 -m 1024 -vnc :1 -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=my-seed.img,if=virtio ** Attachment added: "crash.png"

Re: [Qemu-devel] [PATCH] xen: write information about supported backends

On 01/04/16 16:56, Stefano Stabellini wrote: > On Wed, 30 Mar 2016, Juergen Gross wrote: >> Add a Xenstore directory for each supported pv backend. This will allow >> Xen tools to decide which backend type to use in case there are >> multiple possibilities. >> >> The information is added under >>

[Qemu-devel] [PATCH] opencores_eth: indicate autonegotiation completion

Indicate that autonegotiation is complete in the MII BMSR. This fixes networking on xtfpga platform in linux v4.5. Cc: qemu-sta...@nongnu.org Signed-off-by: Max Filippov --- hw/net/opencores_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Qemu-devel] [PATCH] target-ppc: Correct KVM synchronization for ppc_hash64_set_external_hpt()

On Mon, Apr 04, 2016 at 11:10:56AM +1000, David Gibson wrote: > On Fri, Apr 01, 2016 at 12:28:31PM +0200, Paolo Bonzini wrote: > > > > > > On 01/04/2016 05:52, David Gibson wrote: > > > This seems like the right minimal fix in the qemu-2.6 timeframe to fix > > > the actual bug. However, longer

[Qemu-devel] [PATCH 1/2] acpi: tpm: Fix TPM ACPI description (BZ 1281413)

This patch addresses BZ 1281413. https://bugzilla.redhat.com/show_bug.cgi?id=1281413 Fix the APCI description to make it work on operating systems that are more strict about the contents of the TPM's ACPI description than Linux is. The ACPI description was broken in commit 9e472263. We roll

[Qemu-devel] [PATCH 0/2] acpi: tpm: Fix TPM ACPI description

This series of patches fixes some problems with the TPM's ACPI description. Stefan Berger (2): acpi: tpm: Fix TPM ACPI description (BZ 1281413) acpi: tpm: Get the interrupt the device model is using hw/i386/acpi-build.c | 29 ++--- hw/tpm/tpm_tis.c | 5 -

[Qemu-devel] [PATCH 2/2] acpi: tpm: Get the interrupt the device model is using

Get the interrupt the TPM device model is using. Do not activate the interrupt in the ACPI description yet since the current default value clashes with other devices. Signed-off-by: Stefan Berger --- hw/i386/acpi-build.c | 5 +++-- hw/tpm/tpm_tis.c | 5 -

Re: [Qemu-devel] [PATCH] target-ppc: Correct KVM synchronization for ppc_hash64_set_external_hpt()

On Fri, Apr 01, 2016 at 12:28:31PM +0200, Paolo Bonzini wrote: > > > On 01/04/2016 05:52, David Gibson wrote: > > This seems like the right minimal fix in the qemu-2.6 timeframe to fix > > the actual bug. However, longer term it seems like the correct thing > > to do might be to set

Re: [Qemu-devel] [RFC PATCH v2.1 08/12] spapr: Add CPU type specific core devices

On Fri, Apr 01, 2016 at 11:42:23AM +0530, Bharata B Rao wrote: > On Fri, Apr 01, 2016 at 04:08:44PM +1100, David Gibson wrote: > > On Thu, Mar 31, 2016 at 02:09:17PM +0530, Bharata B Rao wrote: > > > Introduce core devices for each CPU type supported by sPAPR. These > > > core devices are derived

Re: [Qemu-devel] [RFC PATCH v2.1 08/12] spapr: Add CPU type specific core devices

On Thu, Mar 31, 2016 at 02:09:17PM +0530, Bharata B Rao wrote: > Introduce core devices for each CPU type supported by sPAPR. These > core devices are derived from the base spapr-cpu-core device type. > > TODO: > - Add core types for other remaining CPU types > - Handle CPU model alias correctly

Re: [Qemu-devel] [RFC PATCH v2.1 05/12] qdev: hotplug: Introduce HotplugHandler.pre_plug() callback

On Fri, Apr 01, 2016 at 12:38:28PM +0200, Paolo Bonzini wrote: > > > On 01/04/2016 05:30, David Gibson wrote: > > On Thu, Mar 31, 2016 at 02:09:14PM +0530, Bharata B Rao wrote: > >> From: Igor Mammedov > >> > >> pre_plug callback is to be called before device.realize() is

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

On 3 April 2016 at 22:42, Liviu Ionescu wrote: >> On 04 Apr 2016, at 00:30, Peter Maydell wrote: >> Which I completely agree with. If you want to send a patch >> to add the assert I'm happy to review it. > > I guess the original report was clear enough

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 04 Apr 2016, at 00:30, Peter Maydell wrote: > > On 3 April 2016 at 18:56, Liviu Ionescu wrote: >> well, to summarise, I notified you that in certain conditions, >> due to an non-obvious dependency that does not break the build >> when not met,

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

On 3 April 2016 at 18:56, Liviu Ionescu wrote: > well, to summarise, I notified you that in certain conditions, > due to an non-obvious dependency that does not break the build > when not met, the existing code crashes at run time with a > segmentation fault, and I suggested that

Re: [Qemu-devel] [PATCH] virtio-blk: assert on starting/stopping

On 03/04/2016 21:59, Christian Borntraeger wrote: > Thread 1 (Thread 0x3ffad25bb90 (LWP 41685)): > ---Type to continue, or q to quit--- > #0 0x03ffab5be2c0 in raise () at /lib64/libc.so.6 > #1 0x03ffab5bfc26 in abort () at /lib64/libc.so.6 > #2 0x03ffab5b5bce in

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

it shows: -rwxr-xr-x 1 root root 265848 يول 18 2014 /sbin/init 2016-04-03 21:13 GMT+01:00 Marwa Hamza : > it shows: > -rwxr-xr-x 1 root root 265848 يول 18 2014 /sbin/init > > > 2016-04-03 20:49 GMT+01:00 Marwa Hamza : > >> the output of this

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

it shows: -rwxr-xr-x 1 root root 265848 يول 18 2014 /sbin/init 2016-04-03 20:49 GMT+01:00 Marwa Hamza : > the output of this command > ./i386-softmmu/qemu-system-i386 -M pc > -kernel > > > /home/marwa/Bureau/lauterbach/i386_qemu/linux-4.1.18/arch/i386/boot/bzImage > >

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

On Sun, Apr 3, 2016 at 3:49 PM, Marwa Hamza wrote: > the output of this command > ./i386-softmmu/qemu-system-i386 -M pc -kernel >> >> /home/marwa/Bureau/lauterbach/i386_qemu/linux-4.1.18/arch/i386/boot/bzImage >> -initrd >>

Re: [Qemu-devel] [PATCH] virtio-blk: assert on starting/stopping

On 04/03/2016 12:37 PM, Michael S. Tsirkin wrote: > Reentrancy cannot happen while the BQL is being held, > so we should never enter this condition. > > Cc: Christian Borntraeger > Cc: Cornelia Huck > Cc: Paolo Bonzini >

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

the output of this command > ./i386-softmmu/qemu-system-i386 -M pc -kernel > /home/marwa/Bureau/lauterbach/i386_qemu/linux-4.1.18/arch/i386/boot/bzImage > -initrd /home/marwa/Bureau/lauterbach/i386_qemu/busybox-1.21.0/rootfs.img.gz > -append “root=/dev/ram rdinit=/sbin/init” > starting init

[Qemu-devel] [Bug 1565395] Re: qemu-2.4.1 fails when compiled against pulseaudio

** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1565395 Title: qemu-2.4.1 fails when compiled against pulseaudio Status in QEMU: Confirmed Bug

[Qemu-devel] [ RFC Patch v4 3/3] virtio-net rsc: support coalescing ipv6 tcp traffic

From: Wei Xu Most things like ipv4 except there is a significant difference between ipv4 and ipv6, the fragment lenght in ipv4 header includes itself, while it's not included for ipv6, thus means ipv6 can carry a real '65535' payload. Signed-off-by: Wei Xu ---

[Qemu-devel] [ RFC Patch v4 2/3] virtio-net rsc: support coalescing ipv4 tcp traffic

From: Wei Xu All the data packets in a tcp connection will be cached to a big buffer in every receive interval, and will be sent out via a timer, the 'virtio_net_rsc_timeout' controls the interval, the value will influent the performance and response of tcp connection extremely,

[Qemu-devel] [ RFC Patch v4 1/3] virtio-net rsc: add a new host offload(rsc) feature bit

From: Wei Xu A new feature bit 'VIRTIO_NET_F_GUEST_RSC' is introduced to support WHQL Receive-Segment-Offload test, this feature will coalesce tcp packets in IPv4/6 for userspace virtio-net driver. This feature can be enabled either by 'ACK' the feature when loading the driver

[Qemu-devel] [ RFC Patch v4 0/3] Support Receive-Segment-Offload(RSC) for WHQL

From: Wei Xu Changes in V4: - Add new host feature bit - Replace using fixed header lenght with dynamic header lenght in VirtIONet - Change ip/ip6 header union in NetRscUnit to void* pointer - Add macro prefix, adjust code indent, etc. Changes in V3: - Removed big param list,

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

On Sun, Apr 3, 2016 at 9:50 AM, Marwa Hamza wrote: > ./i386-softmmu/qemu-system-i386 -M pc -kernel > /home/marwa/Bureau/lauterbach/i386_qemu/linux-4.1.18/arch/i386/boot/bzImage > -initrd /home/marwa/Bureau/lauterbach/i386_qemu/busybox-1.21.0/rootfs.img.gz > -append

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

but i tried the same thing with arm arch ( file system made by busybox) and i used sh shell and it worked well 2016-04-03 20:20 GMT+02:00 Pranith Kumar : > On Sun, Apr 3, 2016 at 9:50 AM, Marwa Hamza > wrote: > > hello , i tried to run qemu on x64

Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

On Sun, Apr 3, 2016 at 9:50 AM, Marwa Hamza wrote: > hello , i tried to run qemu on x64 system , > > those are steps that i followed > i compile the kernel 4.4.1 with arch =i386 > i download busybox 1.21.0 > make ARCH=i386 menuconfig > I checked the option to compile

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] spapr: compute interrupt vector address from LPCR

On 04/01/2016 04:43 AM, David Gibson wrote: > On Thu, Mar 31, 2016 at 08:13:09AM +0100, Mark Cave-Ayland wrote: >> On 31/03/16 05:55, David Gibson wrote: >> >>> On Wed, Mar 30, 2016 at 05:38:34PM +0200, Cédric Le Goater wrote: This address is changed by the linux kernel using the H_SET_MODE

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 03 Apr 2016, at 20:01, Peter Maydell wrote: > > ... This is you changing QEMU to not compile a file that was > previously always compiled. If you do that then it's > not surprising if things might break when you move to an > upstream version, that's all. well, to

Re: [Qemu-devel] [PATCH 2/2] memory: hide mr->ram_addr from qemu_get_ram_ptr users

On 03/04/2016 15:49, Michael S. Tsirkin wrote: > > I agree but I think we need a better name for this function. > qemu_ram_offset_to_ptr? > Will also serve to make sure backporting patches across this > API change does not cause issues. Yes, this makes sense. If it were all in 2.6, there

Re: [Qemu-devel] [PATCH 8/9] virtio: merge virtio_queue_aio_set_host_notifier_handler with virtio_queue_set_aio

On 03/04/2016 11:06, Michael S. Tsirkin wrote: > On Fri, Apr 01, 2016 at 03:19:53PM +0200, Paolo Bonzini wrote: >> Eliminating the reentrancy is actually a nice thing that we can do >> with the API that Michael proposed, so let's make it first class. >> This also hides the complex

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

On 3 April 2016 at 17:57, Liviu Ionescu wrote: > >> On 03 Apr 2016, at 19:43, Peter Maydell wrote: >> >> On 3 April 2016 at 16:40, Liviu Ionescu wrote: >>> On 03 Apr 2016, at 15:28, Peter Maydell wrote:

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 03 Apr 2016, at 19:43, Peter Maydell wrote: > > On 3 April 2016 at 16:40, Liviu Ionescu wrote: >> >>> On 03 Apr 2016, at 15:28, Peter Maydell wrote: >> >>> since hw/arm/boot.o is in obj-y it should always be built, >>

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

On 3 April 2016 at 16:40, Liviu Ionescu wrote: > >> On 03 Apr 2016, at 15:28, Peter Maydell wrote: > >> since hw/arm/boot.o is in obj-y it should always be built, > > not necessarily, in my build configuration I have if's that > exclude most of the

[Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system

hello , i tried to run qemu on x64 system , those are steps that i followed i compile the kernel 4.4.1 with arch =i386 i download busybox 1.21.0 make ARCH=i386 menuconfig I checked the option to compile Busybox as a static executable make ARCH=i386 install cd _install mkdir proc sys dev lib etc

Re: [Qemu-devel] [PATCH] ui/cocoa.m: fix sending mouse event to guest

On Apr 3, 2016, at 8:21 AM, Peter Maydell wrote: > On 2 April 2016 at 18:53, Programmingkid wrote: >> >> On Apr 2, 2016, at 1:35 PM, Peter Maydell wrote: >> >>> On 2 April 2016 at 18:25, Programmingkid wrote: On Apr 2, 2016, at

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 03 Apr 2016, at 15:28, Peter Maydell wrote: > since hw/arm/boot.o is in obj-y it should always be built, not necessarily, in my build configuration I have if's that exclude most of the files non related to Cortex-M. in previous versions boot.o was not needed.

Re: [Qemu-devel] [PATCH 2/2] target-mips: Implement IEEE 754-2008 functionality for R6 and MSA instructions

Hello, Leon, thank you very much for the kind feedback. Let me clarify my take on the involved issues. 1) Class operations I am going to correct the code as you hinted. The reason I wanted separate handling of MSA class operation is code and module decoupling. Handling of MSA instructions

Re: [Qemu-devel] [PATCH 1/2] softfloat: Enable run-time-configurable meaning of signaling NaN bit

I truly appreciate your guidance and bringing this matter to my attention. It just seems to me that, in similar case, 16-bit default NaN value should be 0x7E00. This value is needed for MSA operations. ("MIPS Architecture for Programmers Volume IV-j: The MIPS32® SIMD Architecture Module",

Re: [Qemu-devel] [PATCH 2/2] memory: hide mr->ram_addr from qemu_get_ram_ptr users

On Thu, Mar 24, 2016 at 12:03:35PM +0100, Paolo Bonzini wrote: > Let users of qemu_get_ram_ptr and qemu_ram_ptr_length pass in an > address that is relative to the MemoryRegion. This basically means > what address_space_translate returns. > > invalidate_and_set_dirty has to add back

Re: [Qemu-devel] [PATCH 1/2] memory: remove unnecessary masking of MemoryRegion ram_addr

On Thu, Mar 24, 2016 at 12:03:34PM +0100, Paolo Bonzini wrote: > mr->ram_block->offset is already aligned to both host and target size > (see qemu_ram_alloc_internal). Remove further masking as it is > unnecessary. > > Signed-off-by: Paolo Bonzini Reviewed-by: Michael S.

Re: [Qemu-devel] [PATCH] acpi: Fix TPM ACPI description to make TPM usable on Windows

On Fri, Apr 01, 2016 at 02:50:43PM -0400, Stefan Berger wrote: > On 03/31/2016 10:07 AM, Igor Mammedov wrote: > >On Thu, 31 Mar 2016 00:03:57 -0400 > >Stefan Berger wrote: > > > >>On 03/30/2016 09:33 AM, Igor Mammedov wrote: > >>>On Mon, 21 Mar 2016 10:21:11 -0400 >

Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code)

Markus Armbruster writes: > Peter Maydell writes: > [...] >> if we move away from C I'd rather >> it to be a language that's nicer than C rather than one that's >> uglier and larger and still retains all of C's flaws. > Seconded strongly. Just curious. Do we agree

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

On 2 April 2016 at 23:15, Liviu Ionescu wrote: > I just updated GNU ARM Eclipse QEMU to 2.5.1 and initially >I had some problems, main() failed quite early, in the first > call to `find_default_machine()`. > > After several debug sessions, I identified the problem to > be a null

Re: [Qemu-devel] [PATCH] ui/cocoa.m: fix sending mouse event to guest

On 2 April 2016 at 18:53, Programmingkid wrote: > > On Apr 2, 2016, at 1:35 PM, Peter Maydell wrote: > >> On 2 April 2016 at 18:25, Programmingkid wrote: >>> >>> On Apr 2, 2016, at 1:07 PM, Peter Maydell wrote: >>> On 2 April 2016 at

Re: [Qemu-devel] [PATCH v2] firmware: qemu_fw_cfg.c: hold ACPI global lock during device access

On Tue, Mar 08, 2016 at 01:30:50PM -0500, Gabriel Somlo wrote: > Allowing for the future possibility of implementing AML-based > (i.e., firmware-triggered) access to the QEMU fw_cfg device, > acquire the global ACPI lock when accessing the device on behalf > of the guest-side sysfs driver, to

[Qemu-devel] [PATCH] virtio-blk: assert on starting/stopping

Reentrancy cannot happen while the BQL is being held, so we should never enter this condition. Cc: Christian Borntraeger Cc: Cornelia Huck Cc: Paolo Bonzini Signed-off-by: Michael S. Tsirkin --- This is a

Re: [Qemu-devel] [PATCH 9/9] virtio: remove starting/stopping checks

On Fri, Apr 01, 2016 at 04:30:44PM +0200, Cornelia Huck wrote: > On Fri, 1 Apr 2016 16:14:22 +0200 > Christian Borntraeger wrote: > > > On 04/01/2016 03:19 PM, Paolo Bonzini wrote: > > > Reentrancy cannot happen while the BQL is being held. > > > > > > Reviewed-by:

Re: [Qemu-devel] [PATCH v2 0/9] virtio: aio handler API

On Fri, Apr 01, 2016 at 03:19:45PM +0200, Paolo Bonzini wrote: > This version fixes some commit messages, is based on qemu.git master > and adds Cornelia's Reviewed-by tags. There are no code changes apart > from context. I agree with patches 1-7 for 2.6. 8 and 9 are cleanups and IMO they are

Re: [Qemu-devel] [PATCH 8/9] virtio: merge virtio_queue_aio_set_host_notifier_handler with virtio_queue_set_aio

On Fri, Apr 01, 2016 at 03:19:53PM +0200, Paolo Bonzini wrote: > Eliminating the reentrancy is actually a nice thing that we can do > with the API that Michael proposed, so let's make it first class. > This also hides the complex assign/set_handler conventions from > callers of

Re: [Qemu-devel] [PATCH v2 0/9] virtio: aio handler API

On Fri, Apr 01, 2016 at 05:16:06PM +0200, Christian Borntraeger wrote: > Now with enable-debug and better call traces > > (gdb) > (gdb) thread apply all bt > > Thread 5 (Thread 0x3ffa0e7f910 (LWP 29839)): > #0 0x03ffa530334a in ioctl () at /lib64/libc.so.6 > #1 0x80081c84 in

[Qemu-devel] [PATCH] xen: piix reuse pci generic class init function

piix3_ide_xen_class_init is identical to piix3_ide_class_init except it's buggy as it does not set exit and does not disable hotplug properly. Switch to the generic one. Reviewed-by: Stefano Stabellini Signed-off-by: Michael S. Tsirkin ---

[Qemu-devel] [Bug 1563887] Status changed to Confirmed

This change was made by a bot. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1563887 Title: qemu-system-ppc64 freezes on starting