[PATCH 2/2] hw/i2c: add pca954x i2c-mux switch
The pca954x is an i2c mux, and this adds support for two variants of
this device: the pca9546 and pca9548.
This device is very common on BMCs to route a different channel to each
PCIe i2c bus downstream from the BMC.
Signed-off-by: Patrick Venture
Reviewed-by: Havard Skinnemoen
Reviewed-by: Hao Wu
---
MAINTAINERS | 6 +
hw/i2c/Kconfig | 4 +
hw/i2c/i2c_mux_pca954x.c | 182 +++
hw/i2c/meson.build | 1 +
hw/i2c/trace-events | 5 +
include/hw/i2c/i2c_mux_pca954x.h | 60 ++
6 files changed, 258 insertions(+)
create mode 100644 hw/i2c/i2c_mux_pca954x.c
create mode 100644 include/hw/i2c/i2c_mux_pca954x.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 69003cdc3c..6cec2a9320 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2040,6 +2040,12 @@ S: Maintained
F: hw/net/tulip.c
F: hw/net/tulip.h
+pca954x
+M: Patrick Venture
+S: Maintained
+F: hw/i2c/i2c_mux_pca954x.c
+F: include/hw/i2c/i2c_mux_pca954x.h
+
Generic Loader
M: Alistair Francis
S: Maintained
diff --git a/hw/i2c/Kconfig b/hw/i2c/Kconfig
index 09642a6dcb..8d120a25d5 100644
--- a/hw/i2c/Kconfig
+++ b/hw/i2c/Kconfig
@@ -28,3 +28,7 @@ config IMX_I2C
config MPC_I2C
bool
select I2C
+
+config PCA954X
+bool
+select I2C
diff --git a/hw/i2c/i2c_mux_pca954x.c b/hw/i2c/i2c_mux_pca954x.c
new file mode 100644
index 00..8017913637
--- /dev/null
+++ b/hw/i2c/i2c_mux_pca954x.c
@@ -0,0 +1,182 @@
+/*
+ * I2C multiplexer for PCA954x series of I2C multiplexer/switch chips.
+ *
+ * Copyright 2021 Google LLC
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/i2c/i2c_mux_pca954x.h"
+#include "hw/i2c/smbus_slave.h"
+#include "hw/qdev-core.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "qemu/queue.h"
+#include "trace.h"
+
+int pca954x_add_child(I2CSlave *mux, uint8_t channel, I2CSlave *child)
+{
+g_autofree char *name = NULL;
+/*
+ * Ok, so we need to try to add the i2c_dev to channel for mux.
+ * A channel can have multiple devices, we need a list for each channel.
+ */
+Pca954xClass *pc = PCA954X_GET_CLASS(mux);
+Pca954xState *pca954x = PCA954X(mux);
+PcaMuxChild *controlled_device;
+
+/* Is the channel legal? */
+if (channel >= pc->nchans) {
+return -1;
+}
+
+controlled_device = g_new0(PcaMuxChild, 1);
+controlled_device->channel = channel;
+controlled_device->child = child;
+object_ref(OBJECT(controlled_device->child));
+
+/* Hide the device. */
+child->reachable = 0;
+
+QSLIST_INSERT_HEAD(>children, controlled_device, sibling);
+
+name = g_strdup_printf("i2c@%u-child[%u]", channel,
+ pca954x->count[channel]);
+object_property_add_link(OBJECT(mux), name,
+ object_get_typename(OBJECT(child)),
+ (Object **)_device->child,
+ NULL, /* read-only property */
+ 0);
+pca954x->count[channel]++;
+
+return 0;
+}
+
+static void pca954x_enable_channel(Pca954xState *s, uint8_t enable_mask)
+{
+PcaMuxChild *kid;
+I2CSlave *child;
+
+/*
+ * For each child, check if their bit is set in data and if yes, enable
+ * them, otherwise disable, hide them.
+ */
+QSLIST_FOREACH(kid, >children, sibling) {
+child = I2C_SLAVE(kid->child);
+if (enable_mask & (1 << kid->channel)) {
+child->reachable = true;
+} else {
+child->reachable = false;
+}
+}
+}
+
+static void pca954x_write(Pca954xState *s, uint8_t data)
+{
+s->control = data;
+pca954x_enable_channel(s, data);
+
+trace_pca954x_write_bytes(data);
+}
+
+static int pca954x_write_data(SMBusDevice *d, uint8_t *buf, uint8_t len)
+{
+Pca954xState *s = PCA954X(d);
+
+if (len == 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: writing empty data\n", __func__);
+return -1;
+}
+
+/*
+ * len should be 1, because they write one byte to enable/disable channels.
+ */
+if (len > 1) {
+qemu_log_mask(LOG_GUEST_ERROR,
+"%s: extra data after channel selection mask\n",
+__func__);
+return -1;
+}
+
+pca954x_write(s, buf[0]);
+return 0;
+}
+
+static uint8_t pca954x_read_byte(SMBusDevice *d)
+{
+Pca954xState *s = PCA954X(d);
+uint8_t data = s->control;
+
[PATCH 1/2] hw/i2c/core: add reachable state boolean
An i2c device can be reachable or not, controlled by some external
factor. This field is leveraged by an i2c mux which presents the
devices on the parent bus when the associated channel is enabled and
otherwise not.
Signed-off-by: Patrick Venture
Reviewed-by: Havard Skinnemoen
Reviewed-by: Hao Wu
---
hw/i2c/core.c| 6 ++
include/hw/i2c/i2c.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/hw/i2c/core.c b/hw/i2c/core.c
index 21ec52ac5a..fa7db4549d 100644
--- a/hw/i2c/core.c
+++ b/hw/i2c/core.c
@@ -18,6 +18,7 @@
#define I2C_BROADCAST 0x00
static Property i2c_props[] = {
+DEFINE_PROP_BOOL("reachable", struct I2CSlave, reachable, true),
DEFINE_PROP_UINT8("address", struct I2CSlave, address, 0),
DEFINE_PROP_END_OF_LIST(),
};
@@ -118,6 +119,9 @@ int i2c_start_transfer(I2CBus *bus, uint8_t address, int
recv)
QTAILQ_FOREACH(kid, >qbus.children, sibling) {
DeviceState *qdev = kid->child;
I2CSlave *candidate = I2C_SLAVE(qdev);
+if (!candidate->reachable) {
+continue;
+}
if ((candidate->address == address) || (bus->broadcast)) {
node = g_malloc(sizeof(struct I2CNode));
node->elt = candidate;
@@ -262,6 +266,7 @@ const VMStateDescription vmstate_i2c_slave = {
.minimum_version_id = 1,
.post_load = i2c_slave_post_load,
.fields = (VMStateField[]) {
+VMSTATE_BOOL(reachable, I2CSlave),
VMSTATE_UINT8(address, I2CSlave),
VMSTATE_END_OF_LIST()
}
@@ -272,6 +277,7 @@ I2CSlave *i2c_slave_new(const char *name, uint8_t addr)
DeviceState *dev;
dev = qdev_new(name);
+qdev_prop_set_bit(dev, "reachable", true);
qdev_prop_set_uint8(dev, "address", addr);
return I2C_SLAVE(dev);
}
diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
index 277dd9f2d6..e5ca15e486 100644
--- a/include/hw/i2c/i2c.h
+++ b/include/hw/i2c/i2c.h
@@ -44,6 +44,9 @@ struct I2CSlaveClass {
struct I2CSlave {
DeviceState qdev;
+/* Whether the i2c child device is reachable from this bus. */
+bool reachable;
+
/* Remaining fields for internal use by the I2C code. */
uint8_t address;
};
--
2.31.0.208.g409f899ff0-goog
[PATCH 0/2] hw/i2c: Adds pca954x i2c mux switch device
The i2c mux device pca954x implements two devices: - the pca9546 and pca9548. Patrick Venture (2): hw/i2c/core: add reachable state boolean hw/i2c: add pca954x i2c-mux switch MAINTAINERS | 6 + hw/i2c/Kconfig | 4 + hw/i2c/core.c| 6 + hw/i2c/i2c_mux_pca954x.c | 182 +++ hw/i2c/meson.build | 1 + hw/i2c/trace-events | 5 + include/hw/i2c/i2c.h | 3 + include/hw/i2c/i2c_mux_pca954x.h | 60 ++ 8 files changed, 267 insertions(+) create mode 100644 hw/i2c/i2c_mux_pca954x.c create mode 100644 include/hw/i2c/i2c_mux_pca954x.h -- 2.31.0.208.g409f899ff0-goog
Re: [PATCH v3 00/11] target/arm mte fixes
On 4/2/21 2:42 PM, Richard Henderson wrote: Changes for v3: * linux-user mprotect fix moved to start, just to get it out of the way while I reworked the others. * Patch 2, the fix for unaligned accesses, has been split into 9. Hopefully these are much easier to review than previously. Technically only patches 1-6,11 are required for bug fixing. Patches 7-10 are only cleanups, but I think they're important for clarity post bug fixing. ... and it fails all of the kasan unit tests. I'll have to investigate more next week. r~
[Bug 1915063] Re: Windows 10 wil not install using qemu-system-x86_64
That is awesome David, qemu64 is like a very low common denominator with only very basic CPU features. While "copy host" means "enable all you can". We can surely work with that a bit, but until I get access to the same HW I need you to do it. If you run in a console `$virsh domcapabilities` it will spew some XML at you. One of the sections will be for "host-model". In my case that looks like Skylake-Client-IBRS Intel ... That means a names CPU type (the one that is closest to what you have) and some feature additionally enabled/disabled. If you could please post the full output you have, that can be useful. >From there you could go two steps. 1. as you see in my example it will list some cpu features on top of the named type. If you remove them one by one you might be able to identify the single-cpu featute that breaks in your case. 2. The named CPU that you have also has a representation, it can be found in /usr/share/libvirt/cpu_map... That ill list all the CPU features that make up the named type. If #1 wasn't sufficient, you can now add those to your guest definition one by one in disabled state, example A description of the underlying mechanism is here https://libvirt.org/formatdomain.html#cpu-model-and-topology -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1915063 Title: Windows 10 wil not install using qemu-system-x86_64 Status in QEMU: New Status in qemu package in Ubuntu: Confirmed Bug description: Steps to reproduce install virt-manager and ovmf if nopt already there copy windows and virtio iso files to /var/lib/libvirt/images Use virt-manager from local machine to create your VMs with the disk, CPUs and memory required Select customize configuration then select OVMF(UEFI) instead of seabios set first CDROM to the windows installation iso (enable in boot options) add a second CDROM and load with the virtio iso change spice display to VNC Always get a security error from windows and it fails to launch the installer (works on RHEL and Fedora) I tried updating the qemu version from Focals 4.2 to Groovy 5.0 which was of no help --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-sutton-focal-amd64-20201030-422+pc-sutton-bachman-focal-amd64+X00 DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2021-01-20 (19 days ago) InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20201030-14:39 MachineType: LENOVO 30E102Z NonfreeKernelModules: nvidia_modeset nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.6.0-1042-oem root=UUID=389cd165-fc52-4814-b837-a1090b9c2387 ro locale=en_US quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.6.0-1042.46-oem 5.6.19 RelatedPackageVersions: linux-restricted-modules-5.6.0-1042-oem N/A linux-backports-modules-5.6.0-1042-oem N/A linux-firmware 1.187.8 RfKill: Tags: focal Uname: Linux 5.6.0-1042-oem x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip docker kvm libvirt lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 07/29/2020 dmi.bios.vendor: LENOVO dmi.bios.version: S07KT08A dmi.board.name: 1046 dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.type: 3 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrS07KT08A:bd07/29/2020:svnLENOVO:pn30E102Z:pvrThinkStationP620:rvnLENOVO:rn1046:rvrNotDefined:cvnLENOVO:ct3:cvrNone: dmi.product.family: INVALID dmi.product.name: 30E102Z dmi.product.sku: LENOVO_MT_30E1_BU_Think_FM_ThinkStation P620 dmi.product.version: ThinkStation P620 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1915063/+subscriptions
testing/next - hexagon toolchain update
Alex, You are the one maintaining the testing/next tree at https://gitlab.com/stsquad/qemu correct? The current patch series for hexagon under review requires toolchain updates. These changes to llvm/clang landed in the last week or two. Can you apply this patch? >From 68547357c895934796e9b4687338bb9e39ac86c5 Mon Sep 17 00:00:00 2001 From: Brian Cain mailto:bc...@quicinc.com Date: Thu, 1 Apr 2021 10:32:24 -0500 Subject: [PATCH] Update llvm-project commit clang was updated with new inline asm registers for hexagon, this is necessary for QEMU test cases currently under review. Signed-off-by: Brian Cain mailto:bc...@quicinc.com --- tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker b/tests/docker/dockerfiles/debian-hexagon-cross.docker index b6fb651..1d19e8f 100644 --- a/tests/docker/dockerfiles/debian-hexagon-cross.docker +++ b/tests/docker/dockerfiles/debian-hexagon-cross.docker @@ -24,7 +24,7 @@ RUN apt update && \ ENV TOOLCHAIN_INSTALL /usr/local ENV ROOTFS /usr/local -ENV LLVM_URL https://github.com/llvm/llvm-project/archive/3d8149c2a1228609fd7d7c91a04681304a2f0ca9.tar.gz +ENV LLVM_URL https://github.com/llvm/llvm-project/archive/bfcd21876adc3498065e4da92799f613e730d475.tar.gz ENV MUSL_URL https://github.com/quic/musl/archive/aff74b395fbf59cd7e93b3691905aa1af6c0778c.tar.gz ENV LINUX_URL https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.6.18.tar.xz 0001-Update-llvm-project-commit.patch Description: 0001-Update-llvm-project-commit.patch
[PULL 0/2] target/xtensa fixes for v6.0
Hi Peter, please pull the following two fixes for the target/xtensa. The following changes since commit 6d40ce00c1166c317e298ad82ecf10e650c4f87d: Update version for v6.0.0-rc1 release (2021-03-30 18:19:07 +0100) are available in the Git repository at: git://github.com/OSLL/qemu-xtensa.git tags/20210403-xtensa for you to fetch changes up to 30c676134eb8f956853a55023d694062062d40d7: target/xtensa: make xtensa_modules static on import (2021-04-03 08:52:18 -0700) target/xtensa fixes for v6.0: - make meson.build pick up all available xtensa core definitions; - don't modify Makefile.objs in import_core.sh; - add sed rule to import_core.sh to make xtensa_modules variable static. Max Filippov (2): target/xtensa: fix meson.build rule for xtensa cores target/xtensa: make xtensa_modules static on import target/xtensa/import_core.sh | 4 +--- target/xtensa/meson.build| 13 - 2 files changed, 5 insertions(+), 12 deletions(-) -- Thanks. -- Max
Re: [PATCH] target/xtensa: fix meson.build rule for xtensa cores
On 4/2/21 9:03 PM, Max Filippov wrote: import_core.sh tries to change Makefile.objs when importing new xtensa core, but that file no longer exists. Rewrite meson.build rule to pick up all source files that match core-*.c pattern and drop commands that change Makefile.objs. Cc:qemu-sta...@nongnu.org # v5.2.0 Signed-off-by: Max Filippov --- target/xtensa/import_core.sh | 3 --- target/xtensa/meson.build| 13 - 2 files changed, 4 insertions(+), 12 deletions(-) Reviewed-by: Richard Henderson r~
[Bug 1921948] Re: MTE tags not checked properly for unaligned accesses at EL1
With v2, a lot of KASAN tests start failing. This likely means that MTE
tag faults stop being generated in certain cases.
With v3 [1], no MTE faults are generated at all.
[1]
https://patchew.org/QEMU/20210402214217.422585-1-richard.hender...@linaro.org/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
Title:
MTE tags not checked properly for unaligned accesses at EL1
Status in QEMU:
In Progress
Bug description:
For kernel memory accesses that span across two memory granules,
QEMU's MTE implementation only checks the tag of the first granule but
not of the second one.
To reproduce this, build the Linux kernel with CONFIG_KASAN_HW_TAGS
enabled, apply the patch below, and boot the kernel:
diff --git a/sound/last.c b/sound/last.c
index f0bb98780e70..04745cb30b74 100644
--- a/sound/last.c
+++ b/sound/last.c
@@ -5,12 +5,18 @@
*/
#include
+#include
#include
static int __init alsa_sound_last_init(void)
{
struct snd_card *card;
int idx, ok = 0;
+
+ char *ptr = kmalloc(128, GFP_KERNEL);
+ pr_err("KASAN report should follow:\n");
+ *(volatile unsigned long *)(ptr + 124);
+ kfree(ptr);
printk(KERN_INFO "ALSA device list:\n");
for (idx = 0; idx < SNDRV_CARDS; idx++) {
KASAN tags the 128 allocated bytes with the same tag as the returned
pointer. The memory granule that follows the 128 allocated bytes has a
different tag (with 1/15 probability).
Expected result: a tag fault is detected and a KASAN report is printed when
accessing bytes [124, 130).
Observed result: no tag fault is detected and no KASAN report is printed.
Here are the flags that I use to run QEMU if they matter:
qemu-system-aarch64 -s -machine virt,mte=on -cpu max -m 2G -smp 2 -net
user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 -net nic
-nographic -kernel ./Image -append "console=ttyAMA0 root=/dev/vda
earlyprintk=serial" -drive file=./fs.img,format=raw,if=virtio -no-
shutdown -no-reboot
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1921948/+subscriptions
Re: [PATCH] tests/qtest: add one more test for the am53c974
On 02/04/2021 17:20, Alexander Bulekov wrote:
Original crash:
qemu-fuzz-i386: ../hw/scsi/esp.c:791: void esp_transfer_data(SCSIRequest *,
uint32_t): Assertion `!s->do_cmd' failed.
==257532== ERROR: libFuzzer: deadly signal
__assert_fail assert/assert.c:101:3
esp_transfer_data hw/scsi/esp.c:791:5
scsi_req_data hw/scsi/scsi-bus.c:1412:9
scsi_disk_emulate_read_data hw/scsi/scsi-disk.c:1407:9
scsi_req_continue hw/scsi/scsi-bus.c:1394:9
do_busid_cmd hw/scsi/esp.c:317:9
handle_s_without_atn hw/scsi/esp.c:393:9
esp_reg_write hw/scsi/esp.c:1029:13
esp_pci_io_write hw/scsi/esp-pci.c:215:9
memory_region_write_accessor softmmu/memory.c:491:5
access_with_adjusted_size softmmu/memory.c:552:18
memory_region_dispatch_write softmmu/memory.c:1502:16
flatview_write_continue softmmu/physmem.c:2746:23
flatview_write softmmu/physmem.c:2786:14
address_space_write softmmu/physmem.c:2878:18
cpu_outl softmmu/ioport.c:80:5
Based-on: <20210401074933.9923-1-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Alexander Bulekov
---
tests/qtest/am53c974-test.c | 18 ++
1 file changed, 18 insertions(+)
The patch took care of the handle_satn_stop assert. Here's a test case
for the other assert.
Great! I've squashed the get_cmd() changes into a v4 version of the patchset.
Pasteable:
cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \
512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \
id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio
outl 0xcf8 0x80001010
outl 0xcfc 0xc000
outl 0xcf8 0x80001004
outw 0xcfc 0x01
outl 0xc00b 0x4100
outb 0xc008 0x42
outw 0xc03f 0x0300
outl 0xc00b 0xc100
EOF
diff --git a/tests/qtest/am53c974-test.c b/tests/qtest/am53c974-test.c
index 9c4285d0c0..506276677a 100644
--- a/tests/qtest/am53c974-test.c
+++ b/tests/qtest/am53c974-test.c
@@ -9,6 +9,22 @@
#include "libqos/libqtest.h"
+static void test_do_cmd_assert(void)
+{
+QTestState *s = qtest_init(
+"-device am53c974,id=scsi "
+"-device scsi-hd,drive=disk0 -drive "
+"id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+qtest_outl(s, 0xcf8, 0x80001010);
+qtest_outl(s, 0xcfc, 0xc000);
+qtest_outl(s, 0xcf8, 0x80001004);
+qtest_outw(s, 0xcfc, 0x01);
+qtest_outl(s, 0xc00b, 0x4100);
+qtest_outb(s, 0xc008, 0x42);
+qtest_outw(s, 0xc03f, 0x0300);
+qtest_outl(s, 0xc00b, 0xc100);
+qtest_quit(s);
+}
static void test_cmdfifo_underflow_ok(void)
{
@@ -194,6 +210,8 @@ int main(int argc, char **argv)
g_test_init(, , NULL);
if (strcmp(arch, "i386") == 0) {
+qtest_add_func("am53c974/test_do_cmd_asser",
+ test_do_cmd_assert);
qtest_add_func("am53c974/test_cmdfifo_underflow_ok",
test_cmdfifo_underflow_ok);
qtest_add_func("am53c974/test_cmdfifo_underflow2_ok",
When I try this patch on top of the v4 patchset I don't get an assert() in
esp_transfer_data here?
ATB,
Mark.
[Bug 1922430] [NEW] 3d accel does not take care of 1280x960 setting
Public bug reported: openSuse 15.2 kde plasma 5.21.3, frameworks 5.80.0 libvirt 7.0.0 qemu 5.2.0 virgl renderer 0.8.2 here is my invocation qemu-kvm -enable-kvm \ -m 2048 -smp 2 -cpu host \ -device virtio-vga,virgl=on -display gtk,gl=on \ -device usb-ehci \ -device usb-kbd \ -device usb-mouse \ -device usb-tablet \ -device ich9-intel-hda \ -device hda-duplex,audiodev=snd0 \ -audiodev pa,id=snd0 \ -device usb-host,vendorid=0x046d,productid=0x08e5 \ -boot menu=on \ -nic bridge \ ~/QEMU_VM/android_x86_7.1-r5.img \ in the kernel command there is "vga=1280x960" with "-device qxl" no problem. I get immediately a window of size 1280x960. with "-device virtio-vga,virgl=on -display gtk,gl=on" i get a tiny window. i must uncheck "zoom to fit" to get a window of size 1280x960. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1922430 Title: 3d accel does not take care of 1280x960 setting Status in QEMU: New Bug description: openSuse 15.2 kde plasma 5.21.3, frameworks 5.80.0 libvirt 7.0.0 qemu 5.2.0 virgl renderer 0.8.2 here is my invocation qemu-kvm -enable-kvm \ -m 2048 -smp 2 -cpu host \ -device virtio-vga,virgl=on -display gtk,gl=on \ -device usb-ehci \ -device usb-kbd \ -device usb-mouse \ -device usb-tablet \ -device ich9-intel-hda \ -device hda-duplex,audiodev=snd0 \ -audiodev pa,id=snd0 \ -device usb-host,vendorid=0x046d,productid=0x08e5 \ -boot menu=on \ -nic bridge \ ~/QEMU_VM/android_x86_7.1-r5.img \ in the kernel command there is "vga=1280x960" with "-device qxl" no problem. I get immediately a window of size 1280x960. with "-device virtio-vga,virgl=on -display gtk,gl=on" i get a tiny window. i must uncheck "zoom to fit" to get a window of size 1280x960. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1922430/+subscriptions
