- 03 7月, 2020 2 次提交
-
-
由 David Hildenbrand 提交于
Let's add a proxy for virtio-mem, make it a memory device, and pass-through the properties. Reviewed-by: NPankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-12-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 David Hildenbrand 提交于
This is the very basic/initial version of virtio-mem. An introduction to virtio-mem can be found in the Linux kernel driver [1]. While it can be used in the current state for hotplug of a smaller amount of memory, it will heavily benefit from resizeable memory regions in the future. Each virtio-mem device manages a memory region (provided via a memory backend). After requested by the hypervisor ("requested-size"), the guest can try to plug/unplug blocks of memory within that region, in order to reach the requested size. Initially, and after a reboot, all memory is unplugged (except in special cases - reboot during postcopy). The guest may only try to plug/unplug blocks of memory within the usable region size. The usable region size is a little bigger than the requested size, to give the device driver some flexibility. The usable region size will only grow, except on reboots or when all memory is requested to get unplugged. The guest can never plug more memory than requested. Unplugged memory will get zapped/discarded, similar to in a balloon device. The block size is variable, however, it is always chosen in a way such that THP splits are avoided (e.g., 2MB). The state of each block (plugged/unplugged) is tracked in a bitmap. As virtio-mem devices (e.g., virtio-mem-pci) will be memory devices, we now expose "VirtioMEMDeviceInfo" via "query-memory-devices". -------------------------------------------------------------------------- There are two important follow-up items that are in the works: 1. Resizeable memory regions: Use resizeable allocations/RAM blocks to grow/shrink along with the usable region size. This avoids creating initially very big VMAs, RAM blocks, and KVM slots. 2. Protection of unplugged memory: Make sure the gust cannot actually make use of unplugged memory. Other follow-up items that are in the works: 1. Exclude unplugged memory during migration (via precopy notifier). 2. Handle remapping of memory. 3. Support for other architectures. -------------------------------------------------------------------------- Example usage (virtio-mem-pci is introduced in follow-up patches): Start QEMU with two virtio-mem devices (one per NUMA node): $ qemu-system-x86_64 -m 4G,maxmem=20G \ -smp sockets=2,cores=2 \ -numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 \ [...] -object memory-backend-ram,id=mem0,size=8G \ -device virtio-mem-pci,id=vm0,memdev=mem0,node=0,requested-size=0M \ -object memory-backend-ram,id=mem1,size=8G \ -device virtio-mem-pci,id=vm1,memdev=mem1,node=1,requested-size=1G Query the configuration: (qemu) info memory-devices Memory device [virtio-mem]: "vm0" memaddr: 0x140000000 node: 0 requested-size: 0 size: 0 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem0 Memory device [virtio-mem]: "vm1" memaddr: 0x340000000 node: 1 requested-size: 1073741824 size: 1073741824 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem1 Add some memory to node 0: (qemu) qom-set vm0 requested-size 500M Remove some memory from node 1: (qemu) qom-set vm1 requested-size 200M Query the configuration again: (qemu) info memory-devices Memory device [virtio-mem]: "vm0" memaddr: 0x140000000 node: 0 requested-size: 524288000 size: 524288000 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem0 Memory device [virtio-mem]: "vm1" memaddr: 0x340000000 node: 1 requested-size: 209715200 size: 209715200 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem1 [1] https://lkml.kernel.org/r/20200311171422.10484-1-david@redhat.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-11-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 02 7月, 2020 5 次提交
-
-
由 David Hildenbrand 提交于
The only remaining special case is postcopy. It cannot handle concurrent discards yet, which would result in requesting already sent pages from the source. Special-case it in virtio-balloon instead. Introduce migration_in_incoming_postcopy(), to find out if incoming postcopy is active. Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-7-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 David Hildenbrand 提交于
Discarding RAM does not work as expected with protected VMs. Let's switch to ram_block_discard_disable() for now, as we want to get rid of qemu_balloon_inhibit(). Note that it will currently never fail, but might fail in the future with new technologies (e.g., virtio-mem). Acked-by: NCornelia Huck <cohuck@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-6-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 David Hildenbrand 提交于
VFIO is (except devices without a physical IOMMU or some mediated devices) incompatible with discarding of RAM. The kernel will pin basically all VM memory. Let's convert to ram_block_discard_disable(), which can now fail, in contrast to qemu_balloon_inhibit(). Leave "x-balloon-allowed" named as it is for now. Reviewed-by: NTony Krowiak <akrowiak@linux.ibm.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Tony Krowiak <akrowiak@linux.ibm.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Pierre Morel <pmorel@linux.ibm.com> Cc: Eric Farman <farman@linux.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-4-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 David Hildenbrand 提交于
E.g., with "pc-q35-4.2", trying to coldplug a virtio-pmem-pci devices results in "virtio-pmem-pci not supported on this bus" Reasons is, that the bus does not support hotplug and, therefore, does not have a hotplug handler. Let's allow coldplugging virtio-pmem devices on such buses. The hotplug order is only relevant for virtio-pmem-pci when the guest is already alive and the device is visible before memory_device_plug() wired up the memory device bits. Hotplug attempts will still fail with: "Error: Bus 'pcie.0' does not support hotplugging" Hotunplug attempts will still fail with: "Error: Bus 'pcie.0' does not support hotplugging" Reported-by: NVivek Goyal <vgoyal@redhat.com> Reviewed-by: NPankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-2-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 David Hildenbrand 提交于
If something goes wrong during precopy, before stopping the VM, we will never send a S_DONE indication to the VM, resulting in the hinted pages not getting released to be used by the guest OS (e.g., Linux). Easy to reproduce: 1. Start migration (e.g., HMP "migrate -d 'exec:gzip -c > STATEFILE.gz'") 2. Cancel migration (e.g., HMP "migrate_cancel") 3. Oberve in the guest (e.g., cat /proc/meminfo) that there is basically no free memory left. While at it, add similar locking to virtio_balloon_free_page_done() as done in virtio_balloon_free_page_stop. Locking is still weird, but that has to be sorted out separately. There is nothing to do in the PRECOPY_NOTIFY_COMPLETE case. Add some comments regarding S_DONE handling. Fixes: c13c4153 ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Reviewed-by: NAlexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Wei Wang <wei.w.wang@intel.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20200629080615.26022-1-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 30 6月, 2020 1 次提交
-
-
由 Philippe Mathieu-Daudé 提交于
When adding the generic PCA955xClass in commit 736132e4, we forgot to set the class_size field. Fill it now to avoid: (gdb) run -machine mcimx6ul-evk -m 128M -display none -serial stdio -kernel ./OS.elf Starting program: ../../qemu/qemu/arm-softmmu/qemu-system-arm -machine mcimx6ul-evk -m 128M -display none -serial stdio -kernel ./OS.elf double free or corruption (!prev) Thread 1 "qemu-system-arm" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 (gdb) where #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff75d8859 in __GI_abort () at abort.c:79 #2 0x00007ffff76433ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff776d285 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x00007ffff764b47c in malloc_printerr (str=str@entry=0x7ffff776f690 "double free or corruption (!prev)") at malloc.c:5347 #4 0x00007ffff764d12c in _int_free (av=0x7ffff779eb80 <main_arena>, p=0x5555567a3990, have_lock=<optimized out>) at malloc.c:4317 #5 0x0000555555c906c3 in type_initialize_interface (ti=ti@entry=0x5555565b8f40, interface_type=0x555556597ad0, parent_type=0x55555662ca10) at qom/object.c:259 #6 0x0000555555c902da in type_initialize (ti=ti@entry=0x5555565b8f40) at qom/object.c:323 #7 0x0000555555c90d20 in type_initialize (ti=0x5555565b8f40) at qom/object.c:1028 $ valgrind --track-origins=yes qemu-system-arm -M mcimx6ul-evk -m 128M -display none -serial stdio -kernel ./OS.elf ==77479== Memcheck, a memory error detector ==77479== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==77479== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==77479== Command: qemu-system-arm -M mcimx6ul-evk -m 128M -display none -serial stdio -kernel ./OS.elf ==77479== ==77479== Invalid write of size 2 ==77479== at 0x6D8322: pca9552_class_init (pca9552.c:424) ==77479== by 0x844D1F: type_initialize (object.c:1029) ==77479== by 0x844D1F: object_class_foreach_tramp (object.c:1016) ==77479== by 0x4AE1057: g_hash_table_foreach (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.2) ==77479== by 0x8453A4: object_class_foreach (object.c:1038) ==77479== by 0x8453A4: object_class_get_list (object.c:1095) ==77479== by 0x556194: select_machine (vl.c:2416) ==77479== by 0x556194: qemu_init (vl.c:3828) ==77479== by 0x40AF9C: main (main.c:48) ==77479== Address 0x583f108 is 0 bytes after a block of size 200 alloc'd ==77479== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==77479== by 0x4AF8D30: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.2) ==77479== by 0x844258: type_initialize.part.0 (object.c:306) ==77479== by 0x844D1F: type_initialize (object.c:1029) ==77479== by 0x844D1F: object_class_foreach_tramp (object.c:1016) ==77479== by 0x4AE1057: g_hash_table_foreach (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.2) ==77479== by 0x8453A4: object_class_foreach (object.c:1038) ==77479== by 0x8453A4: object_class_get_list (object.c:1095) ==77479== by 0x556194: select_machine (vl.c:2416) ==77479== by 0x556194: qemu_init (vl.c:3828) ==77479== by 0x40AF9C: main (main.c:48) Fixes: 736132e4 ("hw/misc/pca9552: Add generic PCA955xClass") Reported-by: NJean-Christophe DUBOIS <jcd@tribudubois.net> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NJean-Christophe DUBOIS <jcd@tribudubois.net> Message-id: 20200629074704.23028-1-f4bug@amsat.org Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 28 6月, 2020 1 次提交
-
-
由 Huacai Chen 提交于
Loongson-3 has an integrated liointc (Local I/O Interrupt Controller). It is similar to Goldfish interrupt controller, but more powerful (e.g., it can route external interrupt to multi-cores). Documents about Loongson-3's liointc: 1, https://wiki.godson.ac.cn/ip_block:liointc; 2, The "I/O中断" section of Loongson-3's user mannual, part 1. Signed-off-by: NHuacai Chen <chenhc@lemote.com> Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: NAleksandar Markovic <aleksandar.qemu.devel@gmail.com> Reviewed-by: NAleksandar Markovic <aleksandar.qemu.devel@gmail.com> Message-Id: <1592995531-32600-3-git-send-email-chenhc@lemote.com>
-
- 26 6月, 2020 31 次提交
-
-
由 Paolo Bonzini 提交于
The xor-as-pow warning in clang actually detected a genuine bug. Fix it. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
The patches that introduced the properties were submitted when QEMU 5.0 had not been released yet, so they got merged under the wrong heading. Move them to hw_compat_5_0 so that 5.0 machine types get the pre-patch behavior. Fixes: b8892129 ("hw/i386/vmport: Propagate IOPort read to vCPU EAX register") Fixes: 0342ee76 ("hw/i386/vmport: Set EAX to -1 on failed and unsupported commands") Fixes: f8bdc550 ("hw/i386/vmport: Report vmware-vmx-type in CMD_GETVERSION") Fixes: aaacf1c1 ("hw/i386/vmport: Add support for CMD_GETBIOSUUID") Reported-by: NLaurent Vivier <lvivier@redhat.com> Cc: Liran Alon <liran.alon@oracle.com> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Jon Doron 提交于
It seems like Windows does not really require 2 IRQs to have a functioning VMBus. Signed-off-by: NJon Doron <arilou@gmail.com> Message-Id: <20200617160904.681845-2-arilou@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Igor Mammedov 提交于
Deprecation period is run out and it's a time to flip the switch introduced by cd5ff833. Disable legacy option for new machine types (since 5.1) and amend documentation. '-numa node,memdev' shall be used instead of disabled option with new machine types. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Message-Id: <20200609135635.761587-1-imammedo@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
I'm not aware of any immediate bugs in qemu where a second runtime evaluation of the arguments to MIN() or MAX() causes a problem, but proactively preventing such abuse is easier than falling prey to an unintended case down the road. At any rate, here's the conversation that sparked the current patch: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg05718.html Update the MIN/MAX macros to only evaluate their argument once at runtime; this uses typeof(1 ? (a) : (b)) to ensure that we are promoting the temporaries to the same type as the final comparison (we have to trigger type promotion, as typeof(bitfield) won't compile; and we can't use typeof((a) + (b)) or even typeof((a) + 0), as some of our uses of MAX are on void* pointers where such addition is undefined). However, we are unable to work around gcc refusing to compile ({}) in a constant context (such as the array length of a static variable), even when only used in the dead branch of a __builtin_choose_expr(), so we have to provide a second macro pair MIN_CONST and MAX_CONST for use when both arguments are known to be compile-time constants and where the result must also be usable as a constant; this second form evaluates arguments multiple times but that doesn't matter for constants. By using a void expression as the expansion if a non-constant is presented to this second form, we can enlist the compiler to ensure the double evaluation is not attempted on non-constants. Alas, as both macros now rely on compiler intrinsics, they are no longer usable in preprocessor #if conditions; those will just have to be open-coded or the logic rewritten into #define or runtime 'if' conditions (but where the compiler dead-code-elimination will probably still apply). I tested that both gcc 10.1.1 and clang 10.0.0 produce errors for all forms of macro mis-use. As the errors can sometimes be cryptic, I'm demonstrating the gcc output: Use of MIN when MIN_CONST is needed: In file included from /home/eblake/qemu/qemu-img.c:25: /home/eblake/qemu/include/qemu/osdep.h:249:5: error: braced-group within expression allowed only inside a function 249 | ({ \ | ^ /home/eblake/qemu/qemu-img.c:92:12: note: in expansion of macro ‘MIN’ 92 | char array[MIN(1, 2)] = ""; | ^~~ Use of MIN_CONST when MIN is needed: /home/eblake/qemu/qemu-img.c: In function ‘is_allocated_sectors’: /home/eblake/qemu/qemu-img.c:1225:15: error: void value not ignored as it ought to be 1225 | i = MIN_CONST(i, n); | ^ Use of MIN in the preprocessor: In file included from /home/eblake/qemu/accel/tcg/translate-all.c:20: /home/eblake/qemu/accel/tcg/translate-all.c: In function ‘page_check_range’: /home/eblake/qemu/include/qemu/osdep.h:249:6: error: token "{" is not valid in preprocessor expressions 249 | ({ \ | ^ Fix the resulting callsites that used #if or computed a compile-time constant min or max to use the new macros. cpu-defs.h is interesting, as CPU_TLB_DYN_MAX_BITS is sometimes used as a constant and sometimes dynamic. It may be worth improving glib's MIN/MAX definitions to be saner, but that is a task for another day. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200625162602.700741-1-eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Anthony PERARD 提交于
Fix typo. Fixes: acd0c941 ("xen: fix build without pci passthrough") Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com> Message-Id: <20200619103115.254127-1-anthony.perard@citrix.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Thomas Huth 提交于
Some tracepoints in megasas.c use a guest-controlled value as an index into the mfi_frame_desc[] array. Thus a malicious guest could cause an out-of-bounds error here. Fortunately, the impact is very low since this can only happen when the corresponding tracepoints have been enabled before, but the problem should be fixed anyway with a proper check. Buglink: https://bugs.launchpad.net/qemu/+bug/1882065Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <20200615072629.32321-1-thuth@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Richard Henderson 提交于
Signed-off-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 20200626033144.790098-44-richard.henderson@linaro.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
The PCA9552 has 16 GPIOs which can be used as input, output or PWM mode. QEMU models the output GPIO with the qemu_irq type. Let the device expose the 16 GPIOs to allow us to later connect LEDs to these outputs. Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-10-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Emit a trace event when a GPIO change its state. Example booting obmc-phosphor-image: $ qemu-system-arm -M witherspoon-bmc -trace pca955x_gpio_change 1592690552.687372:pca955x_gpio_change pca1 GPIO id:0 status: 0 -> 1 1592690552.690169:pca955x_gpio_change pca1 GPIO id:1 status: 0 -> 1 1592690552.691673:pca955x_gpio_change pca1 GPIO id:2 status: 0 -> 1 1592690552.696886:pca955x_gpio_change pca1 GPIO id:3 status: 0 -> 1 1592690552.698614:pca955x_gpio_change pca1 GPIO id:13 status: 0 -> 1 1592690552.699833:pca955x_gpio_change pca1 GPIO id:14 status: 0 -> 1 1592690552.700842:pca955x_gpio_change pca1 GPIO id:15 status: 0 -> 1 1592690683.841921:pca955x_gpio_change pca1 GPIO id:14 status: 1 -> 0 1592690683.861660:pca955x_gpio_change pca1 GPIO id:14 status: 0 -> 1 1592690684.371460:pca955x_gpio_change pca1 GPIO id:14 status: 1 -> 0 1592690684.882115:pca955x_gpio_change pca1 GPIO id:14 status: 0 -> 1 1592690685.391411:pca955x_gpio_change pca1 GPIO id:14 status: 1 -> 0 1592690685.901391:pca955x_gpio_change pca1 GPIO id:14 status: 0 -> 1 1592690686.411678:pca955x_gpio_change pca1 GPIO id:14 status: 1 -> 0 1592690686.921279:pca955x_gpio_change pca1 GPIO id:14 status: 0 -> 1 We notice the GPIO #14 (front-power LED) starts to blink. This LED is described in the witherspoon device-tree [*]: front-power { retain-state-shutdown; default-state = "keep"; gpios = <&pca0 14 GPIO_ACTIVE_LOW>; }; [*] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts?id=b1f9be9392f0#n140Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-9-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
We have 2 distinct PCA9552 devices. Set their description to distinguish them when looking at the trace events. Description name taken from: https://github.com/open-power/witherspoon-xml/blob/master/witherspoon.xmlReviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NCorey Minyard <cminyard@mvista.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-8-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Add a trivial representation of the PCA9552 GPIOs. Example booting obmc-phosphor-image: $ qemu-system-arm -M witherspoon-bmc -trace pca955x_gpio_status 1592689902.327837:pca955x_gpio_status pca-unspecified GPIOs 0-15 [*...............] 1592689902.329934:pca955x_gpio_status pca-unspecified GPIOs 0-15 [**..............] 1592689902.330717:pca955x_gpio_status pca-unspecified GPIOs 0-15 [***.............] 1592689902.331431:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****............] 1592689902.332163:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........*..] 1592689902.332888:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........**.] 1592689902.333629:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........***] 1592690032.793289:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........*.*] 1592690033.303163:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........***] 1592690033.812962:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........*.*] 1592690034.323234:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........***] 1592690034.832922:pca955x_gpio_status pca-unspecified GPIOs 0-15 [****.........*.*] We notice the GPIO #14 (front-power LED) starts to blink. This LED is described in the witherspoon device-tree [*]: front-power { retain-state-shutdown; default-state = "keep"; gpios = <&pca0 14 GPIO_ACTIVE_LOW>; }; [*] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts?id=b1f9be9392f0#n140Suggested-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-7-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Add a description field to distinguish between multiple devices. Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-6-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Extract the code common to the PCA955x family in PCA955xClass, keeping the PCA9552 specific parts into pca9552_class_init(). Remove the 'TODO' comment added in commit 5141d415. Suggested-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-5-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Various code from the PCA9552 device model is generic to the PCA955X family. We'll split the generic code in a base class in the next commit. To ease review, first do a dumb renaming. Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-4-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
The PCA9552 device does not expose LEDs, but simple pins to connnect LEDs to. To be clearer with the device model, rename 'nr_leds' as 'pin_count'. Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-3-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Extract i2c_try_create_slave() and i2c_realize_and_unref() from i2c_create_slave(). We can now set properties on a I2CSlave before it is realized. This is in line with the recent qdev/QOM changes merged in commit 6675a653. Reviewed-by: NCorey Minyard <cminyard@mvista.com> Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072723.6324-2-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
AspeedMachineState seems crippled. We use incorrectly 2 different structures to do the same thing. Merge them altogether: - Move AspeedMachine fields to AspeedMachineState - AspeedMachineState is now QOM - Remove unused AspeedMachine structure Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072132.2868-4-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
To have a more consistent naming, rename AspeedBoardState as AspeedMachineState. Suggested-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200623072132.2868-3-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
I'm confused by this code, 'bmc' is created as: bmc = g_new0(AspeedBoardState, 1); Then we use it as QOM owner for different MemoryRegion objects. But looking at memory_region_init_ram (similarly for ROM): void memory_region_init_ram(MemoryRegion *mr, struct Object *owner, const char *name, uint64_t size, Error **errp) { DeviceState *owner_dev; Error *err = NULL; memory_region_init_ram_nomigrate(mr, owner, name, size, &err); if (err) { error_propagate(errp, err); return; } /* This will assert if owner is neither NULL nor a DeviceState. * We only want the owner here for the purposes of defining a * unique name for migration. TODO: Ideally we should implement * a naming scheme for Objects which are not DeviceStates, in * which case we can relax this restriction. */ owner_dev = DEVICE(owner); vmstate_register_ram(mr, owner_dev); } The expected assertion is not triggered ('bmc' is not NULL neither a DeviceState). 'bmc' structure is defined as: struct AspeedBoardState { AspeedSoCState soc; MemoryRegion ram_container; MemoryRegion max_ram; }; What happens is when using 'OBJECT(bmc)', the QOM macros cast the memory pointed by bmc, which first member is 'soc', which is initialized ...: object_initialize_child(OBJECT(machine), "soc", &bmc->soc, amc->soc_name); The 'soc' object is indeed a DeviceState, so the assertion passes. Since this is fragile and only happens to work by luck, remove the dangerous OBJECT(bmc) owner argument. Note, this probably breaks migration for this machine. Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200623072132.2868-2-f4bug@amsat.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-23-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
This is to allow us to distinguish between ADB device events and ADB bus events separately. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-22-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Handle this at the ADB bus level so that individual implementations do not need to handle this themselves. Finally add an assert() into adb_request() to prevent developers from accidentally making an explicit ADB request without blocking autopoll. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-21-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
The existing ADB state machine is designed to work with Linux which has a different interpretation of the state machine detailed in "Guide to the Macintosh Family Hardware". In particular the current Linux implementation includes an extra change to IDLE state when switching the VIA between send and receive modes which does not occur in MacOS, and omitting this transition causes the current mac_via ADB state machine to fail. Rework the ADB state machine accordingly so that it can enumerate and autopoll the ADB under both Linux and MacOS, including the addition of the new adb_autopoll_block() and adb_autopoll_unblock() functions. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-20-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Currently the logic is split between the mos6522 portB_write() callback and the memory region used to capture the VIA1 MMIO accesses. Move everything into the latter mos6522_q800_via1_write() function to keep all the logic in one place to make it easier to follow. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-19-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Ensure that the PMU buffer is protected from autopoll requests overwriting its contents whilst existing PMU requests are in progress. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-18-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Ensure that the CUDA buffer is protected from autopoll requests overwriting its contents whilst existing CUDA requests are in progress. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-17-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Whilst autopoll is enabled it is necessary to prevent the ADB buffer contents from being overwritten until the host has read back the response in its entirety. Add adb_autopoll_block() and adb_autopoll_unblock() functions in preparation for ensuring that the ADB buffer contents are protected for explicit ADB requests. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-16-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Currently adb_request() is called both for explicit ADB requests and internal autopoll requests via adb_poll(). Move the current functionality into do_adb_request() to be used internally and add a simple adb_request() wrapper for explicit requests. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-15-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Currently only 2 bits are defined: one to indicate if the request timed out (no reply) and another to indicate whether the request was the result of an autopoll operation. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-14-mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Add a new pending variable to ADBBusState which is a bitmask indicating which ADB devices have data to send. Update the bitmask every time that an ADB request is executed. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: NFinn Thain <fthain@telegraphics.com.au> Acked-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20200623204936.24064-13-mark.cave-ayland@ilande.co.uk>
-