Re: [PATCH v2 0/6] hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work

On Sun, Mar 01, 2020 at 11:40:34AM +0100, Eric Auger wrote: > At the moment if the end-user does not specify the gic-version along > with KVM acceleration, v2 is set by default. However most of the > systems now have GICv3 and sometimes they do not support GICv2 > compatibility. In that case we

Re: [PATCH v2 6/6] hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work

On Sun, Mar 01, 2020 at 11:40:40AM +0100, Eric Auger wrote: > At the moment if the end-user does not specify the gic-version along > with KVM acceleration, v2 is set by default. However most of the > systems now have GICv3 and sometimes they do not support GICv2 > compatibility. > > This patch

[PULL 21/23] net/filter.c: Add Options to insert filters anywhere in the filter list

From: Lukas Straub To switch the Secondary to Primary, we need to insert new filters before the filter-rewriter. Add the options insert= and position= to be able to insert filters anywhere in the filter list. position should be "head" or "tail" to insert at the head or tail of the filter list

[PULL 23/23] l2tpv3: fix RFC number typo in qemu-options.hx

From: Stefan Hajnoczi The L2TPv3 RFC number is 3931: https://tools.ietf.org/html/rfc3931 Reported-by: Henrik Johansson Reviewed-by: Stefan Weil Signed-off-by: Stefan Hajnoczi Signed-off-by: Jason Wang --- qemu-options.hx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PULL 22/23] colo: Update Documentation for continuous replication

From: Lukas Straub Document the qemu command-line and qmp commands for continuous replication Signed-off-by: Lukas Straub Signed-off-by: Jason Wang --- docs/COLO-FT.txt | 224 + docs/block-replication.txt | 28 -- 2 files changed,

[PULL 19/23] block/replication.c: Ignore requests after failover

From: Lukas Straub After failover the Secondary side of replication shouldn't change state, because it now functions as our primary disk. In replication_start, replication_do_checkpoint, replication_stop, ignore the request if current state is BLOCK_REPLICATION_DONE (sucessful failover) or

[PULL 20/23] tests/test-replication.c: Add test for for secondary node continuing replication

From: Lukas Straub This simulates the case that happens when we resume COLO after failover. Signed-off-by: Lukas Straub Signed-off-by: Jason Wang --- tests/test-replication.c | 52 1 file changed, 52 insertions(+) diff --git

[PULL 18/23] hw: net: cadence_gem: Fix build errors in DB_PRINT()

From: Bin Meng When CADENCE_GEM_ERR_DEBUG is turned on, there are several compilation errors in DB_PRINT(). Fix them. While we are here, update to use appropriate modifiers in the same DB_PRINT() call. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis Signed-off-by: Jason Wang ---

[PULL 15/23] e1000e: Avoid hw_error if legacy mode used

From: Yuri Benditovich https://bugzilla.redhat.com/show_bug.cgi?id=1787142 The emulation issues hw_error if PSRCTL register is written, for example, with zero value. Such configuration does not present any problem when DTYP bits of RCTL register define legacy format of transfer descriptors.

[PULL 17/23] NetRxPkt: fix hash calculation of IPV6 TCP

From: Yuri Benditovich When requested to calculate the hash for TCPV6 packet, ignore overrides of source and destination addresses in in extension headers. Use these overrides when new hash type NetPktRssIpV6TcpEx requested. Use this type in e1000e hash calculation for IPv6 TCP, which should

Re: [PATCH v2] Arithmetic error in EDID generation fixed

Am 26.02.20 um 13:20 schrieb Anton V. Boyarshinov: > To calculate screen size in centimeters we should calculate: > pixels/dpi*2.54 > but not > pixels*dpi/2540 > > Using wrong formula we actually get 65 DPI and very small fonts. > > Signed-off-by: Anton V. Boyarshinov > --- > Changes from v1:

[PULL 14/23] dp8393x: Don't stop reception upon RBE interrupt assertion

From: Finn Thain Section 3.4.7 of the datasheet explains that, The RBE bit in the Interrupt Status register is set when the SONIC finishes using the second to last receive buffer and reads the last RRA descriptor. Actually, the SONIC is not truly out of resources, but gives the

[PULL 13/23] dp8393x: Don't reset Silicon Revision register

From: Finn Thain The jazzsonic driver in Linux uses the Silicon Revision register value to probe the chip. The driver fails unless the SR register contains 4. Unfortunately, reading this register in QEMU usually returns 0 because the s->regs[] array gets wiped after a software reset. Fixes:

[PULL 16/23] NetRxPkt: Introduce support for additional hash types

From: Yuri Benditovich Add support for following hash types: IPV6 TCP with extension headers IPV4 UDP IPV6 UDP IPV6 UDP with extension headers Signed-off-by: Yuri Benditovich Acked-by: Dmitry Fleytman Signed-off-by: Jason Wang --- hw/net/net_rx_pkt.c | 42

[PULL 06/23] dp8393x: Clear RRRA command register bit only when appropriate

From: Finn Thain It doesn't make sense to clear the command register bit unless the command was actually issued. Signed-off-by: Finn Thain Reviewed-by: Philippe Mathieu-Daudé Tested-by: Laurent Vivier Signed-off-by: Jason Wang --- hw/net/dp8393x.c | 7 +++ 1 file changed, 3

[PULL 11/23] dp8393x: Clear descriptor in_use field to release packet

From: Finn Thain When the SONIC receives a packet into the last available descriptor, it retains ownership of that descriptor for as long as necessary. Section 3.4.7 of the datasheet says, When the system appends more descriptors, the SONIC releases ownership of the descriptor after

[PULL 04/23] dp8393x: Have dp8393x_receive() return the packet size

From: Finn Thain This function re-uses its 'size' argument as a scratch variable. Instead, declare a local 'size' variable for that purpose so that the function result doesn't get messed up. Signed-off-by: Finn Thain Reviewed-by: Philippe Mathieu-Daudé Tested-by: Laurent Vivier

[PULL 05/23] dp8393x: Update LLFA and CRDA registers from rx descriptor

From: Finn Thain Follow the algorithm given in the National Semiconductor DP83932C datasheet in section 3.4.7: At the next reception, the SONIC re-reads the last RXpkt.link field, and updates its CRDA register to point to the next descriptor. The chip is designed to allow the host to

[PULL 12/23] dp8393x: Always update RRA pointers and sequence numbers

From: Finn Thain These operations need to take place regardless of whether or not rx descriptors have been used up (that is, EOL flag was observed). The algorithm is now the same for a packet that was withheld as for a packet that was not. Signed-off-by: Finn Thain Tested-by: Laurent Vivier

[PULL 09/23] dp8393x: Use long-word-aligned RRA pointers in 32-bit mode

From: Finn Thain Section 3.4.1 of the datasheet says, The alignment of the RRA is confined to either word or long word boundaries, depending upon the data width mode. In 16-bit mode, the RRA must be aligned to a word boundary (A0 is always zero) and in 32-bit mode, the RRA is

[PULL 02/23] dp8393x: Always use 32-bit accesses

From: Finn Thain The DP83932 and DP83934 have 32 data lines. The datasheet says, Data Bus: These bidirectional lines are used to transfer data on the system bus. When the SONIC is a bus master, 16-bit data is transferred on D15-D0 and 32-bit data is transferred on D31-D0. When the

[PULL 10/23] dp8393x: Pad frames to word or long word boundary

From: Finn Thain The existing code has a bug where the Remaining Buffer Word Count (RBWC) is calculated with a truncating division, which gives the wrong result for odd-sized packets. Section 1.4.1 of the datasheet says, Once the end of the packet has been reached, the serializer will

[PULL 01/23] dp8393x: Mask EOL bit from descriptor addresses

From: Finn Thain The Least Significant bit of a descriptor address register is used as an EOL flag. It has to be masked when the register value is to be used as an actual address for copying memory around. But when the registers are to be updated the EOL bit should not be masked. Signed-off-by:

[PULL 07/23] dp8393x: Implement packet size limit and RBAE interrupt

From: Finn Thain Add a bounds check to prevent a large packet from causing a buffer overflow. This is defensive programming -- I haven't actually tried sending an oversized packet or a jumbo ethernet frame. The SONIC handles packets that are too big for the buffer by raising the RBAE interrupt

[PULL 02/23] dp8393x: Always use 32-bit accesses

From: Finn Thain The DP83932 and DP83934 have 32 data lines. The datasheet says, Data Bus: These bidirectional lines are used to transfer data on the system bus. When the SONIC is a bus master, 16-bit data is transferred on D15-D0 and 32-bit data is transferred on D31-D0. When the

[PULL 00/23] Net patches

The following changes since commit e0175b71638cf4398903c0d25f93fe62e0606389: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' into staging (2020-02-28 16:39:27 +) are available in the git repository at: https://github.com/jasowang/qemu.git

[PULL 08/23] dp8393x: Don't clobber packet checksum

From: Finn Thain A received packet consumes pkt_size bytes in the buffer and the frame checksum that's appended to it consumes another 4 bytes. The Receive Buffer Address register takes the former quantity into account but not the latter. So the next packet written to the buffer overwrites the

[PULL 03/23] dp8393x: Clean up endianness hacks

From: Finn Thain According to the datasheet, section 3.4.4, "in 32-bit mode ... the SONIC always writes long words". Therefore, use the same technique for the 'in_use' field that is used everywhere else, and write the full long word. Signed-off-by: Finn Thain Tested-by: Laurent Vivier

[PULL 01/23] dp8393x: Mask EOL bit from descriptor addresses

From: Finn Thain The Least Significant bit of a descriptor address register is used as an EOL flag. It has to be masked when the register value is to be used as an actual address for copying memory around. But when the registers are to be updated the EOL bit should not be masked. Signed-off-by:

[PULL 00/23] Net patches

The following changes since commit e0175b71638cf4398903c0d25f93fe62e0606389: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' into staging (2020-02-28 16:39:27 +) are available in the git repository at: https://github.com/jasowang/qemu.git

Re: [PATCH v2] Arithmetic error in EDID generation fixed

On Wed, Feb 26, 2020 at 03:20:54PM +0300, Anton V. Boyarshinov wrote: > To calculate screen size in centimeters we should calculate: > pixels/dpi*2.54 > but not > pixels*dpi/2540 > > Using wrong formula we actually get 65 DPI and very small fonts. Added to vga patch queu. thanks, Gerd

Re: [Qemu-devel] [PATCH RFC v5 0/5] virtio-iommu: VFIO integration

Hi Bharat, On 3/2/20 6:12 AM, Bharat Bhushan wrote: > > Hi Eric,  > > On Fri, Feb 28, 2020 at 3:06 PM Auger Eric > wrote: > > Hi Bharat, > > On 11/27/18 7:52 AM, Bharat Bhushan wrote: > > This patch series integrates VFIO with virtio-iommu. This is >

Re: [PATCH] l2tpv3: fix RFC number typo in qemu-options.hx

On 2020/2/29 下午7:57, Stefan Weil wrote: Am 29.02.20 um 12:17 schrieb Stefan Hajnoczi: The L2TPv3 RFC number is 3931: https://tools.ietf.org/html/rfc3931 Reported-by: Henrik Johansson Signed-off-by: Stefan Hajnoczi --- qemu-options.hx | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

On 3/1/20 4:13 PM, Programmingkid wrote: > Ok, I was just looking at Intel's x87 chip documentation. It supports IEEE > 754 floating point operations and exception flags. This leads me to this > question. Would simply taking the host exception flags and using them to set > the PowerPC's FPU's

[PATCH V3] vhost: correctly turn on VIRTIO_F_IOMMU_PLATFORM

We turn on device IOTLB via VIRTIO_F_IOMMU_PLATFORM unconditionally on platform without IOMMU support. This can lead unnecessary IOTLB transactions which will damage the performance. Fixing this by check whether the device is backed by IOMMU and disable device IOTLB. Reported-by: Halil Pasic

Re: [PATCH v2] i386: Fix GCC warning with snprintf when HAX is enabled

On 3/1/20 11:17 AM, Julio Faracco wrote: > -snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); > +assert(vm_id < 0); > + > +if (snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", > + vm_id) < 0) > +return NULL; > + And the assert is

Re: [PATCH v2] i386: Fix GCC warning with snprintf when HAX is enabled

On 3/1/20 11:17 AM, Julio Faracco wrote: > -snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); > +assert(vm_id < 0); > + > +if (snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", > + vm_id) < 0) > +return NULL; > + No, you don't need the

[PATCH] virtio-serial-bus: do cleanup on the error path in realize() to avoid memleaks

port->bh forgot to delete on the error path, this patch add it to fix memleaks. It's easy to reproduce as follow(add a same nr port): {'execute': 'device_add', 'arguments': {'id': 'virtio_serial_pci0', 'driver': 'virtio-serial-pci', 'bus': 'pci.0', 'addr': '0x5'}, 'id': 'yVkZcGgV'}

[Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.

Im using Mint 19.3 based on Ubuntu 18.04 with QEMU 2.11 from repository, keyboard is working but mouse not in Win98. Could someone else to restest it? Here is my Qemu starting script: qemu-system-x86_64 -m 512 \ -machine type=pc-i440fx-bionic \ -smp 1,sockets=1,cores=1,threads=1 \ -vga

Re: [PATCH v3] i386: Fix GCC warning with snprintf when HAX is enabled

Sorry my ignorance, Paolo. But why should I remove MAX_{VM,VCPU}_ID? Did you mean that check? if (vm_id > MAX_VM_ID || vcpu_id > MAX_VCPU_ID) { fprintf(stderr, "Too big vm id %x or vcpu id %x\n", vm_id, vcpu_id); return NULL; } Wouldn't it be dangerous? -- Julio Cesar

Re: [PATCH V2] MAINTAINERS: Add entry for Guest X86 HAXM CPUs

On 2020-02-28 19:00, Paolo Bonzini wrote: On 28/02/20 02:20, Colin Xu wrote: HAXM covers below files: include/sysemu/hax.h target/i386/hax-* V2: Add HAXM github page for wiki and issue tracking. Cc: Wenchao Wang Cc: Hang Yuan Reviewed-by: Hang Yuan Signed-off-by: Colin Xu ---

Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

> On Feb 26, 2020, at 1:09 PM, Alex Bennée wrote: > > > G 3 writes: > >> Accuracy is an important part of the IEEE 754 floating point standard. The >> whole purpose of this standard is to ensure floating point calculations are >> consistent across multiple CPUs. I believe referring to this

Re: [PATCH v3] i386: Fix GCC warning with snprintf when HAX is enabled

On 01/03/20 20:21, Julio Faracco wrote: > +assert(vm_id < 0); > + > +if (snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", > + vm_id) < 0) > +return NULL; > + > return name; > } > > @@ -140,8 +145,12 @@ static char *hax_vcpu_devfs_string(int vm_id,

qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.

I got this while running qemu under VNC, and was told to report it. including the following information: - Operating system Debian GNU/Linux sid/x32 - X11 Server x11vnc 0.9.16-3 - xprop -root _NET_ACTIVE_WINDOW(WINDOW): window id # 0x1400010

[PATCH v6 18/18] docs: add Orange Pi PC document

The Xunlong Orange Pi PC machine is a functional ARM machine based on the Allwinner H3 System-on-Chip. It supports mainline Linux, U-Boot, NetBSD and is covered by acceptance tests. This commit adds a documentation text file with a description of the machine and instructions for the user.

[PATCH v6 09/18] hw/arm/allwinner-h3: add EMAC ethernet device

The Allwinner Sun8i System on Chip family includes an Ethernet MAC (EMAC) which provides 10M/100M/1000M Ethernet connectivity. This commit adds support for the Allwinner EMAC from the Sun8i family (H2+, H3, A33, etc), including emulation for the following functionality: * DMA transfers * MII

[PATCH v6 12/18] hw/arm/allwinner: add RTC device support

Allwinner System-on-Chips usually contain a Real Time Clock (RTC) for non-volatile system date and time keeping. This commit adds a generic Allwinner RTC device that supports the RTC devices found in Allwinner SoC family sun4i (A10), sun7i (A20) and sun6i and newer (A31, H2+, H3, etc). The

[PATCH v6 11/18] hw/arm/allwinner-h3: add SDRAM controller device

In the Allwinner H3 SoC the SDRAM controller is responsible for interfacing with the external Synchronous Dynamic Random Access Memory (SDRAM). Types of memory that the SDRAM controller supports are DDR2/DDR3 and capacities of up to 2GiB. This commit adds emulation support of the Allwinner H3

[PATCH v6 15/18] tests/boot_linux_console: Add a SD card test for the OrangePi PC board

From: Philippe Mathieu-Daudé The kernel image and DeviceTree blob are built by the Armbian project (based on Debian): https://www.armbian.com/orange-pi-pc/ The SD image is from the kernelci.org project: https://kernelci.org/faq/#the-code If ARM is a target being built, "make check-acceptance"

[PATCH v6 13/18] tests/boot_linux_console: Add a quick test for the OrangePi PC board

From: Philippe Mathieu-Daudé This test boots a Linux kernel on a OrangePi PC board and verify the serial output is working. The kernel image and DeviceTree blob are built by the Armbian project (based on Debian): https://www.armbian.com/orange-pi-pc/ If ARM is a target being built, "make

[PATCH v6 08/18] hw/arm/allwinner: add SD/MMC host controller

The Allwinner System on Chip families sun4i and above contain an integrated storage controller for Secure Digital (SD) and Multi Media Card (MMC) interfaces. This commit adds support for the Allwinner SD/MMC storage controller with the following emulated features: * DMA transfers * Direct FIFO

[PATCH v6 10/18] hw/arm/allwinner-h3: add Boot ROM support

A real Allwinner H3 SoC contains a Boot ROM which is the first code that runs right after the SoC is powered on. The Boot ROM is responsible for loading user code (e.g. a bootloader) from any of the supported external devices and writing the downloaded code to internal SRAM. After loading the SoC

[PATCH v6 07/18] hw/arm/allwinner: add Security Identifier device

The Security Identifier device found in various Allwinner System on Chip designs gives applications a per-board unique identifier. This commit adds support for the Allwinner Security Identifier using a 128-bit UUID value as input. Signed-off-by: Niek Linnenbank --- include/hw/arm/allwinner-h3.h

[PATCH v6 17/18] tests/boot_linux_console: Test booting NetBSD via U-Boot on OrangePi PC

From: Philippe Mathieu-Daudé This test boots U-Boot then NetBSD (stored on a SD card) on a OrangePi PC board. As it requires ~1.3GB of storage, it is disabled by default. U-Boot is built by the Debian project [1], and the SD card image is provided by the NetBSD organization [2]. Once the

[PATCH v6 04/18] hw/arm/allwinner-h3: add USB host controller

The Allwinner H3 System on Chip contains multiple USB 2.0 bus connections which provide software access using the Enhanced Host Controller Interface (EHCI) and Open Host Controller Interface (OHCI) interfaces. This commit adds support for both interfaces in the Allwinner H3 System on Chip.

[PATCH v6 06/18] hw/arm/allwinner: add CPU Configuration module

Various Allwinner System on Chip designs contain multiple processors that can be configured and reset using the generic CPU Configuration module interface. This commit adds support for the Allwinner CPU configuration interface which emulates the following features: * CPU reset * CPU status

[PATCH v6 02/18] hw/arm: add Xunlong Orange Pi PC machine

The Xunlong Orange Pi PC is an Allwinner H3 System on Chip based embedded computer with mainline support in both U-Boot and Linux. The board comes with a Quad Core Cortex A7 @ 1.3GHz, 1GiB RAM, 100Mbit ethernet, USB, SD/MMC, USB, HDMI and various other I/O. This commit add support for the Xunlong

[PATCH v6 16/18] tests/boot_linux_console: Add a SLOW test booting Ubuntu on OrangePi PC

From: Philippe Mathieu-Daudé This test boots Ubuntu Bionic on a OrangePi PC board. As it requires 1GB of storage, and is slow, this test is disabled on automatic CI testing. It is useful for workstation testing. Currently Avocado timeouts too quickly, so we can't run userland commands. The

[PATCH v6 03/18] hw/arm/allwinner-h3: add Clock Control Unit

The Clock Control Unit is responsible for clock signal generation, configuration and distribution in the Allwinner H3 System on Chip. This commit adds support for the Clock Control Unit which emulates a simple read/write register interface. Signed-off-by: Niek Linnenbank Reviewed-by: Philippe

[PATCH v6 14/18] tests/boot_linux_console: Add initrd test for the Orange Pi PC board

From: Philippe Mathieu-Daudé This test boots a Linux kernel on a OrangePi PC board and verify the serial output is working. The kernel image and DeviceTree blob are built by the Armbian project (based on Debian): https://www.armbian.com/orange-pi-pc/ The cpio image used comes from the

[PATCH v6 00/18] Add Allwinner H3 SoC and Orange Pi PC Machine

Dear QEMU developers, Hereby I would like to contribute the following set of patches to QEMU which add support for the Allwinner H3 System on Chip and the Orange Pi PC machine. The following features and devices are supported: * SMP (Quad Core Cortex A7) * Generic Interrupt Controller

[PATCH v6 01/18] hw/arm: add Allwinner H3 System-on-Chip

The Allwinner H3 is a System on Chip containing four ARM Cortex A7 processor cores. Features and specifications include DDR2/DDR3 memory, SD/MMC storage cards, 10/100/1000Mbit Ethernet, USB 2.0, HDMI and various I/O modules. This commit adds support for the Allwinner H3 System on Chip.

[PATCH v6 05/18] hw/arm/allwinner-h3: add System Control module

The Allwinner H3 System on Chip has an System Control module that provides system wide generic controls and device information. This commit adds support for the Allwinner H3 System Control module. Signed-off-by: Niek Linnenbank Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe

Re: [PATCH v2 1/2] dp264: use pci_create() to initialise the cmd646 device

On Sun, 1 Mar 2020, Mark Cave-Ayland wrote: Remove the call to pci_cmd646_ide_init() since global device init functions are deprecated in preference of using qdev directly. Signed-off-by: Mark Cave-Ayland Reviewed-by: Richard Henderson --- hw/alpha/dp264.c | 7 ++- 1 file changed, 6

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On Sun, 1 Mar 2020, Mark Cave-Ayland wrote: On 01/03/2020 18:53, BALATON Zoltan wrote: On Sun, 1 Mar 2020, BALATON Zoltan wrote: is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a which corresponds to native mode but this is what the Linux fixup function does, firmware

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On 01/03/2020 18:53, BALATON Zoltan wrote: > On Sun, 1 Mar 2020, BALATON Zoltan wrote: >> is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a >> which >> corresponds to native mode but this is what the Linux fixup function does, >> firmware >> sets it to 0x8f which means

[PATCH v3] i386: Fix GCC warning with snprintf when HAX is enabled

When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). This commit is checking if snprintf returns an error. This is a simple way to avoid this warnings. An `assert()` boundary checks were added before snprintf too. For more details, one example of warning: CC

[PATCH v2] i386: Fix GCC warning with snprintf when HAX is enabled

When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). This commit is checking if snprintf returns an error. This is a simple way to avoid this warnings. An `assert()` boundary checks were added before snprintf too. For more details, one example of warning: CC

[PATCH v2 1/2] dp264: use pci_create() to initialise the cmd646 device

Remove the call to pci_cmd646_ide_init() since global device init functions are deprecated in preference of using qdev directly. Signed-off-by: Mark Cave-Ayland Reviewed-by: Richard Henderson --- hw/alpha/dp264.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

[PATCH v2 0/2] cmd646: remove pci_cmd646_ide_init() function

The recent cmd646 discussions reminded me of this patch I've had sitting in an old branch for a while. The DP264 machine is the last remaining user of the deprecated pci_cmd646_ide_init() init function. Switch it over to using qdev via pci_create() and then remove the now-unused

[PATCH v2 2/2] cmd646: remove unused pci_cmd646_ide_init() function

Signed-off-by: Mark Cave-Ayland Reviewed-by: Richard Henderson --- hw/ide/cmd646.c | 12 include/hw/ide.h | 2 -- 2 files changed, 14 deletions(-) diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c index 335c060673..d953932104 100644 --- a/hw/ide/cmd646.c +++ b/hw/ide/cmd646.c @@

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On Sun, 1 Mar 2020, BALATON Zoltan wrote: is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a which corresponds to native mode but this is what the Linux fixup function does, firmware sets it to 0x8f which means native mode. I mean, 0x8a legacy mode and 0x8f native mode,

Re: [PATCH] i386: Fix GCC warning with snprintf when HAX is enabled

On 3/1/20 8:35 AM, Julio Faracco wrote: > When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with > snprintf(). This commit is checking if snprintf returns an error. This > is a simple way to avoid this warnings. > > For more details, one example of warning: > CC

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On Sun, 1 Mar 2020, Mark Cave-Ayland wrote: On 01/03/2020 16:42, BALATON Zoltan wrote: The other part I'm not sure about is that I can't see how via_ide_set_irq() can ever raise a native PCI IRQ - comparing with my experience on cmd646, should there not be a pci_set_irq(d, level) at the end?

Re: [PATCH v2 5/6] hw/arm/virt: kvm: Check the chosen gic version is supported by the host

Hi Richard, On 3/1/20 6:56 PM, Richard Henderson wrote: > On 3/1/20 2:40 AM, Eric Auger wrote: >> +/* Check chosen version is effectively supported by the host */ >> +if (vms->gic_version == VIRT_GIC_VERSION_2 && >> + !(probe_bitmap & KVM_ARM_VGIC_V2)) { >> +

Re: [PATCH] hw/ide: Remove status register read side effect

Hello, On Wed, 26 Feb 2020, jasper.low...@bt.com wrote: According to the CMD646U2 specification: "When an IDE port is in PCI IDE Legacy Mode, the PCI646U2 is compatible with standard ISA IDE. The IDE task file registers are mapped to the standard ISA port addresses, and IDE drive interrupts

Re: [PATCH v2 6/6] hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work

On 3/1/20 2:40 AM, Eric Auger wrote: > At the moment if the end-user does not specify the gic-version along > with KVM acceleration, v2 is set by default. However most of the > systems now have GICv3 and sometimes they do not support GICv2 > compatibility. > > This patch keeps the default v2

Re: [PATCH v2 5/6] hw/arm/virt: kvm: Check the chosen gic version is supported by the host

On 3/1/20 2:40 AM, Eric Auger wrote: > +/* Check chosen version is effectively supported by the host */ > +if (vms->gic_version == VIRT_GIC_VERSION_2 && > + !(probe_bitmap & KVM_ARM_VGIC_V2)) { > +error_report("host does not support in-kernel GICv2 >

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On 01/03/2020 16:42, BALATON Zoltan wrote: >> The other part I'm not sure about is that I can't see how via_ide_set_irq() >> can ever >> raise a native PCI IRQ - comparing with my experience on cmd646, should >> there not be >> a pci_set_irq(d, level) at the end? > > According to my tests with

Re: [PATCH v2 4/6] target/arm/kvm: Let kvm_arm_vgic_probe() return a bitmap

On 3/1/20 2:40 AM, Eric Auger wrote: > Convert kvm_arm_vgic_probe() so that it returns a > bitmap of supported in-kernel emulation VGIC versions instead > of the max version: at the moment values can be v2 and v3. > This allows to expose the case where the host GICv3 also > supports GICv2

Re: [PATCH v2 3/6] hw/arm/virt: Introduce finalize_gic_version()

On 3/1/20 2:40 AM, Eric Auger wrote: > Let's move the code which freezes which gic-version to > be applied in a dedicated function. We also now set by > default the VIRT_GIC_VERSION_NO_SET. This eventually > turns into the legacy v2 choice in the finalize() function. > > Signed-off-by: Eric Auger

Re: [PATCH v2 2/6] hw/arm/virt: Use VIRT_GIC_VERSION defines

On 3/1/20 2:40 AM, Eric Auger wrote: > +#define VIRT_GIC_VERSION_MAX(-1) > +#define VIRT_GIC_VERSION_HOST 0 > +#define VIRT_GIC_VERSION_2 2 > +#define VIRT_GIC_VERSION_3 3 Any reason this shouldn't be enum VirtGICType? Anyway, this is an improvement. Reviewed-by: Richard

Re: [PATCH v2 1/6] hw/arm/virt: Document 'max' value in gic-version property description

On 3/1/20 2:40 AM, Eric Auger wrote: > Mention 'max' value in the gic-version property description. > > Signed-off-by: Eric Auger > --- > hw/arm/virt.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~

[PATCH 3/3] hw/arm/fsl-imx6: Wire up USB controllers

With this patch, the USB controllers on 'sabrelite' are detected and can be used to boot the system. Signed-off-by: Guenter Roeck --- hw/arm/Kconfig| 2 ++ hw/arm/fsl-imx6.c | 36 include/hw/arm/fsl-imx6.h | 3 +++ 3 files changed, 41

[PATCH 1/3] Add dummy i.MXS STMP register support

STMP registers are registers with a specific register layout. When using this layout, a register is implemented as set of four: - The register itself - A register to set individual register bits - A register to reset individual register bits - A register to toggle individual register bits This

[PATCH 2/3] arm: fsl-imx6ul: Wire up USB controllers

IMX6UL USB controllers are quite similar to IMX7 USB controllers. Wire them up the same way. The only real difference is that wiring up dummy phy devices is necessary to avoid phy reset timeouts in the Linux kernel. With this patch, the USB controllers on 'mcimx6ul-evk' are detected and can be

[PATCH 0/3] Wire up USB controllers on fsl-imx6 and fsl-imx6ul

This patch series wires up the USB controllers on fsl-imx6 and fsl-imx6ul emulations. The first patch is a prerequisite for the following patches. It provides a dummy implementation of a register widely used on i.MX systems, and specifically the reset behavior of this register. This is needed to

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On Sun, 1 Mar 2020, Mark Cave-Ayland wrote: On 01/03/2020 11:35, Mark Cave-Ayland wrote: On 29/02/2020 23:02, BALATON Zoltan wrote: Some machines operate in "non 100% native mode" where interrupts are fixed at legacy IDE interrupts and some guests expect this behaviour without checking based

[PATCH] i386: Fix GCC warning with snprintf when HAX is enabled

When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). This commit is checking if snprintf returns an error. This is a simple way to avoid this warnings. For more details, one example of warning: CC i386-softmmu/target/i386/hax-posix.o qemu/target/i386/hax-posix.c:

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On Sun, 1 Mar 2020, Mark Cave-Ayland wrote: On 29/02/2020 23:02, BALATON Zoltan wrote: Some machines operate in "non 100% native mode" where interrupts are fixed at legacy IDE interrupts and some guests expect this behaviour without checking based on knowledge about hardware. Even Linux has

[Bug 1865350] [NEW] fstrim not working with image mounted to path?

Public bug reported: guest os: windows server standard 2016 qemu agent version 100.0.0 os supports trimming path mounted image does not support trimming C:\Users\Administrator>fsutil behavior query disabledeletenotify NTFS DisableDeleteNotify = 0 ReFS DisableDeleteNotify = 1 [@ ~]# virsh

Re: [PATCH 1/2] ide: Make room for flags in PCIIDEState and add one for legacy IRQ routing

On Sun, 1 Mar 2020, Mark Cave-Ayland wrote: On 29/02/2020 23:02, BALATON Zoltan wrote: We'll need a flag for implementing some device specific behaviour in via-ide but we already have a currently CMD646 specific field that can be repurposed for this and leave room for furhter flags if needed in

[Bug 1865348] [NEW] virsh domfsinfo testdom crashes the guest agent

Public bug reported: [@ ~]# virsh qemu-agent-command vps-01 '{"execute":"guest-get-fsinfo"}' error: Guest agent is not responding: Guest agent disappeared while executing command [@ ~]# virsh domfsinfo vps-01 error: Unable to get filesystem information error: Guest agent is not responding:

[Question] About GET LBA STATUS(16) support in qemu scsi emulation layer

Hi all, I'm not familiar with scsi, I'm curious why there is no GET LBA STATUS(16) support in qemu scsi emulation layer. So far, There is only one subcommand of SERVICE ACTION was implemented: The READ CAPACITY(16) e.g. static int32_t scsi_disk_emulate_command(SCSIRequest *req, uint8_t *buf)

Re: [PATCH v2 1/2] tests/vhost-user-bridge: move to contrib/

On Fri, Feb 07, 2020 at 10:54:11AM +0100, Laurent Vivier wrote: > vhost-user-bridge is not a test. Move it to contrib/ and > add it to the tools list. > > It will be built only if tools (--enable-tools) and > vhost-user (--enable-vhost-user) are enabled (both are set > by default). > >

[PATCH] vhost-vsock: fix error message output

error_setg_errno takes a positive error number, so we should not invert errno's sign. Signed-off-by: Nick Erdmann --- hw/virtio/vhost-vsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c index 66da96583b..9f9093e196

Re: [PATCH v5 00/50] Initial support for multi-process qemu

Jagannathan Raman writes: > Hello > > Started with the presentation in October 2017 made by Marc-Andre (Red Hat) > and Konrad Wilk (Oracle) [1], and continued by Jag's BoF at KVM Forum 2018, > the multi-process project is now available and presented in this patchset. > This first series

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On 01/03/2020 11:35, Mark Cave-Ayland wrote: > On 29/02/2020 23:02, BALATON Zoltan wrote: > >> Some machines operate in "non 100% native mode" where interrupts are >> fixed at legacy IDE interrupts and some guests expect this behaviour >> without checking based on knowledge about hardware. Even

Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

On 29/02/2020 23:02, BALATON Zoltan wrote: > Some machines operate in "non 100% native mode" where interrupts are > fixed at legacy IDE interrupts and some guests expect this behaviour > without checking based on knowledge about hardware. Even Linux has > arch specific workarounds for this that

Re: [PATCH 1/2] ide: Make room for flags in PCIIDEState and add one for legacy IRQ routing

On 29/02/2020 23:02, BALATON Zoltan wrote: > We'll need a flag for implementing some device specific behaviour in > via-ide but we already have a currently CMD646 specific field that can > be repurposed for this and leave room for furhter flags if needed in > the future. This patch changes the

  1   2   >