Re: Semihosting, arm, riscv, ppc and common code
> On 16 Jan 2020, at 04:04, Benjamin Herrenschmidt > wrote: > > ... I agree, which is also why I want to use the same interface for > powerpc, it will simply make life easier for everybody. I don't know the current implementation in QEMU, but I suggest you also take a look at the current Arm specs: https://static.docs.arm.com/100863/0200/semihosting.pdf The implementation in OpenOCD is: https://github.com/xpack-dev-tools/openocd/blob/xpack/src/target/semihosting_common.c > The calls > aren't perfect but they do work sufficiently well to be useful and I > haven't yet been convinced that it can't be extended if necessary. In theory it can, in practice it'll not be easy. Imagine that you decide to use Arm semihosting for your architecture, and implement it in QEMU. Then you try to convince other tool developers to do the same. If you ask them nicely, they might copy/paste the Arm code, and you're done, major commercial tools will have Arm semihosting support for your architecture and it becomes a de facto standard. If at a later time you decide to extend the protocol, you have to go again to all commercial tool vendors and ask them to implement the extension. You'll need good reasons to convince them. In my case it was easier to convince SEGGER to add Arm semihosting support to their RISC-V JTAG, because we had a long relationship, but even so I doubt they'll be happy to implement extensions. --- Anyway, from my experience, for practical cases the Arm semihosting is more than enough, once you have a functional implementation for the client side you simply forget about it, and you can use it for any architecture. My implementation is the following: https://github.com/micro-os-plus/semihosting-xpack/blob/xpack/src/syscalls-semihosting.cpp Regards, Liviu
Re: [PATCH v5 18/22] tests/tcg/aarch64: add a gdbstub testcase for SVE registers
Richard Henderson writes:
> On 1/14/20 5:09 AM, Alex Bennée wrote:
>> A very simple test case which sets and reads SVE registers while
>> running a test case. We don't really need to compile a SVE binary for
>> this case but we will later so keep it simple for now.
>>
>> Signed-off-by: Alex Bennée
>>
>> ---
>> v5
>> - properly plumb in
>> - skip if fails to connect
>> ---
>> tests/.gitignore | 1 +
>> tests/tcg/aarch64/Makefile.target | 15 +
>> tests/tcg/aarch64/gdbstub/test-sve.py | 81 +++
>> 3 files changed, 97 insertions(+)
>> create mode 100644 tests/tcg/aarch64/gdbstub/test-sve.py
>
> I don't understand how this is working. What's the process that provides the
> container for the register state?
>
> I would have expected *some* binary to be used, even if it is only "int main()
> { return 0; }".
It is, it's using the sysregs test:
--bin $<
>
>
>
> r~
--
Alex Bennée
Re: [PATCH 071/104] virtiofsd: extract root inode init into setup_root()
> From: Miklos Szeredi
>
> Inititialize the root inode in a single place.
>
> Signed-off-by: Miklos Szeredi
> Signed-off-by: Stefan Hajnoczi
> ---
> tools/virtiofsd/passthrough_ll.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/tools/virtiofsd/passthrough_ll.c
> b/tools/virtiofsd/passthrough_ll.c
> index ef8b88e3d1..0f33c3c5e9 100644
> --- a/tools/virtiofsd/passthrough_ll.c
> +++ b/tools/virtiofsd/passthrough_ll.c
> @@ -2336,6 +2336,29 @@ static void log_func(enum fuse_log_level level, const
> char *_fmt, va_list ap)
> }
> }
>
> +static void setup_root(struct lo_data *lo, struct lo_inode *root)
> +{
> +int fd, res;
> +struct stat stat;
> +
> +fd = open("/", O_PATH);
> +if (fd == -1) {
> +fuse_log(FUSE_LOG_ERR, "open(%s, O_PATH): %m\n", lo->source);
> +exit(1);
> +}
> +
> +res = fstatat(fd, "", , AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW);
> +if (res == -1) {
> +fuse_log(FUSE_LOG_ERR, "fstatat(%s): %m\n", lo->source);
> +exit(1);
> +}
> +
> +root->fd = fd;
> +root->ino = stat.st_ino;
> +root->dev = stat.st_dev;
> +root->refcount = 2;
> +}
> +
> int main(int argc, char *argv[])
> {
> struct fuse_args args = FUSE_ARGS_INIT(argc, argv);
> @@ -2411,8 +2434,6 @@ int main(int argc, char *argv[])
> if (lo.debug) {
> current_log_level = FUSE_LOG_DEBUG;
> }
> -lo.root.refcount = 2;
> -
> if (lo.source) {
> struct stat stat;
> int res;
> @@ -2480,6 +2501,7 @@ int main(int argc, char *argv[])
>
> setup_sandbox(, se, opts.syslog);
>
> +setup_root(, );
> /* Block until ctrl+c or fusermount -u */
> ret = virtio_loop(se);
Following block still remains in main():
2933lo.root.is_symlink = false;
...
2952lo.root.fd = open(lo.source, O_PATH);
2953
2954if (lo.root.fd == -1) {
2955fuse_log(FUSE_LOG_ERR, "open(\"%s\", O_PATH): %m\n", lo.source);
2956exit(1);
2957}
L.2933 should be included in lo_setup_root() and can we just remove L.2952-2957?
Thanks,
Misono
Re: [PATCH 070/104] virtiofsd: fail when parent inode isn't known in lo_do_lookup()
Looks good to me.
Reviewed-by: Misono Tomohiro
> ---
> tools/virtiofsd/passthrough_ll.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/tools/virtiofsd/passthrough_ll.c
> b/tools/virtiofsd/passthrough_ll.c
> index 1618db5a92..ef8b88e3d1 100644
> --- a/tools/virtiofsd/passthrough_ll.c
> +++ b/tools/virtiofsd/passthrough_ll.c
> @@ -778,6 +778,15 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t
> parent, const char *name,
> struct lo_data *lo = lo_data(req);
> struct lo_inode *inode, *dir = lo_inode(req, parent);
>
> +/*
> + * name_to_handle_at() and open_by_handle_at() can reach here with fuse
> + * mount point in guest, but we don't have its inode info in the
> + * ino_map.
> + */
> +if (!dir) {
> +return ENOENT;
> +}
> +
> memset(e, 0, sizeof(*e));
> e->attr_timeout = lo->timeout;
> e->entry_timeout = lo->timeout;
> @@ -787,7 +796,7 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t
> parent, const char *name,
> name = ".";
> }
>
> -newfd = openat(lo_fd(req, parent), name, O_PATH | O_NOFOLLOW);
> +newfd = openat(dir->fd, name, O_PATH | O_NOFOLLOW);
> if (newfd == -1) {
> goto out_err;
> }
> @@ -797,7 +806,7 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t
> parent, const char *name,
> goto out_err;
> }
>
> -inode = lo_find(lo_data(req), >attr);
> +inode = lo_find(lo, >attr);
> if (inode) {
> close(newfd);
> newfd = -1;
> @@ -813,6 +822,7 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t
> parent, const char *name,
> inode->is_symlink = S_ISLNK(e->attr.st_mode);
> inode->refcount = 1;
> inode->fd = newfd;
> +newfd = -1;
> inode->ino = e->attr.st_ino;
> inode->dev = e->attr.st_dev;
[Bug 1859916] Re: coreaudio not working on MacOS
** Description changed: OS: MacOS Catalina 10.15.2 qemu-system-x86_64 -version QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Qemu install via brew: brew install qemu --- I use following to install Ubuntu 18.04 desktop successfully:- IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 MAC_ADDR=xx:xx:xx:xx:xx:xx qemu-system-x86_64 \ -no-user-config -nodefaults \ -show-cursor \ -name u64d01 \ -M q35,accel=hvf,usb=off,vmport=off \ -cpu host -smp 4 -m 2048 \ -overcommit mem-lock=off \ -overcommit cpu-pm=off \ -rtc base=utc,clock=host \ \ -device virtio-tablet-pci \ -device virtio-vga \ \ -device virtio-blk-pci,drive=ssd1 \ -drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ \ -device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \ \ -device ich9-intel-hda,id=snd,msi=on \ -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ -audiodev coreaudio,id=snd0,out.buffer-count=1 \ \ -cdrom $IMG_CD Removing the last -cdrom line Ubuntu desktop boot up and everything work perfectly except the audio. I test with wav audio driver by replacing the -audiodev line as follow, - which save the client audio to a wave file, like below and it work - perfectly: + which save the client audio to a wave file: -audiodev wav,id=snd0,path=$HOME/qemu.wav - I start the vm, open firefox and play a few video, then shutdown the vm. + I start the vm, open firefox, play a few video, then shutdown the vm. Then I can play the qemu.wav file and all the audio was recorded there. However, I can't get audio directly with coreaudio. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1859916 Title: coreaudio not working on MacOS Status in QEMU: New Bug description: OS: MacOS Catalina 10.15.2 qemu-system-x86_64 -version QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Qemu install via brew: brew install qemu --- I use following to install Ubuntu 18.04 desktop successfully:- IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 MAC_ADDR=xx:xx:xx:xx:xx:xx qemu-system-x86_64 \ -no-user-config -nodefaults \ -show-cursor \ -name u64d01 \ -M q35,accel=hvf,usb=off,vmport=off \ -cpu host -smp 4 -m 2048 \ -overcommit mem-lock=off \ -overcommit cpu-pm=off \ -rtc base=utc,clock=host \ \ -device virtio-tablet-pci \ -device virtio-vga \ \ -device virtio-blk-pci,drive=ssd1 \ -drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ \ -device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \ \ -device ich9-intel-hda,id=snd,msi=on \ -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ -audiodev coreaudio,id=snd0,out.buffer-count=1 \ \ -cdrom $IMG_CD Removing the last -cdrom line Ubuntu desktop boot up and everything work perfectly except the audio. I test with wav audio driver by replacing the -audiodev line as follow, which save the client audio to a wave file: -audiodev wav,id=snd0,path=$HOME/qemu.wav I start the vm, open firefox, play a few video, then shutdown the vm. Then I can play the qemu.wav file and all the audio was recorded there. However, I can't get audio directly with coreaudio. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1859916/+subscriptions
Re: [PATCH v2] hw/ppc/prep: Remove the deprecated "prep" machine and the OpenHackware BIOS
On Tue, Jan 14, 2020 at 12:46:17PM +0100, Thomas Huth wrote:
> It's been deprecated since QEMU v3.1. The 40p machine should be
> used nowadays instead.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Acked-by: Hervé Poussineau
> Signed-off-by: Thomas Huth
Applied to ppc-for-5.0, thanks.
> ---
> v2: Rebase to master (qtests moved to a separate directory)
>
> .gitmodules | 3 -
> MAINTAINERS | 1 -
> Makefile | 2 +-
> docs/interop/firmware.json| 3 +-
> hw/ppc/ppc.c | 18 --
> hw/ppc/prep.c | 384 +-
> include/hw/ppc/ppc.h | 1 -
> pc-bios/README| 3 -
> pc-bios/ppc_rom.bin | Bin 1048576 -> 0 bytes
> qemu-deprecated.texi | 6 -
> qemu-doc.texi | 15 +-
> roms/openhackware | 1 -
> tests/qtest/boot-order-test.c | 25 ---
> tests/qtest/cdrom-test.c | 2 +-
> tests/qtest/endianness-test.c | 2 +-
> 15 files changed, 10 insertions(+), 456 deletions(-)
> delete mode 100644 pc-bios/ppc_rom.bin
> delete mode 16 roms/openhackware
>
> diff --git a/.gitmodules b/.gitmodules
> index 19792c9a11..9c0501a4d4 100644
> --- a/.gitmodules
> +++ b/.gitmodules
> @@ -10,9 +10,6 @@
> [submodule "roms/openbios"]
> path = roms/openbios
> url = https://git.qemu.org/git/openbios.git
> -[submodule "roms/openhackware"]
> - path = roms/openhackware
> - url = https://git.qemu.org/git/openhackware.git
> [submodule "roms/qemu-palcode"]
> path = roms/qemu-palcode
> url = https://git.qemu.org/git/qemu-palcode.git
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 483edfbc0b..c5b1cbbac5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1087,7 +1087,6 @@ F: hw/dma/i82374.c
> F: hw/rtc/m48t59-isa.c
> F: include/hw/isa/pc87312.h
> F: include/hw/rtc/m48t59.h
> -F: pc-bios/ppc_rom.bin
> F: tests/acceptance/ppc_prep_40p.py
>
> sPAPR
> diff --git a/Makefile b/Makefile
> index 32bd554480..195f5fbe27 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -768,7 +768,7 @@ ifdef INSTALL_BLOBS
> BLOBS=bios.bin bios-256k.bin bios-microvm.bin sgabios.bin vgabios.bin
> vgabios-cirrus.bin \
> vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \
> vgabios-ramfb.bin vgabios-bochs-display.bin vgabios-ati.bin \
> -ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin
> QEMU,cgthree.bin \
> +openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin QEMU,cgthree.bin
> \
> pxe-e1000.rom pxe-eepro100.rom pxe-ne2k_pci.rom \
> pxe-pcnet.rom pxe-rtl8139.rom pxe-virtio.rom \
> efi-e1000.rom efi-eepro100.rom efi-ne2k_pci.rom \
> diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
> index 8ffb7856d2..240f565397 100644
> --- a/docs/interop/firmware.json
> +++ b/docs/interop/firmware.json
> @@ -27,8 +27,7 @@
> #
> # @openfirmware: The interface is defined by the (historical) IEEE
> #1275-1994 standard. Examples for firmware projects that
> -#provide this interface are: OpenBIOS, OpenHackWare,
> -#SLOF.
> +#provide this interface are: OpenBIOS and SLOF.
> #
> # @uboot: Firmware interface defined by the U-Boot project.
> #
> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
> index 4c5fa29399..4a11fb1640 100644
> --- a/hw/ppc/ppc.c
> +++ b/hw/ppc/ppc.c
> @@ -1490,24 +1490,6 @@ int ppc_dcr_init (CPUPPCState *env, int
> (*read_error)(int dcrn),
> }
>
>
> /*/
> -/* Debug port */
> -void PPC_debug_write (void *opaque, uint32_t addr, uint32_t val)
> -{
> -addr &= 0xF;
> -switch (addr) {
> -case 0:
> -printf("%c", val);
> -break;
> -case 1:
> -printf("\n");
> -fflush(stdout);
> -break;
> -case 2:
> -printf("Set loglevel to %04" PRIx32 "\n", val);
> -qemu_set_log(val | 0x100);
> -break;
> -}
> -}
>
> int ppc_cpu_pir(PowerPCCPU *cpu)
> {
> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
> index 862345c2ac..111cc80867 100644
> --- a/hw/ppc/prep.c
> +++ b/hw/ppc/prep.c
> @@ -42,7 +42,7 @@
> #include "hw/loader.h"
> #include "hw/rtc/mc146818rtc.h"
> #include "hw/isa/pc87312.h"
> -#include "hw/net/ne2000-isa.h"
> +#include "hw/qdev-properties.h"
> #include "sysemu/arch_init.h"
> #include "sysemu/kvm.h"
> #include "sysemu/qtest.h"
> @@ -60,178 +60,9 @@
>
> #define CFG_ADDR 0xf510
>
> -#define BIOS_SIZE (1 * MiB)
> -#define BIOS_FILENAME "ppc_rom.bin"
> #define KERNEL_LOAD_ADDR 0x0100
> #define INITRD_LOAD_ADDR 0x0180
>
> -/* Constants for devices init */
> -static const int ide_iobase[2] = { 0x1f0, 0x170 };
> -static const int ide_iobase2[2] = { 0x3f6, 0x376 };
> -static const int ide_irq[2] = { 13, 13 };
> -
> -#define NE2000_NB_MAX 6
> -
> -static uint32_t ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320,
[Bug 1859920] [NEW] daemoniz not working on MacOS
Public bug reported: OS: MacOS Catalina 10.15.2 Qemu install via brew: brew install qemu qemu-system-x86_64 -version QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers --- Start Ubuntu Desktop 18.04 client as follow: IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 MAC_ADDR=xx:xx:xx:xx:xx:xx qemu-system-x86_64 \ -no-user-config -nodefaults \ -show-cursor \ -name u64d01 \ -M q35,accel=hvf,usb=off,vmport=off \ -cpu host -smp 4 -m 2048 \ -overcommit mem-lock=off \ -overcommit cpu-pm=off \ -rtc base=utc,clock=host \ \ -device virtio-tablet-pci \ -device virtio-vga \ \ -device virtio-blk-pci,drive=ssd1 \ -drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ \ -device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \ \ -device ich9-intel-hda,id=snd,msi=on \ -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ -audiodev coreaudio,id=snd0,out.buffer-count=1 \ \ -daemonize Give following error: objc[3432]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. objc[3432]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. I checked "ps -ef|grep qemu" before and after the command, there was no qemu process running. ** 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/1859920 Title: daemoniz not working on MacOS Status in QEMU: New Bug description: OS: MacOS Catalina 10.15.2 Qemu install via brew: brew install qemu qemu-system-x86_64 -version QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers --- Start Ubuntu Desktop 18.04 client as follow: IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 MAC_ADDR=xx:xx:xx:xx:xx:xx qemu-system-x86_64 \ -no-user-config -nodefaults \ -show-cursor \ -name u64d01 \ -M q35,accel=hvf,usb=off,vmport=off \ -cpu host -smp 4 -m 2048 \ -overcommit mem-lock=off \ -overcommit cpu-pm=off \ -rtc base=utc,clock=host \ \ -device virtio-tablet-pci \ -device virtio-vga \ \ -device virtio-blk-pci,drive=ssd1 \ -drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ \ -device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \ \ -device ich9-intel-hda,id=snd,msi=on \ -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ -audiodev coreaudio,id=snd0,out.buffer-count=1 \ \ -daemonize Give following error: objc[3432]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. objc[3432]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. I checked "ps -ef|grep qemu" before and after the command, there was no qemu process running. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1859920/+subscriptions
[Bug 1859916] [NEW] coreaudio not working on MacOS
Public bug reported: OS: MacOS Catalina 10.15.2 qemu-system-x86_64 -version QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Qemu install via brew: brew install qemu --- I use following to install Ubuntu 18.04 desktop successfully:- IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 MAC_ADDR=xx:xx:xx:xx:xx:xx qemu-system-x86_64 \ -no-user-config -nodefaults \ -show-cursor \ -name u64d01 \ -M q35,accel=hvf,usb=off,vmport=off \ -cpu host -smp 4 -m 2048 \ -overcommit mem-lock=off \ -overcommit cpu-pm=off \ -rtc base=utc,clock=host \ \ -device virtio-tablet-pci \ -device virtio-vga \ \ -device virtio-blk-pci,drive=ssd1 \ -drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ \ -device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \ \ -device ich9-intel-hda,id=snd,msi=on \ -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ -audiodev coreaudio,id=snd0,out.buffer-count=1 \ \ -cdrom $IMG_CD Removing the last -cdrom line Ubuntu desktop boot up and everything work perfectly except the audio. I test with wav audio driver by replacing the -audiodev line as follow, which save the client audio to a wave file, like below and it work perfectly: -audiodev wav,id=snd0,path=$HOME/qemu.wav I start the vm, open firefox and play a few video, then shutdown the vm. Then I can play the qemu.wav file and all the audio was recorded there. However, I can't get audio directly with coreaudio. ** 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/1859916 Title: coreaudio not working on MacOS Status in QEMU: New Bug description: OS: MacOS Catalina 10.15.2 qemu-system-x86_64 -version QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Qemu install via brew: brew install qemu --- I use following to install Ubuntu 18.04 desktop successfully:- IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 MAC_ADDR=xx:xx:xx:xx:xx:xx qemu-system-x86_64 \ -no-user-config -nodefaults \ -show-cursor \ -name u64d01 \ -M q35,accel=hvf,usb=off,vmport=off \ -cpu host -smp 4 -m 2048 \ -overcommit mem-lock=off \ -overcommit cpu-pm=off \ -rtc base=utc,clock=host \ \ -device virtio-tablet-pci \ -device virtio-vga \ \ -device virtio-blk-pci,drive=ssd1 \ -drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ \ -device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ -netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::-:22 \ \ -device ich9-intel-hda,id=snd,msi=on \ -device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ -audiodev coreaudio,id=snd0,out.buffer-count=1 \ \ -cdrom $IMG_CD Removing the last -cdrom line Ubuntu desktop boot up and everything work perfectly except the audio. I test with wav audio driver by replacing the -audiodev line as follow, which save the client audio to a wave file, like below and it work perfectly: -audiodev wav,id=snd0,path=$HOME/qemu.wav I start the vm, open firefox and play a few video, then shutdown the vm. Then I can play the qemu.wav file and all the audio was recorded there. However, I can't get audio directly with coreaudio. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1859916/+subscriptions
Re: Semihosting, arm, riscv, ppc and common code
On Wed, 2020-01-15 at 12:01 +, Alex Bennée wrote: > > > There seem to be some linux-user stuff in there, I'm mostly considering > > whatever ARM does today but we can certainly extend later. > > Depends on if it is to be used. AFAIK the main users of arm linux user > are compiler test cases for M-profile CPUs. For microwatt I was going to implement HW support as well via JTAG but the user linux-user bits are less obviously useful to me. That said, most of that code can trivially be made arch neutral by replacing the use of the arch specific CPU type with CPUState as the first argument to most functions. There are only a handful of arch specific helpers needed from there to extract the op & arg, set the result etc.. > > The idea is to make sure ARM, RiscV and POWER use the same protocol and > > code base to make picolibc (and others) life easier. Bug compatible > > :-) > > Hmm, I'm not so sure. QEMU tries to emulate real HW although I > appreciate that is a somewhat loose definition once you get to things > like -M virt and other such SW like abstractions. Is semihosting even > going to be a thing on real RiscV/Power silicon? It will be on microwatt once I add support for it. We could probably make it work on real power9 if the systems give access to the external debug facilities of the processor as well. I'm no longer involved with powerpc in a professional capacity but I can ask Anton or Paul to help there. Cheers, Ben.
Re: [PATCH v3 4/7] dt-bindings: gpio: Add gpio-repeater bindings
Hi Linus,
On 07/01/20 2:52 PM, Harish Jenny K N wrote:
> On 06/01/20 1:42 PM, Geert Uytterhoeven wrote:
>> Hi Rob,
>>
>> On Fri, Dec 6, 2019 at 4:04 PM Rob Herring wrote:
>>> On Fri, Dec 6, 2019 at 3:17 AM Geert Uytterhoeven
>>> wrote:
On Thu, Dec 5, 2019 at 10:06 PM Rob Herring wrote:
> On Wed, Nov 27, 2019 at 09:42:50AM +0100, Geert Uytterhoeven wrote:
>> Add Device Tree bindings for a GPIO repeater, with optional translation
>> of physical signal properties. This is useful for describing explicitly
>> the presence of e.g. an inverter on a GPIO line, and was inspired by the
>> non-YAML gpio-inverter bindings by Harish Jenny K N
>> [1].
>>
>> Note that this is different from a GPIO Nexus Node[2], which cannot do
>> physical signal property translation.
> It can't? Why not? The point of the passthru mask is to not do
> translation of flags, but without it you are always doing translation of
> cells.
Thanks for pushing me deeper into nexuses!
You're right, you can map from one type to another.
However, you cannot handle the "double inversion" of an ACTIVE_LOW
signal with a physical inverter added:
nexus: led-nexus {
#gpio-cells = <2>;
gpio-map = <0 0 19 GPIO_ACTIVE_LOW>, // inverted
<1 0 20 GPIO_ACTIVE_HIGH>,//
noninverted
<2 0 21 GPIO_ACTIVE_LOW>; // inverted
gpio-map-mask = <3 0>;
// default gpio-map-pass-thru = <0 0>;
};
leds {
compatible = "gpio-leds";
led6-inverted {
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
led7-noninverted {
gpios = < 1 GPIO_ACTIVE_HIGH>;
};
led8-double-inverted { // FAILS: still inverted
gpios = < 2 GPIO_ACTIVE_LOW>;
};
};
It "works" if the last entry in gpio-map is changed to GPIO_ACTIVE_HIGH.
Still, the consumer would see the final translated polarity, and not the
actual one it needs to program the consumer for.
>>> I'm not really following. Why isn't a double inversion just the same
>>> as no inversion?
>> Because the nexus can only mask and/or substitute bits.
>> It cannot do a XOR operation on the GPIO flags.
>>
>> While an inverter can be described implicitly by exchanging the
>> GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags, this has its limitations.
>> Each GPIO line has only a single GPIO_ACTIVE_* flag, but applies to both
>> th provider and consumer sides:
>> 1. The GPIO provider (controller) looks at the flags to know the
>> polarity, so it can translate between logical (active/not active)
>> and physical (high/low) signal levels.
>> 2. While the signal polarity is usually fixed on the GPIO consumer
>> side (e.g. an LED is tied to either the supply voltage or GND),
>> it may be configurable on some devices, and both sides need to
>> agree. Hence the GPIO_ACTIVE_* flag as seen by the consumer must
>> match the actual polarity.
>> There exists a similar issue with interrupt flags, where both the
>> interrupt controller and the device generating the interrupt need
>> to agree, which breaks in the presence of a physical inverter not
>> described in DT (see e.g. [3]).
> Adding an inverted flag as I've suggested would also solve this issue.
As per your suggestion in "Re: [PATCH V4 2/2] gpio: inverter: document
the inverter bindings"?
https://lore.kernel.org/linux-devicetree/cal_jsqlp___2o-nau+2ppqy0qmjx6+an3hbyz-ob9+qfvwg...@mail.gmail.com/
Oh, now I understand. I was misguided by Harish' interpretation
https://lore.kernel.org/linux-devicetree/dde73334-a26d-b53f-6b97-4101c1cdc...@mentor.com/
which assumed an "inverted" property, e.g.
inverted = /bits/ 8 <0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0>;
But you actually meant a new GPIO_INVERTED flag, to be ORed into the 2nd
cell of a GPIO specifier? I.e. add to include/dt-bindings/gpio/gpio.h"
/* Bit 6 expresses the presence of a physical inverter */
#define GPIO_INVERTED 64
>>> Exactly.
>> OK, makes sense.
>
> The reason I went for "inverted" property is because, we can specify this for
> gpios at provider side.
>
> The usecase needed to define the polarity which did not have kernel space
> consumer driver.
>
>
> I am not sure how do we achieve this using GPIO_INVERTED flag. We need some
> sort of node/gpio-hog to specify these
>
> type of properties? Otherwise gpio-pin will be held by kernel or the module
> using the hog property and the user space application will not be able to
Re: [PATCH v2 82/86] numa: forbid '-numa node, mem' for 5.0 and newer machine types
On Wed, Jan 15, 2020 at 04:07:37PM +0100, Igor Mammedov wrote:
> Deprecation period is ran out and it's a time to flip the switch
> introduced by cd5ff8333a.
> Disable legacy option for new machine types and amend documentation.
>
> Signed-off-by: Igor Mammedov
ppc parts
Acked-by: David Gibson
> ---
> CC: peter.mayd...@linaro.org
> CC: ehabk...@redhat.com
> CC: marcel.apfelb...@gmail.com
> CC: m...@redhat.com
> CC: pbonz...@redhat.com
> CC: r...@twiddle.net
> CC: da...@gibson.dropbear.id.au
> CC: libvir-l...@redhat.com
> CC: qemu-...@nongnu.org
> CC: qemu-...@nongnu.org
> ---
> hw/arm/virt.c| 2 +-
> hw/core/numa.c | 6 ++
> hw/i386/pc.c | 1 -
> hw/i386/pc_piix.c| 1 +
> hw/i386/pc_q35.c | 1 +
> hw/ppc/spapr.c | 2 +-
> qemu-deprecated.texi | 16
> qemu-options.hx | 8
> 8 files changed, 14 insertions(+), 23 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index e2fbca3..49de0d8 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -2049,7 +2049,6 @@ static void virt_machine_class_init(ObjectClass *oc,
> void *data)
> hc->pre_plug = virt_machine_device_pre_plug_cb;
> hc->plug = virt_machine_device_plug_cb;
> hc->unplug_request = virt_machine_device_unplug_request_cb;
> -mc->numa_mem_supported = true;
> mc->auto_enable_numa_with_memhp = true;
> mc->default_ram_id = "mach-virt.ram";
> }
> @@ -2153,6 +2152,7 @@ DEFINE_VIRT_MACHINE_AS_LATEST(5, 0)
> static void virt_machine_4_2_options(MachineClass *mc)
> {
> compat_props_add(mc->compat_props, hw_compat_4_2, hw_compat_4_2_len);
> +mc->numa_mem_supported = true;
> }
> DEFINE_VIRT_MACHINE(4, 2)
>
> diff --git a/hw/core/numa.c b/hw/core/numa.c
> index 0970a30..3177066 100644
> --- a/hw/core/numa.c
> +++ b/hw/core/numa.c
> @@ -117,6 +117,12 @@ static void parse_numa_node(MachineState *ms,
> NumaNodeOptions *node,
> }
>
> if (node->has_mem) {
> +if (!mc->numa_mem_supported) {
> +error_setg(errp, "Parameter -numa node,mem is not supported by
> this"
> + " machine type. Use -numa node,memdev instead");
> +return;
> +}
> +
> numa_info[nodenr].node_mem = node->mem;
> if (!qtest_enabled()) {
> warn_report("Parameter -numa node,mem is deprecated,"
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 21b8290..fa8d024 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1947,7 +1947,6 @@ static void pc_machine_class_init(ObjectClass *oc, void
> *data)
> hc->unplug = pc_machine_device_unplug_cb;
> mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;
> mc->nvdimm_supported = true;
> -mc->numa_mem_supported = true;
> mc->default_ram_id = "pc.ram";
>
> object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int",
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index fa12203..0a9b9e0 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -435,6 +435,7 @@ static void pc_i440fx_4_2_machine_options(MachineClass *m)
> pc_i440fx_5_0_machine_options(m);
> m->alias = NULL;
> m->is_default = 0;
> +m->numa_mem_supported = true;
> compat_props_add(m->compat_props, hw_compat_4_2, hw_compat_4_2_len);
> compat_props_add(m->compat_props, pc_compat_4_2, pc_compat_4_2_len);
> }
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 84cf925..4d6e2be 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -363,6 +363,7 @@ static void pc_q35_4_2_machine_options(MachineClass *m)
> {
> pc_q35_5_0_machine_options(m);
> m->alias = NULL;
> +m->numa_mem_supported = true;
> compat_props_add(m->compat_props, hw_compat_4_2, hw_compat_4_2_len);
> compat_props_add(m->compat_props, pc_compat_4_2, pc_compat_4_2_len);
> }
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index bcbe1f1..2686b73 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4383,7 +4383,6 @@ static void spapr_machine_class_init(ObjectClass *oc,
> void *data)
> * in which LMBs are represented and hot-added
> */
> mc->numa_mem_align_shift = 28;
> -mc->numa_mem_supported = true;
> mc->auto_enable_numa = true;
>
> smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
> @@ -4465,6 +4464,7 @@ static void
> spapr_machine_4_2_class_options(MachineClass *mc)
> {
> spapr_machine_5_0_class_options(mc);
> compat_props_add(mc->compat_props, hw_compat_4_2, hw_compat_4_2_len);
> +mc->numa_mem_supported = true;
> }
>
> DEFINE_SPAPR_MACHINE(4_2, "4.2", false);
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 982af95..17a0e1d 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -89,22 +89,6 @@ error in the future.
> The @code{-realtime mlock=on|off} argument has been replaced by the
> @code{-overcommit mem-lock=on|off} argument.
>
> -@subsection -numa node,mem=@var{size} (since 4.1)
> -
> -The
Re: [PATCH v2 71/86] ppc:virtex_ml507: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:26PM +0100, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
> ---
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> CC: edgar.igles...@gmail.com
> ---
> hw/ppc/virtex_ml507.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c
> index 651d8db..b74a269 100644
> --- a/hw/ppc/virtex_ml507.c
> +++ b/hw/ppc/virtex_ml507.c
> @@ -193,7 +193,6 @@ static int xilinx_load_device_tree(hwaddr addr,
>
> static void virtex_init(MachineState *machine)
> {
> -ram_addr_t ram_size = machine->ram_size;
> const char *kernel_filename = machine->kernel_filename;
> const char *kernel_cmdline = machine->kernel_cmdline;
> hwaddr initrd_base = 0;
> @@ -204,7 +203,6 @@ static void virtex_init(MachineState *machine)
> CPUPPCState *env;
> hwaddr ram_base = 0;
> DriveInfo *dinfo;
> -MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
> qemu_irq irq[32], *cpu_irq;
> int kernel_size;
> int i;
> @@ -221,8 +219,7 @@ static void virtex_init(MachineState *machine)
>
> qemu_register_reset(main_cpu_reset, cpu);
>
> -memory_region_allocate_system_memory(phys_ram, NULL, "ram", ram_size);
> -memory_region_add_subregion(address_space_mem, ram_base, phys_ram);
> +memory_region_add_subregion(address_space_mem, ram_base, machine->ram);
>
> dinfo = drive_get(IF_PFLASH, 0, 0);
> pflash_cfi01_register(PFLASH_BASEADDR, "virtex.flash", FLASH_SIZE,
> @@ -265,7 +262,7 @@ static void virtex_init(MachineState *machine)
> /* If we failed loading ELF's try a raw image. */
> kernel_size = load_image_targphys(kernel_filename,
>boot_offset,
> - ram_size);
> + machine->ram_size);
> boot_info.bootstrap_pc = boot_offset;
> high = boot_info.bootstrap_pc + kernel_size + 8192;
> }
> @@ -276,7 +273,7 @@ static void virtex_init(MachineState *machine)
> if (machine->initrd_filename) {
> initrd_base = high = ROUND_UP(high, 4);
> initrd_size = load_image_targphys(machine->initrd_filename,
> - high, ram_size - high);
> + high, machine->ram_size -
> high);
>
> if (initrd_size < 0) {
> error_report("couldn't load ram disk '%s'",
> @@ -290,7 +287,7 @@ static void virtex_init(MachineState *machine)
> boot_info.fdt = high + (8192 * 2);
> boot_info.fdt &= ~8191;
>
> -xilinx_load_device_tree(boot_info.fdt, ram_size,
> +xilinx_load_device_tree(boot_info.fdt, machine->ram_size,
> initrd_base, initrd_size,
> kernel_cmdline);
> }
> @@ -302,6 +299,7 @@ static void virtex_machine_init(MachineClass *mc)
> mc->desc = "Xilinx Virtex ML507 reference design";
> mc->init = virtex_init;
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440-xilinx");
> +mc->default_ram_id = "ram";
> }
>
> DEFINE_MACHINE("virtex-ml507", virtex_machine_init)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v2 71/86] ppc:virtex_ml507: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:26PM +0100, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
Since this is (AFAICT) independent of the main purpose of your series,
I've also applied it to my ppc-for-5.0 tree. If we get a conflict
because of that it should be easy to resolve.
> ---
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> CC: edgar.igles...@gmail.com
> ---
> hw/ppc/virtex_ml507.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c
> index 651d8db..b74a269 100644
> --- a/hw/ppc/virtex_ml507.c
> +++ b/hw/ppc/virtex_ml507.c
> @@ -193,7 +193,6 @@ static int xilinx_load_device_tree(hwaddr addr,
>
> static void virtex_init(MachineState *machine)
> {
> -ram_addr_t ram_size = machine->ram_size;
> const char *kernel_filename = machine->kernel_filename;
> const char *kernel_cmdline = machine->kernel_cmdline;
> hwaddr initrd_base = 0;
> @@ -204,7 +203,6 @@ static void virtex_init(MachineState *machine)
> CPUPPCState *env;
> hwaddr ram_base = 0;
> DriveInfo *dinfo;
> -MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
> qemu_irq irq[32], *cpu_irq;
> int kernel_size;
> int i;
> @@ -221,8 +219,7 @@ static void virtex_init(MachineState *machine)
>
> qemu_register_reset(main_cpu_reset, cpu);
>
> -memory_region_allocate_system_memory(phys_ram, NULL, "ram", ram_size);
> -memory_region_add_subregion(address_space_mem, ram_base, phys_ram);
> +memory_region_add_subregion(address_space_mem, ram_base, machine->ram);
>
> dinfo = drive_get(IF_PFLASH, 0, 0);
> pflash_cfi01_register(PFLASH_BASEADDR, "virtex.flash", FLASH_SIZE,
> @@ -265,7 +262,7 @@ static void virtex_init(MachineState *machine)
> /* If we failed loading ELF's try a raw image. */
> kernel_size = load_image_targphys(kernel_filename,
>boot_offset,
> - ram_size);
> + machine->ram_size);
> boot_info.bootstrap_pc = boot_offset;
> high = boot_info.bootstrap_pc + kernel_size + 8192;
> }
> @@ -276,7 +273,7 @@ static void virtex_init(MachineState *machine)
> if (machine->initrd_filename) {
> initrd_base = high = ROUND_UP(high, 4);
> initrd_size = load_image_targphys(machine->initrd_filename,
> - high, ram_size - high);
> + high, machine->ram_size -
> high);
>
> if (initrd_size < 0) {
> error_report("couldn't load ram disk '%s'",
> @@ -290,7 +287,7 @@ static void virtex_init(MachineState *machine)
> boot_info.fdt = high + (8192 * 2);
> boot_info.fdt &= ~8191;
>
> -xilinx_load_device_tree(boot_info.fdt, ram_size,
> +xilinx_load_device_tree(boot_info.fdt, machine->ram_size,
> initrd_base, initrd_size,
> kernel_cmdline);
> }
> @@ -302,6 +299,7 @@ static void virtex_machine_init(MachineClass *mc)
> mc->desc = "Xilinx Virtex ML507 reference design";
> mc->init = virtex_init;
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440-xilinx");
> +mc->default_ram_id = "ram";
> }
>
> DEFINE_MACHINE("virtex-ml507", virtex_machine_init)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH 053/104] virtiofsd: Drop CAP_FSETID if client asked for it
> From: Vivek Goyal
>
> If client requested killing setuid/setgid bits on file being written, drop
> CAP_FSETID capability so that setuid/setgid bits are cleared upon write
> automatically.
>
> pjdfstest chown/12.t needs this.
>
> Signed-off-by: Vivek Goyal
> dgilbert: reworked for libcap-ng
Looks good to me.
Reviewed-by: Misono Tomohiro
> ---
> tools/virtiofsd/passthrough_ll.c | 105 +++
> 1 file changed, 105 insertions(+)
>
> diff --git a/tools/virtiofsd/passthrough_ll.c
> b/tools/virtiofsd/passthrough_ll.c
> index 6a09b28608..ab318a6f36 100644
> --- a/tools/virtiofsd/passthrough_ll.c
> +++ b/tools/virtiofsd/passthrough_ll.c
> @@ -201,6 +201,91 @@ static int load_capng(void)
> return 0;
> }
>
> +/*
> + * Helpers for dropping and regaining effective capabilities. Returns 0
> + * on success, error otherwise
> + */
> +static int drop_effective_cap(const char *cap_name, bool *cap_dropped)
> +{
> +int cap, ret;
> +
> +cap = capng_name_to_capability(cap_name);
> +if (cap < 0) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "capng_name_to_capability(%s) failed:%s\n",
> + cap_name, strerror(errno));
> +goto out;
> +}
> +
> +if (load_capng()) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "load_capng() failed\n");
> +goto out;
> +}
> +
> +/* We dont have this capability in effective set already. */
> +if (!capng_have_capability(CAPNG_EFFECTIVE, cap)) {
> +ret = 0;
> +goto out;
> +}
> +
> +if (capng_update(CAPNG_DROP, CAPNG_EFFECTIVE, cap)) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "capng_update(DROP,) failed\n");
> +goto out;
> +}
> +
> +if (capng_apply(CAPNG_SELECT_CAPS)) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "drop:capng_apply() failed\n");
> +goto out;
> +}
> +
> +ret = 0;
> +if (cap_dropped) {
> +*cap_dropped = true;
> +}
> +
> +out:
> +return ret;
> +}
> +
> +static int gain_effective_cap(const char *cap_name)
> +{
> +int cap;
> +int ret = 0;
> +
> +cap = capng_name_to_capability(cap_name);
> +if (cap < 0) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "capng_name_to_capability(%s) failed:%s\n",
> + cap_name, strerror(errno));
> +goto out;
> +}
> +
> +if (load_capng()) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "load_capng() failed\n");
> +goto out;
> +}
> +
> +if (capng_update(CAPNG_ADD, CAPNG_EFFECTIVE, cap)) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "capng_update(ADD,) failed\n");
> +goto out;
> +}
> +
> +if (capng_apply(CAPNG_SELECT_CAPS)) {
> +ret = errno;
> +fuse_log(FUSE_LOG_ERR, "gain:capng_apply() failed\n");
> +goto out;
> +}
> +ret = 0;
> +
> +out:
> +return ret;
> +}
> +
> static void lo_map_init(struct lo_map *map)
> {
> map->elems = NULL;
> @@ -1559,6 +1644,7 @@ static void lo_write_buf(fuse_req_t req, fuse_ino_t ino,
> (void)ino;
> ssize_t res;
> struct fuse_bufvec out_buf = FUSE_BUFVEC_INIT(fuse_buf_size(in_buf));
> +bool cap_fsetid_dropped = false;
>
> out_buf.buf[0].flags = FUSE_BUF_IS_FD | FUSE_BUF_FD_SEEK;
> out_buf.buf[0].fd = lo_fi_fd(req, fi);
> @@ -1570,12 +1656,31 @@ static void lo_write_buf(fuse_req_t req, fuse_ino_t
> ino,
> out_buf.buf[0].size, (unsigned long)off);
> }
>
> +/*
> + * If kill_priv is set, drop CAP_FSETID which should lead to kernel
> + * clearing setuid/setgid on file.
> + */
> +if (fi->kill_priv) {
> +res = drop_effective_cap("FSETID", _fsetid_dropped);
> +if (res != 0) {
> +fuse_reply_err(req, res);
> +return;
> +}
> +}
> +
> res = fuse_buf_copy(_buf, in_buf, 0);
> if (res < 0) {
> fuse_reply_err(req, -res);
> } else {
> fuse_reply_write(req, (size_t)res);
> }
> +
> +if (cap_fsetid_dropped) {
> +res = gain_effective_cap("FSETID");
> +if (res) {
> +fuse_log(FUSE_LOG_ERR, "Failed to gain CAP_FSETID\n");
> +}
> +}
> }
>
> static void lo_statfs(fuse_req_t req, fuse_ino_t ino)
> --
> 2.23.0
Re: [PATCH v2 68/86] ppc:prep: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:23PM +0100, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
Although it's probably fairly pointless, since I'm looking to merge a
patch removing prep entirely soon.
> ---
> CC: hpous...@reactos.org
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> ---
> hw/ppc/prep.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
> index 862345c..bf75dde 100644
> --- a/hw/ppc/prep.c
> +++ b/hw/ppc/prep.c
> @@ -400,7 +400,6 @@ static int PPC_NVRAM_set_params (Nvram *nvram, uint16_t
> NVRAM_size,
> /* PowerPC PREP hardware initialisation */
> static void ppc_prep_init(MachineState *machine)
> {
> -ram_addr_t ram_size = machine->ram_size;
> const char *kernel_filename = machine->kernel_filename;
> const char *kernel_cmdline = machine->kernel_cmdline;
> const char *initrd_filename = machine->initrd_filename;
> @@ -413,7 +412,6 @@ static void ppc_prep_init(MachineState *machine)
> MemoryRegion *xcsr = g_new(MemoryRegion, 1);
> #endif
> int linux_boot, i, nb_nics1;
> -MemoryRegion *ram = g_new(MemoryRegion, 1);
> uint32_t kernel_base, initrd_base;
> long kernel_size, initrd_size;
> DeviceState *dev;
> @@ -444,15 +442,14 @@ static void ppc_prep_init(MachineState *machine)
> qemu_register_reset(ppc_prep_reset, cpu);
> }
>
> -/* allocate RAM */
> -memory_region_allocate_system_memory(ram, NULL, "ppc_prep.ram",
> ram_size);
> -memory_region_add_subregion(sysmem, 0, ram);
> +/* map RAM */
> +memory_region_add_subregion(sysmem, 0, machine->ram);
>
> if (linux_boot) {
> kernel_base = KERNEL_LOAD_ADDR;
> /* now we can load the kernel */
> kernel_size = load_image_targphys(kernel_filename, kernel_base,
> - ram_size - kernel_base);
> + machine->ram_size - kernel_base);
> if (kernel_size < 0) {
> error_report("could not load kernel '%s'", kernel_filename);
> exit(1);
> @@ -461,7 +458,7 @@ static void ppc_prep_init(MachineState *machine)
> if (initrd_filename) {
> initrd_base = INITRD_LOAD_ADDR;
> initrd_size = load_image_targphys(initrd_filename, initrd_base,
> - ram_size - initrd_base);
> + machine->ram_size -
> initrd_base);
> if (initrd_size < 0) {
> error_report("could not load initial ram disk '%s'",
> initrd_filename);
> @@ -576,7 +573,7 @@ static void ppc_prep_init(MachineState *machine)
> sysctrl->nvram = m48t59;
>
> /* Initialise NVRAM */
> -PPC_NVRAM_set_params(m48t59, NVRAM_SIZE, "PREP", ram_size,
> +PPC_NVRAM_set_params(m48t59, NVRAM_SIZE, "PREP", machine->ram_size,
> ppc_boot_device,
> kernel_base, kernel_size,
> kernel_cmdline,
> @@ -596,6 +593,7 @@ static void prep_machine_init(MachineClass *mc)
> mc->default_boot_order = "cad";
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("602");
> mc->default_display = "std";
> +mc->default_ram_id = "ppc_prep.ram";
> }
>
> static int prep_set_cmos_checksum(DeviceState *dev, void *opaque)
> @@ -814,6 +812,7 @@ static void ibm_40p_machine_init(MachineClass *mc)
> mc->init = ibm_40p_init;
> mc->max_cpus = 1;
> mc->default_ram_size = 128 * MiB;
> +mc->default_ram_id = "ppc_prep.ram";
> mc->block_default_type = IF_SCSI;
> mc->default_boot_order = "c";
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("604");
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v2 69/86] ppc:spapr: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:24PM +0100, Igor Mammedov wrote: > memory_region_allocate_system_memory() API is going away, so > replace it with memdev allocated MemoryRegion. The later is > initialized by generic code, so board only needs to opt in > to memdev scheme by providing > MachineClass::default_ram_id > and using MachineState::ram instead of manually initializing > RAM memory region. > > Signed-off-by: Igor Mammedov Acked-by: David Gibson > --- > CC: da...@gibson.dropbear.id.au > CC: qemu-...@nongnu.org > --- > hw/ppc/spapr.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index 30a5fbd..bcbe1f1 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -2587,7 +2587,6 @@ static void spapr_machine_init(MachineState *machine) > PCIHostState *phb; > int i; > MemoryRegion *sysmem = get_system_memory(); > -MemoryRegion *ram = g_new(MemoryRegion, 1); > hwaddr node0_size = spapr_node0_size(machine); > long load_limit, fw_size; > char *filename; > @@ -2766,10 +2765,8 @@ static void spapr_machine_init(MachineState *machine) > kvmppc_enable_h_page_init(); > } > > -/* allocate RAM */ > -memory_region_allocate_system_memory(ram, NULL, "ppc_spapr.ram", > - machine->ram_size); > -memory_region_add_subregion(sysmem, 0, ram); > +/* map RAM */ > +memory_region_add_subregion(sysmem, 0, machine->ram); > > /* always allocate the device memory information */ > machine->device_memory = g_malloc0(sizeof(*machine->device_memory)); > @@ -4344,6 +4341,7 @@ static void spapr_machine_class_init(ObjectClass *oc, > void *data) > mc->no_parallel = 1; > mc->default_boot_order = ""; > mc->default_ram_size = 512 * MiB; > +mc->default_ram_id = "ppc_spapr.ram"; > mc->default_display = "std"; > mc->kvm_type = spapr_kvm_type; > machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SPAPR_PCI_HOST_BRIDGE); -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v2 66/86] ppc/{ppc440_bamboo, sam460x}: drop RAM size fixup
On Wed, Jan 15, 2020 at 04:07:21PM +0100, Igor Mammedov wrote:
> If user provided non-sense RAM size, board will complain and
> continue running with max RAM size supported or sometimes
> crash like this:
> %QEMU -M bamboo -m 1
> exec.c:1926: find_ram_offset: Assertion `size != 0' failed.
> Aborted (core dumped)
> Also RAM is going to be allocated by generic code, so it won't be
> possible for board to fix things up for user.
>
> Make it error message and exit to force user fix CLI,
> instead of accepting non-sense CLI values.
> That also fixes crash issue, since wrongly calculated size
> isn't used to allocate RAM
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
> ---
> v2:
> * s/ppc4xx_sdram_adjust/ppc4xx_sdram_prep/
> (BALATON Zoltan )
> * print possible valid ram size id not all RAM was distributed
> * initialize ram_bases/ram_bases at the same time we are checking
> that user supplied RAM would fit available banks and drop nested
> loop that were duplicating the same calculations.
> * coincidentally fix crash when -m is less than minimal bank size
>
> CC: bala...@eik.bme.hu
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> ---
> include/hw/ppc/ppc4xx.h | 9
> hw/ppc/ppc440_bamboo.c | 11 --
> hw/ppc/ppc4xx_devs.c| 56
> +
> hw/ppc/sam460ex.c | 5 ++---
> 4 files changed, 39 insertions(+), 42 deletions(-)
>
> diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
> index 7d82259..103c875 100644
> --- a/include/hw/ppc/ppc4xx.h
> +++ b/include/hw/ppc/ppc4xx.h
> @@ -42,11 +42,10 @@ enum {
> qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
> uint32_t dcr_base, int has_ssr, int has_vr);
>
> -ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
> - MemoryRegion ram_memories[],
> - hwaddr ram_bases[],
> - hwaddr ram_sizes[],
> - const ram_addr_t sdram_bank_sizes[]);
> +void ppc4xx_sdram_prep(ram_addr_t ram_size, int nr_banks,
> + MemoryRegion ram_memories[],
> + hwaddr ram_bases[], hwaddr ram_sizes[],
> + const ram_addr_t sdram_bank_sizes[]);
>
> void ppc4xx_sdram_init (CPUPPCState *env, qemu_irq irq, int nbanks,
> MemoryRegion ram_memories[],
> diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
> index b782641..c162598 100644
> --- a/hw/ppc/ppc440_bamboo.c
> +++ b/hw/ppc/ppc440_bamboo.c
> @@ -158,7 +158,6 @@ static void main_cpu_reset(void *opaque)
>
> static void bamboo_init(MachineState *machine)
> {
> -ram_addr_t ram_size = machine->ram_size;
> const char *kernel_filename = machine->kernel_filename;
> const char *kernel_cmdline = machine->kernel_cmdline;
> const char *initrd_filename = machine->initrd_filename;
> @@ -203,10 +202,8 @@ static void bamboo_init(MachineState *machine)
> /* SDRAM controller */
> memset(ram_bases, 0, sizeof(ram_bases));
> memset(ram_sizes, 0, sizeof(ram_sizes));
> -ram_size = ppc4xx_sdram_adjust(ram_size, PPC440EP_SDRAM_NR_BANKS,
> - ram_memories,
> - ram_bases, ram_sizes,
> - ppc440ep_sdram_bank_sizes);
> +ppc4xx_sdram_prep(ram_size, PPC440EP_SDRAM_NR_BANKS, ram_memories,
> + ram_bases, ram_sizes, ppc440ep_sdram_bank_sizes);
> /* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0.
> */
> ppc4xx_sdram_init(env, pic[14], PPC440EP_SDRAM_NR_BANKS, ram_memories,
>ram_bases, ram_sizes, 1);
> @@ -268,7 +265,7 @@ static void bamboo_init(MachineState *machine)
> /* Load initrd. */
> if (initrd_filename) {
> initrd_size = load_image_targphys(initrd_filename, RAMDISK_ADDR,
> - ram_size - RAMDISK_ADDR);
> + machine->ram_size - RAMDISK_ADDR);
>
> if (initrd_size < 0) {
> error_report("could not load ram disk '%s' at %x",
> @@ -279,7 +276,7 @@ static void bamboo_init(MachineState *machine)
>
> /* If we're loading a kernel directly, we must load the device tree too.
> */
> if (kernel_filename) {
> -if (bamboo_load_device_tree(FDT_ADDR, ram_size, RAMDISK_ADDR,
> +if (bamboo_load_device_tree(FDT_ADDR, machine->ram_size,
> RAMDISK_ADDR,
> initrd_size, kernel_cmdline) < 0) {
> error_report("couldn't load device tree");
> exit(1);
> diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
> index c2e5013..92d33a4 100644
> --- a/hw/ppc/ppc4xx_devs.c
> +++ b/hw/ppc/ppc4xx_devs.c
> @@ -673,16 +673,16 @@ void ppc4xx_sdram_init (CPUPPCState *env, qemu_irq irq,
Re: [PATCH v2 65/86] ppc:ppc405_boards: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:20PM +0100, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> PS:
> in ref405ep alias RAM into ram_memories[] to avoid re-factoring
> its user ppc405ep_init(), which would be invasive and out of
> scope this patch.
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
> ---
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> ---
> hw/ppc/ppc405_boards.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
> index a7a432d..f447e6e 100644
> --- a/hw/ppc/ppc405_boards.c
> +++ b/hw/ppc/ppc405_boards.c
> @@ -168,8 +168,8 @@ static void ref405ep_init(MachineState *machine)
> }
>
> /* XXX: fix this */
> -memory_region_allocate_system_memory(_memories[0], NULL,
> "ef405ep.ram",
> - machine->ram_size);
> +memory_region_init_alias(_memories[0], NULL, "ef405ep.ram.alias",
> + machine->ram, 0, machine->ram_size);
> ram_bases[0] = 0;
> ram_sizes[0] = machine->ram_size;
> memory_region_init(_memories[1], NULL, "ef405ep.ram1", 0);
> @@ -310,6 +310,7 @@ static void ref405ep_class_init(ObjectClass *oc, void
> *data)
> mc->desc = "ref405ep";
> mc->init = ref405ep_init;
> mc->default_ram_size = 0x0800;
> +mc->default_ram_id = "ef405ep.ram";
> }
>
> static const TypeInfo ref405ep_type = {
> @@ -422,7 +423,6 @@ static void taihu_405ep_init(MachineState *machine)
> MemoryRegion *sysmem = get_system_memory();
> MemoryRegion *bios;
> MemoryRegion *ram_memories = g_new(MemoryRegion, 2);
> -MemoryRegion *ram = g_malloc0(sizeof(*ram));
> hwaddr ram_bases[2], ram_sizes[2];
> long bios_size;
> target_ulong kernel_base, initrd_base;
> @@ -436,18 +436,16 @@ static void taihu_405ep_init(MachineState *machine)
> mc->default_ram_size);
> exit(EXIT_FAILURE);
> }
> -memory_region_allocate_system_memory(ram, NULL, "taihu_405ep.ram",
> - machine->ram_size);
>
> ram_bases[0] = 0;
> ram_sizes[0] = 0x0400;
> memory_region_init_alias(_memories[0], NULL,
> - "taihu_405ep.ram-0", ram, ram_bases[0],
> + "taihu_405ep.ram-0", machine->ram, ram_bases[0],
> ram_sizes[0]);
> ram_bases[1] = 0x0400;
> ram_sizes[1] = 0x0400;
> memory_region_init_alias(_memories[1], NULL,
> - "taihu_405ep.ram-1", ram, ram_bases[1],
> + "taihu_405ep.ram-1", machine->ram, ram_bases[1],
> ram_sizes[1]);
> ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
>, , kernel_filename == NULL ? 0 : 1);
> @@ -543,6 +541,7 @@ static void taihu_class_init(ObjectClass *oc, void *data)
> mc->desc = "taihu";
> mc->init = taihu_405ep_init;
> mc->default_ram_size = 0x0800;
> +mc->default_ram_id = "ef405ep.ram";
> }
>
> static const TypeInfo taihu_type = {
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v2 64/86] ppc:ppc405_boards: add RAM size checks
On Wed, Jan 15, 2020 at 04:07:19PM +0100, Igor Mammedov wrote:
> If user provided non-sense RAM size, board will ignore it
> and continue running with fixed RAM size.
>
> Also RAM is going to be allocated by generic code, so it
> won't be possible for board to fix CLI.
>
> Make it error message and exit to force user fix CLI,
> instead of accepting non-sense CLI values.
>
> PS:
> move fixed RAM size into mc->default_ram_size, so that
> generic code will know how much to allocate.
>
> Signed-off-by: Igor Mammedov
Wow, that's spectacularly broken.
Acked-by: David Gibson
> ---
> v2:
> * fix format string causing build failure on 32-bit host
> (Philippe Mathieu-Daudé )
>
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> ---
> hw/ppc/ppc405_boards.c | 36 +++-
> 1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
> index 1f721fe..a7a432d 100644
> --- a/hw/ppc/ppc405_boards.c
> +++ b/hw/ppc/ppc405_boards.c
> @@ -137,7 +137,7 @@ static void ref405ep_fpga_init(MemoryRegion *sysmem,
> uint32_t base)
>
> static void ref405ep_init(MachineState *machine)
> {
> -ram_addr_t ram_size = machine->ram_size;
> +MachineClass *mc = MACHINE_GET_CLASS(machine);
> const char *kernel_filename = machine->kernel_filename;
> const char *kernel_cmdline = machine->kernel_cmdline;
> const char *initrd_filename = machine->initrd_filename;
> @@ -161,15 +161,20 @@ static void ref405ep_init(MachineState *machine)
> DriveInfo *dinfo;
> MemoryRegion *sysmem = get_system_memory();
>
> +if (machine->ram_size != mc->default_ram_size) {
> +error_report("Invalid RAM size, should be " RAM_ADDR_UFMT " Bytes",
> + mc->default_ram_size);
> +exit(EXIT_FAILURE);
> +}
> +
> /* XXX: fix this */
> memory_region_allocate_system_memory(_memories[0], NULL,
> "ef405ep.ram",
> - 0x0800);
> + machine->ram_size);
> ram_bases[0] = 0;
> -ram_sizes[0] = 0x0800;
> +ram_sizes[0] = machine->ram_size;
> memory_region_init(_memories[1], NULL, "ef405ep.ram1", 0);
> ram_bases[1] = 0x;
> ram_sizes[1] = 0x;
> -ram_size = 128 * MiB;
> env = ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
> , , kernel_filename == NULL ? 0 : 1);
> /* allocate SRAM */
> @@ -227,7 +232,7 @@ static void ref405ep_init(MachineState *machine)
> if (linux_boot) {
> memset(, 0, sizeof(bd));
> bd.bi_memstart = 0x;
> -bd.bi_memsize = ram_size;
> +bd.bi_memsize = machine->ram_size;
> bd.bi_flashstart = -bios_size;
> bd.bi_flashsize = -bios_size;
> bd.bi_flashoffset = 0;
> @@ -255,7 +260,7 @@ static void ref405ep_init(MachineState *machine)
> kernel_base = KERNEL_LOAD_ADDR;
> /* now we can load the kernel */
> kernel_size = load_image_targphys(kernel_filename, kernel_base,
> - ram_size - kernel_base);
> + machine->ram_size - kernel_base);
> if (kernel_size < 0) {
> error_report("could not load kernel '%s'", kernel_filename);
> exit(1);
> @@ -266,7 +271,7 @@ static void ref405ep_init(MachineState *machine)
> if (initrd_filename) {
> initrd_base = INITRD_LOAD_ADDR;
> initrd_size = load_image_targphys(initrd_filename, initrd_base,
> - ram_size - initrd_base);
> + machine->ram_size -
> initrd_base);
> if (initrd_size < 0) {
> error_report("could not load initial ram disk '%s'",
> initrd_filename);
> @@ -304,6 +309,7 @@ static void ref405ep_class_init(ObjectClass *oc, void
> *data)
>
> mc->desc = "ref405ep";
> mc->init = ref405ep_init;
> +mc->default_ram_size = 0x0800;
> }
>
> static const TypeInfo ref405ep_type = {
> @@ -408,7 +414,7 @@ static void taihu_cpld_init(MemoryRegion *sysmem,
> uint32_t base)
>
> static void taihu_405ep_init(MachineState *machine)
> {
> -ram_addr_t ram_size = machine->ram_size;
> +MachineClass *mc = MACHINE_GET_CLASS(machine);
> const char *kernel_filename = machine->kernel_filename;
> const char *initrd_filename = machine->initrd_filename;
> char *filename;
> @@ -425,10 +431,13 @@ static void taihu_405ep_init(MachineState *machine)
> int fl_idx;
> DriveInfo *dinfo;
>
> -/* RAM is soldered to the board so the size cannot be changed */
> -ram_size = 0x0800;
> +if (machine->ram_size != mc->default_ram_size) {
> +error_report("Invalid RAM size, should be " RAM_ADDR_UFMT " Bytes",
> +
Re: [RFC PATCH 3/3] Introduce Configurable Number of Memory Slots Exposed by vhost-user:
On Tue, Jan 14, 2020 at 02:12:46AM -0500, Michael S. Tsirkin wrote: > > On Mon, Dec 09, 2019 at 02:00:47AM -0500, Raphael Norwitz wrote: > > The current vhost-user implementation in Qemu imposes a limit on the > > maximum number of memory slots exposed to a VM using a vhost-user > > device. This change provides a new protocol feature > > VHOST_USER_F_CONFIGURE_SLOTS which, when enabled, lifts this limit > > and allows a VM with a vhost-user device to expose a configurable > > number of memory slots, up to the maximum supported by the platform. > > Existing backends are unaffected. > > > > This feature works by using three new messages, > > VHOST_USER_GET_MAX_MEM_SLOTS, VHOST_USER_ADD_MEM_REG and > > VHOST_USER_REM_MEM_REG. VHOST_USER_GET_MAX_MEM_SLOTS gets the > > number of memory slots the backend is willing to accept. Then, > > when the memory tables are set or updated, a series of > > VHOST_USER_ADD_MEM_REG and VHOST_USER_REM_MEM_REG messages are sent > > to transmit the regions to map and/or unmap instead of trying to > > send all the regions in one fixed size VHOST_USER_SET_MEM_TABLE message. > > > > The vhost_user struct maintains a shadow state of the VM’s memory > > regions. When the memory tables are modified, the > > vhost_user_set_mem_table() function compares the new device memory state > > to the shadow state and only sends regions which need to be unmapped or > > mapped in. The regions which must be unmapped are sent first, followed > > by the new regions to be mapped in. After all the messages have been sent, > > the shadow state is set to the current virtual device state. > > > > The current feature implementation does not work with postcopy migration > > and cannot be enabled if the VHOST_USER_PROTOCOL_F_REPLY_ACK feature has > > also been negotiated. > > > > Signed-off-by: Raphael Norwitz > > --- > > docs/interop/vhost-user.rst | 43 > > hw/virtio/vhost-user.c | 251 > > > > 2 files changed, 273 insertions(+), 21 deletions(-) > > > > diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst > > index 7827b71..855a072 100644 > > --- a/docs/interop/vhost-user.rst > > +++ b/docs/interop/vhost-user.rst > > @@ -785,6 +785,7 @@ Protocol features > >#define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10 > >#define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11 > >#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 > > + #define VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS 13 > > > > Master message types > > > > @@ -1190,6 +1191,48 @@ Master message types > >ancillary data. The GPU protocol is used to inform the master of > >rendering state and updates. See vhost-user-gpu.rst for details. > > > > +``VHOST_USER_GET_MAX_MEM_SLOTS`` > > + :id: 34 > > + :equivalent ioctl: N/A > > + :slave payload: u64 > > + > > + When the VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS protocol feature has been > > + successfully negotiated, this message is submitted by master to the > > + slave. The slave should return the message with a u64 payload > > + containing the maximum number of memory slots for QEMU to expose to > > + the guest. This message is not supported with postcopy migration or if > > + the VHOST_USER_PROTOCOL_F_REPLY_ACK feature has also been negotiated. > > + > > +``VHOST_USER_ADD_MEM_REG`` > > + :id: 35 > > + :equivalent ioctl: N/A > > + :slave payload: memory region > > + > > + When the VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS protocol feature has been > > + successfully negotiated, this message is submitted by master to the > > slave. > > + The message payload contains a memory region descriptor struct, > > describing > > + a region of guest memory which the slave device must map in. When the > > + VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS protocol feature has been > > successfully > > + negotiated, along with the VHOST_USER_REM_MEM_REG message, this message > > is > > + used to set and update the memory tables of the slave device. This > > message > > + is not supported with postcopy migration or if the > > + VHOST_USER_PROTOCOL_F_REPLY_ACK feature has also been negotiated. > > + > > +``VHOST_USER_REM_MEM_REG`` > > + :id: 36 > > + :equivalent ioctl: N/A > > + :slave payload: memory region > > + > > + When the VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS protocol feature has been > > + successfully negotiated, this message is submitted by master to the > > slave. > > + The message payload contains a memory region descriptor struct, > > describing > > + a region of guest memory which the slave device must unmap. When the > > + VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS protocol feature has been > > successfully > > + negotiated, along with the VHOST_USER_ADD_MEM_REG message, this message > > is > > + used to set and update the memory tables of the slave device. This > > message > > + is not supported with postcopy migration or if the > > + VHOST_USER_PROTOCOL_F_REPLY_ACK
Re: [RFC PATCH 1/3] Fixed Error Handling in vhost_user_set_mem_table_postcopy
Makes sense - will fix
On Tue, Jan 14, 2020 at 02:07:03AM -0500, Michael S. Tsirkin wrote:
>
> On Mon, Dec 09, 2019 at 02:00:45AM -0500, Raphael Norwitz wrote:
> > The current vhost_user_set_mem_table_postcopy() implementation
> > populates each region of the VHOST_USER_SET_MEM_TABLE
> > message without first checking if there are more than
> > VHOST_MEMORY_MAX_NREGIONS already populated. This can
> > cause memory corruption and potentially a crash if too many
> > regions are added to the message during the postcopy step.
> >
> > Additionally, after populating each region, the current
> > implementation asserts that the current region index is less than
> > VHOST_MEMORY_MAX_NREGIONS. Thus, even if the aforementioned
> > bug is fixed by moving the existing assert up, too many hot-adds
> > during the postcopy step will bring down qemu instead of
> > gracefully propogating up the error as in
> > vhost_user_set_mem_table().
> >
> > This change cleans up error handling in
> > vhost_user_set_mem_table_postcopy() such that it handles
> > an unsupported number of memory hot-adds like
> > vhost_user_set_mem_table(), gracefully propogating an error
> > up instead of corrupting memory and crashing qemu.
> >
> > Signed-off-by: Raphael Norwitz
>
> Unfortunately all the nice error handling is mostly
> futile since vhost_commit does:
>
> r = dev->vhost_ops->vhost_set_mem_table(dev, dev->mem);
> if (r < 0) {
> VHOST_OPS_DEBUG("vhost_set_mem_table failed");
> }
> goto out;
>
> so the reason there's an assert is that we really must never
> hit this path at all. So moving assert up seems cleaner.
>
> > ---
> > hw/virtio/vhost-user.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> > index 02a9b25..f74ff3b 100644
> > --- a/hw/virtio/vhost-user.c
> > +++ b/hw/virtio/vhost-user.c
> > @@ -441,6 +441,10 @@ static int vhost_user_set_mem_table_postcopy(struct
> > vhost_dev *dev,
> > );
> > fd = memory_region_get_fd(mr);
> > if (fd > 0) {
> > +if (fd_num == VHOST_MEMORY_MAX_NREGIONS) {
> > +error_report("Failed preparing vhost-user memory table
> > msg");
> > +return -1;
> > +}
> > trace_vhost_user_set_mem_table_withfd(fd_num, mr->name,
> >reg->memory_size,
> >reg->guest_phys_addr,
> > @@ -453,7 +457,6 @@ static int vhost_user_set_mem_table_postcopy(struct
> > vhost_dev *dev,
> > msg.payload.memory.regions[fd_num].guest_phys_addr =
> > reg->guest_phys_addr;
> > msg.payload.memory.regions[fd_num].mmap_offset = offset;
> > -assert(fd_num < VHOST_MEMORY_MAX_NREGIONS);
> > fds[fd_num++] = fd;
> > } else {
> > u->region_rb_offset[i] = 0;
> > --
> > 1.8.3.1
>
>
[PATCH 08/12] linux-user: Add support for setting alsa timer enhanced read using ioctl
On Wednesday, January 15, 2020, Laurent Vivier wrote: > Le 15/01/2020 à 20:17, Filip Bozuta a écrit : > > > > On 15.1.20. 17:37, Arnd Bergmann wrote: > >> On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier > wrote: > >>> Le 15/01/2020 à 17:18, Arnd Bergmann a écrit : > On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta > wrote: > > This patch implements functionality of following ioctl: > > > > SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read > > > > Sets enhanced time read which is used for reading time with > > timestamps > > and events. The third ioctl's argument is a pointer to an > > 'int'. Enhanced > > reading is set if the third argument is different than 0, > > otherwise normal > > time reading is set. > > > > Implementation notes: > > > > Because the implemented ioctl has 'int' as its third argument, > > the > > implementation was straightforward. > > > > Signed-off-by: Filip Bozuta > I think this one is wrong when you go between 32-bit and 64-bit > >>> kernel uses an "int" and "int" is always 32bit. > >>> The problem is most likely with timespec I think. > >>> > targets, and it gets worse with the kernel patches that just got > merged for linux-5.5, which extends the behavior to deal with > 64-bit time_t on 32-bit architectures. > > Please have a look at > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n > ext.git/log/?h=80fe7430c70859 > > >>> Yes, we already had the same kind of problem with SIOCGSTAMP and > >>> SIOCGSTAMPNS. > >>> > >>> Do the kernel patches add new ioctl numbers to differentiate 32bit and > >>> 64bit time_t? > >> Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument > >> is a pure 'int' that decides what format you get when you 'read' from > the > >> same file descriptor. > >> > >> For emulating 64-bit on 32-bit kernels, you have to use the new > >> SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on > >> 64-bit kernels, you probably have to return -ENOTTY to > >> SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to > >> emulate the read() behavior. > >> When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64, > >> you can translate that into the 64-bit > >> SNDRV_TIMER_IOCTL_TREAD_OLD. > >> > >> Arnd > > > > > > Thank you for bringing this up to my attention. Unfortunately i have > > some duties of academic nature in next month so i won't have much time > > fix this bug. I will try to fix this as soon as possible. > > Could you at least to try to have a mergeable series before you have to > stop to work on this? > > You can only manage the case before the change reported by Arnd (I will > manage the new case myself later). > > Hi, all. Sorry for interjecting myself into this discussion, but I just want to let you know about some related practicalities. Filip is a student that is from time to time (usually between two exam seasons) an intern in our company, working 4 hours each work day. He spent his internship in different teams in prevous years, and, from around mid-October 2019, was appointed to QEMU team. After some introductory tasks, he was assigned his main task: linux-user support for RTCs and ALSA timers. This series is the result of his work, and, to my great pleasure, is virtually entirely his independant work. I am positive he can complete the series by himself, even in the light of additional complexities mentioned in this thread. However, his exam season just started (Jan. 15th), and lasts till Feb. 15th. Our policy, in general, is not to burden the students during exam seasons, and that is why we can't expect prompt updates from him for the time being. In view of this, Laurent, please take Filip's status into consideration. As far as mergeability is concerned, my impression is that patches 1-6 and 13 are ready for merging, while patches 7-12 would require some additional (netlink-support-like) work, that would unfortunately be possible only after Feb. 15th. Best wishes, Aleksandar Thanks, > Laurent > > >
Re: [PATCH v7 03/11] hw/core: create Resettable QOM interface
On 1/16/20 2:59 AM, Philippe Mathieu-Daudé wrote: On 1/15/20 1:36 PM, Damien Hedde wrote: This commit defines an interface allowing multi-phase reset. This aims to solve a problem of the actual single-phase reset (built in DeviceClass and BusClass): reset behavior is dependent on the order in which reset handlers are called. In particular doing external side-effect (like setting an qemu_irq) is problematic because receiving object may not be reset yet. The Resettable interface divides the reset in 3 well defined phases. To reset an object tree, all 1st phases are executed then all 2nd then all 3rd. See the comments in include/hw/resettable.h for a more complete description. The interface defines 3 phases to let the future possibility of holding an object into reset for some time. The qdev/qbus reset in DeviceClass and BusClass will be modified in following commits to use this interface. A mechanism is provided to allow executing a transitional reset handler in place of the 2nd phase which is executed in children-then-parent order inside a tree. This will allow to transition devices and buses smoothly while keeping the exact current qdev/qbus reset behavior for now. Documentation will be added in a following commit. Signed-off-by: Damien Hedde Reviewed-by: Richard Henderson --- v7 update: un-nest struct ResettablePhases --- Makefile.objs | 1 + include/hw/resettable.h | 211 +++ hw/core/resettable.c | 238 hw/core/Makefile.objs | 1 + hw/core/trace-events | 17 +++ 5 files changed, 468 insertions(+) create mode 100644 include/hw/resettable.h create mode 100644 hw/core/resettable.c diff --git a/Makefile.objs b/Makefile.objs index 7c1e50f9d6..9752d549b4 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -191,6 +191,7 @@ trace-events-subdirs += migration trace-events-subdirs += net trace-events-subdirs += ui endif +trace-events-subdirs += hw/core TL;DR Duplicating this line breaks using the LTTng Userspace Tracer library (UST backend). Probably because you started this series before commit 26b8e6dc42b got merged, Jun 13 2019! Indeed Oct 02 2018... https://www.mail-archive.com/qemu-devel@nongnu.org/msg564153.html The problem is you (correctly) sorted alphabetically while Alexey appended at the end. trace-events-subdirs += hw/display trace-events-subdirs += qapi trace-events-subdirs += qom [...] diff --git a/hw/core/trace-events b/hw/core/trace-events index a375aa88a4..a2e43f1120 100644 --- a/hw/core/trace-events +++ b/hw/core/trace-events @@ -9,3 +9,20 @@ qbus_reset(void *obj, const char *objtype) "obj=%p(%s)" qbus_reset_all(void *obj, const char *objtype) "obj=%p(%s)" qbus_reset_tree(void *obj, const char *objtype) "obj=%p(%s)" qdev_update_parent_bus(void *obj, const char *objtype, void *oldp, const char *oldptype, void *newp, const char *newptype) "obj=%p(%s) old_parent=%p(%s) new_parent=%p(%s)" + +# resettable.c +resettable_reset(void *obj, int cold) "obj=%p cold=%d" +resettable_reset_assert_begin(void *obj, int cold) "obj=%p cold=%d" +resettable_reset_assert_end(void *obj) "obj=%p" +resettable_reset_release_begin(void *obj, int cold) "obj=%p cold=%d" +resettable_reset_release_end(void *obj) "obj=%p" +resettable_phase_enter_begin(void *obj, const char *objtype, uint32_t count, int type) "obj=%p(%s) count=%" PRIu32 " type=%d" +resettable_phase_enter_exec(void *obj, const char *objtype, int type, int has_method) "obj=%p(%s) type=%d method=%d" +resettable_phase_enter_end(void *obj, const char *objtype, uint32_t count) "obj=%p(%s) count=%" PRIu32 +resettable_phase_hold_begin(void *obj, const char *objtype, uint32_t count, int type) "obj=%p(%s) count=%" PRIu32 " type=%d" +resettable_phase_hold_exec(void *obj, const char *objtype, int has_method) "obj=%p(%s) method=%d" +resettable_phase_hold_end(void *obj, const char *objtype, uint32_t count) "obj=%p(%s) count=%" PRIu32 +resettable_phase_exit_begin(void *obj, const char *objtype, uint32_t count, int type) "obj=%p(%s) count=%" PRIu32 " type=%d" +resettable_phase_exit_exec(void *obj, const char *objtype, int has_method) "obj=%p(%s) method=%d" +resettable_phase_exit_end(void *obj, const char *objtype, uint32_t count) "obj=%p(%s) count=%" PRIu32 +resettable_transitional_function(void *obj, const char *objtype) "obj=%p(%s)" Something here breaks ./configure --enable-trace-backends=ust: CC trace-ust-all.o In file included from trace-ust-all.h:13, from trace-ust-all.c:13: trace-ust-all.h:35151:1: error: redefinition of ‘__tracepoint_cb_qemu___loader_write_rom’ 35151 | TRACEPOINT_EVENT( | ^~~~ trace-ust-all.h:31791:1: note: previous definition of ‘__tracepoint_cb_qemu___loader_write_rom’ was here 31791 | TRACEPOINT_EVENT( | ^~~~ ... ./trace-ust-all.h:35388:1: error: redefinition of
Re: Semihosting, arm, riscv, ppc and common code
On Thu, 2020-01-16 at 00:02 +0200, Liviu Ionescu wrote: > > ... they did have the opportunity to do better, and did not. > > I don't know why you present Arm semihosting as a disaster. It is not > perfect, but it is functional, and common unit tests use only a small > subset of the calls. > > And there is no 'window of opportunity', if the RISC-V guys will ever > want to reinvent the wheel and come with an official 'RISC-V > semihosting' specs, they can do it at any time, and this will have no > impact on existing devices, everything will continue to work as > before, only the debuggers/emulators will need to be upgraded. > > But the only immediate effect such a move will have is that software > efforts in test frameworks will be increased, to support another > protocol, while the advantages will be minimal. I agree, which is also why I want to use the same interface for powerpc, it will simply make life easier for everybody. The calls aren't perfect but they do work sufficiently well to be useful and I haven't yet been convinced that it can't be extended if necessary. Cheers, Ben.
Re: [PATCH v2 63/86] ppc:pnv: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:18PM +0100, Igor Mammedov wrote: > memory_region_allocate_system_memory() API is going away, so > replace it with memdev allocated MemoryRegion. The later is > initialized by generic code, so board only needs to opt in > to memdev scheme by providing > MachineClass::default_ram_id > and using MachineState::ram instead of manually initializing > RAM memory region. > > Signed-off-by: Igor Mammedov Acked-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v7 02/11] hw/core/qdev: add trace events to help with resettable transition
On 1/15/20 1:36 PM, Damien Hedde wrote:
Adds trace events to reset procedure and when updating the parent
bus of a device.
Signed-off-by: Damien Hedde
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Cornelia Huck
Tested-by: Philippe Mathieu-Daudé
---
hw/core/qdev.c | 29 ++---
hw/core/trace-events | 9 +
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 8c0c8284c8..5cb03136b5 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -38,6 +38,7 @@
#include "hw/boards.h"
#include "hw/sysbus.h"
#include "migration/vmstate.h"
+#include "trace.h"
bool qdev_hotplug = false;
static bool qdev_hot_added = false;
@@ -98,7 +99,11 @@ void qdev_set_parent_bus(DeviceState *dev, BusState *bus)
bool replugging = dev->parent_bus != NULL;
if (replugging) {
-/* Keep a reference to the device while it's not plugged into
+trace_qdev_update_parent_bus(dev, object_get_typename(OBJECT(dev)),
+dev->parent_bus, object_get_typename(OBJECT(dev->parent_bus)),
+OBJECT(bus), object_get_typename(OBJECT(bus)));
+/*
+ * Keep a reference to the device while it's not plugged into
* any bus, to avoid it potentially evaporating when it is
* dereffed in bus_remove_child().
*/
@@ -296,6 +301,18 @@ HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
return hotplug_ctrl;
}
+static int qdev_prereset(DeviceState *dev, void *opaque)
+{
+trace_qdev_reset_tree(dev, object_get_typename(OBJECT(dev)));
+return 0;
+}
+
+static int qbus_prereset(BusState *bus, void *opaque)
+{
+trace_qbus_reset_tree(bus, object_get_typename(OBJECT(bus)));
+return 0;
+}
+
static int qdev_reset_one(DeviceState *dev, void *opaque)
{
device_legacy_reset(dev);
@@ -306,6 +323,7 @@ static int qdev_reset_one(DeviceState *dev, void *opaque)
static int qbus_reset_one(BusState *bus, void *opaque)
{
BusClass *bc = BUS_GET_CLASS(bus);
+trace_qbus_reset(bus, object_get_typename(OBJECT(bus)));
if (bc->reset) {
bc->reset(bus);
}
@@ -314,7 +332,9 @@ static int qbus_reset_one(BusState *bus, void *opaque)
void qdev_reset_all(DeviceState *dev)
{
-qdev_walk_children(dev, NULL, NULL, qdev_reset_one, qbus_reset_one, NULL);
+trace_qdev_reset_all(dev, object_get_typename(OBJECT(dev)));
+qdev_walk_children(dev, qdev_prereset, qbus_prereset,
+ qdev_reset_one, qbus_reset_one, NULL);
}
void qdev_reset_all_fn(void *opaque)
@@ -324,7 +344,9 @@ void qdev_reset_all_fn(void *opaque)
void qbus_reset_all(BusState *bus)
{
-qbus_walk_children(bus, NULL, NULL, qdev_reset_one, qbus_reset_one, NULL);
+trace_qbus_reset_all(bus, object_get_typename(OBJECT(bus)));
+qbus_walk_children(bus, qdev_prereset, qbus_prereset,
+ qdev_reset_one, qbus_reset_one, NULL);
}
void qbus_reset_all_fn(void *opaque)
@@ -1131,6 +1153,7 @@ void device_legacy_reset(DeviceState *dev)
{
DeviceClass *klass = DEVICE_GET_CLASS(dev);
+trace_qdev_reset(dev, object_get_typename(OBJECT(dev)));
if (klass->reset) {
klass->reset(dev);
}
diff --git a/hw/core/trace-events b/hw/core/trace-events
index fe47a9c8cb..a375aa88a4 100644
--- a/hw/core/trace-events
+++ b/hw/core/trace-events
@@ -1,2 +1,11 @@
# loader.c
loader_write_rom(const char *name, uint64_t gpa, uint64_t size, bool isrom) "%s:
@0x%"PRIx64" size=0x%"PRIx64" ROM=%d"
+
+# qdev.c
+qdev_reset(void *obj, const char *objtype) "obj=%p(%s)"
+qdev_reset_all(void *obj, const char *objtype) "obj=%p(%s)"
+qdev_reset_tree(void *obj, const char *objtype) "obj=%p(%s)"
+qbus_reset(void *obj, const char *objtype) "obj=%p(%s)"
+qbus_reset_all(void *obj, const char *objtype) "obj=%p(%s)"
+qbus_reset_tree(void *obj, const char *objtype) "obj=%p(%s)"
+qdev_update_parent_bus(void *obj, const char *objtype, void *oldp, const char *oldptype,
void *newp, const char *newptype) "obj=%p(%s) old_parent=%p(%s)
new_parent=%p(%s)"
Re: [PATCH v7 04/11] hw/core: add Resettable support to BusClass and DeviceClass
On 1/15/20 1:36 PM, Damien Hedde wrote:
This commit adds support of Resettable interface to buses and devices:
+ ResettableState structure is added in the Bus/Device state
+ Resettable methods are implemented.
+ device/bus_is_in_reset function defined
This commit allows to transition the objects to the new
multi-phase interface without changing the reset behavior at all.
Object single reset method can be split into the 3 different phases
but the 3 phases are still executed in a row for a given object.
From the qdev/qbus reset api point of view, nothing is changed.
qdev_reset_all() and qbus_reset_all() are not modified as well as
device_legacy_reset().
Transition of an object must be done from parent class to child class.
Care has been taken to allow the transition of a parent class
without requiring the child classes to be transitioned at the same
time. Note that SysBus and SysBusDevice class do not need any transition
because they do not override the legacy reset method.
Signed-off-by: Damien Hedde
Reviewed-by: Richard Henderson
Reviewed-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
include/hw/qdev-core.h | 27
hw/core/bus.c | 97 ++
hw/core/qdev.c | 93
tests/Makefile.include | 1 +
4 files changed, 218 insertions(+)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index b8341b0fb0..1b4b420617 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -5,6 +5,7 @@
#include "qemu/bitmap.h"
#include "qom/object.h"
#include "hw/hotplug.h"
+#include "hw/resettable.h"
enum {
DEV_NVECTORS_UNSPECIFIED = -1,
@@ -117,6 +118,11 @@ typedef struct DeviceClass {
bool hotpluggable;
/* callbacks */
+/*
+ * Reset method here is deprecated and replaced by methods in the
+ * resettable class interface to implement a multi-phase reset.
+ * TODO: remove once every reset callback is unused
+ */
DeviceReset reset;
DeviceRealize realize;
DeviceUnrealize unrealize;
@@ -141,6 +147,7 @@ struct NamedGPIOList {
/**
* DeviceState:
* @realized: Indicates whether the device has been fully constructed.
+ * @reset: ResettableState for the device; handled by Resettable interface.
*
* This structure should not be accessed directly. We declare it here
* so that it can be embedded in individual device state structures.
@@ -163,6 +170,7 @@ struct DeviceState {
int num_child_bus;
int instance_id_alias;
int alias_required_for_version;
+ResettableState reset;
};
struct DeviceListener {
@@ -215,6 +223,7 @@ typedef struct BusChild {
/**
* BusState:
* @hotplug_handler: link to a hotplug handler associated with bus.
+ * @reset: ResettableState for the bus; handled by Resettable interface.
*/
struct BusState {
Object obj;
@@ -226,6 +235,7 @@ struct BusState {
int num_children;
QTAILQ_HEAD(, BusChild) children;
QLIST_ENTRY(BusState) sibling;
+ResettableState reset;
};
/**
@@ -412,6 +422,18 @@ void qdev_reset_all_fn(void *opaque);
void qbus_reset_all(BusState *bus);
void qbus_reset_all_fn(void *opaque);
+/**
+ * device_is_in_reset:
+ * Return true if the device @dev is currently being reset.
+ */
+bool device_is_in_reset(DeviceState *dev);
+
+/**
+ * bus_is_in_reset:
+ * Return true if the bus @bus is currently being reset.
+ */
+bool bus_is_in_reset(BusState *bus);
+
/* This should go away once we get rid of the NULL bus hack */
BusState *sysbus_get_default(void);
@@ -433,6 +455,11 @@ void qdev_machine_init(void);
*/
void device_legacy_reset(DeviceState *dev);
+/**
+ * device_class_set_parent_reset:
+ * TODO: remove the function when DeviceClass's reset method
+ * is not used anymore.
+ */
void device_class_set_parent_reset(DeviceClass *dc,
DeviceReset dev_reset,
DeviceReset *parent_reset);
diff --git a/hw/core/bus.c b/hw/core/bus.c
index 7f3d2a3dbd..2698f715bd 100644
--- a/hw/core/bus.c
+++ b/hw/core/bus.c
@@ -68,6 +68,28 @@ int qbus_walk_children(BusState *bus,
return 0;
}
+bool bus_is_in_reset(BusState *bus)
+{
+return resettable_is_in_reset(OBJECT(bus));
+}
+
+static ResettableState *bus_get_reset_state(Object *obj)
+{
+BusState *bus = BUS(obj);
+return >reset;
+}
+
+static void bus_reset_child_foreach(Object *obj, ResettableChildCallback cb,
+void *opaque, ResetType type)
+{
+BusState *bus = BUS(obj);
+BusChild *kid;
+
+QTAILQ_FOREACH(kid, >children, sibling) {
+cb(OBJECT(kid->child), opaque, type);
+}
+}
+
static void qbus_realize(BusState *bus, DeviceState *parent, const char *name)
{
const char *typename = object_get_typename(OBJECT(bus));
@@ -199,12 +221,83 @@ static char
Re: [PATCH v7 06/11] hw/core/qdev: handle parent bus change regarding resettable
On 1/15/20 1:36 PM, Damien Hedde wrote:
In qdev_set_parent_bus(), when changing the parent bus of a
realized device, if the source and destination buses are not in the
same reset state, some adaptations are required. This patch adds
needed call to resettable_change_parent() to make sure a device reset
state stays coherent with its parent bus.
The addition is a no-op if:
1. the device being parented is not realized.
2. the device is realized, but both buses are not under reset.
Case 2 means that as long as qdev_set_parent_bus() is called
during the machine realization procedure (which is before the
machine reset so nothing is in reset), it is a no op.
There are 52 call sites of qdev_set_parent_bus(). All but one fall
into the no-op case:
+ 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/
{vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device
parent bus just before realizing the same vdev(vgpu).
+ hw/core/qdev.c: when creating a device in qdev_try_create()
+ hw/core/sysbus.c: when initializing a device in the sysbus
+ hw/i386/amd_iommu.c: before realizing AMDVIState/pci
+ hw/isa/piix4.c: before realizing PIIX4State/rtc
+ hw/misc/auxbus.c: when creating an AUXBus
+ hw/misc/auxbus.c: when creating an AUXBus child
+ hw/misc/macio/macio.c: when initializing a MACIOState child
+ hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu
+ hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda
+ hw/net/virtio-net.c: Used for migration when using the failover
mechanism to migration a vfio-pci/net. It is
a no-op because at this point the device is
already on the bus.
+ hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root
+ hw/pci-host/gpex.c: before realizing GPEXHost/root
+ hw/pci-host/prep.c: when initializaing PREPPCIState/pci_dev
typo "initializing"
+ hw/pci-host/q35.c: before realizing Q35PCIHost/mch
+ hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev
+ hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root
+ hw/s390x/event-facility.c: when creating SCLPEventFacility/
TYPE_SCLP_QUIESCE
+ hw/s390x/event-facility.c: ditto with SCLPEventFacility/
TYPE_SCLP_CPU_HOTPLUG
+ hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice
just after realizing it. Ok because at this point the destination
bus (sysbus) is not in reset; the realize step is before the
machine reset.
+ hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below.
+ hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs
line in ssi_auto_connect_slave(). Ok because this function is only
used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c,
hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c.
+ hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device
+ qdev-monitor.c: in device hotplug creation procedure before realize
Note that this commit alone will have no effect, right now there is no
use of resettable API to reset anything. So a bus will never be tagged
as in-reset by this same API.
The one place where side-effect will occurs is in hw/sd/core.c in
sdbus_reparent_card(). This function is only used in the raspi machines,
including during the sysbus reset procedure. This case will be
carrefully handled when doing the multiple phase reset transition.
Signed-off-by: Damien Hedde
Reviewed-by: Peter Maydell
Reviewed-by: Richard Henderson
Tested-by: Philippe Mathieu-Daudé
---
v6 update: there are now 3 more call sites (52 instead of 49).
+ hw/isa/piix4.c
+ hw/net/virtio-net.c
+ hw/virtio/vhost-user-fs-pci.c (in list below)
Exhaustive list of the 29 "virtio" caller to qdev_set_parent_bus():
+ hw/display/virtio-gpu-pci.c: VirtIOGPUPCIBase/vgpu realize
+ hw/display/virtio-vga.c: VirtIOVGABase/vgpu realize
+ hw/s390x/vhost-vsock-ccw.c: VHostVSockCCWState/vdev realize
+ hw/s390x/virtio-ccw-9p.c:V9fsCCWState/vdev realize
+ hw/s390x/virtio-ccw-balloon.c: VirtIOBalloonCcw/vdev realize
+ hw/s390x/virtio-ccw-blk.c: VirtIOBlkCcw/vdev realize
+ hw/s390x/virtio-ccw-crypto.c:VirtIOCryptoCcw/vdev realize
+ hw/s390x/virtio-ccw-gpu.c: VirtIOGPUCcw/vdev realize
+ hw/s390x/virtio-ccw-input.c: VirtIOInputCcw/vdev realize
+ hw/s390x/virtio-ccw-net.c: VirtIONetCcw/vdev realize
+ hw/s390x/virtio-ccw-rng.c: VirtIORNGCcw/vdev realize
+ hw/s390x/virtio-ccw-scsi.c: VirtIOSCSICcw/vdev realize
+ hw/s390x/virtio-ccw-scsi.c: VHostSCSICcw/vdev realize
+ hw/s390x/virtio-ccw-serial.c:VirtioSerialCcw/vdev realize
+ hw/virtio/vhost-scsi-pci.c: VHostSCSIPCI/vdev realize
+ hw/virtio/vhost-user-blk-pci.c: VHostUserBlkPCI/vdev realize
+ hw/virtio/vhost-user-fs-pci.c: VHostUserFSPCI/vdev realize
+ hw/virtio/vhost-user-scsi-pci.c: VHostUserSCSIPCI/vdev realize
+ hw/virtio/vhost-vsock-pci.c: VHostVSockPCI/vdev
Re: [PATCH v2 62/86] ppc:mac_oldworld: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:17PM +0100, Igor Mammedov wrote: > memory_region_allocate_system_memory() API is going away, so > replace it with memdev allocated MemoryRegion. The later is > initialized by generic code, so board only needs to opt in > to memdev scheme by providing > MachineClass::default_ram_id > and using MachineState::ram instead of manually initializing > RAM memory region. > > Signed-off-by: Igor Mammedov Acked-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: Semihosting, arm, riscv, ppc and common code
On Wed, 2020-01-15 at 13:32 +, Peter Maydell wrote: > On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt > wrote: > > On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote: > > > Note that semihosting is not a "here's a handy QEMU feature" > > > thing. It's an architecture-specific API and ABI, which should > > > be defined somewhere in a standard external to QEMU. > > > > There is no such standard for powerpc today that I know of. > > So you need to write one down somewhere. You're proposing > an ABI which will be implemented by multiple implementors > and used by multiple consumers. That needs a spec, not > just code. I don't want to see more semihosting implementations > added to QEMU that don't have a specification written > down somewhere. That's ok, I can probably get openpower to put a link to the ARM one somewhere :-) > The point about the mistakes is that you can't easily fix > them by adding extensions, because the core of the biggest > mistake is "we didn't provide a good way to allow extensions to > be added and probed for by the user". So we had to implement > an ugly and hard to implement mechanism instead. > New > architectures could mandate providing the good way from the start > and avoid the painful-to-implement approach entirely. > (I think RISCV has already missed this window of opportunity, > which is a shame.) It is done and so now we have two architectures using that standard, I think the value in using the same overweight the value in fixing it but yes, we should try to agree on a method of extending at least. Is it really that hard ? IE. We could add a new call for capabilities that takes a pointer to a region which we pre-zero before calling in the client and if remains zero after the call, then the new stuff isn't there for example. That sort of stuff is easy, or am I missing something ? Cheers, Ben.
Re: [PATCH v2 61/86] ppc:mac_newworld: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:16PM +0100, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
> ---
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> CC: mark.cave-ayl...@ilande.co.uk
> ---
> hw/ppc/mac_newworld.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 3594517..2546d33 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -118,7 +118,7 @@ static void ppc_core99_init(MachineState *machine)
> char *filename;
> IrqLines *openpic_irqs;
> int linux_boot, i, j, k;
> -MemoryRegion *ram = g_new(MemoryRegion, 1), *bios = g_new(MemoryRegion,
> 1);
> +MemoryRegion *bios = g_new(MemoryRegion, 1);
> hwaddr kernel_base, initrd_base, cmdline_base = 0;
> long kernel_size, initrd_size;
> UNINHostState *uninorth_pci;
> @@ -152,8 +152,7 @@ static void ppc_core99_init(MachineState *machine)
> }
>
> /* allocate RAM */
> -memory_region_allocate_system_memory(ram, NULL, "ppc_core99.ram",
> ram_size);
> -memory_region_add_subregion(get_system_memory(), 0, ram);
> +memory_region_add_subregion(get_system_memory(), 0, machine->ram);
>
> /* allocate and load BIOS */
> memory_region_init_ram(bios, NULL, "ppc_core99.bios", BIOS_SIZE,
> @@ -586,6 +585,7 @@ static void core99_machine_class_init(ObjectClass *oc,
> void *data)
> #else
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
> #endif
> +mc->default_ram_id = "ppc_core99.ram";
> mc->ignore_boot_device_suffixes = true;
> fwc->get_dev_path = core99_fw_dev_path;
> }
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v2 60/86] ppc:e500: use memdev for RAM
On Wed, Jan 15, 2020 at 04:07:15PM +0100, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
> ---
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> ---
> hw/ppc/e500.c | 5 +
> hw/ppc/e500plat.c | 1 +
> hw/ppc/mpc8544ds.c | 1 +
> 3 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> index 6d119fe..256ab5a 100644
> --- a/hw/ppc/e500.c
> +++ b/hw/ppc/e500.c
> @@ -831,7 +831,6 @@ static void ppce500_power_off(void *opaque, int line, int
> on)
> void ppce500_init(MachineState *machine)
> {
> MemoryRegion *address_space_mem = get_system_memory();
> -MemoryRegion *ram = g_new(MemoryRegion, 1);
> PPCE500MachineState *pms = PPCE500_MACHINE(machine);
> const PPCE500MachineClass *pmc = PPCE500_MACHINE_GET_CLASS(machine);
> PCIBus *pci_bus;
> @@ -912,9 +911,7 @@ void ppce500_init(MachineState *machine)
> }
>
> /* Register Memory */
> -memory_region_allocate_system_memory(ram, NULL, "mpc8544ds.ram",
> - machine->ram_size);
> -memory_region_add_subregion(address_space_mem, 0, ram);
> +memory_region_add_subregion(address_space_mem, 0, machine->ram);
>
> dev = qdev_create(NULL, "e500-ccsr");
> object_property_add_child(qdev_get_machine(), "e500-ccsr",
> diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
> index 7078386..bddd5e7 100644
> --- a/hw/ppc/e500plat.c
> +++ b/hw/ppc/e500plat.c
> @@ -97,6 +97,7 @@ static void e500plat_machine_class_init(ObjectClass *oc,
> void *data)
> mc->init = e500plat_init;
> mc->max_cpus = 32;
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("e500v2_v30");
> +mc->default_ram_id = "mpc8544ds.ram";
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ETSEC_COMMON);
> }
>
> diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
> index c2c5e11..8117750 100644
> --- a/hw/ppc/mpc8544ds.c
> +++ b/hw/ppc/mpc8544ds.c
> @@ -55,6 +55,7 @@ static void e500plat_machine_class_init(ObjectClass *oc,
> void *data)
> mc->init = mpc8544ds_init;
> mc->max_cpus = 15;
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("e500v2_v30");
> +mc->default_ram_id = "mpc8544ds.ram";
> }
>
> #define TYPE_MPC8544DS_MACHINE MACHINE_TYPE_NAME("mpc8544ds")
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v7 03/11] hw/core: create Resettable QOM interface
On 1/15/20 1:36 PM, Damien Hedde wrote:
This commit defines an interface allowing multi-phase reset. This aims
to solve a problem of the actual single-phase reset (built in
DeviceClass and BusClass): reset behavior is dependent on the order
in which reset handlers are called. In particular doing external
side-effect (like setting an qemu_irq) is problematic because receiving
object may not be reset yet.
The Resettable interface divides the reset in 3 well defined phases.
To reset an object tree, all 1st phases are executed then all 2nd then
all 3rd. See the comments in include/hw/resettable.h for a more complete
description. The interface defines 3 phases to let the future
possibility of holding an object into reset for some time.
The qdev/qbus reset in DeviceClass and BusClass will be modified in
following commits to use this interface. A mechanism is provided
to allow executing a transitional reset handler in place of the 2nd
phase which is executed in children-then-parent order inside a tree.
This will allow to transition devices and buses smoothly while
keeping the exact current qdev/qbus reset behavior for now.
Documentation will be added in a following commit.
Signed-off-by: Damien Hedde
Reviewed-by: Richard Henderson
---
v7 update: un-nest struct ResettablePhases
---
Makefile.objs | 1 +
include/hw/resettable.h | 211 +++
hw/core/resettable.c| 238
hw/core/Makefile.objs | 1 +
hw/core/trace-events| 17 +++
5 files changed, 468 insertions(+)
create mode 100644 include/hw/resettable.h
create mode 100644 hw/core/resettable.c
diff --git a/Makefile.objs b/Makefile.objs
index 7c1e50f9d6..9752d549b4 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -191,6 +191,7 @@ trace-events-subdirs += migration
trace-events-subdirs += net
trace-events-subdirs += ui
endif
+trace-events-subdirs += hw/core
TL;DR Duplicating this line breaks using the LTTng Userspace Tracer
library (UST backend).
Probably because you started this series before commit 26b8e6dc42b got
merged, Jun 13 2019!
Indeed Oct 02 2018...
https://www.mail-archive.com/qemu-devel@nongnu.org/msg564153.html
The problem is you (correctly) sorted alphabetically while Alexey
appended at the end.
trace-events-subdirs += hw/display
trace-events-subdirs += qapi
trace-events-subdirs += qom
diff --git a/include/hw/resettable.h b/include/hw/resettable.h
new file mode 100644
index 00..58b3df4c22
--- /dev/null
+++ b/include/hw/resettable.h
@@ -0,0 +1,211 @@
+/*
+ * Resettable interface header.
+ *
+ * Copyright (c) 2019 GreenSocs SAS
+ *
+ * Authors:
+ * Damien Hedde
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef HW_RESETTABLE_H
+#define HW_RESETTABLE_H
+
+#include "qom/object.h"
+
+#define TYPE_RESETTABLE_INTERFACE "resettable"
+
+#define RESETTABLE_CLASS(class) \
+OBJECT_CLASS_CHECK(ResettableClass, (class), TYPE_RESETTABLE_INTERFACE)
+
+#define RESETTABLE_GET_CLASS(obj) \
+OBJECT_GET_CLASS(ResettableClass, (obj), TYPE_RESETTABLE_INTERFACE)
+
+typedef struct ResettableState ResettableState;
+
+/**
+ * ResetType:
+ * Types of reset.
+ *
+ * + Cold: reset resulting from a power cycle of the object.
+ *
+ * TODO: Support has to be added to handle more types. In particular,
+ * ResettableState structure needs to be expanded.
+ */
+typedef enum ResetType {
+RESET_TYPE_COLD,
+} ResetType;
+
+/*
+ * ResettableClass:
+ * Interface for resettable objects.
+ *
+ * See docs/devel/reset.rst for more detailed information about how QEMU models
+ * reset. This whole API must only be used when holding the iothread mutex.
+ *
+ * All objects which can be reset must implement this interface;
+ * it is usually provided by a base class such as DeviceClass or BusClass.
+ * Every Resettable object must maintain some state tracking the
+ * progress of a reset operation by providing a ResettableState structure.
+ * The functions defined in this module take care of updating the
+ * state of the reset.
+ * The base class implementation of the interface provides this
+ * state and implements the associated method: get_state.
+ *
+ * Concrete object implementations (typically specific devices
+ * such as a UART model) should provide the functions
+ * for the phases.enter, phases.hold and phases.exit methods, which
+ * they can set in their class init function, either directly or
+ * by calling resettable_class_set_parent_phases().
+ * The phase methods are guaranteed to only only ever be called once
+ * for any reset event, in the order 'enter', 'hold', 'exit'.
+ * An object will always move quickly from 'enter' to 'hold'
+ * but might remain in 'hold' for an arbitrary period of time
+ * before eventually reset is deasserted and the 'exit' phase is called.
+ * Object implementations should be prepared for functions handling
+ *
Re: [PATCH v2 07/86] arm:aspeed: convert valid RAM sizes to data
On Wed, 15 Jan 2020 at 15:10, Igor Mammedov wrote:
>
> various foo_rambits() hardcode mapping of RAM sizes to RAM feature bits,
> which is hard to reuse and repeats over and over.
>
> Convert maps into GLib's hash tables and perform mapping using
> common mapping function.
Thanks for the patch.
I find the existing code straight forward to understand, and for this
reason I would prefer to leave it as it is. Would you mind dropping
this patch from your series?
>
> Follow up patch will reuse tables for actually checking ram-size
> property.
>
> Signed-off-by: Igor Mammedov
> ---
> CC: c...@kaod.org
> CC: peter.mayd...@linaro.org
> CC: and...@aj.id.au
> CC: j...@jms.id.au
> CC: qemu-...@nongnu.org
> ---
> include/hw/misc/aspeed_sdmc.h | 2 +
> hw/misc/aspeed_sdmc.c | 116
> --
> 2 files changed, 47 insertions(+), 71 deletions(-)
>
> diff --git a/include/hw/misc/aspeed_sdmc.h b/include/hw/misc/aspeed_sdmc.h
> index 5dbde59..de1501f 100644
> --- a/include/hw/misc/aspeed_sdmc.h
> +++ b/include/hw/misc/aspeed_sdmc.h
> @@ -39,6 +39,8 @@ typedef struct AspeedSDMCState {
> typedef struct AspeedSDMCClass {
> SysBusDeviceClass parent_class;
>
> +GHashTable *ram2feat;
> +int fallback_ram_size;
> uint64_t max_ram_size;
> uint32_t (*compute_conf)(AspeedSDMCState *s, uint32_t data);
> void (*write)(AspeedSDMCState *s, uint32_t reg, uint32_t data);
> diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c
> index 2df3244..3fc80f0 100644
> --- a/hw/misc/aspeed_sdmc.c
> +++ b/hw/misc/aspeed_sdmc.c
> @@ -148,72 +148,6 @@ static const MemoryRegionOps aspeed_sdmc_ops = {
> .valid.max_access_size = 4,
> };
>
> -static int ast2400_rambits(AspeedSDMCState *s)
> -{
> -switch (s->ram_size >> 20) {
> -case 64:
> -return ASPEED_SDMC_DRAM_64MB;
> -case 128:
> -return ASPEED_SDMC_DRAM_128MB;
> -case 256:
> -return ASPEED_SDMC_DRAM_256MB;
> -case 512:
> -return ASPEED_SDMC_DRAM_512MB;
> -default:
> -break;
> -}
> -
> -/* use a common default */
> -warn_report("Invalid RAM size 0x%" PRIx64 ". Using default 256M",
> -s->ram_size);
> -s->ram_size = 256 << 20;
> -return ASPEED_SDMC_DRAM_256MB;
> -}
> -
> -static int ast2500_rambits(AspeedSDMCState *s)
> -{
> -switch (s->ram_size >> 20) {
> -case 128:
> -return ASPEED_SDMC_AST2500_128MB;
> -case 256:
> -return ASPEED_SDMC_AST2500_256MB;
> -case 512:
> -return ASPEED_SDMC_AST2500_512MB;
> -case 1024:
> -return ASPEED_SDMC_AST2500_1024MB;
> -default:
> -break;
> -}
> -
> -/* use a common default */
> -warn_report("Invalid RAM size 0x%" PRIx64 ". Using default 512M",
> -s->ram_size);
> -s->ram_size = 512 << 20;
> -return ASPEED_SDMC_AST2500_512MB;
> -}
> -
> -static int ast2600_rambits(AspeedSDMCState *s)
> -{
> -switch (s->ram_size >> 20) {
> -case 256:
> -return ASPEED_SDMC_AST2600_256MB;
> -case 512:
> -return ASPEED_SDMC_AST2600_512MB;
> -case 1024:
> -return ASPEED_SDMC_AST2600_1024MB;
> -case 2048:
> -return ASPEED_SDMC_AST2600_2048MB;
> -default:
> -break;
> -}
> -
> -/* use a common default */
> -warn_report("Invalid RAM size 0x%" PRIx64 ". Using default 1024M",
> -s->ram_size);
> -s->ram_size = 1024 << 20;
> -return ASPEED_SDMC_AST2600_1024MB;
> -}
> -
> static void aspeed_sdmc_reset(DeviceState *dev)
> {
> AspeedSDMCState *s = ASPEED_SDMC(dev);
> @@ -257,11 +191,14 @@ static Property aspeed_sdmc_properties[] = {
> static void aspeed_sdmc_class_init(ObjectClass *klass, void *data)
> {
> DeviceClass *dc = DEVICE_CLASS(klass);
> +AspeedSDMCClass *asc = ASPEED_SDMC_CLASS(klass);
> +
> dc->realize = aspeed_sdmc_realize;
> dc->reset = aspeed_sdmc_reset;
> dc->desc = "ASPEED SDRAM Memory Controller";
> dc->vmsd = _aspeed_sdmc;
> dc->props = aspeed_sdmc_properties;
> +asc->ram2feat = g_hash_table_new(g_direct_hash, g_direct_equal);
> }
>
> static const TypeInfo aspeed_sdmc_info = {
> @@ -273,10 +210,28 @@ static const TypeInfo aspeed_sdmc_info = {
> .abstract = true,
> };
>
> +static int aspeed_get_ram_feat(AspeedSDMCState *s)
> +{
> +AspeedSDMCClass *asc = ASPEED_SDMC_GET_CLASS(s);
> +int ram_mb = s->ram_size >> 20;
> +gpointer val;
> +
> +if (g_hash_table_contains(asc->ram2feat, GINT_TO_POINTER(ram_mb))) {
> +val = g_hash_table_lookup(asc->ram2feat, GINT_TO_POINTER(ram_mb));
> +return GPOINTER_TO_INT(val);
> +}
> +
> +warn_report("Invalid RAM size 0x%" PRIx64 ". Using default %dM",
> + s->ram_size, asc->fallback_ram_size);
> +s->ram_size = asc->fallback_ram_size << 20;
> +val = g_hash_table_lookup(asc->ram2feat, >fallback_ram_size);
> +return GPOINTER_TO_INT(val);
> +}
> +
>
[PULL v2 00/34] tcg patch queue
For version 2, drop the -static and -pie changes,
i.e. patches 1-7 from version 1.
I'll come back to those after the required linux-user changes are
upstream. In the meantime, it's still a large enough set of patches.
r~
The following changes since commit 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92:
Merge remote-tracking branch 'remotes/kraxel/tags/ui-20200114-pull-request'
into staging (2020-01-14 16:00:31 +)
are available in the Git repository at:
https://github.com/rth7680/qemu.git tags/pull-tcg-20200115
for you to fetch changes up to 3e5a01ef0268ee4c9d342a26dbf6624d6b5b20d6:
MAINTAINERS: Replace Claudio Fontana for tcg/aarch64 (2020-01-15 15:13:10
-1000)
Add cpu_{ld,st}*_mmuidx_ra
Remove MMU_MODE*_SUFFIX
Move tcg headers under include/
Philippe Mathieu-Daudé (4):
tcg: Search includes from the project root source directory
tcg: Search includes in the parent source directory
tcg: Move TCG headers to include/tcg/
configure: Remove tcg/ from the preprocessor include search list
Richard Henderson (30):
target/xtensa: Use probe_access for itlb_hit_test
cputlb: Use trace_mem_get_info instead of trace_mem_build_info
trace: Remove trace_mem_build_info_no_se_[bl]e
target/s390x: Include tcg.h in mem_helper.c
target/arm: Include tcg.h in sve_helper.c
accel/tcg: Include tcg.h in tcg-runtime.c
linux-user: Include tcg.h in syscall.c
linux-user: Include trace-root.h in syscall-trace.h
plugins: Include trace/mem.h in api.c
cputlb: Move body of cpu_ldst_template.h out of line
translator: Use cpu_ld*_code instead of open-coding
cputlb: Rename helper_ret_ld*_cmmu to cpu_ld*_code
cputlb: Provide cpu_(ld,st}*_mmuidx_ra for user-only
target/i386: Use cpu_*_mmuidx_ra instead of templates
cputlb: Expand cpu_ldst_useronly_template.h in user-exec.c
target/nios2: Remove MMU_MODE{0,1}_SUFFIX
target/alpha: Remove MMU_MODE{0,1}_SUFFIX
target/cris: Remove MMU_MODE{0,1}_SUFFIX
target/i386: Remove MMU_MODE{0,1,2}_SUFFIX
target/microblaze: Remove MMU_MODE{0,1,2}_SUFFIX
target/sh4: Remove MMU_MODE{0,1}_SUFFIX
target/unicore32: Remove MMU_MODE{0,1}_SUFFIX
target/xtensa: Remove MMU_MODE{0,1,2,3}_SUFFIX
target/m68k: Use cpu_*_mmuidx_ra instead of MMU_MODE{0,1}_SUFFIX
target/mips: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
target/s390x: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
target/ppc: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
cputlb: Remove support for MMU_MODE*_SUFFIX
cputlb: Expand cpu_ldst_template.h in cputlb.c
MAINTAINERS: Replace Claudio Fontana for tcg/aarch64
accel/tcg/atomic_template.h | 67 ++---
include/exec/cpu_ldst.h | 446 +-
include/exec/cpu_ldst_template.h | 211 --
include/exec/cpu_ldst_useronly_template.h | 159 ---
include/exec/translator.h | 48 +---
{tcg => include/tcg}/tcg-gvec-desc.h | 0
{tcg => include/tcg}/tcg-mo.h | 0
{tcg => include/tcg}/tcg-op-gvec.h| 0
{tcg => include/tcg}/tcg-op.h | 2 +-
{tcg => include/tcg}/tcg-opc.h| 0
{tcg => include/tcg}/tcg.h| 33 +--
include/user/syscall-trace.h | 2 +
target/alpha/cpu.h| 2 -
target/cris/cpu.h | 2 -
target/i386/cpu.h | 3 -
target/m68k/cpu.h | 2 -
target/microblaze/cpu.h | 3 -
target/mips/cpu.h | 4 -
target/nios2/cpu.h| 2 -
target/ppc/cpu.h | 2 -
target/s390x/cpu.h| 5 -
target/sh4/cpu.h | 2 -
target/unicore32/cpu.h| 2 -
target/xtensa/cpu.h | 4 -
tcg/i386/tcg-target.h | 2 +-
trace/mem-internal.h | 17 --
accel/tcg/cpu-exec.c | 2 +-
accel/tcg/cputlb.c| 315 -
accel/tcg/tcg-runtime-gvec.c | 2 +-
accel/tcg/tcg-runtime.c | 1 +
accel/tcg/translate-all.c | 2 +-
accel/tcg/user-exec.c | 238 +++-
bsd-user/main.c | 2 +-
cpus.c| 2 +-
exec.c| 2 +-
linux-user/main.c | 2 +-
linux-user/syscall.c | 1 +
plugins/api.c | 1 +
target/alpha/translate.c | 2 +-
target/arm/helper-a64.c
RE: [PATCH RFC 00/12] *** mulitple RDMA channels for migration ***
Thanks for your review. I will add more trace_ calls in the next version(V2) and modify its according to your suggestions. -Original Message- From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com] Sent: Thursday, January 16, 2020 3:57 AM To: fengzhimin Cc: quint...@redhat.com; arm...@redhat.com; ebl...@redhat.com; qemu-devel@nongnu.org; Zhanghailiang ; jemmy858...@gmail.com Subject: Re: [PATCH RFC 00/12] *** mulitple RDMA channels for migration *** * Zhimin Feng (fengzhim...@huawei.com) wrote: > From: fengzhimin > > Currently there is a single channel for RDMA migration, this causes > the problem that the network bandwidth is not fully utilized for > 25Gigabit NIC. Inspired by the Multifd, we use two RDMA channels to > send RAM pages, which we call MultiRDMA. > > We compare the migration performance of MultiRDMA with origin RDMA > migration. The VM specifications for migration are as follows: > - VM use 4k page; > - the number of VCPU is 4; > - the total memory is 16Gigabit; > - use 'mempress' tool to pressurize VM(mempress 8000 500); > - use 25Gigabit network card to migrate; > > For origin RDMA and MultiRDMA migration, the total migration times of > VM are as follows: > + > | | NOT rdma-pin-all | rdma-pin-all | > + > | origin RDMA | 18 s | 23 s | > - > | MultiRDMA | 13 s | 18 s | > + Very nice. > For NOT rdma-pin-all migration, the multiRDMA can improve the total > migration time by about 27.8%. > For rdma-pin-all migration, the multiRDMA can improve the total > migration time by about 21.7%. > > Test the multiRDMA migration like this: > 'virsh migrate --live --rdma-parallel --migrateuri rdma://hostname > domain qemu+tcp://hostname/system' It will take me a while to finish the review; but another general suggestion is add more trace_ calls; it will make it easier to diagnose problems later. Dave > > fengzhimin (12): > migration: Add multiRDMA capability support > migration: Export the 'migration_incoming_setup' function > and add the 'migrate_use_rdma_pin_all' function > migration: Create the multi-rdma-channels parameter > migration/rdma: Create multiRDMA migration threads > migration/rdma: Create the multiRDMA channels > migration/rdma: Transmit initial package > migration/rdma: Be sure all channels are created > migration/rdma: register memory for multiRDMA channels > migration/rdma: Wait for all multiRDMA to complete registration > migration/rdma: use multiRDMA to send RAM block for rdma-pin-all mode > migration/rdma: use multiRDMA to send RAM block for NOT rdma-pin-all > mode > migration/rdma: only register the virt-ram block for MultiRDMA > > migration/migration.c | 55 +- > migration/migration.h |6 + > migration/rdma.c | 1320 + > monitor/hmp-cmds.c|7 + > qapi/migration.json | 27 +- > 5 files changed, 1285 insertions(+), 130 deletions(-) > > -- > 2.19.1 > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2 59/86] ppc:e500: drop RAM size fixup
On Wed, Jan 15, 2020 at 04:07:14PM +0100, Igor Mammedov wrote:
> If user provided non-sense RAM size, board will complain and
> continue running with max RAM size supported.
> Also RAM is going to be allocated by generic code, so it won't be
> possible for board to fix things up for user.
>
> Make it error message and exit to force user fix CLI,
> instead of accepting non-sense CLI values.
>
> While at it, replace usage of global ram_size with
> machine->ram_size
>
> Signed-off-by: Igor Mammedov
Acked-by: David Gibson
>
> ---
> v2:
> * fix format string cousing build failure on 32-bit host
>(Philippe Mathieu-Daudé )
>
> CC: da...@gibson.dropbear.id.au
> CC: qemu-...@nongnu.org
> ---
> hw/ppc/e500.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> index 12b6a5b..6d119fe 100644
> --- a/hw/ppc/e500.c
> +++ b/hw/ppc/e500.c
> @@ -906,12 +906,14 @@ void ppce500_init(MachineState *machine)
>
> env = firstenv;
>
> -/* Fixup Memory size on a alignment boundary */
> -ram_size &= ~(RAM_SIZES_ALIGN - 1);
> -machine->ram_size = ram_size;
> +if (!QEMU_IS_ALIGNED(machine->ram_size, RAM_SIZES_ALIGN)) {
> +error_report("RAM size must be multiple of %" PRIu64,
> RAM_SIZES_ALIGN);
> +exit(EXIT_FAILURE);
> +}
>
> /* Register Memory */
> -memory_region_allocate_system_memory(ram, NULL, "mpc8544ds.ram",
> ram_size);
> +memory_region_allocate_system_memory(ram, NULL, "mpc8544ds.ram",
> + machine->ram_size);
> memory_region_add_subregion(address_space_mem, 0, ram);
>
> dev = qdev_create(NULL, "e500-ccsr");
> @@ -1083,7 +1085,7 @@ void ppce500_init(MachineState *machine)
> kernel_base = cur_base;
> kernel_size = load_image_targphys(machine->kernel_filename,
>cur_base,
> - ram_size - cur_base);
> + machine->ram_size - cur_base);
> if (kernel_size < 0) {
> error_report("could not load kernel '%s'",
> machine->kernel_filename);
> @@ -1097,7 +1099,7 @@ void ppce500_init(MachineState *machine)
> if (machine->initrd_filename) {
> initrd_base = (cur_base + INITRD_LOAD_PAD) & ~INITRD_PAD_MASK;
> initrd_size = load_image_targphys(machine->initrd_filename,
> initrd_base,
> - ram_size - initrd_base);
> + machine->ram_size - initrd_base);
>
> if (initrd_size < 0) {
> error_report("could not load initial ram disk '%s'",
> @@ -1115,7 +1117,7 @@ void ppce500_init(MachineState *machine)
> * ensures enough space between kernel and initrd.
> */
> dt_base = (loadaddr + payload_size + DTC_LOAD_PAD) & ~DTC_PAD_MASK;
> -if (dt_base + DTB_MAX_SIZE > ram_size) {
> +if (dt_base + DTB_MAX_SIZE > machine->ram_size) {
> error_report("not enough memory for device tree");
> exit(1);
> }
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
[PATCH] ui/gtk: Get display refresh rate with GDK version 3.22 or later
The GdkMonitor was introduced in GTK+ 3.22:
https://developer.gnome.org/gdk3/stable/api-index-3-22.html#api-index-3.22
If we build with older GTK+, the build fails:
CC ui/gtk.o
qemu/ui/gtk.c: In function ‘gd_vc_gfx_init’:
qemu/ui/gtk.c:1973:5: error: unknown type name ‘GdkMonitor’
GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
^
qemu/ui/gtk.c:1973:27: error: implicit declaration of function
‘gdk_display_get_monitor_at_window’ [-Werror=implicit-function-declaration]
GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
^
qemu/ui/gtk.c:1973:5: error: nested extern declaration of
‘gdk_display_get_monitor_at_window’ [-Werror=nested-externs]
GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
^
qemu/ui/gtk.c:1973:27: error: initialization makes pointer from integer
without a cast [-Werror=int-conversion]
GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
^
qemu/ui/gtk.c:2035:28: error: implicit declaration of function
‘gdk_monitor_get_refresh_rate’ [-Werror=implicit-function-declaration]
refresh_rate_millihz = gdk_monitor_get_refresh_rate(monitor);
^
qemu/ui/gtk.c:2035:5: error: nested extern declaration of
‘gdk_monitor_get_refresh_rate’ [-Werror=nested-externs]
refresh_rate_millihz = gdk_monitor_get_refresh_rate(monitor);
^
cc1: all warnings being treated as errors
qemu/rules.mak:69: recipe for target 'ui/gtk.o' failed
make: *** [ui/gtk.o] Error 1
We only use the GdkMonitor API to get the monitor refresh rate.
GTK+ provides convenient definition in
(already include by ) to check which API are available.
Extract this code as a new gd_refresh_rate_millihz() function,
and check GDK_VERSION_3_22 is defined before calling its API.
If it is not defined, return 0. This is safe and fixes our build
failure.
Fixes: c4c00922cc (display/gtk: get proper refreshrate)
Signed-off-by: Philippe Mathieu-Daudé
---
Sorry I missed that, I only tested Nikola's patch on my workstation
which runs Fedora 30:
$ pkg-config --modversion gtk+-3.0
3.24.11
If Gerd acks this patch, we might consider having it directly
applied as a build fix.
---
ui/gtk.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index 7355d34fcf..d18892d1de 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1961,6 +1961,23 @@ static GtkWidget *gd_create_menu_machine(GtkDisplayState
*s)
return machine_menu;
}
+/*
+ * If available, return the refresh rate of the display in milli-Hertz,
+ * else return 0.
+ */
+static int gd_refresh_rate_millihz(GtkDisplayState *s)
+{
+#ifdef GDK_VERSION_3_22
+GdkDisplay *dpy = gtk_widget_get_display(s->window);
+GdkWindow *win = gtk_widget_get_window(s->window);
+GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
+
+return gdk_monitor_get_refresh_rate(monitor);
+#else
+return 0;
+#endif
+}
+
static GSList *gd_vc_gfx_init(GtkDisplayState *s, VirtualConsole *vc,
QemuConsole *con, int idx,
GSList *group, GtkWidget *view_menu)
@@ -1968,10 +1985,6 @@ static GSList *gd_vc_gfx_init(GtkDisplayState *s,
VirtualConsole *vc,
bool zoom_to_fit = false;
int refresh_rate_millihz;
-GdkDisplay *dpy = gtk_widget_get_display(s->window);
-GdkWindow *win = gtk_widget_get_window(s->window);
-GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
-
vc->label = qemu_console_get_label(con);
vc->s = s;
vc->gfx.scale_x = 1.0;
@@ -2032,7 +2045,7 @@ static GSList *gd_vc_gfx_init(GtkDisplayState *s,
VirtualConsole *vc,
vc->gfx.kbd = qkbd_state_init(con);
vc->gfx.dcl.con = con;
-refresh_rate_millihz = gdk_monitor_get_refresh_rate(monitor);
+refresh_rate_millihz = gd_refresh_rate_millihz(s);
if (refresh_rate_millihz) {
vc->gfx.dcl.update_interval = MILLISEC_PER_SEC / refresh_rate_millihz;
}
--
2.21.1
RE: [PATCH 084/104] Virtiofsd: fix memory leak on fuse queueinfo
> * Misono Tomohiro (misono.tomoh...@jp.fujitsu.com) wrote:
> > > From: Liu Bo
> > >
> > > For fuse's queueinfo, both queueinfo array and queueinfos are
> > > allocated in
> > > fv_queue_set_started() but not cleaned up when the daemon process quits.
> > >
> > > This fixes the leak in proper places.
> > >
> > > Signed-off-by: Liu Bo
> > > Signed-off-by: Eric Ren
> > > ---
> > > tools/virtiofsd/fuse_virtio.c | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/tools/virtiofsd/fuse_virtio.c
> > > b/tools/virtiofsd/fuse_virtio.c index 7b22ae8d4f..a364f23d5d 100644
> > > --- a/tools/virtiofsd/fuse_virtio.c
> > > +++ b/tools/virtiofsd/fuse_virtio.c
> > > @@ -671,6 +671,8 @@ static void fv_queue_set_started(VuDev *dev, int
> > > qidx, bool started)
> > > }
> > > close(ourqi->kill_fd);
> > > ourqi->kick_fd = -1;
> > > +free(vud->qi[qidx]);
> > > +vud->qi[qidx] = NULL;
> > > }
> > > }
> > >
> > > @@ -878,6 +880,13 @@ int virtio_session_mount(struct fuse_session
> > > *se) void virtio_session_close(struct fuse_session *se) {
> > > close(se->vu_socketfd);
> >
> > I beleve above close() should be removed as it is called 6 line below.
>
> You're right, I think that's my fault from when I merged this patch with
> 'Virtiofsd: fix segfault when quit before dev init'.
>
> Fixed.
Given that:
Reviewed-by: Misono Tomohiro
Thanks.
> Thanks.
>
> Dave
>
> > > +
> > > +if (!se->virtio_dev) {
> > > +return;
> > > +}
> > > +
> > > +close(se->vu_socketfd);
> > > +free(se->virtio_dev->qi);
> > > free(se->virtio_dev);
> > > se->virtio_dev = NULL;
> > > }
> > > --
> > > 2.23.0
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2 35/86] arm:xilinx_zynq: use memdev for RAM
On Thu, Jan 16, 2020 at 1:29 AM Igor Mammedov wrote:
>
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Alistair Francis
Alistair
> ---
> CC: peter.mayd...@linaro.org
> CC: qemu-...@nongnu.org
> CC: edgar.igles...@gmail.com
> CC: alist...@alistair23.me
> ---
> hw/arm/xilinx_zynq.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
> index df950fc..0ef9688 100644
> --- a/hw/arm/xilinx_zynq.c
> +++ b/hw/arm/xilinx_zynq.c
> @@ -160,7 +160,6 @@ static void zynq_init(MachineState *machine)
> {
> ARMCPU *cpu;
> MemoryRegion *address_space_mem = get_system_memory();
> -MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
> MemoryRegion *ocm_ram = g_new(MemoryRegion, 1);
> DeviceState *dev;
> SysBusDevice *busdev;
> @@ -190,9 +189,7 @@ static void zynq_init(MachineState *machine)
> object_property_set_bool(OBJECT(cpu), true, "realized", _fatal);
>
> /* DDR remapped to address zero. */
> -memory_region_allocate_system_memory(ext_ram, NULL, "zynq.ext_ram",
> - machine->ram_size);
> -memory_region_add_subregion(address_space_mem, 0, ext_ram);
> +memory_region_add_subregion(address_space_mem, 0, machine->ram);
>
> /* 256K of on-chip memory */
> memory_region_init_ram(ocm_ram, NULL, "zynq.ocm_ram", 256 * KiB,
> @@ -318,6 +315,7 @@ static void zynq_machine_init(MachineClass *mc)
> mc->no_sdcard = 1;
> mc->ignore_memory_transaction_failures = true;
> mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a9");
> +mc->default_ram_id = "zynq.ext_ram";
> }
>
> DEFINE_MACHINE("xilinx-zynq-a9", zynq_machine_init)
> --
> 2.7.4
>
>
Re: [PATCH v2 37/86] arm:xlnx-zcu102: use memdev for RAM
On Thu, Jan 16, 2020 at 1:39 AM Igor Mammedov wrote:
>
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
> MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Alistair Francis
Alistair
> ---
> CC: alist...@alistair23.me
> CC: edgar.igles...@gmail.com
> CC: peter.mayd...@linaro.org
> CC: qemu-...@nongnu.org
> ---
> hw/arm/xlnx-zcu102.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
> index 53cfe7c..bd645ad 100644
> --- a/hw/arm/xlnx-zcu102.c
> +++ b/hw/arm/xlnx-zcu102.c
> @@ -28,7 +28,6 @@ typedef struct XlnxZCU102 {
> MachineState parent_obj;
>
> XlnxZynqMPState soc;
> -MemoryRegion ddr_ram;
>
> bool secure;
> bool virt;
> @@ -87,13 +86,10 @@ static void xlnx_zcu102_init(MachineState *machine)
> ram_size);
> }
>
> -memory_region_allocate_system_memory(>ddr_ram, NULL, "ddr-ram",
> - ram_size);
> -
> object_initialize_child(OBJECT(machine), "soc", >soc, sizeof(s->soc),
> TYPE_XLNX_ZYNQMP, _abort, NULL);
>
> -object_property_set_link(OBJECT(>soc), OBJECT(>ddr_ram),
> +object_property_set_link(OBJECT(>soc), OBJECT(machine->ram),
> "ddr-ram", _abort);
> object_property_set_bool(OBJECT(>soc), s->secure, "secure",
> _fatal);
> @@ -211,6 +207,7 @@ static void xlnx_zcu102_machine_class_init(ObjectClass
> *oc, void *data)
> mc->ignore_memory_transaction_failures = true;
> mc->max_cpus = XLNX_ZYNQMP_NUM_APU_CPUS + XLNX_ZYNQMP_NUM_RPU_CPUS;
> mc->default_cpus = XLNX_ZYNQMP_NUM_APU_CPUS;
> +mc->default_ram_id = "ddr-ram";
> }
>
> static const TypeInfo xlnx_zcu102_machine_init_typeinfo = {
> --
> 2.7.4
>
>
Re: [PATCH v7 10/11] vl: replace deprecated qbus_reset_all registration
On 1/15/20 1:36 PM, Damien Hedde wrote:
Replace deprecated qbus_reset_all by resettable_cold_reset_fn for
the sysbus reset registration.
Apart for the raspi machines, this does not impact the behavior
because:
+ at this point resettable just calls the old reset methods of devices
and buses in the same order as qdev/qbus.
+ resettable handlers registered with qemu_register_reset are
serialized; there is no interleaving.
+ eventual explicit calls to legacy reset API (device_reset or
qdev/qbus_reset) inside this reset handler will not be masked out
by resettable mechanism; they do not go through resettable api.
For the raspi machines, during the sysbus reset the sd-card is not
reset twice anymore but only once. This is a consequence of switching
both sysbus reset and changing parent to resettable; it detects the
second reset is not needed. This has no impact on the state after
reset; the sd-card reset method only reset local state and query
information from the block backend.
Signed-off-by: Damien Hedde
Reviewed-by: Peter Maydell
Reviewed-by: Richard Henderson
---
The raspi reset change can be observed by using the following command
(reset will occurs, then do Ctrl-C to end qemu; no firmware is
given here).
qemu-system-aarch64 -M raspi3 \
-trace resettable_phase_hold_exec \
-trace qdev_update_parent_bus \
-trace resettable_change_parent \
-trace qdev_reset -trace qbus_reset
Before the patch, the qdev/qbus_reset traces show when reset method are
called. After the patch, the resettable_phase_hold_exec show when reset
method are called.
The traced reset order of the raspi3 is listed below. I've added empty
lines and the tree structure.
+->bcm2835-peripherals reset
|
| +->sd-card reset
| +->sd-bus reset
+->bcm2835_gpio reset
| -> dev_update_parent_bus (move the sd-card on the sdhci-bus)
| -> resettable_change_parent
|
+->bcm2835-dma reset
|
| +->bcm2835-sdhost-bus reset
+->bcm2835-sdhost reset
|
| +->sd-card (reset ONLY BEFORE BEFORE THE PATCH)
| +->sdhci-bus reset
+->generic-sdhci reset
|
+->bcm2835-rng reset
+->bcm2835-property reset
+->bcm2835-fb reset
+->bcm2835-mbox reset
+->bcm2835-aux reset
+->pl011 reset
+->bcm2835-ic reset
+->bcm2836-control reset
System reset
In both case, the sd-card is reset (being on bcm2835_gpio/sd-bus) then moved
to generic-sdhci/sdhci-bus by the bcm2835_gpio reset method.
Before the patch, it is then reset again being part of generic-sdhci/sdhci-bus.
After the patch, it considered again for reset but its reset method is not
called because it is already flagged as reset.
I find this information helpful, have you considered including it in the
description?
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
vl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/vl.c b/vl.c
index 751401214c..e5a537d4f9 100644
--- a/vl.c
+++ b/vl.c
@@ -4362,7 +4362,15 @@ int main(int argc, char **argv, char **envp)
/* TODO: once all bus devices are qdevified, this should be done
* when bus is created by qdev.c */
-qemu_register_reset(qbus_reset_all_fn, sysbus_get_default());
+/*
+ * TODO: If we had a main 'reset container' that the whole system
+ * lived in, we could reset that using the multi-phase reset
+ * APIs. For the moment, we just reset the sysbus, which will cause
+ * all devices hanging off it (and all their child buses, recursively)
+ * to be reset. Note that this will *not* reset any Device objects
+ * which are not attached to some part of the qbus tree!
+ */
+qemu_register_reset(resettable_cold_reset_fn, sysbus_get_default());
qemu_run_machine_init_done_notifiers();
if (rom_check_and_register_reset() != 0) {
Re: [PATCH 085/104] virtiofsd: Support remote posix locks
On Thu, Dec 12, 2019 at 04:38:45PM +, Dr. David Alan Gilbert (git) wrote:
> From: Vivek Goyal
>
> Doing posix locks with-in guest kernel are not sufficient if a file/dir
> is being shared by multiple guests. So we need the notion of daemon doing
> the locks which are visible to rest of the guests.
>
> Given posix locks are per process, one can not call posix lock API on host,
> otherwise bunch of basic posix locks properties are broken. For example,
> If two processes (A and B) in guest open the file and take locks on different
> sections of file, if one of the processes closes the fd, it will close
> fd on virtiofsd and all posix locks on file will go away. This means if
> process A closes the fd, then locks of process B will go away too.
>
> Similar other problems exist too.
>
> This patch set tries to emulate posix locks while using open file
> description locks provided on Linux.
>
> Daemon provides two options (-o posix_lock, -o no_posix_lock) to enable
> or disable posix locking in daemon. By default it is enabled.
>
> There are few issues though.
>
> - GETLK() returns pid of process holding lock. As we are emulating locks
> using OFD, and these locks are not per process and don't return pid
> of process, so GETLK() in guest does not reuturn process pid.
>
> - As of now only F_SETLK is supported and not F_SETLKW. We can't block
> the thread in virtiofsd for arbitrary long duration as there is only
> one thread serving the queue. That means unlock request will not make
> it to daemon and F_SETLKW will block infinitely and bring virtio-fs
> to a halt. This is a solvable problem though and will require significant
> changes in virtiofsd and kernel. Left as a TODO item for now.
>
> Signed-off-by: Vivek Goyal
> ---
> tools/virtiofsd/passthrough_ll.c | 190 +++
> 1 file changed, 190 insertions(+)
>
> diff --git a/tools/virtiofsd/passthrough_ll.c
> b/tools/virtiofsd/passthrough_ll.c
> index fbcc222860..fc79d5ac43 100644
> --- a/tools/virtiofsd/passthrough_ll.c
> +++ b/tools/virtiofsd/passthrough_ll.c
> @@ -68,6 +68,13 @@
> #include "seccomp.h"
>
> #define HAVE_POSIX_FALLOCATE 1
> +
> +/* Keep track of inode posix locks for each owner. */
> +struct lo_inode_plock {
> +uint64_t lock_owner;
> +int fd; /* fd for OFD locks */
> +};
> +
> struct lo_map_elem {
> union {
> struct lo_inode *inode;
> @@ -96,6 +103,8 @@ struct lo_inode {
> struct lo_key key;
> uint64_t refcount; /* protected by lo->mutex */
> fuse_ino_t fuse_ino;
> +pthread_mutex_t plock_mutex;
> +GHashTable *posix_locks; /* protected by lo_inode->plock_mutex */
> };
>
> struct lo_cred {
> @@ -115,6 +124,7 @@ struct lo_data {
> int norace;
> int writeback;
> int flock;
> +int posix_lock;
> int xattr;
> const char *source;
> double timeout;
> @@ -138,6 +148,8 @@ static const struct fuse_opt lo_opts[] = {
> { "source=%s", offsetof(struct lo_data, source), 0 },
> { "flock", offsetof(struct lo_data, flock), 1 },
> { "no_flock", offsetof(struct lo_data, flock), 0 },
> +{ "posix_lock", offsetof(struct lo_data, posix_lock), 1 },
> +{ "no_posix_lock", offsetof(struct lo_data, posix_lock), 0 },
> { "xattr", offsetof(struct lo_data, xattr), 1 },
> { "no_xattr", offsetof(struct lo_data, xattr), 0 },
> { "timeout=%lf", offsetof(struct lo_data, timeout), 0 },
> @@ -486,6 +498,17 @@ static void lo_init(void *userdata, struct
> fuse_conn_info *conn)
> fuse_log(FUSE_LOG_DEBUG, "lo_init: activating flock locks\n");
> conn->want |= FUSE_CAP_FLOCK_LOCKS;
> }
> +
> +if (conn->capable & FUSE_CAP_POSIX_LOCKS) {
> +if (lo->posix_lock) {
> +fuse_log(FUSE_LOG_DEBUG, "lo_init: activating posix locks\n");
> +conn->want |= FUSE_CAP_POSIX_LOCKS;
> +} else {
> +fuse_log(FUSE_LOG_DEBUG, "lo_init: disabling posix locks\n");
> +conn->want &= ~FUSE_CAP_POSIX_LOCKS;
> +}
> +}
> +
> if ((lo->cache == CACHE_NONE && !lo->readdirplus_set) ||
> lo->readdirplus_clear) {
> fuse_log(FUSE_LOG_DEBUG, "lo_init: disabling readdirplus\n");
> @@ -773,6 +796,19 @@ static struct lo_inode *lo_find(struct lo_data *lo,
> struct stat *st)
> return p;
> }
>
> +/* value_destroy_func for posix_locks GHashTable */
> +static void posix_locks_value_destroy(gpointer data)
> +{
> +struct lo_inode_plock *plock = data;
> +
> +/*
> + * We had used open() for locks and had only one fd. So
> + * closing this fd should release all OFD locks.
> + */
> +close(plock->fd);
> +free(plock);
> +}
> +
> static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name,
> struct fuse_entry_param *e)
> {
> @@ -826,6 +862,9 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t
> parent, const char *name,
> newfd = -1;
>
Re: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
On 1/15/20 7:09 AM, Igor Mammedov wrote: > On Wed, 15 Jan 2020 08:43:33 -0800 (PST) > no-re...@patchew.org wrote: > >> Patchew URL: >> https://patchew.org/QEMU/1579100861-73692-1-git-send-email-imamm...@redhat.com/ >> >> >> >> Hi, >> >> This series seems to have some coding style problems. See output below for >> more information: > [...] > >> 6/86 Checking commit b9b1823833a3 (alpha:dp264: use memdev for RAM) >> ERROR: spaces required around that '*' (ctx:WxV) >> #30: FILE: hw/alpha/alpha_sys.h:14: >> +PCIBus *typhoon_init(MemoryRegion *, ISABus **, qemu_irq *, AlphaCPU *[4], > > patch keeps the same style that was used in original code > I can rewrite it on the next respin to mach current codestyle False positive. The script doesn't understand pointers well, and it's triggering the rule for multiplication. r~
Re: [PATCH v5 21/22] gdbstub: change GDBState.last_packet to GByteArray
On 1/14/20 5:09 AM, Alex Bennée wrote: > From: Damien Hedde > > Remove the packet size upper limit by using a GByteArray > instead of a statically allocated array for last_packet. > Thus we can now send big packets. > > Also remove the last_packet_len field and use last_packet->len > instead. > > Signed-off-by: Damien Hedde > Reviewed-by: Philippe Mathieu-Daudé > Message-Id: <20191211160514.58373-2-damien.he...@greensocs.com> > Signed-off-by: Alex Bennée > --- > gdbstub.c | 39 +-- > 1 file changed, 21 insertions(+), 18 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v5 22/22] gdbstub: do not split gdb_monitor_write payload
On 1/14/20 5:09 AM, Alex Bennée wrote: > From: Damien Hedde > > Since we can now send packets of arbitrary length: > simplify gdb_monitor_write() and send the whole payload > in one packet. > > Suggested-by: Luc Michel > Signed-off-by: Damien Hedde > Signed-off-by: Alex Bennée > Message-Id: <20191211160514.58373-3-damien.he...@greensocs.com> > --- > gdbstub.c | 23 +++ > 1 file changed, 3 insertions(+), 20 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v5 20/22] tests/tcg/aarch64: add test-sve-ioctl guest-debug test
On 1/14/20 5:09 AM, Alex Bennée wrote: > This test exercises the gdbstub while runing the sve-iotcl test. I > haven't plubmed it into make system as we need a way of verifying if > gdb has the right support for SVE. > > Signed-off-by: Alex Bennée > > --- > v4 > - interrogate ZCR_EL1 directly as no longer have vg Note that ZCR_EL1 does not give you the correct answer if the hypervisor has set ZCR_EL2 to something lower. Also, ZCR_EL1 it itself not correct if the hardware does not support all vector sizes. See some of Andrew Jones' qemu command-line work. Try -cpu max,sve512=on and then use the ioctl to set vq to 3 (sve384). The result will be an effective vq of 2 (sve256). We *really* need vg, as computed from sve_zcr_len_for_el(). r~
Re: [PATCH v3 1/3] target/riscv: Fix tb->flags FS status
On Thu, Jan 16, 2020 at 7:46 AM Richard Henderson
wrote:
>
> On 1/14/20 8:28 PM, Alistair Francis wrote:
> > On Wed, Jan 15, 2020 at 4:18 PM wrote:
> >>
> >> It was found that running libquantum on riscv-linux qemu produced an
> >> incorrect result. After investigation, FP registers are not saved
> >> during context switch due to incorrect mstatus.FS.
> >>
> >> In current implementation tb->flags merges all non-disabled state to
> >> dirty. This means the code in mark_fs_dirty in translate.c that
> >> handles initial and clean states is unreachable.
> >>
> >> This patch fixes it and is successfully tested with:
> >> libquantum
> >>
> >> Thanks to Richard for pointing out the actual bug.
> >>
> >> v3: remove the redundant condition
> >> v2: root cause FS problem
> >>
> >> Suggested-by: Richard Henderson
> >> Signed-off-by: ShihPo Hung
> >> Reviewed-by: Richard Henderson
> >> ---
> >> target/riscv/cpu.h | 5 +
> >> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> >> index e59343e..de0a8d8 100644
> >> --- a/target/riscv/cpu.h
> >> +++ b/target/riscv/cpu.h
> >> @@ -293,10 +293,7 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState
> >> *env, target_ulong *pc,
> >> #ifdef CONFIG_USER_ONLY
> >> *flags = TB_FLAGS_MSTATUS_FS;
> >> #else
> >> -*flags = cpu_mmu_index(env, 0);
> >> -if (riscv_cpu_fp_enabled(env)) {
> >> -*flags |= TB_FLAGS_MSTATUS_FS;
> >> -}
> >> +*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
> >
> > I don't think this is right, you should use the riscv_cpu_fp_enabled()
> > function.
> >
> > Right now it's the same as env->mstatus & MSTATUS_FS but when the
> > Hypervisor extension goes in riscv_cpu_fp_enabled() will be more
> > complex.
>
> Hmm. Are you sure something like
>
> flags |= riscv_cpu_effective_mstatus(env) & MSTATUS_FS;
>
> wouldn't be more appropriate for the hypervisor extension?
I was more thinking:
if (riscv_cpu_fp_enabled(env)) {
*flags |= env->mstatus & MSTATUS_FS;
}
as floating point can be disabled from multiple places when we have
the H extension.
>
> I guess I should have another browse through your hv patchset, but I worry now
> about bare uses of env->mstatus, if they no longer mean what they appear to
> mean.
That was why this was all refacted in the first place as we now need
to check against env->vsstatus as well (depending on virt status).
Alistair
>
>
> r~
Re: [PATCH 101/104] virtiofsd: prevent FUSE_INIT/FUSE_DESTROY races
On Thu, Dec 12, 2019 at 04:39:01PM +, Dr. David Alan Gilbert (git) wrote:
> From: Stefan Hajnoczi
>
> When running with multiple threads it can be tricky to handle
> FUSE_INIT/FUSE_DESTROY in parallel with other request types or in
> parallel with themselves. Serialize FUSE_INIT and FUSE_DESTROY so that
> malicious clients cannot trigger race conditions.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tools/virtiofsd/fuse_i.h| 1 +
> tools/virtiofsd/fuse_lowlevel.c | 18 ++
> 2 files changed, 19 insertions(+)
>
> diff --git a/tools/virtiofsd/fuse_i.h b/tools/virtiofsd/fuse_i.h
> index d0679508cd..8a4a05b319 100644
> --- a/tools/virtiofsd/fuse_i.h
> +++ b/tools/virtiofsd/fuse_i.h
> @@ -61,6 +61,7 @@ struct fuse_session {
> struct fuse_req list;
> struct fuse_req interrupts;
> pthread_mutex_t lock;
> +pthread_rwlock_t init_rwlock;
> int got_destroy;
> int broken_splice_nonblock;
> uint64_t notify_ctr;
> diff --git a/tools/virtiofsd/fuse_lowlevel.c b/tools/virtiofsd/fuse_lowlevel.c
> index 10f478b00c..9f01c05e3e 100644
> --- a/tools/virtiofsd/fuse_lowlevel.c
> +++ b/tools/virtiofsd/fuse_lowlevel.c
> @@ -2431,6 +2431,19 @@ void fuse_session_process_buf_int(struct fuse_session
> *se,
> req->ctx.pid = in->pid;
> req->ch = ch ? fuse_chan_get(ch) : NULL;
>
> +/*
> + * INIT and DESTROY requests are serialized, all other request types
> + * run in parallel. This prevents races between FUSE_INIT and ordinary
> + * requests, FUSE_INIT and FUSE_INIT, FUSE_INIT and FUSE_DESTROY, and
> + * FUSE_DESTROY and FUSE_DESTROY.
> + */
> +if (in->opcode == FUSE_INIT || in->opcode == CUSE_INIT ||
> +in->opcode == FUSE_DESTROY) {
> +pthread_rwlock_wrlock(>init_rwlock);
> +} else {
> +pthread_rwlock_rdlock(>init_rwlock);
> +}
> +
> err = EIO;
> if (!se->got_init) {
> enum fuse_opcode expected;
> @@ -2488,10 +2501,13 @@ void fuse_session_process_buf_int(struct fuse_session
> *se,
> } else {
> fuse_ll_ops[in->opcode].func(req, in->nodeid, );
> }
> +
> +pthread_rwlock_unlock(>init_rwlock);
> return;
>
> reply_err:
> fuse_reply_err(req, err);
> +pthread_rwlock_unlock(>init_rwlock);
> }
>
> #define LL_OPTION(n, o, v) \
> @@ -2538,6 +2554,7 @@ void fuse_session_destroy(struct fuse_session *se)
> se->op.destroy(se->userdata);
> }
> }
> +pthread_rwlock_destroy(>init_rwlock);
> pthread_mutex_destroy(>lock);
> free(se->cuse_data);
> if (se->fd != -1) {
> @@ -2631,6 +2648,7 @@ struct fuse_session *fuse_session_new(struct fuse_args
> *args,
> list_init_req(>list);
> list_init_req(>interrupts);
> fuse_mutex_init(>lock);
> +pthread_rwlock_init(>init_rwlock, NULL);
>
> memcpy(>op, op, op_size);
> se->owner = getuid();
Looks good to me.
Reviewed-by: Masayoshi Mizuma
> --
> 2.23.0
>
>
Re: [PATCH v5 17/22] tests/guest-debug: add a simple test runner
On 1/14/20 5:09 AM, Alex Bennée wrote: > +if "system" in args.qemu: > +cmd = "%s %s %s -s -S" % (args.qemu, args.qargs, args.binary) > +else: > +cmd = "%s %s -g 1234 %s" % (args.qemu, args.qargs, args.binary) Oh, hard-coding of the port is going to cause failures. Multiple users on the system both running qemu tests. Parallel make. Anything. I think we should really consider adding support for debugging over unix sockets or named pipes, both of which work well with the file system to avoid conflict. r~
Re: [PATCH v5 18/22] tests/tcg/aarch64: add a gdbstub testcase for SVE registers
On 1/14/20 5:09 AM, Alex Bennée wrote:
> A very simple test case which sets and reads SVE registers while
> running a test case. We don't really need to compile a SVE binary for
> this case but we will later so keep it simple for now.
>
> Signed-off-by: Alex Bennée
>
> ---
> v5
> - properly plumb in
> - skip if fails to connect
> ---
> tests/.gitignore | 1 +
> tests/tcg/aarch64/Makefile.target | 15 +
> tests/tcg/aarch64/gdbstub/test-sve.py | 81 +++
> 3 files changed, 97 insertions(+)
> create mode 100644 tests/tcg/aarch64/gdbstub/test-sve.py
I don't understand how this is working. What's the process that provides the
container for the register state?
I would have expected *some* binary to be used, even if it is only "int main()
{ return 0; }".
r~
Re: [PATCH v5 19/22] tests/tcg/aarch64: add SVE iotcl test
On 1/14/20 5:09 AM, Alex Bennée wrote:
> +int main(int argc, char **argv)
> +{
> +unsigned int sve_feature = (get_cpu_reg(ID_AA64PFR0_EL1) >> 32) & 0xf;
> +/* Exit early if we don't support SVE at all */
> +if (sve_feature == 0x1) {
> +/* we also need to probe for the ioctl support */
> +if (getauxval(AT_HWCAP) & HWCAP_SVE) {
You should only probe hwcap.
r!
[PATCH 2/2] virtio-balloon: Reject qmp_balloon during hot-unplug
Hot-unplug takes some time due to communication with the guest.
Do not change the device while freeing up resources.
Signed-off-by: Julia Suvorova
---
balloon.c | 2 +-
hw/virtio/virtio-balloon.c | 9 -
include/sysemu/balloon.h | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/balloon.c b/balloon.c
index f104b42961..998ec53a0f 100644
--- a/balloon.c
+++ b/balloon.c
@@ -119,5 +119,5 @@ void qmp_balloon(int64_t target, Error **errp)
}
trace_balloon_event(balloon_opaque, target);
-balloon_event_fn(balloon_opaque, target);
+balloon_event_fn(balloon_opaque, target, errp);
}
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 57f3b9f22d..0fa4e4454b 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -717,12 +717,19 @@ static void virtio_balloon_stat(void *opaque, BalloonInfo
*info)
VIRTIO_BALLOON_PFN_SHIFT);
}
-static void virtio_balloon_to_target(void *opaque, ram_addr_t target)
+static void virtio_balloon_to_target(void *opaque, ram_addr_t target,
+ Error **errp)
{
+DeviceState *bus_dev = qdev_get_bus_device(DEVICE(opaque));
VirtIOBalloon *dev = VIRTIO_BALLOON(opaque);
VirtIODevice *vdev = VIRTIO_DEVICE(dev);
ram_addr_t vm_ram_size = get_current_ram_size();
+if (bus_dev && bus_dev->pending_deleted_event) {
+error_setg(errp, "Hot-unplug of %s is in progress", vdev->name);
+return;
+}
+
if (target > vm_ram_size) {
target = vm_ram_size;
}
diff --git a/include/sysemu/balloon.h b/include/sysemu/balloon.h
index aea0c44985..b3a09ca946 100644
--- a/include/sysemu/balloon.h
+++ b/include/sysemu/balloon.h
@@ -17,7 +17,7 @@
#include "exec/cpu-common.h"
#include "qapi/qapi-types-misc.h"
-typedef void (QEMUBalloonEvent)(void *opaque, ram_addr_t target);
+typedef void (QEMUBalloonEvent)(void *opaque, ram_addr_t target, Error **errp);
typedef void (QEMUBalloonStatus)(void *opaque, BalloonInfo *info);
int qemu_add_balloon_handler(QEMUBalloonEvent *event_func,
--
2.24.1
[PATCH 0/2] virtio-balloon: Reject qmp_balloon during hot-unplug
Julia Suvorova (2): qdev: Introduce qdev_get_bus_device virtio-balloon: Reject qmp_balloon during hot-unplug balloon.c | 2 +- hw/core/qdev.c | 5 + hw/pci-bridge/pci_expander_bridge.c | 4 +++- hw/scsi/scsi-bus.c | 4 +++- hw/usb/bus.c| 4 +++- hw/usb/dev-smartcard-reader.c | 32 + hw/virtio/virtio-balloon.c | 9 +++- hw/virtio/virtio-pci.c | 16 +-- include/hw/qdev-core.h | 2 ++ include/sysemu/balloon.h| 2 +- 10 files changed, 64 insertions(+), 16 deletions(-) -- 2.24.1
[PATCH 1/2] qdev: Introduce qdev_get_bus_device
For bus devices, it is useful to be able to handle the parent device.
Signed-off-by: Julia Suvorova
---
hw/core/qdev.c | 5 +
hw/pci-bridge/pci_expander_bridge.c | 4 +++-
hw/scsi/scsi-bus.c | 4 +++-
hw/usb/bus.c| 4 +++-
hw/usb/dev-smartcard-reader.c | 32 +
hw/virtio/virtio-pci.c | 16 +--
include/hw/qdev-core.h | 2 ++
7 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 9f1753f5cf..ad8226e240 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -114,6 +114,11 @@ void qdev_set_parent_bus(DeviceState *dev, BusState *bus)
}
}
+DeviceState *qdev_get_bus_device(const DeviceState *dev)
+{
+return dev->parent_bus ? dev->parent_bus->parent : NULL;
+}
+
/* Create a new device. This only initializes the device state
structure and allows properties to be set. The device still needs
to be realized. See qdev-core.h. */
diff --git a/hw/pci-bridge/pci_expander_bridge.c
b/hw/pci-bridge/pci_expander_bridge.c
index 0592818447..63a6c07406 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -125,9 +125,11 @@ static char *pxb_host_ofw_unit_address(const SysBusDevice
*dev)
assert(position >= 0);
pxb_dev_base = DEVICE(pxb_dev);
-main_host = PCI_HOST_BRIDGE(pxb_dev_base->parent_bus->parent);
+main_host = PCI_HOST_BRIDGE(qdev_get_bus_device(pxb_dev_base));
main_host_sbd = SYS_BUS_DEVICE(main_host);
+g_assert(main_host);
+
if (main_host_sbd->num_mmio > 0) {
return g_strdup_printf(TARGET_FMT_plx ",%x",
main_host_sbd->mmio[0].addr, position + 1);
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index ad0e7f6d88..3d9497882b 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -1558,10 +1558,12 @@ void scsi_device_purge_requests(SCSIDevice *sdev,
SCSISense sense)
static char *scsibus_get_dev_path(DeviceState *dev)
{
SCSIDevice *d = SCSI_DEVICE(dev);
-DeviceState *hba = dev->parent_bus->parent;
+DeviceState *hba = qdev_get_bus_device(dev);
char *id;
char *path;
+g_assert(hba);
+
id = qdev_get_dev_path(hba);
if (id) {
path = g_strdup_printf("%s/%d:%d:%d", id, d->channel, d->id, d->lun);
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index a6522f5429..26bf794315 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -587,9 +587,11 @@ static void usb_bus_dev_print(Monitor *mon, DeviceState
*qdev, int indent)
static char *usb_get_dev_path(DeviceState *qdev)
{
USBDevice *dev = USB_DEVICE(qdev);
-DeviceState *hcd = qdev->parent_bus->parent;
+DeviceState *hcd = qdev_get_bus_device(qdev);
char *id = NULL;
+g_assert(hcd);
+
if (dev->flags & (1 << USB_DEV_FLAG_FULL_PATH)) {
id = qdev_get_dev_path(hcd);
}
diff --git a/hw/usb/dev-smartcard-reader.c b/hw/usb/dev-smartcard-reader.c
index 4568db2568..fbb3599ddd 100644
--- a/hw/usb/dev-smartcard-reader.c
+++ b/hw/usb/dev-smartcard-reader.c
@@ -1185,10 +1185,12 @@ void ccid_card_send_apdu_to_guest(CCIDCardState *card,
uint8_t *apdu, uint32_t len)
{
DeviceState *qdev = DEVICE(card);
-USBDevice *dev = USB_DEVICE(qdev->parent_bus->parent);
+USBDevice *dev = USB_DEVICE(qdev_get_bus_device(qdev));
USBCCIDState *s = USB_CCID_DEV(dev);
Answer *answer;
+g_assert(dev);
+
if (!ccid_has_pending_answers(s)) {
DPRINTF(s, 1, "CCID ERROR: got an APDU without pending answers\n");
return;
@@ -1208,9 +1210,11 @@ void ccid_card_send_apdu_to_guest(CCIDCardState *card,
void ccid_card_card_removed(CCIDCardState *card)
{
DeviceState *qdev = DEVICE(card);
-USBDevice *dev = USB_DEVICE(qdev->parent_bus->parent);
+USBDevice *dev = USB_DEVICE(qdev_get_bus_device(qdev));
USBCCIDState *s = USB_CCID_DEV(dev);
+g_assert(dev);
+
ccid_on_slot_change(s, false);
ccid_flush_pending_answers(s);
ccid_reset(s);
@@ -1219,9 +1223,11 @@ void ccid_card_card_removed(CCIDCardState *card)
int ccid_card_ccid_attach(CCIDCardState *card)
{
DeviceState *qdev = DEVICE(card);
-USBDevice *dev = USB_DEVICE(qdev->parent_bus->parent);
+USBDevice *dev = USB_DEVICE(qdev_get_bus_device(qdev));
USBCCIDState *s = USB_CCID_DEV(dev);
+g_assert(dev);
+
DPRINTF(s, 1, "CCID Attach\n");
return 0;
}
@@ -1229,9 +1235,11 @@ int ccid_card_ccid_attach(CCIDCardState *card)
void ccid_card_ccid_detach(CCIDCardState *card)
{
DeviceState *qdev = DEVICE(card);
-USBDevice *dev = USB_DEVICE(qdev->parent_bus->parent);
+USBDevice *dev = USB_DEVICE(qdev_get_bus_device(qdev));
USBCCIDState *s = USB_CCID_DEV(dev);
+g_assert(dev);
+
DPRINTF(s, 1, "CCID Detach\n");
if (ccid_card_inserted(s)) {
ccid_on_slot_change(s, false);
@@ -1242,9 +1250,11 @@
Re: [PATCH v5 17/22] tests/guest-debug: add a simple test runner
On 1/14/20 5:09 AM, Alex Bennée wrote: > +gdb_cmd = "%s %s -ex 'target remote localhost:1234' -x %s" % (args.gdb, > args.binary, args.test) It'd be nice to wrap this line. Otherwise, Reviewed-by: Richard Henderson r~
Re: [PATCH v5 16/22] configure: allow user to specify what gdb to use
On 1/14/20 5:09 AM, Alex Bennée wrote: > + --with-gdb=GBB-path gdb to use for gdbstub tests [$gdb_bin] s/GBB/GDB/ Reviewed-by: Richard Henderson r~
Re: [PATCH v5 15/22] tests/tcg/aarch64: userspace system register test
On 1/14/20 5:09 AM, Alex Bennée wrote: > This tests a bunch of registers that the kernel allows userspace to > read including the CPUID registers. We need a SVE aware compiler as we > are testing the id_aa64zfr0_el1 register in the set. > > Signed-off-by: Alex Bennée > Message-Id: <20190205190224.2198-7-alex.ben...@linaro.org> > > --- > vgdbstub > - don't build unless using docker or CROSS_CC_HAS_SVE > --- > tests/tcg/aarch64/sysregs.c | 172 ++ > tests/tcg/aarch64/Makefile.target | 6 ++ > 2 files changed, 178 insertions(+) > create mode 100644 tests/tcg/aarch64/sysregs.c Reviewed-by: Richard Henderson r~
Re: [PATCH v5 13/22] tests/tcg: add a configure compiler check for ARMv8.1 and SVE
On 1/14/20 5:09 AM, Alex Bennée wrote: > + > +# Test for compiler features for optional tests. We only do this > +# for cross compilers because ensuring the docker containers based > +# compilers is a requirememt for adding a new test that needs a > +# compiler feature. > +case $target in > +aarch64-*) > +if do_compiler "$target_compiler" $target_compiler_cflags \ > + -march=armv8.1-a+sve -o $TMPE $TMPC; then > +echo "CROSS_CC_HAS_SVE=y" >> $config_target_mak > +fi > +;; > +esac Reviewed-by: Richard Henderson What's the status of the docker containers wrt the BTI and MTE extensions? ;-) We already have tests for those, disabled. I currently edit the makefile when I want to test them explicitly. r~
Re: [PATCH v5 09/22] target/arm: prepare for multiple dynamic XMLs
On 1/14/20 5:09 AM, Alex Bennée wrote: > We will want to generate similar dynamic XML for gdbstub support of > SVE registers (the upstream doesn't use XML). To that end lightly > rename a few things to make the distinction. > > Signed-off-by: Alex Bennée > --- > target/arm/cpu.h | 20 +--- > target/arm/gdbstub.c | 30 +++--- > target/arm/helper.c | 4 ++-- > 3 files changed, 30 insertions(+), 24 deletions(-) It seems to me, that if vg were present in the xml, and honored by gdb, that the xml for the rest of the registers *could* describe the maximum register width as opposed to the current register width. At which point this wouldn't need to be dynamic at all -- merely have a comment next to ARM_MAX_VQ that changes must be reflected in the gdb xml file too. Which I expect to never happen. But again, this is how gdb works today, so Acked-by: Richard Henderson r~
Re: [PATCH v5 12/22] target/arm: generate xml description of our SVE registers
On 1/14/20 5:09 AM, Alex Bennée wrote: > We also expose a the helpers to read/write the the registers. > > Signed-off-by: Alex Bennée > > --- > v2 > - instead of zNpM expose zN at sve_max_vq width > - wrap union in union q(us), d(usf), s(usf), h(usf), b(us) > v3 > - add a vg pseudo register for current width > - spacing fixes > - use switch/case for whole group > - drop fpsr_pos marker > - remove unused variables > v4 > - const-ify vec_lanes > - drop vg Sigh. This still feels like we're coding to a gdb bug. I assert that vg (or equivalent information) is required for the job to be done correctly. It's a per-core and therefore, for user-space, per-thread quantity. We cannot possibly be "changing targets" for the "thread N" command. I'll give you an Acked-by: Richard Henderson because I recognize that this is how gdb works today, but I don't like it. r~
Re: Semihosting, arm, riscv, ppc and common code
> On 15 Jan 2020, at 23:28, Richard Henderson > wrote: > > For risc-v, the odd nop-full semi-hosting call sequence That unfortunate call sequence was the least worst compromise that the RISC-V design team could agree on. :-( The actual problem was that the RISC-V instruction set has a single BREAK op code, without any way to parametrise it, and they refused to spend another op code for an extra BREAK. > was chosen to work with > jtag debuggers on real silicon. Yes, I know at least two, SEGGER J-Link of OpenOCD. But again, there is nothing in the silicon related to the odd call sequence or the ABI, everything is implemented in the debuggers. The silicon has only to break to the debugger, then it's up to the debugger to decide if this is a semihosting call or a regular break. > ... they did have the opportunity to do better, and did not. I don't know why you present Arm semihosting as a disaster. It is not perfect, but it is functional, and common unit tests use only a small subset of the calls. And there is no 'window of opportunity', if the RISC-V guys will ever want to reinvent the wheel and come with an official 'RISC-V semihosting' specs, they can do it at any time, and this will have no impact on existing devices, everything will continue to work as before, only the debuggers/emulators will need to be upgraded. But the only immediate effect such a move will have is that software efforts in test frameworks will be increased, to support another protocol, while the advantages will be minimal. Regards, Liviu
Re: [PATCH v2 41/86] hw/hppa/machine: Correctly check the firmware is in PDC range
On Wed, 15 Jan 2020, Philippe Mathieu-Daudé wrote:
On 1/15/20 7:15 PM, BALATON Zoltan wrote:
On Wed, 15 Jan 2020, Igor Mammedov wrote:
From: Philippe Mathieu-Daudé
The firmware has to reside in the PDC range. If the Elf file
expects to load it below FIRMWARE_START, it is incorrect,
regardless the RAM size.
Acked-by: Helge Deller
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..6775d87 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -155,7 +155,7 @@ static void machine_hppa_init(MachineState *machine)
qemu_log_mask(CPU_LOG_PAGE, "Firmware loaded at 0x%08" PRIx64
"-0x%08" PRIx64 ", entry at 0x%08" PRIx64 ".\n",
firmware_low, firmware_high, firmware_entry);
- if (firmware_low < ram_size || firmware_high >= FIRMWARE_END) {
+ if (firmware_low < FIRMWARE_START || firmware_high >= FIRMWARE_END) {
error_report("Firmware overlaps with memory or IO space");
exit(1);
Should this also be EXIT_FAILURE like in other places when you're changing
the line nearby?
I didn't changed this line, this seems unrelated to the patch purpose.
Fair enough. Just thought because there was patch 85/86 making that change
to keep consistency. Maybe you can change this in that patch but I don't
really mind just spotted it.
Regards,
BALATON Zoltan
Re: [PATCH v8 13/13] linux-user: Add support for TYPE_LONG and TYPE_ULONG in do_ioctl()
Le 15/01/2020 à 20:36, Filip Bozuta a écrit : > Function "do_ioctl()" located in file "syscall.c" was missing > an option for TYPE_LONG and TYPE_ULONG. This caused some ioctls > to not be recognised because they had the third argument that was > of type 'long' or 'unsigned long'. > > For example: > > Since implemented ioctls RTC_IRQP_SET and RTC_EPOCH_SET > are of type IOW(writing type) that have unsigned long as > their third argument, they were not recognised in QEMU > before the changes of this patch. > > Signed-off-by: Filip Bozuta > --- > linux-user/syscall.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index a3993a2..2ba2c5c 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -5176,6 +5176,8 @@ static abi_long do_ioctl(int fd, int cmd, abi_long arg) > break; > case TYPE_PTRVOID: > case TYPE_INT: > +case TYPE_LONG: > +case TYPE_ULONG: > ret = get_errno(safe_ioctl(fd, ie->host_cmd, arg)); > break; > case TYPE_PTR: > Reviewed-by: Laurent Vivier I will move this patch at the beginning of the series when I'll merge it. Thanks, Laurent
Re: [PATCH] m68k: Fix regression causing Single-Step via GDB/RSP to not single step
On 1/15/20 1:03 AM, Laurent Vivier wrote:
> +if (dc->base.singlestep_enabled) {
> +tcg_gen_movi_i32(QREG_PC, dc->pc);
> +gen_helper_raise_exception(cpu_env, tcg_const_i32(EXCP_DEBUG));
This leaks the temporary, and so not quite ideal. It would be of more concern
if the rest of the m68k port was audited, so that you could turn on leak
detection.
I would suggest routing all calls to gen_helper_raise_exception through a
function (gen_raise_exception, usually), which takes an int argument, and does
all of the TCGv_i32 management internally.
But otherwise,
Reviewed-by: Richard Henderson
r~
Re: [PATCH v7 13/13] linux-user: Add support for TYPE_LONG and TYPE_ULONG in do_ioctl()
Le 15/01/2020 à 20:12, Filip Bozuta a écrit : > Function "do_ioctl()" located in file "syscall.c" was missing > an option for TYPE_LONG and TYPE_ULONG. This caused some ioctls > to not be recognised because they had the third argument that was > of type 'long' or 'unsigned long'. > > For example: > > Since implemented ioctls RTC_IRQP_SET and RTC_EPOCH_SET > are of type IOW(writing type) that have unsigned long as > their third argument, they were not recognised in QEMU > before the changes of this patch. > > Signed-off-by: Filip Bozuta > --- > linux-user/syscall.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index a3993a2..2ba2c5c 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -5176,6 +5176,8 @@ static abi_long do_ioctl(int fd, int cmd, abi_long arg) > break; > case TYPE_PTRVOID: > case TYPE_INT: > +case TYPE_LONG: > +case TYPE_ULONG: > ret = get_errno(safe_ioctl(fd, ie->host_cmd, arg)); > break; > case TYPE_PTR: > Reviewed-by: Laurent Vivier
Re: [PATCH 08/12] linux-user: Add support for setting alsa timer enhanced read using ioctl
Le 15/01/2020 à 20:17, Filip Bozuta a écrit : > > On 15.1.20. 17:37, Arnd Bergmann wrote: >> On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier wrote: >>> Le 15/01/2020 à 17:18, Arnd Bergmann a écrit : On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta wrote: > This patch implements functionality of following ioctl: > > SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read > > Sets enhanced time read which is used for reading time with > timestamps > and events. The third ioctl's argument is a pointer to an > 'int'. Enhanced > reading is set if the third argument is different than 0, > otherwise normal > time reading is set. > > Implementation notes: > > Because the implemented ioctl has 'int' as its third argument, > the > implementation was straightforward. > > Signed-off-by: Filip Bozuta I think this one is wrong when you go between 32-bit and 64-bit >>> kernel uses an "int" and "int" is always 32bit. >>> The problem is most likely with timespec I think. >>> targets, and it gets worse with the kernel patches that just got merged for linux-5.5, which extends the behavior to deal with 64-bit time_t on 32-bit architectures. Please have a look at https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=80fe7430c70859 >>> Yes, we already had the same kind of problem with SIOCGSTAMP and >>> SIOCGSTAMPNS. >>> >>> Do the kernel patches add new ioctl numbers to differentiate 32bit and >>> 64bit time_t? >> Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument >> is a pure 'int' that decides what format you get when you 'read' from the >> same file descriptor. >> >> For emulating 64-bit on 32-bit kernels, you have to use the new >> SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on >> 64-bit kernels, you probably have to return -ENOTTY to >> SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to >> emulate the read() behavior. >> When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64, >> you can translate that into the 64-bit >> SNDRV_TIMER_IOCTL_TREAD_OLD. >> >> Arnd > > > Thank you for bringing this up to my attention. Unfortunately i have > some duties of academic nature in next month so i won't have much time > fix this bug. I will try to fix this as soon as possible. Could you at least to try to have a mergeable series before you have to stop to work on this? You can only manage the case before the change reported by Arnd (I will manage the new case myself later). Thanks, Laurent
Re: [PATCH v3 1/3] target/riscv: Fix tb->flags FS status
On 1/14/20 8:28 PM, Alistair Francis wrote:
> On Wed, Jan 15, 2020 at 4:18 PM wrote:
>>
>> It was found that running libquantum on riscv-linux qemu produced an
>> incorrect result. After investigation, FP registers are not saved
>> during context switch due to incorrect mstatus.FS.
>>
>> In current implementation tb->flags merges all non-disabled state to
>> dirty. This means the code in mark_fs_dirty in translate.c that
>> handles initial and clean states is unreachable.
>>
>> This patch fixes it and is successfully tested with:
>> libquantum
>>
>> Thanks to Richard for pointing out the actual bug.
>>
>> v3: remove the redundant condition
>> v2: root cause FS problem
>>
>> Suggested-by: Richard Henderson
>> Signed-off-by: ShihPo Hung
>> Reviewed-by: Richard Henderson
>> ---
>> target/riscv/cpu.h | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
>> index e59343e..de0a8d8 100644
>> --- a/target/riscv/cpu.h
>> +++ b/target/riscv/cpu.h
>> @@ -293,10 +293,7 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState
>> *env, target_ulong *pc,
>> #ifdef CONFIG_USER_ONLY
>> *flags = TB_FLAGS_MSTATUS_FS;
>> #else
>> -*flags = cpu_mmu_index(env, 0);
>> -if (riscv_cpu_fp_enabled(env)) {
>> -*flags |= TB_FLAGS_MSTATUS_FS;
>> -}
>> +*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
>
> I don't think this is right, you should use the riscv_cpu_fp_enabled()
> function.
>
> Right now it's the same as env->mstatus & MSTATUS_FS but when the
> Hypervisor extension goes in riscv_cpu_fp_enabled() will be more
> complex.
Hmm. Are you sure something like
flags |= riscv_cpu_effective_mstatus(env) & MSTATUS_FS;
wouldn't be more appropriate for the hypervisor extension?
I guess I should have another browse through your hv patchset, but I worry now
about bare uses of env->mstatus, if they no longer mean what they appear to
mean.
r~
Re: [PATCH v2 67/86] ppc:ppc440_bamboo/sam460ex: use memdev for RAM
On Wed, 15 Jan 2020, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov
---
CC: bala...@eik.bme.hu
CC: da...@gibson.dropbear.id.au
CC: qemu-...@nongnu.org
---
include/hw/ppc/ppc4xx.h | 2 +-
hw/ppc/ppc440_bamboo.c | 3 ++-
hw/ppc/ppc4xx_devs.c| 9 +++--
hw/ppc/sam460ex.c | 3 ++-
4 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 103c875..f0bef46 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -42,7 +42,7 @@ enum {
qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
uint32_t dcr_base, int has_ssr, int has_vr);
-void ppc4xx_sdram_prep(ram_addr_t ram_size, int nr_banks,
+void ppc4xx_sdram_prep(MemoryRegion *ram, int nr_banks,
MemoryRegion ram_memories[],
hwaddr ram_bases[], hwaddr ram_sizes[],
const ram_addr_t sdram_bank_sizes[]);
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index c162598..cb4a1ad 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -202,7 +202,7 @@ static void bamboo_init(MachineState *machine)
/* SDRAM controller */
memset(ram_bases, 0, sizeof(ram_bases));
memset(ram_sizes, 0, sizeof(ram_sizes));
-ppc4xx_sdram_prep(ram_size, PPC440EP_SDRAM_NR_BANKS, ram_memories,
+ppc4xx_sdram_prep(machine->ram, PPC440EP_SDRAM_NR_BANKS, ram_memories,
ram_bases, ram_sizes, ppc440ep_sdram_bank_sizes);
/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
ppc4xx_sdram_init(env, pic[14], PPC440EP_SDRAM_NR_BANKS, ram_memories,
@@ -289,6 +289,7 @@ static void bamboo_machine_init(MachineClass *mc)
mc->desc = "bamboo";
mc->init = bamboo_init;
mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440epb");
+mc->default_ram_id = "ppc4xx.sdram";
}
DEFINE_MACHINE("bamboo", bamboo_machine_init)
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index 92d33a4..9c3762d 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -673,13 +673,12 @@ void ppc4xx_sdram_init (CPUPPCState *env, qemu_irq irq,
int nbanks,
* The 4xx SDRAM controller supports a small number of banks, and each bank
* must be one of a small set of sizes. The number of banks and the supported
* sizes varies by SoC. */
-void ppc4xx_sdram_prep(ram_addr_t ram_size, int nr_banks,
+void ppc4xx_sdram_prep(MemoryRegion *ram, int nr_banks,
Maybe you need to also update the comment above which talks about
'ram_size' that you don't have any more.
MemoryRegion ram_memories[],
hwaddr ram_bases[], hwaddr ram_sizes[],
const ram_addr_t sdram_bank_sizes[])
{
-MemoryRegion *ram = g_malloc0(sizeof(*ram));
-ram_addr_t size_left = ram_size;
+ram_addr_t size_left = memory_region_size(ram);
ram_addr_t base = 0;
ram_addr_t bank_size;
int last_bank = 0;
@@ -704,7 +703,7 @@ void ppc4xx_sdram_prep(ram_addr_t ram_size, int nr_banks,
}
if (size_left) {
-ram_addr_t used_size = ram_size - size_left;
+ram_addr_t used_size = memory_region_size(ram) - size_left;
GString *s = g_string_new(NULL);
for (i = 0; sdram_bank_sizes[i]; i++) {
@@ -721,8 +720,6 @@ void ppc4xx_sdram_prep(ram_addr_t ram_size, int nr_banks,
exit(EXIT_FAILURE);
}
-memory_region_allocate_system_memory(ram, NULL, "ppc4xx.sdram", ram_size);
-
for (i = 0; i <= last_bank; i++) {
Can this for cycle now completely merged with the one above and init the
alias regions also there?
Regards,
BALATON Zoltan
char name[32];
snprintf(name, sizeof(name), "ppc4xx.sdram%d", i);
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index ec7ac1f..8d27a3f 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -324,7 +324,7 @@ static void sam460ex_init(MachineState *machine)
/* SDRAM controller */
/* put all RAM on first bank because board has one slot
* and firmware only checks that */
-ppc4xx_sdram_prep(machine->ram_size, 1, ram_memories, ram_bases, ram_sizes,
+ppc4xx_sdram_prep(machine->ram, 1, ram_memories, ram_bases, ram_sizes,
ppc460ex_sdram_bank_sizes);
/* FIXME: does 460EX have ECC interrupts? */
@@ -483,6 +483,7 @@ static void sam460ex_machine_init(MachineClass *mc)
mc->init = sam460ex_init;
mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("460exb");
mc->default_ram_size = 512 * MiB;
+mc->default_ram_id = "ppc4xx.sdram";
}
DEFINE_MACHINE("sam460ex", sam460ex_machine_init)
Re: [PATCH v2 66/86] ppc/{ppc440_bamboo,sam460x}: drop RAM size fixup
Subject line is still wrong, it's sam460ex not sam460x. Also you change
ppc:whatever to ppc/whatever here but left : as path separator in all
other patches. This is not consistent with other commits where the tag in
the title is usually a path of the changed part or in this case could be
ppc/ arm/ etc. Colon as path separator looks weird so I think this change
should be done for all patches to match other commits not just this one,
On Wed, 15 Jan 2020, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported or sometimes
crash like this:
%QEMU -M bamboo -m 1
exec.c:1926: find_ram_offset: Assertion `size != 0' failed.
Aborted (core dumped)
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
That also fixes crash issue, since wrongly calculated size
isn't used to allocate RAM
Signed-off-by: Igor Mammedov
---
v2:
* s/ppc4xx_sdram_adjust/ppc4xx_sdram_prep/
(BALATON Zoltan )
Thanks but prep is not a good name in PPC context as one of the arch
standards is also called that (PowerPC Reference Platform or PReP) so
using that here is ambiguous. Better spell it out or call it something
else (such as ppc4xx_sdram_banks).
* print possible valid ram size id not all RAM was distributed
* initialize ram_bases/ram_bases at the same time we are checking
that user supplied RAM would fit available banks and drop nested
loop that were duplicating the same calculations.
* coincidentally fix crash when -m is less than minimal bank size
CC: bala...@eik.bme.hu
CC: da...@gibson.dropbear.id.au
CC: qemu-...@nongnu.org
---
include/hw/ppc/ppc4xx.h | 9
hw/ppc/ppc440_bamboo.c | 11 --
hw/ppc/ppc4xx_devs.c| 56 +
hw/ppc/sam460ex.c | 5 ++---
4 files changed, 39 insertions(+), 42 deletions(-)
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 7d82259..103c875 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -42,11 +42,10 @@ enum {
qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
uint32_t dcr_base, int has_ssr, int has_vr);
-ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
- MemoryRegion ram_memories[],
- hwaddr ram_bases[],
- hwaddr ram_sizes[],
- const ram_addr_t sdram_bank_sizes[]);
+void ppc4xx_sdram_prep(ram_addr_t ram_size, int nr_banks,
+ MemoryRegion ram_memories[],
+ hwaddr ram_bases[], hwaddr ram_sizes[],
+ const ram_addr_t sdram_bank_sizes[]);
void ppc4xx_sdram_init (CPUPPCState *env, qemu_irq irq, int nbanks,
MemoryRegion ram_memories[],
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index b782641..c162598 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -158,7 +158,6 @@ static void main_cpu_reset(void *opaque)
static void bamboo_init(MachineState *machine)
{
-ram_addr_t ram_size = machine->ram_size;
const char *kernel_filename = machine->kernel_filename;
const char *kernel_cmdline = machine->kernel_cmdline;
const char *initrd_filename = machine->initrd_filename;
@@ -203,10 +202,8 @@ static void bamboo_init(MachineState *machine)
/* SDRAM controller */
memset(ram_bases, 0, sizeof(ram_bases));
memset(ram_sizes, 0, sizeof(ram_sizes));
-ram_size = ppc4xx_sdram_adjust(ram_size, PPC440EP_SDRAM_NR_BANKS,
- ram_memories,
- ram_bases, ram_sizes,
- ppc440ep_sdram_bank_sizes);
+ppc4xx_sdram_prep(ram_size, PPC440EP_SDRAM_NR_BANKS, ram_memories,
+ ram_bases, ram_sizes, ppc440ep_sdram_bank_sizes);
/* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
ppc4xx_sdram_init(env, pic[14], PPC440EP_SDRAM_NR_BANKS, ram_memories,
ram_bases, ram_sizes, 1);
@@ -268,7 +265,7 @@ static void bamboo_init(MachineState *machine)
/* Load initrd. */
if (initrd_filename) {
initrd_size = load_image_targphys(initrd_filename, RAMDISK_ADDR,
- ram_size - RAMDISK_ADDR);
+ machine->ram_size - RAMDISK_ADDR);
if (initrd_size < 0) {
error_report("could not load ram disk '%s' at %x",
@@ -279,7 +276,7 @@ static void bamboo_init(MachineState *machine)
/* If we're loading a kernel directly, we must load the device tree too. */
if (kernel_filename) {
-if (bamboo_load_device_tree(FDT_ADDR, ram_size, RAMDISK_ADDR,
+if (bamboo_load_device_tree(FDT_ADDR,
[Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c
I've created a new patches for getdents bug
https://sourceware.org/bugzilla/show_bug.cgi?id=23960 and I can't
reproduce python permissions issue anymore. My mips image built with
qemu user works perfect.
** Bug watch added: Sourceware.org Bugzilla #23960
https://sourceware.org/bugzilla/show_bug.cgi?id=23960
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1858461
Title:
Please refactor linux-user/mips/cpu_loop.c
Status in QEMU:
New
Bug description:
Hello. I am working with qemu on test images. I've added a new syscall
(436) to qemu but received ENOSYS from mips application.
Please open "linux-user/mips/cpu_loop.c". I've added at the end of
"mips_syscall_args" the following:
```
MIPS_SYS(sys_getdents64_x32, 3)
```
But
```
syscall_num = env->active_tc.gpr[2] - 4000;
if (syscall_num >= sizeof(mips_syscall_args)) {
ret = -TARGET_ENOSYS;
```
returns -TARGET_ENOSYS
We can see that "linux-user/mips/cpu_loop.c" differs a lot from
"linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc.
Can you please refactor mips cpu loop in the same way as arm? Thank
you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1858461/+subscriptions
Re: [PATCH 08/12] linux-user: Add support for setting alsa timer enhanced read using ioctl
Le 15/01/2020 à 20:51, Arnd Bergmann a écrit : > On Wed, Jan 15, 2020 at 8:17 PM Filip Bozuta wrote: >> On 15.1.20. 17:37, Arnd Bergmann wrote: >>> On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier wrote: Le 15/01/2020 à 17:18, Arnd Bergmann a écrit : > On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta > wrote: Do the kernel patches add new ioctl numbers to differentiate 32bit and 64bit time_t? >>> >>> Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument >>> is a pure 'int' that decides what format you get when you 'read' from the >>> same file descriptor. >>> >>> For emulating 64-bit on 32-bit kernels, you have to use the new >>> SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on >>> 64-bit kernels, you probably have to return -ENOTTY to >>> SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to >>> emulate the read() behavior. >>> When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64, >>> you can translate that into the 64-bit >>> SNDRV_TIMER_IOCTL_TREAD_OLD. > >> >> Thank you for bringing this up to my attention. Unfortunately i have >> some duties of academic nature in next month so i won't have much time >> fix this bug. I will try to fix this as soon as possible. > > One more thing: I just realized it gets worse when emulating cross-endian, > as then even without calling SNDRV_TIMER_IOCTL_TREAD, reading > data from /dev/snd/timer requires byteswapping the two words. We already have this case with netlink and we are able to translate data on the fly. Thanks, Laurent
Re: Semihosting, arm, riscv, ppc and common code
On 1/15/20 2:01 AM, Alex Bennée wrote: > Hmm, I'm not so sure. QEMU tries to emulate real HW although I > appreciate that is a somewhat loose definition once you get to things > like -M virt and other such SW like abstractions. Is semihosting even > going to be a thing on real RiscV/Power silicon? For risc-v, the odd nop-full semi-hosting call sequence was chosen to work with jtag debuggers on real silicon. As for the rest of the abi, the stuff after the debugger/emulator has gotten control, they did have the opportunity to do better, and did not. r~
Re: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
Patchew URL:
https://patchew.org/QEMU/1579100861-73692-1-git-send-email-imamm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
Type: series
Message-id: 1579100861-73692-1-git-send-email-imamm...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Switched to a new branch 'test'
2d14010 numa: remove deprecated implicit RAM distribution between nodes
bac70b8 numa: make exit() usage consistent
53861b0 tests:numa-test: use explicit memdev to specify node RAM
56297b3 tests:numa-test: make top level args dynamic and g_autofree(cli)
cleanups
3e6445f numa: forbid '-numa node, mem' for 5.0 and newer machine types
d70a9f2 hostmem: fix strict bind policy
92d7974 hostmem: introduce "prealloc-threads" property
4fd9cfe make mem_path local variable
74d0083 exec: drop bogus mem_path from qemu_ram_alloc_from_fd()
afb329b exec: cleanup qemu_minrampagesize()/qemu_maxrampagesize()
7dfb5ed post conversion default_ram_id cleanup
f7cb074 remove no longer used memory_region_allocate_system_memory()
738f1a3 sparc:niagara: use memdev for RAM
e120e67 sparc:sun4m: use memdev for RAM
24b259e sparc:leon3: use memdev for RAM
4904e75 ppc:virtex_ml507: use memdev for RAM
65dbc2c ppc:virtex_ml507: remove unused arguments
ab63a98 ppc:spapr: use memdev for RAM
b4d5ea5 ppc:prep: use memdev for RAM
036f996 ppc:ppc440_bamboo/sam460ex: use memdev for RAM
73d3d69 ppc/{ppc440_bamboo,sam460x}: drop RAM size fixup
4525782 ppc:ppc405_boards: use memdev for RAM
53365b4 ppc:ppc405_boards: add RAM size checks
f025b4f ppc:pnv: use memdev for RAM
0329900 ppc:mac_oldworld: use memdev for RAM
92fb2bc ppc:mac_newworld: use memdev for RAM
eaab307 ppc:e500: use memdev for RAM
5bc78d1 ppc:e500: drop RAM size fixup
b959a8d mips:mips_r4k: use memdev for RAM
4fa91f4 mips:mips_mipssim: use memdev for RAM
f726ba3 mips:mips_malta: use memdev for RAM
e50c092 mips:mips_jazz: use memdev for RAM
d9a07ca mips:mips_fulong2e: use memdev for RAM
05d6a5e mips:mips_fulong2e: drop RAM size fixup
73027e0 mips:boston-cube: use memdev for RAM
eb6e93f m68k:next-cube: use memdev for RAM
3ad54a8 m68k:mcf5208: use memdev for RAM
31b4fbd m68k:an5206: use memdev for RAM
17a90ad lm32:milkymist: use memdev for RAM
934be97 lm32:lm32_boards: use memdev for RAM
debb3a4 x86:pc: use memdev for RAM
64a0031 x86:microvm: use memdev for RAM
c14b753 hppa: use memdev for RAM
9838169 hw/hppa/machine: Map the PDC memory region with higher priority
329d37d hw/hppa/machine: Restrict the total memory size to 3GB
82196f2 hw/hppa/machine: Correctly check the firmware is in PDC range
18f08804 cris:axis_dev88: use memdev for RAM
420420e null-machine: use memdev for RAM
fab1efc s390x:s390-virtio-ccw: use memdev for RAM
cb1a184 arm:xlnx-zcu102: use memdev for RAM
dafc5fe arm:xlnx-versal-virt: use memdev for RAM
8939184 arm:xilinx_zynq: use memdev for RAM
64008ac arm:xilinx_zynq: drop RAM size fixup
edc3824 arm:virt: use memdev for RAM
9c8ff93 arm:vexpress: use memdev for RAM
9f032bc arm:versatilepb: use memdev for RAM
03de308 arm:sbsa-ref: use memdev for RAM
bc94738 arm:sabrelite: use memdev for RAM
af2175c arm:raspi: use memdev for RAM
1943756 arm:palm: use memdev for RAM
b329f68 arm:omap_sx1: use memdev for RAM
04a9490 arm:nseries: use memdev for RAM
7769298 arm:musicpal: use memdev for RAM
6d13cec arm:mps2: use memdev for RAM
e0e52ec arm:mps2-tz: use memdev for RAM
d9daba7 arm:mcimx7d-sabre: use memdev for RAM
a701677 arm:mcimx6ul-evk: use memdev for RAM
b3879f1 arm:kzm: use memdev for RAM
91d718e arm:kzm: drop RAM size fixup
18d4ce5 arm:integratorcp: use memdev for RAM
a396753 arm:imx25_pdk: use memdev for RAM
77e06e0 arm:imx25_pdk: drop RAM size fixup
f404c60 arm:highbank: use memdev for RAM
c60b4f9 arm:digic_boards: use memdev for RAM
deb657f arm:cubieboard: use memdev for RAM
be1ddd2 arm:collie: use memdev for RAM
fca3baa arm:aspeed: use memdev for RAM
99a74b3 hw:aspeed: drop warning and bogus ram_size fixup
f2ccbf8 arm:aspeed: actually check RAM size
0fd04a9 arm:aspeed: convert valid RAM sizes to data
06f609f alpha:dp264: use memdev for RAM
40a1eec initialize MachineState::ram in NUMA case
9ef003b machine: introduce convenience MachineState::ram
16ac6d5 machine: alias -mem-path and -mem-prealloc into memory-foo backend
3026057 machine: introduce ram-memdev property
58ea704 numa: remove deprecated -mem-path fallback to anonymous RAM
=== OUTPUT BEGIN ===
1/86 Checking commit 58ea704ecde0 (numa: remove deprecated -mem-path fallback
to anonymous RAM)
2/86 Checking commit 3026057508a7 (machine: introduce ram-memdev property)
3/86 Checking commit 16ac6d5dfca0 (machine: alias -mem-path and -mem-prealloc
into memory-foo backend)
4/86
Re: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
Patchew URL: https://patchew.org/QEMU/1579100861-73692-1-git-send-email-imamm...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === TESTiotest-qcow2: 217 socket_accept failed: Resource temporarily unavailable ** ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:272:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0) /tmp/qemu-test/src/tests/qtest/libqtest.c:140: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:272:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0) make: *** [check-qtest-x86_64] Error 1 make: *** Waiting for unfinished jobs TESTcheck-qtest-aarch64: tests/qtest/test-hmp TESTiotest-qcow2: 220 --- raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=755fcbfd171f40b1b16d6aac34e7c09b', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-qd5wtatm/src/docker-src.2020-01-15-15.50.14.28652:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2. filter=--filter=label=com.qemu.instance.uuid=755fcbfd171f40b1b16d6aac34e7c09b make[1]: *** [docker-run] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-qd5wtatm/src' make: *** [docker-run-test-quick@centos7] Error 2 real11m0.219s user0m8.267s The full log is available at http://patchew.org/logs/1579100861-73692-1-git-send-email-imamm...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH v6 11/21] libqtest: make bufwrite rely on the TransportOps
On 200103 1745, Philippe Mathieu-Daudé wrote:
> On 11/29/19 10:34 PM, Oleinik, Alexander wrote:
> > When using qtest "in-process" communication, qtest_sendf directly calls
> > a function in the server (qtest.c). Previously, bufwrite used
> > socket_send, which bypasses the TransportOps enabling the call into
> > qtest.c. This change replaces the socket_send calls with ops->send,
> > maintaining the benefits of the direct socket_send call, while adding
> > support for in-process qtest calls.
> >
> > Signed-off-by: Alexander Bulekov
> > ---
> > tests/libqtest.c | 4 ++--
> > tests/libqtest.h | 3 +++
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/libqtest.c b/tests/libqtest.c
> > index ac4b6ab5f0..a7df92319a 100644
> > --- a/tests/libqtest.c
> > +++ b/tests/libqtest.c
> > @@ -1080,8 +1080,8 @@ void qtest_bufwrite(QTestState *s, uint64_t addr,
> > const void *data, size_t size)
> > bdata = g_base64_encode(data, size);
> > qtest_sendf(s, "b64write 0x%" PRIx64 " 0x%zx ", addr, size);
> > -socket_send(s->fd, bdata, strlen(bdata));
> > -socket_send(s->fd, "\n", 1);
> > +s->ops.send(s, bdata);
> > +s->ops.send(s, "\n");
>
> Ah, is this the send_line() from patch #5?
>
> Now it makes sense to move the send("\n") there and call it send_line().
>
> Moving the send(\n) we get this in patch #5:
>
> static void qtest_client_socket_send_line(QTestState *s,
>const char *bufline)
> {
> socket_send(s->fd, bufline, strlen(bufline));
> socket_send(s->fd, "\n", 1);
> }
Would this also involve changing all of the
qtest_{clock_step,in,out,read,write...} functions to remove the '\n'
from the calls to qtest_sendf? Not that it matters much, but it also
seems to double the number of syscalls needed to send each qtest
command.
> > qtest_rsp(s, 0);
> > g_free(bdata);
> > }
> > diff --git a/tests/libqtest.h b/tests/libqtest.h
> > index c9e21e05b3..0e9b8908ef 100644
> > --- a/tests/libqtest.h
> > +++ b/tests/libqtest.h
> > @@ -729,4 +729,7 @@ bool qtest_probe_child(QTestState *s);
> >*/
> > void qtest_set_expected_status(QTestState *s, int status);
> > +QTestState *qtest_inproc_init(bool log, const char* arch,
> > +void (*send)(void*, const char*));
> > +void qtest_client_inproc_recv(void *opaque, const char *str);
> > #endif
> >
>
Re: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
Patchew URL:
https://patchew.org/QEMU/1579100861-73692-1-git-send-email-imamm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
Type: series
Message-id: 1579100861-73692-1-git-send-email-imamm...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Switched to a new branch 'test'
11a20c3 numa: remove deprecated implicit RAM distribution between nodes
d86b08b numa: make exit() usage consistent
8646e5e tests:numa-test: use explicit memdev to specify node RAM
e73639d tests:numa-test: make top level args dynamic and g_autofree(cli)
cleanups
22e8003 numa: forbid '-numa node, mem' for 5.0 and newer machine types
4636732 hostmem: fix strict bind policy
547e119 hostmem: introduce "prealloc-threads" property
37e2c24 make mem_path local variable
3f12da2 exec: drop bogus mem_path from qemu_ram_alloc_from_fd()
82d8312 exec: cleanup qemu_minrampagesize()/qemu_maxrampagesize()
fad9d83 post conversion default_ram_id cleanup
dba7fdb remove no longer used memory_region_allocate_system_memory()
b3cee01 sparc:niagara: use memdev for RAM
193cdb5 sparc:sun4m: use memdev for RAM
7b57adc sparc:leon3: use memdev for RAM
1b43407 ppc:virtex_ml507: use memdev for RAM
d151f5a ppc:virtex_ml507: remove unused arguments
9696d27 ppc:spapr: use memdev for RAM
42503a2 ppc:prep: use memdev for RAM
07bab1c ppc:ppc440_bamboo/sam460ex: use memdev for RAM
78dacf7 ppc/{ppc440_bamboo,sam460x}: drop RAM size fixup
c946d56 ppc:ppc405_boards: use memdev for RAM
90799d8 ppc:ppc405_boards: add RAM size checks
95965c8 ppc:pnv: use memdev for RAM
8794a61 ppc:mac_oldworld: use memdev for RAM
803a239 ppc:mac_newworld: use memdev for RAM
de3715d ppc:e500: use memdev for RAM
aa12e5f ppc:e500: drop RAM size fixup
05ef318 mips:mips_r4k: use memdev for RAM
0577baa mips:mips_mipssim: use memdev for RAM
a1226bd mips:mips_malta: use memdev for RAM
f059e6d mips:mips_jazz: use memdev for RAM
9fde8b0 mips:mips_fulong2e: use memdev for RAM
974b1c0 mips:mips_fulong2e: drop RAM size fixup
6f147f5 mips:boston-cube: use memdev for RAM
f97cebd m68k:next-cube: use memdev for RAM
aa9050c m68k:mcf5208: use memdev for RAM
2e37399 m68k:an5206: use memdev for RAM
7471a18 lm32:milkymist: use memdev for RAM
06d3b1b lm32:lm32_boards: use memdev for RAM
b72206f x86:pc: use memdev for RAM
f0ed8ae x86:microvm: use memdev for RAM
56cec52 hppa: use memdev for RAM
dad8af3 hw/hppa/machine: Map the PDC memory region with higher priority
14d9db7 hw/hppa/machine: Restrict the total memory size to 3GB
8bb59b8 hw/hppa/machine: Correctly check the firmware is in PDC range
f66c661 cris:axis_dev88: use memdev for RAM
30ec2c7 null-machine: use memdev for RAM
eca7ad3 s390x:s390-virtio-ccw: use memdev for RAM
9efacaa arm:xlnx-zcu102: use memdev for RAM
6c17f5e arm:xlnx-versal-virt: use memdev for RAM
c974680 arm:xilinx_zynq: use memdev for RAM
5214578 arm:xilinx_zynq: drop RAM size fixup
487a287 arm:virt: use memdev for RAM
f59a421 arm:vexpress: use memdev for RAM
5f18495 arm:versatilepb: use memdev for RAM
4ef5f91 arm:sbsa-ref: use memdev for RAM
e67a909 arm:sabrelite: use memdev for RAM
8b211a1 arm:raspi: use memdev for RAM
c2fe517 arm:palm: use memdev for RAM
59fa4ec arm:omap_sx1: use memdev for RAM
54372f1 arm:nseries: use memdev for RAM
a460240 arm:musicpal: use memdev for RAM
00a31d8 arm:mps2: use memdev for RAM
6384dde arm:mps2-tz: use memdev for RAM
d675a78 arm:mcimx7d-sabre: use memdev for RAM
a5d1f43 arm:mcimx6ul-evk: use memdev for RAM
e5d7dc1 arm:kzm: use memdev for RAM
c3cc180 arm:kzm: drop RAM size fixup
f843b3e arm:integratorcp: use memdev for RAM
4dee2dc arm:imx25_pdk: use memdev for RAM
c794dcf arm:imx25_pdk: drop RAM size fixup
999f220 arm:highbank: use memdev for RAM
91d80f4 arm:digic_boards: use memdev for RAM
aab50b1 arm:cubieboard: use memdev for RAM
8d954fe arm:collie: use memdev for RAM
7b0d326 arm:aspeed: use memdev for RAM
6a7c2af hw:aspeed: drop warning and bogus ram_size fixup
172ef43 arm:aspeed: actually check RAM size
0e55e08 arm:aspeed: convert valid RAM sizes to data
ff6444e alpha:dp264: use memdev for RAM
b02edb3 initialize MachineState::ram in NUMA case
5d0b636 machine: introduce convenience MachineState::ram
0fc2004 machine: alias -mem-path and -mem-prealloc into memory-foo backend
6d984b5 machine: introduce ram-memdev property
08fae89 numa: remove deprecated -mem-path fallback to anonymous RAM
=== OUTPUT BEGIN ===
1/86 Checking commit 08fae890b67d (numa: remove deprecated -mem-path fallback
to anonymous RAM)
2/86 Checking commit 6d984b5dbe35 (machine: introduce ram-memdev property)
3/86 Checking commit 0fc2004b03fa (machine: alias -mem-path and -mem-prealloc
into memory-foo backend)
4/86
Re: [PATCH v2 19/86] arm:kzm: use memdev for RAM
> "Igor" == Igor Mammedov writes: Igor> memory region. Igor> Signed-off-by: Igor Mammedov Igor> Reviewed-by: Philippe Mathieu-Daudé Igor> --- Igor> CC: peter.ch...@nicta.com.au You can add: Reviewed-by: Peter Chubb Igor> CC: peter.mayd...@linaro.org Igor> CC: qemu-...@nongnu.org Peter C
Re: [PATCH RFC 00/12] *** mulitple RDMA channels for migration ***
* Zhimin Feng (fengzhim...@huawei.com) wrote: > From: fengzhimin > > Currently there is a single channel for RDMA migration, this causes > the problem that the network bandwidth is not fully utilized for > 25Gigabit NIC. Inspired by the Multifd, we use two RDMA channels to > send RAM pages, which we call MultiRDMA. > > We compare the migration performance of MultiRDMA with origin > RDMA migration. The VM specifications for migration are as follows: > - VM use 4k page; > - the number of VCPU is 4; > - the total memory is 16Gigabit; > - use 'mempress' tool to pressurize VM(mempress 8000 500); > - use 25Gigabit network card to migrate; > > For origin RDMA and MultiRDMA migration, the total migration times of > VM are as follows: > + > | | NOT rdma-pin-all | rdma-pin-all | > + > | origin RDMA | 18 s | 23 s | > - > | MultiRDMA | 13 s | 18 s | > + Very nice. > For NOT rdma-pin-all migration, the multiRDMA can improve the > total migration time by about 27.8%. > For rdma-pin-all migration, the multiRDMA can improve the > total migration time by about 21.7%. > > Test the multiRDMA migration like this: > 'virsh migrate --live --rdma-parallel --migrateuri > rdma://hostname domain qemu+tcp://hostname/system' It will take me a while to finish the review; but another general suggestion is add more trace_ calls; it will make it easier to diagnose problems later. Dave > > fengzhimin (12): > migration: Add multiRDMA capability support > migration: Export the 'migration_incoming_setup' function > and add the 'migrate_use_rdma_pin_all' function > migration: Create the multi-rdma-channels parameter > migration/rdma: Create multiRDMA migration threads > migration/rdma: Create the multiRDMA channels > migration/rdma: Transmit initial package > migration/rdma: Be sure all channels are created > migration/rdma: register memory for multiRDMA channels > migration/rdma: Wait for all multiRDMA to complete registration > migration/rdma: use multiRDMA to send RAM block for rdma-pin-all mode > migration/rdma: use multiRDMA to send RAM block for NOT rdma-pin-all > mode > migration/rdma: only register the virt-ram block for MultiRDMA > > migration/migration.c | 55 +- > migration/migration.h |6 + > migration/rdma.c | 1320 + > monitor/hmp-cmds.c|7 + > qapi/migration.json | 27 +- > 5 files changed, 1285 insertions(+), 130 deletions(-) > > -- > 2.19.1 > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RFC 05/12] migration/rdma: Create the multiRDMA channels
* Zhimin Feng (fengzhim...@huawei.com) wrote:
> From: fengzhimin
>
> In both sides. We still don't transmit anything through them,
> and we only build the RDMA connections.
>
> Signed-off-by: fengzhimin
> ---
> migration/rdma.c | 253 +--
> 1 file changed, 223 insertions(+), 30 deletions(-)
>
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 992e5abfed..5b780bef36 100644
> --- a/migration/rdma.c
> +++ b/migration/rdma.c
> @@ -403,6 +403,10 @@ typedef struct {
> char *name;
> /* channel thread id */
> QemuThread thread;
> +/* RDMAContext channel */
> +RDMAContext *rdma;
> +/* communication channel */
> +QEMUFile *file;
> /* sem where to wait for more work */
> QemuSemaphore sem;
> /* this mutex protects the following parameters */
> @@ -429,6 +433,10 @@ typedef struct {
> char *name;
> /* channel thread id */
> QemuThread thread;
> +/* RDMAContext channel */
> +RDMAContext *rdma;
> +/* communication channel */
> +QEMUFile *file;
> /* sem where to wait for more work */
> QemuSemaphore sem;
> /* this mutex protects the following parameters */
> @@ -3417,6 +3425,27 @@ static int qemu_rdma_accept(RDMAContext *rdma)
> qemu_set_fd_handler(rdma->channel->fd,
> rdma_accept_incoming_migration,
> NULL,
> (void *)(intptr_t)rdma->return_path);
> +} else if (migrate_use_multiRDMA()) {
> +int thread_count;
> +int i;
> +RDMAContext *multi_rdma = NULL;
> +thread_count = migrate_multiRDMA_channels();
> +/* create the multi Thread RDMA channels */
> +for (i = 0; i < thread_count; i++) {
> +if (multiRDMA_recv_state->params[i].rdma->cm_id == NULL) {
> +multi_rdma = multiRDMA_recv_state->params[i].rdma;
> +break;
> +}
> +}
> +
> +if (multi_rdma) {
> +qemu_set_fd_handler(rdma->channel->fd,
> +rdma_accept_incoming_migration,
> +NULL, (void *)(intptr_t)multi_rdma);
> +} else {
> +qemu_set_fd_handler(rdma->channel->fd, rdma_cm_poll_handler,
> +NULL, rdma);
> +}
> } else {
> qemu_set_fd_handler(rdma->channel->fd, rdma_cm_poll_handler,
> NULL, rdma);
> @@ -4029,6 +4058,58 @@ static QEMUFile *qemu_fopen_rdma(RDMAContext *rdma,
> const char *mode)
> return rioc->file;
> }
>
> +static void *multiRDMA_recv_thread(void *opaque)
> +{
> +MultiRDMARecvParams *p = opaque;
> +
> +while (true) {
> +qemu_mutex_lock(>mutex);
> +if (p->quit) {
> +qemu_mutex_unlock(>mutex);
> +break;
> +}
> +qemu_mutex_unlock(>mutex);
> +qemu_sem_wait(>sem);
> +}
> +
> +qemu_mutex_lock(>mutex);
> +p->running = false;
> +qemu_mutex_unlock(>mutex);
> +
> +return NULL;
> +}
> +
> +static void multiRDMA_recv_new_channel(QEMUFile *f, int id)
> +{
> +MultiRDMARecvParams *p;
> +Error *local_err = NULL;
> +
> +p = _recv_state->params[id];
> +if (p->file != NULL) {
> +error_setg(_err,
> + "multiRDMA: received id '%d' already setup'", id);
> +return ;
> +}
> +p->file = f;
> +
> +qemu_thread_create(>thread, p->name, multiRDMA_recv_thread, p,
> + QEMU_THREAD_JOINABLE);
> +atomic_inc(_recv_state->count);
> +}
> +
> +static void migration_multiRDMA_process_incoming(QEMUFile *f, RDMAContext
> *rdma)
> +{
> +MigrationIncomingState *mis = migration_incoming_get_current();
> +
> +if (!mis->from_src_file) {
> +rdma->migration_started_on_destination = 1;
> +migration_incoming_setup(f);
> +migration_incoming_process();
> +} else {
> +multiRDMA_recv_new_channel(f, multiRDMA_recv_state->count);
> +}
> +}
> +
> static void rdma_accept_incoming_migration(void *opaque)
> {
> RDMAContext *rdma = opaque;
> @@ -4057,29 +4138,13 @@ static void rdma_accept_incoming_migration(void
> *opaque)
> return;
> }
>
> -rdma->migration_started_on_destination = 1;
> -migration_fd_process_incoming(f);
> -}
> -
> -static void *multiRDMA_recv_thread(void *opaque)
> -{
> -MultiRDMARecvParams *p = opaque;
> -
> -while (true) {
> -qemu_mutex_lock(>mutex);
> -if (p->quit) {
> -qemu_mutex_unlock(>mutex);
> -break;
> -}
> -qemu_mutex_unlock(>mutex);
> -qemu_sem_wait(>sem);
> +if (migrate_use_multiRDMA()) {
> +/* build the multiRDMA channels */
> +migration_multiRDMA_process_incoming(f, rdma);
> +} else {
> +rdma->migration_started_on_destination = 1;
> +migration_fd_process_incoming(f);
> }
> -
> -
Re: [PATCH v2 18/86] arm:kzm: drop RAM size fixup
> "Igor" == Igor Mammedov writes:
Igor> If user provided non-sense RAM size, board will complain and
Igor> continue running with max RAM size supported. Also RAM is going
Igor> to be allocated by generic code, so it won't be possible for
Igor> board to fix things up for user.
Igor> Make it error message and exit to force user fix CLI, instead of
Igor> accepting non-sense CLI values.
I think this comment needs rewording a little. Maybe:
If the user provided too large a RAM size, the code used to
complain and trim it to the max size. Now tht RAM is allocated by
generic code, that's no longer possible, so generate an error and
exit instead.
Igor>/* Check the amount of memory is compatible with the SOC */
Igor> if (machine->ram_size > (FSL_IMX31_SDRAM0_SIZE +
Igor> FSL_IMX31_SDRAM1_SIZE)) {
Igor> - warn_report("RAM size " RAM_ADDR_FMT " above max supported, "
Igor> + error_report("RAM size " RAM_ADDR_FMT " above max supported, "
Igor>"reduced to %x", machine->ram_size,
Igor>FSL_IMX31_SDRAM0_SIZE + FSL_IMX31_SDRAM1_SIZE);
This needs to be changed so it doesn't say that the RAM size
is reduced, just what the maximum is. Maybe:
error_report("RAM size " RAM_ADDR_FMT " above max (%x) supported.",
machine->ram_size, FSL_IMX31_SDRAM0_SIZE +
FSL_IMX31_SDRAM1_SIZE);
Peter C
Re: [PATCH 08/12] linux-user: Add support for setting alsa timer enhanced read using ioctl
On Wed, Jan 15, 2020 at 8:17 PM Filip Bozuta wrote: > On 15.1.20. 17:37, Arnd Bergmann wrote: > > On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier wrote: > >> Le 15/01/2020 à 17:18, Arnd Bergmann a écrit : > >>> On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta > >>> wrote: > >> Do the kernel patches add new ioctl numbers to differentiate 32bit and > >> 64bit time_t? > > > > Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument > > is a pure 'int' that decides what format you get when you 'read' from the > > same file descriptor. > > > > For emulating 64-bit on 32-bit kernels, you have to use the new > > SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on > > 64-bit kernels, you probably have to return -ENOTTY to > > SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to > > emulate the read() behavior. > > When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64, > > you can translate that into the 64-bit > > SNDRV_TIMER_IOCTL_TREAD_OLD. > > Thank you for bringing this up to my attention. Unfortunately i have > some duties of academic nature in next month so i won't have much time > fix this bug. I will try to fix this as soon as possible. One more thing: I just realized it gets worse when emulating cross-endian, as then even without calling SNDRV_TIMER_IOCTL_TREAD, reading data from /dev/snd/timer requires byteswapping the two words. Arnd
[PATCH v8 13/13] linux-user: Add support for TYPE_LONG and TYPE_ULONG in do_ioctl()
Function "do_ioctl()" located in file "syscall.c" was missing an option for TYPE_LONG and TYPE_ULONG. This caused some ioctls to not be recognised because they had the third argument that was of type 'long' or 'unsigned long'. For example: Since implemented ioctls RTC_IRQP_SET and RTC_EPOCH_SET are of type IOW(writing type) that have unsigned long as their third argument, they were not recognised in QEMU before the changes of this patch. Signed-off-by: Filip Bozuta --- linux-user/syscall.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index a3993a2..2ba2c5c 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -5176,6 +5176,8 @@ static abi_long do_ioctl(int fd, int cmd, abi_long arg) break; case TYPE_PTRVOID: case TYPE_INT: +case TYPE_LONG: +case TYPE_ULONG: ret = get_errno(safe_ioctl(fd, ie->host_cmd, arg)); break; case TYPE_PTR: -- 2.7.4
[PATCH v8 07/13] linux-user: Add support for getting alsa timer version and id
This patch implements functionalities of following ioctls:
SNDRV_TIMER_IOCTL_PVERSION - Getting the sound timer version
Read the sound timer version. The third ioctl's argument is
a pointer to an int in which the specified timers version
is returned.
SNDRV_TIMER_IOCTL_NEXT_DEVICE - Getting id information about next timer
Read id information about the next timer device from the sound timer
device list. The id infomration is returned in the following structure:
struct snd_timer_id {
int dev_class;/* timer device class number */
int dev_sclass; /* slave device class number (unused) */
int card; /* card number */
int device; /* device number */
int subdevice;/* sub-device number */
};
The devices in the sound timer device list are arranged by the fields
of this structure respectively (first by dev_class number, then by
card number, ...). A pointer to this structure should be passed as
the third ioctl's argument. Before calling the ioctl, the parameters
of this structure should be initialized in relation to the next timer
device which information is to be obtained. For example, if a wanted
timer device has the device class number equal to or bigger then 2,
the field dev_class should be initialized to 2. After the ioctl call,
the structure fields are filled with values from the next device in
the sound timer device list. If there is no next device in the list,
the structure is filled with "zero" id values (in that case all
fields are filled with value -1).
Implementation notes:
The ioctl 'SNDRV_TIMER_IOCTL_NEXT_DEVICE' has a pointer to a
'struct snd_timer_id' as its third argument. That is the reason why
corresponding definition is added in 'linux-user/syscall_types.h'.
Since all elements of this structure are of type 'int', the rest of
the implementation was straightforward.
The line '#include ' was added to recognize
preprocessor definitions for these ioctls. This needs to be
done only once in this series of commits. Also, the content
of this file (with respect to ioctl definitions) remained
unchanged for a long time, therefore there is no need to
worry about supporting older Linux kernel version.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 4
linux-user/syscall.c | 1 +
linux-user/syscall_defs.h | 5 +
linux-user/syscall_types.h | 7 +++
4 files changed, 17 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 1f1f3e6..ed1bd4c 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -449,6 +449,10 @@
IOCTL(SOUND_MIXER_WRITE_LOUD, IOC_W, MK_PTR(TYPE_INT))
IOCTL(SOUND_MIXER_WRITE_RECSRC, IOC_W, MK_PTR(TYPE_INT))
+ IOCTL(SNDRV_TIMER_IOCTL_PVERSION, IOC_R, MK_PTR(TYPE_INT))
+ IOCTL(SNDRV_TIMER_IOCTL_NEXT_DEVICE, IOC_RW,
+MK_PTR(MK_STRUCT(STRUCT_snd_timer_id)))
+
IOCTL(HDIO_GETGEO, IOC_R, MK_PTR(MK_STRUCT(STRUCT_hd_geometry)))
IOCTL(HDIO_GET_UNMASKINTR, IOC_R, MK_PTR(TYPE_INT))
IOCTL(HDIO_GET_MULTCOUNT, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 74c3c08..a3993a2 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -108,6 +108,7 @@
#include
#include
#include
+#include
#include "linux_loop.h"
#include "uname.h"
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index af4f366..7ceb6f8 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2425,6 +2425,11 @@ struct target_statfs64 {
#define TARGET_SOUND_MIXER_WRITE_RECSRC
TARGET_MIXER_WRITE(SOUND_MIXER_RECSRC)
+/* alsa timer ioctls */
+#define TARGET_SNDRV_TIMER_IOCTL_PVERSION TARGET_IOR('T', 0x00, int)
+#define TARGET_SNDRV_TIMER_IOCTL_NEXT_DEVICE TARGET_IOWR('T', 0x01,
\
+struct snd_timer_id)
+
/* vfat ioctls */
#define TARGET_VFAT_IOCTL_READDIR_BOTHTARGET_IORU('r', 1)
#define TARGET_VFAT_IOCTL_READDIR_SHORT TARGET_IORU('r', 2)
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 4027272..2f4cd78 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -83,6 +83,13 @@ STRUCT(buffmem_desc,
STRUCT(mixer_info,
MK_ARRAY(TYPE_CHAR, 16), MK_ARRAY(TYPE_CHAR, 32), TYPE_INT,
MK_ARRAY(TYPE_INT, 10))
+STRUCT(snd_timer_id,
+ TYPE_INT, /* dev_class */
+ TYPE_INT, /* dev_sclass */
+ TYPE_INT, /* card */
+ TYPE_INT, /* device */
+ TYPE_INT) /* subdevice */
+
/* loop device ioctls */
STRUCT(loop_info,
TYPE_INT, /* lo_number */
--
2.7.4
[PATCH v8 05/13] linux-user: Add support for getting/setting RTC PLL correction using ioctls
This patch implements functionalities of following ioctls:
RTC_PLL_GET - Getting PLL correction
Read the PLL correction for RTCs that support PLL. The PLL correction
is returned in the following structure:
struct rtc_pll_info {
int pll_ctrl;/* placeholder for fancier control */
int pll_value; /* get/set correction value */
int pll_max; /* max +ve (faster) adjustment value */
int pll_min; /* max -ve (slower) adjustment value */
int pll_posmult; /* factor for +ve correction */
int pll_negmult; /* factor for -ve correction */
long pll_clock; /* base PLL frequency */
};
A pointer to this structure should be passed as the third
ioctl's argument.
RTC_PLL_SET - Setting PLL correction
Sets the PLL correction for RTCs that support PLL. The PLL correction
that is set is specified by the rtc_pll_info structure pointed to by
the third ioctl's' argument.
Implementation notes:
All ioctls in this patch have a pointer to a structure rtc_pll_info
as their third argument. All elements of this structure are of
type 'int', except the last one that is of type 'long'. That is
the reason why a separate target structure (target_rtc_pll_info)
is defined in linux-user/syscall_defs. The rest of the
implementation is straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 2 ++
linux-user/syscall_defs.h | 14 ++
linux-user/syscall_types.h | 9 +
3 files changed, 25 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index b09396e..0a4e3f1 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -87,6 +87,8 @@
IOCTL(RTC_EPOCH_SET, IOC_W, TYPE_ULONG)
IOCTL(RTC_WKALM_RD, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_wkalrm)))
IOCTL(RTC_WKALM_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_wkalrm)))
+ IOCTL(RTC_PLL_GET, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_pll_info)))
+ IOCTL(RTC_PLL_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_pll_info)))
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 37504a2..8370f41 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -763,6 +763,16 @@ struct target_pollfd {
#define TARGET_KDSETLED0x4B32 /* set led state [lights, not flags] */
#define TARGET_KDSIGACCEPT 0x4B4E
+struct target_rtc_pll_info {
+int pll_ctrl;
+int pll_value;
+int pll_max;
+int pll_min;
+int pll_posmult;
+int pll_negmult;
+abi_long pll_clock;
+};
+
/* real time clock ioctls */
#define TARGET_RTC_AIE_ON TARGET_IO('p', 0x01)
#define TARGET_RTC_AIE_OFF TARGET_IO('p', 0x02)
@@ -782,6 +792,10 @@ struct target_pollfd {
#define TARGET_RTC_EPOCH_SETTARGET_IOW('p', 0x0e, abi_ulong)
#define TARGET_RTC_WKALM_RD TARGET_IOR('p', 0x10, struct rtc_wkalrm)
#define TARGET_RTC_WKALM_SETTARGET_IOW('p', 0x0f, struct rtc_wkalrm)
+#define TARGET_RTC_PLL_GET TARGET_IOR('p', 0x11,
\
+ struct target_rtc_pll_info)
+#define TARGET_RTC_PLL_SET TARGET_IOW('p', 0x12,
\
+ struct target_rtc_pll_info)
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SH4) ||
\
defined(TARGET_XTENSA)
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 820bc8e..4027272 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -271,6 +271,15 @@ STRUCT(rtc_wkalrm,
TYPE_CHAR, /* pending */
MK_STRUCT(STRUCT_rtc_time)) /* time */
+STRUCT(rtc_pll_info,
+ TYPE_INT, /* pll_ctrl */
+ TYPE_INT, /* pll_value */
+ TYPE_INT, /* pll_max */
+ TYPE_INT, /* pll_min */
+ TYPE_INT, /* pll_posmult */
+ TYPE_INT, /* pll_negmult */
+ TYPE_LONG) /* pll_clock */
+
STRUCT(blkpg_ioctl_arg,
TYPE_INT, /* op */
TYPE_INT, /* flags */
--
2.7.4
Re: [PATCH v2 00/86] refactor main RAM allocation to use hostmem backend
Patchew URL: https://patchew.org/QEMU/1579100861-73692-1-git-send-email-imamm...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === TESTiotest-qcow2: 184 socket_accept failed: Resource temporarily unavailable ** ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:272:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0) /tmp/qemu-test/src/tests/qtest/libqtest.c:140: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:272:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0) TESTiotest-qcow2: 186 make: *** [check-qtest-x86_64] Error 1 make: *** Waiting for unfinished jobs TESTiotest-qcow2: 187 TESTiotest-qcow2: 190 --- raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=22666b33f869455386111b839b4d494c', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-2tanos8_/src/docker-src.2020-01-15-14.28.46.4844:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2. filter=--filter=label=com.qemu.instance.uuid=22666b33f869455386111b839b4d494c make[1]: *** [docker-run] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-2tanos8_/src' make: *** [docker-run-test-quick@centos7] Error 2 real10m47.563s user0m8.283s The full log is available at http://patchew.org/logs/1579100861-73692-1-git-send-email-imamm...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
[PATCH v8 12/13] linux-user: Add support for selected alsa timer instructions using ioctls
This patch implements functionalities of following ioctls:
SNDRV_TIMER_IOCTL_START - Start selected alsa timer
Starts the timer device that is selected. The third ioctl's argument is
ignored. Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT"
should be called first to select the timer that is to be started. If no
timer is selected, the error EBADFD ("File descriptor in bad shape")
is returned.
SNDRV_TIMER_IOCTL_STOP - Stop selected alsa timer
Stops the timer device that is selected. The third ioctl's argument is
ignored. Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT"
should be called first to select the timer that is to be stopped. If no
timer is selected, the error EBADFD ("File descriptor in bad shape")
is returned.
SNDRV_TIMER_IOCTL_CONTINUE - Continue selected alsa timer
Continues the timer device that is selected. The third ioctl's argument is
ignored. Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT"
should be called first to select the timer that is to be continued. If no
timer is selected, the error EBADFD ("File descriptor in bad shape")
is returned.
SNDRV_TIMER_IOCTL_PAUSE - Pause selected alsa timer
Pauses the timer device that is selected. The third ioctl's argument is
ignored. Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT"
should be called first to select the timer that is to be paused. If no
timer is selected, the error EBADFD ("File descriptor in bad shape")
is returned.
Implementation notes:
Since all of the implemented ioctls have NULL as their third argument,
their implementation was straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h | 4
linux-user/syscall_defs.h | 4
2 files changed, 8 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 43e7e5d..75a2f0e 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -466,6 +466,10 @@
MK_PTR(MK_STRUCT(STRUCT_snd_timer_params)))
IOCTL(SNDRV_TIMER_IOCTL_STATUS, IOC_R,
MK_PTR(MK_STRUCT(STRUCT_snd_timer_status)))
+ IOCTL(SNDRV_TIMER_IOCTL_START, 0, TYPE_NULL)
+ IOCTL(SNDRV_TIMER_IOCTL_STOP, 0, TYPE_NULL)
+ IOCTL(SNDRV_TIMER_IOCTL_CONTINUE, 0, TYPE_NULL)
+ IOCTL(SNDRV_TIMER_IOCTL_PAUSE, 0, TYPE_NULL)
IOCTL(HDIO_GETGEO, IOC_R, MK_PTR(MK_STRUCT(STRUCT_hd_geometry)))
IOCTL(HDIO_GET_UNMASKINTR, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index d5f5cad..2d86d78 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2505,6 +2505,10 @@ struct target_snd_timer_status {
struct snd_timer_params)
#define TARGET_SNDRV_TIMER_IOCTL_STATUS TARGET_IOR('T', 0x14,
\
struct target_snd_timer_status)
+#define TARGET_SNDRV_TIMER_IOCTL_STARTTARGET_IO('T', 0xa0)
+#define TARGET_SNDRV_TIMER_IOCTL_STOP TARGET_IO('T', 0xa1)
+#define TARGET_SNDRV_TIMER_IOCTL_CONTINUE TARGET_IO('T', 0xa2)
+#define TARGET_SNDRV_TIMER_IOCTL_PAUSETARGET_IO('T', 0xa3)
/* vfat ioctls */
#define TARGET_VFAT_IOCTL_READDIR_BOTHTARGET_IORU('r', 1)
--
2.7.4
[PATCH v8 08/13] linux-user: Add support for setting alsa timer enhanced read using ioctl
This patch implements functionality of following ioctl:
SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read
Sets enhanced time read which is used for reading time with timestamps
and events. The third ioctl's argument is a pointer to an 'int'. Enhanced
reading is set if the third argument is different than 0, otherwise normal
time reading is set.
Implementation notes:
Because the implemented ioctl has 'int' as its third argument, the
implementation was straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h | 1 +
linux-user/syscall_defs.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index ed1bd4c..9106773 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -452,6 +452,7 @@
IOCTL(SNDRV_TIMER_IOCTL_PVERSION, IOC_R, MK_PTR(TYPE_INT))
IOCTL(SNDRV_TIMER_IOCTL_NEXT_DEVICE, IOC_RW,
MK_PTR(MK_STRUCT(STRUCT_snd_timer_id)))
+ IOCTL(SNDRV_TIMER_IOCTL_TREAD, IOC_W, MK_PTR(TYPE_INT))
IOCTL(HDIO_GETGEO, IOC_R, MK_PTR(MK_STRUCT(STRUCT_hd_geometry)))
IOCTL(HDIO_GET_UNMASKINTR, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 7ceb6f8..0971623 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2429,6 +2429,7 @@ struct target_statfs64 {
#define TARGET_SNDRV_TIMER_IOCTL_PVERSION TARGET_IOR('T', 0x00, int)
#define TARGET_SNDRV_TIMER_IOCTL_NEXT_DEVICE TARGET_IOWR('T', 0x01,
\
struct snd_timer_id)
+#define TARGET_SNDRV_TIMER_IOCTL_TREADTARGET_IOW('T', 0x02, int)
/* vfat ioctls */
#define TARGET_VFAT_IOCTL_READDIR_BOTHTARGET_IORU('r', 1)
--
2.7.4
[PATCH v8 02/13] linux-user: Add support for getting/setting RTC time and alarm using ioctls
This patch implements functionalities of following ioctls:
RTC_RD_TIME - Getting RTC time
Returns this RTC's time in the following structure:
struct rtc_time {
int tm_sec;
int tm_min;
int tm_hour;
int tm_mday;
int tm_mon;
int tm_year;
int tm_wday; /* unused */
int tm_yday; /* unused */
int tm_isdst;/* unused */
};
The fields in this structure have the same meaning and ranges
as the tm structure described in gmtime man page. A pointer
to this structure should be passed as the third ioctl's argument.
RTC_SET_TIME - Setting RTC time
Sets this RTC's time to the time specified by the rtc_time
structure pointed to by the third ioctl's argument. To set
the RTC's time the process must be privileged (i.e., have the
CAP_SYS_TIME capability).
RTC_ALM_READ, RTC_ALM_SET - Getting/Setting alarm time
Read and set the alarm time, for RTCs that support alarms.
The alarm interrupt must be separately enabled or disabled
using the RTC_AIE_ON, RTC_AIE_OFF requests. The third
ioctl's argument is a pointer to a rtc_time structure. Only
the tm_sec, tm_min, and tm_hour fields of this structure are
used.
Implementation notes:
All ioctls in this patch have pointer to a structure rtc_time
as their third argument. That is the reason why corresponding
definition is added in linux-user/syscall_types.h. Since all
elements of this structure are of type 'int', the rest of the
implementation is straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 4
linux-user/syscall_defs.h | 4
linux-user/syscall_types.h | 11 +++
3 files changed, 19 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 97741c7..f472794 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -77,6 +77,10 @@
IOCTL(RTC_PIE_OFF, 0, TYPE_NULL)
IOCTL(RTC_WIE_ON, 0, TYPE_NULL)
IOCTL(RTC_WIE_OFF, 0, TYPE_NULL)
+ IOCTL(RTC_ALM_READ, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
+ IOCTL(RTC_ALM_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
+ IOCTL(RTC_RD_TIME, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
+ IOCTL(RTC_SET_TIME, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index f91579a..f0bf09d 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -772,6 +772,10 @@ struct target_pollfd {
#define TARGET_RTC_PIE_OFF TARGET_IO('p', 0x06)
#define TARGET_RTC_WIE_ON TARGET_IO('p', 0x0f)
#define TARGET_RTC_WIE_OFF TARGET_IO('p', 0x10)
+#define TARGET_RTC_ALM_READ TARGET_IOR('p', 0x08, struct rtc_time)
+#define TARGET_RTC_ALM_SET TARGET_IOW('p', 0x07, struct rtc_time)
+#define TARGET_RTC_RD_TIME TARGET_IOR('p', 0x09, struct rtc_time)
+#define TARGET_RTC_SET_TIME TARGET_IOW('p', 0x0a, struct rtc_time)
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SH4) ||
\
defined(TARGET_XTENSA)
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 4e36983..a35072a 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -255,6 +255,17 @@ STRUCT(blkpg_partition,
MK_ARRAY(TYPE_CHAR, BLKPG_DEVNAMELTH), /* devname */
MK_ARRAY(TYPE_CHAR, BLKPG_VOLNAMELTH)) /* volname */
+STRUCT(rtc_time,
+ TYPE_INT, /* tm_sec */
+ TYPE_INT, /* tm_min */
+ TYPE_INT, /* tm_hour */
+ TYPE_INT, /* tm_mday */
+ TYPE_INT, /* tm_mon */
+ TYPE_INT, /* tm_year */
+ TYPE_INT, /* tm_wday */
+ TYPE_INT, /* tm_yday */
+ TYPE_INT) /* tm_isdst */
+
STRUCT(blkpg_ioctl_arg,
TYPE_INT, /* op */
TYPE_INT, /* flags */
--
2.7.4
[PATCH v8 00/13] linux-user: Add support for real time clock and
This series covers following RTC and sound timer ioctls:
RTC ioctls(22):
* RTC_AIE_ON * RTC_ALM_SET * RTC_WKALM_SET
* RTC_AIE_OFF * RTC_ALM_READ* RTC_WKALM_RD
* RTC_UIE_ON * RTC_RD_TIME * RTC_PLL_GET
* RTC_UIE_OFF * RTC_SET_TIME* RTC_PLL_SET
* RTC_PIE_ON * RTC_IRQP_READ * RTC_VL_READ
* RTC_PIE_OFF * RTC_IRQP_SET* RTC_VL_CLR
* RTC_WIE_ON * RTC_EPOCH_READ
* RTC_WIE_OFF * RTC_EPOCH_SET
Sound timer ioctls(14):
* SNDRV_TIMER_IOCTL_PVERSION * SNDRV_TIMER_IOCTL_INFO
* SNDRV_TIMER_IOCTL_NEXT_DEVICE * SNDRV_TIMER_IOCTL_PARAMS
* SNDRV_TIMER_IOCTL_TREAD * SNDRV_TIMER_IOCTL_STATUS
* SNDRV_TIMER_IOCTL_GINFO * SNDRV_TIMER_IOCTL_START
* SNDRV_TIMER_IOCTL_GPARAMS * SNDRV_TIMER_IOCTL_STOP
* SNDRV_TIMER_IOCTL_GSTATUS * SNDRV_TIMER_IOCTL_CONTINUE
* SNDRV_TIMER_IOCTL_SELECT* SNDRV_TIMER_IOCTL_PAUSE
The functionalities of individual ioctls were described in this series
patch commit messages.
Testing method for RTC ioctls:
Mini test programs were written for each ioctl. Those programs were
compiled (sometimes using cross-compilers) for the following
architectures:
* Intel 64-bit (little endian)
* Power pc 32-bit (big endian)
* Power pc 64-bit (big endian)
The corresponding native programs were executed without using
QEMU on following hosts:
* Intel Core i7-4790K (x86_64 host)
* Power 7447A (ppc32 host)
All applicable compiled programs were in turn executed through QEMU
and the results obtained were the same ones gotten for native
execution.
Example of a test program:
For ioctl RTC_RD_TIME the following test program was used:
#include
#include
#include
#include
#include
#include
#include
#define ERROR -1
int main()
{
int fd = open("/dev/rtc", O_RDWR | O_NONBLOCK);
if(fd == ERROR)
{
perror("open");
return -1;
}
struct rtc_time cur_time;
if(ioctl(fd, RTC_RD_TIME, _time) < 0)
{
perror("ioctl");
return -1;
}
printf("Second: %d, Minute: %d, Hour: %d, Day: %d, Month: %d, Year:
%d,",
cur_time.tm_sec, cur_time.tm_min, cur_time.tm_hour,
cur_time.tm_mday, cur_time.tm_mon, cur_time.tm_year);
return 0;
}
Limitations of testing:
The test host pc that was used for testing (intel pc) has RTC
that doesn't support all RTC features that are accessible
through ioctls. This means that testing can't discover
functionality errors related to the third argument of ioctls
that are used for features which are not supported. For example,
running the test program for ioctl RTC_EPOCH_READ gives
the error output: inappropriate ioctl for device. As expected,
the same output was obtained through QEMU which means that this
ioctl is recognized in QEMU but doesn't really do anything
because it is not supported in the host computer's RTC.
Conclusion: Some RTC ioctls need to be tested on computers
that support their functionalities so that it can be inferred
that they are really supported in QEMU. In absence of such
test hosts, the specifications of those ioctls need to be
carefully checked manually and the implementations should be
updated accordingly.
Testing method for sound timer ioctls:
The alsa ioctl test suite, that can be found on github
("https://github.com/alsa-project/alsa-utils;), was used the test
the implemented ioctls. The file "timer.c", located in this test
suite, contains test functions that are used to test alsa timer
ioctls. This file was compiled (sometimes using cross-compilers)
for the following architectures:
* Intel 64-bit (little endian)
* Power pc 32-bit (big endian)
* Power pc 64-bit (big endian)
The corresponding compiled test files were executed without using
QEMU on following hosts:
* Intel Core i7-4790K (x86_64 host)
* Power 7447A (ppc32 host)
The corresponding native compiled test files were executed without using
QEMU on following hosts:
* Intel Core i7-4790K (x86_64 host)
* Power 7447A (ppc32 host)
All compiled test files were in turn executed through QEMU
and the results obtained were the same ones gotten for native
execution.
Also, mini test programs were written to test further functionalities
of individual ioctls. Those programs were, like the file "timer.c",
compiled for different architectures and were
[PATCH v8 09/13] linux-user: Add support for getting/setting specified alsa timer parameters using ioctls
This patch implements functionalities of following ioctls:
SNDRV_TIMER_IOCTL_GINFO - Getting information about specified timer
Read information about the specified timer. The information about the
timer is returned in the following structure:
struct snd_timer_ginfo {
struct snd_timer_id tid; /* requested timer ID */
unsigned int flags; /* timer flags - SNDRV_TIMER_FLG_* */
int card; /* card number */
unsigned char id[64]; /* timer identification */
unsigned char name[80]; /* timer name */
unsigned long reserved0; /* reserved for future use */
unsigned long resolution; /* average period resolution in ns */
unsigned long resolution_min; /* minimal period resolution in ns */
unsigned long resolution_max; /* maximal period resolution in ns */
unsigned int clients; /* active timer clients */
unsigned char reserved[32]; /* reserved */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling the ioctl, the field "tid" should be initialized with the id
information for the timer which information is to be obtained. After the
ioctl call, the rest of the structure fields are filled with values from
the timer device with the specified id. If there is no device with the
specified id, the error ENODEV ("No such device") is returned.
SNDRV_TIMER_IOCTL_GPARAMS - Setting precise period duration
Sets timer precise period duration numerator and denominator in seconds. The
period duration is set in the following structure:
struct snd_timer_gparams {
struct snd_timer_id tid;/* requested timer ID */
unsigned long period_num; /* period duration - numerator */
unsigned long period_den; /* period duration - denominator */
unsigned char reserved[32]; /* reserved */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling the ioctl, the field "tid" should be initialized with the id
information for the timer which period duration is to be set. Also, the
fileds "period_num" and "period_den" should be filled with the period
duration numerator and denominator values that are to be set respectively.
If there is no device with the specified id, the error ENODEV ("No such
device") is returned.
SNDRV_TIMER_IOCTL_GSTATUS - Getting current period resolution
Read timer current period resolution in nanoseconds and period resolution
numerator and denominator in seconds. The period resolution information is
returned in the following structure:
struct snd_timer_gstatus {
struct snd_timer_id tid;/* requested timer ID */
unsigned long resolution; /* current period resolution in ns */
unsigned long resolution_num; /* period resolution - numerator */
unsigned long resolution_den; /* period resolution - denominator */
unsigned char reserved[32]; /* reserved for future use */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling the ioctl, the field "tid" should be initialized with the id
information for the timer which period resolution is to be obtained. After
the ioctl call, the rest of the structure fields are filled with values
from the timer device with the specified id. If there is no device with the
specified id, the error ENODEV ("No such device") is returned.
Implementation notes:
All ioctls in this patch have pointer to some kind of a structure as their
third argument. That is the reason why corresponding definitions were added
in 'linux-user/syscall_types.h'. All of these strcutures have some fields
that are of type 'unsigned long'. That is the reason why separate target
structures were defined in 'linux-user/syscall_defs.h'. Also, all of the
structures have a field with type 'struct snd_timer_id' which is the reason
why a separate target structure 'struct target_snd_timer_id' was also
defined. The rest of the implementation was straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 6 ++
linux-user/syscall_defs.h | 43 +++
linux-user/syscall_types.h | 26 ++
3 files changed, 75 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 9106773..989eb9b 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -453,6 +453,12 @@
IOCTL(SNDRV_TIMER_IOCTL_NEXT_DEVICE, IOC_RW,
MK_PTR(MK_STRUCT(STRUCT_snd_timer_id)))
IOCTL(SNDRV_TIMER_IOCTL_TREAD, IOC_W, MK_PTR(TYPE_INT))
+ IOCTL(SNDRV_TIMER_IOCTL_GINFO, IOC_RW,
+MK_PTR(MK_STRUCT(STRUCT_snd_timer_ginfo)))
+
[PATCH v8 06/13] linux-user: Add support for read/clear RTC voltage low detector using ioctls
This patch implements functionalities of following ioctls:
RTC_VL_READ - Read voltage low detection information
Read the voltage low for RTCs that support voltage low.
The third ioctl's' argument points to an int in which
the voltage low is returned.
RTC_VL_CLR - Clear voltage low information
Clear the information about voltage low for RTCs that
support voltage low. The third ioctl(2) argument is
ignored.
Implementation notes:
Since one ioctl has a pointer to 'int' as its third agrument,
and another ioctl has NULL as its third argument, their
implementation was straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h | 2 ++
linux-user/syscall_defs.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 0a4e3f1..1f1f3e6 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -89,6 +89,8 @@
IOCTL(RTC_WKALM_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_wkalrm)))
IOCTL(RTC_PLL_GET, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_pll_info)))
IOCTL(RTC_PLL_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_pll_info)))
+ IOCTL(RTC_VL_READ, IOC_R, MK_PTR(TYPE_INT))
+ IOCTL(RTC_VL_CLR, 0, TYPE_NULL)
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 8370f41..af4f366 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -796,6 +796,8 @@ struct target_rtc_pll_info {
struct target_rtc_pll_info)
#define TARGET_RTC_PLL_SET TARGET_IOW('p', 0x12,
\
struct target_rtc_pll_info)
+#define TARGET_RTC_VL_READ TARGET_IOR('p', 0x13, int)
+#define TARGET_RTC_VL_CLR TARGET_IO('p', 0x14)
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SH4) ||
\
defined(TARGET_XTENSA)
--
2.7.4
[PATCH v8 01/13] linux-user: Add support for enabling/disabling RTC features using ioctls
This patch implements functionalities of following ioctls:
RTC_AIE_ON, RTC_AIE_OFF - Alarm interrupt enabling on/off
Enable or disable the alarm interrupt, for RTCs that support
alarms. The third ioctl's argument is ignored.
RTC_UIE_ON, RTC_UIE_OFF - Update interrupt enabling on/off
Enable or disable the interrupt on every clock update, for
RTCs that support this once-per-second interrupt. The third
ioctl's argument is ignored.
RTC_PIE_ON, RTC_PIE_OFF - Periodic interrupt enabling on/off
Enable or disable the periodic interrupt, for RTCs that sup‐
port these periodic interrupts. The third ioctl's argument
is ignored. Only a privileged process (i.e., one having the
CAP_SYS_RESOURCE capability) can enable the periodic interrupt
if the frequency is currently set above the value specified in
/proc/sys/dev/rtc/max-user-freq.
RTC_WIE_ON, RTC_WIE_OFF - Watchdog interrupt enabling on/off
Enable or disable the Watchdog interrupt, for RTCs that sup-
port this Watchdog interrupt. The third ioctl's argument is
ignored.
Implementation notes:
Since all of involved ioctls have NULL as their third argument,
their implementation was straightforward.
The line '#include ' was added to recognize
preprocessor definitions for these ioctls. This needs to be
done only once in this series of commits. Also, the content
of this file (with respect to ioctl definitions) remained
unchanged for a long time, therefore there is no need to
worry about supporting older Linux kernel version.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h | 9 +
linux-user/syscall.c | 1 +
linux-user/syscall_defs.h | 10 ++
3 files changed, 20 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index c6b9d6a..97741c7 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -69,6 +69,15 @@
IOCTL(KDSETLED, 0, TYPE_INT)
IOCTL_SPECIAL(KDSIGACCEPT, 0, do_ioctl_kdsigaccept, TYPE_INT)
+ IOCTL(RTC_AIE_ON, 0, TYPE_NULL)
+ IOCTL(RTC_AIE_OFF, 0, TYPE_NULL)
+ IOCTL(RTC_UIE_ON, 0, TYPE_NULL)
+ IOCTL(RTC_UIE_OFF, 0, TYPE_NULL)
+ IOCTL(RTC_PIE_ON, 0, TYPE_NULL)
+ IOCTL(RTC_PIE_OFF, 0, TYPE_NULL)
+ IOCTL(RTC_WIE_ON, 0, TYPE_NULL)
+ IOCTL(RTC_WIE_OFF, 0, TYPE_NULL)
+
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
IOCTL(BLKRRPART, 0, TYPE_NULL)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index ce399a5..74c3c08 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -107,6 +107,7 @@
#include
#include
#include
+#include
#include "linux_loop.h"
#include "uname.h"
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 98c2119..f91579a 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -763,6 +763,16 @@ struct target_pollfd {
#define TARGET_KDSETLED0x4B32 /* set led state [lights, not flags] */
#define TARGET_KDSIGACCEPT 0x4B4E
+/* real time clock ioctls */
+#define TARGET_RTC_AIE_ON TARGET_IO('p', 0x01)
+#define TARGET_RTC_AIE_OFF TARGET_IO('p', 0x02)
+#define TARGET_RTC_UIE_ON TARGET_IO('p', 0x03)
+#define TARGET_RTC_UIE_OFF TARGET_IO('p', 0x04)
+#define TARGET_RTC_PIE_ON TARGET_IO('p', 0x05)
+#define TARGET_RTC_PIE_OFF TARGET_IO('p', 0x06)
+#define TARGET_RTC_WIE_ON TARGET_IO('p', 0x0f)
+#define TARGET_RTC_WIE_OFF TARGET_IO('p', 0x10)
+
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SH4) ||
\
defined(TARGET_XTENSA)
#define TARGET_FIOGETOWN TARGET_IOR('f', 123, int)
--
2.7.4
[PATCH v8 11/13] linux-user: Add support for getting/setting selected alsa timer parameters using ioctls
This patch implements functionalities of following ioctls:
SNDRV_TIMER_IOCTL_INFO - Getting information about selected timer
Read information about the selected timer. The information is returned in
the following structure:
struct snd_timer_info {
unsigned int flags; /* timer flags - SNDRV_TIMER_FLG_* */
int card; /* card number */
unsigned char id[64]; /* timer identificator */
unsigned char name[80]; /* timer name */
unsigned long reserved0;/* reserved for future use */
unsigned long resolution; /* average period resolution in ns */
unsigned char reserved[64]; /* reserved for future use */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT" should be
called first to select the timer which information is to be obtained. If no
timer is selected, the error EBADFD ("File descriptor in bad shape") is
returned.
SNDRV_TIMER_IOCTL_PARAMS - Setting parameters for selected timer
Sets parameters for the selected timer. The paramaters are set in the
following structure:
struct snd_timer_params {
unsigned int flags; /* flags - SNDRV_TIMER_PSFLG_* */
unsigned int ticks; /* requested resolution in ticks */
unsigned int queue_size;/* total size of queue (32-1024) */
unsigned int reserved0; /* reserved, was: failure locations */
unsigned int filter;/* event filter */
unsigned char reserved[60]; /* reserved */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT" should be
called first to select the timer which parameters are to be set. If no
timer is selected, the error EBADFD ("File descriptor in bad shape") is
returned.
SNDRV_TIMER_IOCTL_STATUS - Getting status of selected timer
Read status of the selected timer. The status of the timer is returned in
the following structure:
struct snd_timer_status {
struct timespec tstamp; /* Timestamp - last update */
unsigned int resolution;/* current period resolution in ns */
unsigned int lost; /* counter of master tick lost */
unsigned int overrun; /* count of read queue overruns */
unsigned int queue; /* used queue size */
unsigned char reserved[64]; /* reserved */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling this ioctl, the ioctl "SNDRV_TIMER_IOCTL_SELECT" should be
called first to select the timer which status is to be obtained. If no
timer is selected, the error EBADFD ("File descriptor in bad shape") is
returned.
Implementation notes:
All ioctls in this patch have pointer to some kind of a structure
as their third argument. That is the reason why corresponding
definitions were added in 'linux-user/syscall_types.h'. Structure
'snd_timer_status' has field of type 'struct timespec' which is why
a corresponding definition of that structure was also added in
'linux-user/syscall_types.h'. All of these strucutures have some
fields that are of type 'unsigned long'. That is the reason why
separate target structures were defined in 'linux-user/syscall_defs.h'.
Structure 'struct timespec' already had a separate target definition
so that definition was used to define a target structure for
'snd_timer_status'. The rest of the implementation was straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 5 +
linux-user/syscall_defs.h | 25 +
linux-user/syscall_types.h | 29 +
3 files changed, 59 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 7652117..43e7e5d 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -461,6 +461,11 @@
MK_PTR(MK_STRUCT(STRUCT_snd_timer_gstatus)))
IOCTL(SNDRV_TIMER_IOCTL_SELECT, IOC_W,
MK_PTR(MK_STRUCT(STRUCT_snd_timer_select)))
+ IOCTL(SNDRV_TIMER_IOCTL_INFO, IOC_R,
MK_PTR(MK_STRUCT(STRUCT_snd_timer_info)))
+ IOCTL(SNDRV_TIMER_IOCTL_PARAMS, IOC_W,
+MK_PTR(MK_STRUCT(STRUCT_snd_timer_params)))
+ IOCTL(SNDRV_TIMER_IOCTL_STATUS, IOC_R,
+MK_PTR(MK_STRUCT(STRUCT_snd_timer_status)))
IOCTL(HDIO_GETGEO, IOC_R, MK_PTR(MK_STRUCT(STRUCT_hd_geometry)))
IOCTL(HDIO_GET_UNMASKINTR, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 39b9739..d5f5cad 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2467,6 +2467,25 @@ struct target_snd_timer_select {
unsigned char reserved[32];
};
+struct target_snd_timer_info {
+unsigned int flags;
+int card;
+unsigned
[PATCH v8 03/13] linux-user: Add support for getting/setting RTC periodic interrupt and epoch using ioctls
This patch implements functionalities of following ioctls:
RTC_IRQP_READ, RTC_IRQP_SET - Getting/Setting IRQ rate
Read and set the frequency for periodic interrupts, for RTCs
that support periodic interrupts. The periodic interrupt must
be separately enabled or disabled using the RTC_PIE_ON,
RTC_PIE_OFF requests. The third ioctl's argument is an
unsigned long * or an unsigned long, respectively. The value
is the frequency in interrupts per second. The set of allow‐
able frequencies is the multiples of two in the range 2 to
8192. Only a privileged process (i.e., one having the
CAP_SYS_RESOURCE capability) can set frequencies above the
value specified in /proc/sys/dev/rtc/max-user-freq. (This
file contains the value 64 by default.)
RTC_EPOCH_READ, RTC_EPOCH_SET - Getting/Setting epoch
Many RTCs encode the year in an 8-bit register which is either
interpreted as an 8-bit binary number or as a BCD number. In
both cases, the number is interpreted relative to this RTC's
Epoch. The RTC's Epoch is initialized to 1900 on most systems
but on Alpha and MIPS it might also be initialized to 1952,
1980, or 2000, depending on the value of an RTC register for
the year. With some RTCs, these operations can be used to
read or to set the RTC's Epoch, respectively. The third
ioctl's argument is an unsigned long * or an unsigned long,
respectively, and the value returned (or assigned) is the
Epoch. To set the RTC's Epoch the process must be privileged
(i.e., have the CAP_SYS_TIME capability).
Implementation notes:
All ioctls in this patch have a pointer to 'ulong' as their
third argument. That is the reason why corresponding parts
of added code in linux-user/syscall_defs.h contain special
handling related to 'ulong' type: they use 'abi_ulong' type
to make sure that ioctl's code is calculated correctly for
both 32-bit and 64-bit targets. Also, 'MK_PTR(TYPE_ULONG)'
is used for the similar reason in linux-user/ioctls.h.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h | 4
linux-user/syscall_defs.h | 4
2 files changed, 8 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index f472794..accbdee 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -81,6 +81,10 @@
IOCTL(RTC_ALM_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
IOCTL(RTC_RD_TIME, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
IOCTL(RTC_SET_TIME, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_time)))
+ IOCTL(RTC_IRQP_READ, IOC_R, MK_PTR(TYPE_ULONG))
+ IOCTL(RTC_IRQP_SET, IOC_W, TYPE_ULONG)
+ IOCTL(RTC_EPOCH_READ, IOC_R, MK_PTR(TYPE_ULONG))
+ IOCTL(RTC_EPOCH_SET, IOC_W, TYPE_ULONG)
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index f0bf09d..bbfa935 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -776,6 +776,10 @@ struct target_pollfd {
#define TARGET_RTC_ALM_SET TARGET_IOW('p', 0x07, struct rtc_time)
#define TARGET_RTC_RD_TIME TARGET_IOR('p', 0x09, struct rtc_time)
#define TARGET_RTC_SET_TIME TARGET_IOW('p', 0x0a, struct rtc_time)
+#define TARGET_RTC_IRQP_READTARGET_IOR('p', 0x0b, abi_ulong)
+#define TARGET_RTC_IRQP_SET TARGET_IOW('p', 0x0c, abi_ulong)
+#define TARGET_RTC_EPOCH_READ TARGET_IOR('p', 0x0d, abi_ulong)
+#define TARGET_RTC_EPOCH_SETTARGET_IOW('p', 0x0e, abi_ulong)
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SH4) ||
\
defined(TARGET_XTENSA)
--
2.7.4
[PATCH v8 04/13] linux-user: Add support for getting/setting RTC wakeup alarm using ioctls
This patch implements functionalities of following ioctls:
RTC_WKALM_SET, RTC_WKALM_GET - Getting/Setting wakeup alarm
Some RTCs support a more powerful alarm interface, using these
ioctls to read or write the RTC's alarm time (respectively)
with this structure:
struct rtc_wkalrm {
unsigned char enabled;
unsigned char pending;
struct rtc_time time;
};
The enabled flag is used to enable or disable the alarm
interrupt, or to read its current status; when using these
calls, RTC_AIE_ON and RTC_AIE_OFF are not used. The pending
flag is used by RTC_WKALM_RD to report a pending interrupt
(so it's mostly useless on Linux, except when talking to the
RTC managed by EFI firmware). The time field is as used with
RTC_ALM_READ and RTC_ALM_SET except that the tm_mday, tm_mon,
and tm_year fields are also valid. A pointer to this structure
should be passed as the third ioctl's argument.
Implementation notes:
All ioctls in this patch have a pointer to a structure
rtc_wkalrm as their third argument. That is the reason why
corresponding definition is added in linux-user/syscall_types.h.
Since all elements of this structure are either of type
'unsigned char' or 'struct rtc_time' (that was covered in one
of previous patches), the rest of the implementation is
straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 2 ++
linux-user/syscall_defs.h | 2 ++
linux-user/syscall_types.h | 5 +
3 files changed, 9 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index accbdee..b09396e 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -85,6 +85,8 @@
IOCTL(RTC_IRQP_SET, IOC_W, TYPE_ULONG)
IOCTL(RTC_EPOCH_READ, IOC_R, MK_PTR(TYPE_ULONG))
IOCTL(RTC_EPOCH_SET, IOC_W, TYPE_ULONG)
+ IOCTL(RTC_WKALM_RD, IOC_R, MK_PTR(MK_STRUCT(STRUCT_rtc_wkalrm)))
+ IOCTL(RTC_WKALM_SET, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtc_wkalrm)))
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index bbfa935..37504a2 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -780,6 +780,8 @@ struct target_pollfd {
#define TARGET_RTC_IRQP_SET TARGET_IOW('p', 0x0c, abi_ulong)
#define TARGET_RTC_EPOCH_READ TARGET_IOR('p', 0x0d, abi_ulong)
#define TARGET_RTC_EPOCH_SETTARGET_IOW('p', 0x0e, abi_ulong)
+#define TARGET_RTC_WKALM_RD TARGET_IOR('p', 0x10, struct rtc_wkalrm)
+#define TARGET_RTC_WKALM_SETTARGET_IOW('p', 0x0f, struct rtc_wkalrm)
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SH4) ||
\
defined(TARGET_XTENSA)
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index a35072a..820bc8e 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -266,6 +266,11 @@ STRUCT(rtc_time,
TYPE_INT, /* tm_yday */
TYPE_INT) /* tm_isdst */
+STRUCT(rtc_wkalrm,
+ TYPE_CHAR, /* enabled */
+ TYPE_CHAR, /* pending */
+ MK_STRUCT(STRUCT_rtc_time)) /* time */
+
STRUCT(blkpg_ioctl_arg,
TYPE_INT, /* op */
TYPE_INT, /* flags */
--
2.7.4
[PATCH v8 10/13] linux-user: Add support for selecting alsa timer using ioctl
This patch implements functionality of following ioctl:
SNDRV_TIMER_IOCTL_SELECT - Selecting timer
Selects the timer which id is specified. The timer id is specified in the
following strcuture:
struct snd_timer_select {
struct snd_timer_id id; /* timer ID */
unsigned char reserved[32]; /* reserved */
};
A pointer to this structure should be passed as the third ioctl's argument.
Before calling the ioctl, the field "tid" should be initialized with the id
information for the timer which is to be selected. If there is no timer
device with the specified id, the error ENODEV ("No such device") is
returned.
Implementation notes:
Ioctl implemented in this patch has a pointer to a
'struct snd_timer_select' as its third argument.
That is the reason why a corresponding definition
was added in 'linux-user/syscall_types.h'. The rest
of the implementation was straightforward.
Reviewed-by: Laurent Vivier
Signed-off-by: Filip Bozuta
---
linux-user/ioctls.h| 2 ++
linux-user/syscall_defs.h | 7 +++
linux-user/syscall_types.h | 4
3 files changed, 13 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 989eb9b..7652117 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -459,6 +459,8 @@
MK_PTR(MK_STRUCT(STRUCT_snd_timer_gparams)))
IOCTL(SNDRV_TIMER_IOCTL_GSTATUS, IOC_RW,
MK_PTR(MK_STRUCT(STRUCT_snd_timer_gstatus)))
+ IOCTL(SNDRV_TIMER_IOCTL_SELECT, IOC_W,
+MK_PTR(MK_STRUCT(STRUCT_snd_timer_select)))
IOCTL(HDIO_GETGEO, IOC_R, MK_PTR(MK_STRUCT(STRUCT_hd_geometry)))
IOCTL(HDIO_GET_UNMASKINTR, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index a675b92..39b9739 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2462,6 +2462,11 @@ struct target_snd_timer_gstatus {
unsigned char reserved[32];
};
+struct target_snd_timer_select {
+struct target_snd_timer_id id;
+unsigned char reserved[32];
+};
+
/* alsa timer ioctls */
#define TARGET_SNDRV_TIMER_IOCTL_PVERSION TARGET_IOR('T', 0x00, int)
#define TARGET_SNDRV_TIMER_IOCTL_NEXT_DEVICE TARGET_IOWR('T', 0x01,
\
@@ -2473,6 +2478,8 @@ struct target_snd_timer_gstatus {
struct
target_snd_timer_gparams)
#define TARGET_SNDRV_TIMER_IOCTL_GSTATUS TARGET_IOWR('T', 0x05,
\
struct
target_snd_timer_gstatus)
+#define TARGET_SNDRV_TIMER_IOCTL_SELECT TARGET_IOW('T', 0x10,
\
+struct target_snd_timer_select)
/* vfat ioctls */
#define TARGET_VFAT_IOCTL_READDIR_BOTHTARGET_IORU('r', 1)
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 4e90716..767632d 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -116,6 +116,10 @@ STRUCT(snd_timer_gstatus,
TYPE_ULONG, /* resolution_den */
MK_ARRAY(TYPE_CHAR, 32)) /* reserved */
+STRUCT(snd_timer_select,
+ MK_STRUCT(STRUCT_snd_timer_id), /* id */
+ MK_ARRAY(TYPE_CHAR, 32)) /* reserved */
+
/* loop device ioctls */
STRUCT(loop_info,
TYPE_INT, /* lo_number */
--
2.7.4
Re: [PATCH v2 38/86] s390x:s390-virtio-ccw: use memdev for RAM
On 1/15/20 4:06 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov
---
CC: r...@twiddle.net
CC: da...@redhat.com
CC: coh...@redhat.com
CC: pa...@linux.ibm.com
CC: borntrae...@de.ibm.com
CC: qemu-s3...@nongnu.org
---
hw/s390x/s390-virtio-ccw.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index e0e2813..cbdd4ba 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -154,14 +154,12 @@ static void virtio_ccw_register_hcalls(void)
virtio_ccw_hcall_early_printk);
}
-static void s390_memory_init(ram_addr_t mem_size)
+static void s390_memory_init(MemoryRegion *ram)
{
MemoryRegion *sysmem = get_system_memory();
-MemoryRegion *ram = g_new(MemoryRegion, 1);
Error *local_err = NULL;
/* allocate RAM for core */
-memory_region_allocate_system_memory(ram, NULL, "s390.ram", mem_size);
memory_region_add_subregion(sysmem, 0, ram);
/*
@@ -245,7 +243,7 @@ static void ccw_init(MachineState *machine)
s390_sclp_init();
/* init memory + setup max page size. Required for the CPU model */
-s390_memory_init(machine->ram_size);
+s390_memory_init(machine->ram);
/* init CPUs (incl. CPU model) early so s390_has_feature() works */
s390_init_cpus(machine);
@@ -471,6 +469,7 @@ static void ccw_machine_class_init(ObjectClass *oc, void
*data)
hc->plug = s390_machine_device_plug;
hc->unplug_request = s390_machine_device_unplug_request;
nc->nmi_monitor_handler = s390_nmi;
+mc->default_ram_id = "s390.ram";
}
static inline bool machine_get_aes_key_wrap(Object *obj, Error **errp)
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 37/86] arm:xlnx-zcu102: use memdev for RAM
On 1/15/20 4:06 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov
---
CC: alist...@alistair23.me
CC: edgar.igles...@gmail.com
CC: peter.mayd...@linaro.org
CC: qemu-...@nongnu.org
---
hw/arm/xlnx-zcu102.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index 53cfe7c..bd645ad 100644
--- a/hw/arm/xlnx-zcu102.c
+++ b/hw/arm/xlnx-zcu102.c
@@ -28,7 +28,6 @@ typedef struct XlnxZCU102 {
MachineState parent_obj;
XlnxZynqMPState soc;
-MemoryRegion ddr_ram;
bool secure;
bool virt;
@@ -87,13 +86,10 @@ static void xlnx_zcu102_init(MachineState *machine)
ram_size);
}
-memory_region_allocate_system_memory(>ddr_ram, NULL, "ddr-ram",
- ram_size);
-
object_initialize_child(OBJECT(machine), "soc", >soc, sizeof(s->soc),
TYPE_XLNX_ZYNQMP, _abort, NULL);
-object_property_set_link(OBJECT(>soc), OBJECT(>ddr_ram),
+object_property_set_link(OBJECT(>soc), OBJECT(machine->ram),
"ddr-ram", _abort);
object_property_set_bool(OBJECT(>soc), s->secure, "secure",
_fatal);
@@ -211,6 +207,7 @@ static void xlnx_zcu102_machine_class_init(ObjectClass *oc,
void *data)
mc->ignore_memory_transaction_failures = true;
mc->max_cpus = XLNX_ZYNQMP_NUM_APU_CPUS + XLNX_ZYNQMP_NUM_RPU_CPUS;
mc->default_cpus = XLNX_ZYNQMP_NUM_APU_CPUS;
+mc->default_ram_id = "ddr-ram";
}
static const TypeInfo xlnx_zcu102_machine_init_typeinfo = {
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 10/86] arm:aspeed: use memdev for RAM
On 1/15/20 4:06 PM, Igor Mammedov wrote:
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov
---
CC: c...@kaod.org
CC: peter.mayd...@linaro.org
CC: and...@aj.id.au
CC: j...@jms.id.au
CC: qemu-...@nongnu.org
---
hw/arm/aspeed.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 525c547..330254b 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -35,7 +35,6 @@ static struct arm_boot_info aspeed_board_binfo = {
struct AspeedBoardState {
AspeedSoCState soc;
MemoryRegion ram_container;
-MemoryRegion ram;
MemoryRegion max_ram;
};
@@ -184,6 +183,7 @@ static void aspeed_machine_init(MachineState *machine)
memory_region_init(>ram_container, NULL, "aspeed-ram-container",
UINT32_MAX);
+memory_region_add_subregion(>ram_container, 0, machine->ram);
object_initialize_child(OBJECT(machine), "soc", >soc,
(sizeof(bmc->soc)), amc->soc_name, _abort,
@@ -215,8 +215,6 @@ static void aspeed_machine_init(MachineState *machine)
object_property_set_bool(OBJECT(>soc), true, "realized",
_fatal);
-memory_region_allocate_system_memory(>ram, NULL, "ram", ram_size);
-memory_region_add_subregion(>ram_container, 0, >ram);
memory_region_add_subregion(get_system_memory(),
sc->memmap[ASPEED_SDRAM],
>ram_container);
@@ -393,6 +391,7 @@ static void aspeed_machine_class_init(ObjectClass *oc, void
*data)
mc->no_floppy = 1;
mc->no_cdrom = 1;
mc->no_parallel = 1;
+mc->default_ram_id = "ram";
}
static void aspeed_machine_palmetto_class_init(ObjectClass *oc, void *data)
Reviewed-by: Philippe Mathieu-Daudé
