Re: base format
On Thu, 25 Apr 2024 at 09:55, lacsaP Patatetom wrote: > > hi, > > when using `qemu-img create`, why do I have to specify the format of the base > image ? > can't `qemu-img` detect it itself ? Image format detection isn't 100% reliable. Notably, a 'raw' format image could in theory look like any of the other image types if it happens to start with the right kind of data. thanks -- PMM
Re: armv7-m: tlb_set_page_full: Assertion failed
On Fri, 29 Mar 2024 at 12:47, Raphaël Poggi wrote: > > Hi, > > I am currently working on adding support of a custom ASIC based on > ARMv7-M (Cortex-M3). > > I have a RAM region defined as followed: > > base address = 0x0021E000 > size = 0x1FFC > > For some reason, during memcpy performed on guest side, I have an > assertion failed: > > qemu-system-arm: ../accel/tcg/cputlb.c:1169: tlb_set_page_full: > Assertion `!(iotlb & ~TARGET_PAGE_MASK)' failed. > > Here are some information I was able to gather during my debugging: > - my memcpy is the following: > > dest = 0x206006 (another ram region) > src = 0x21e008 > size = 0x3f9 > > - during the access that triggers the assertion, here are the state of > some variables just before the assertion: > > iotlb = 0xb03fc - ram_addr = 0xb - xlat = 0x3fc - TARGET_PAGE_MASK > = 0xfc0 > > - the last two lines of the gdb backtrace from qemu process: > > #4 0x55de29fc in tlb_set_page_full > (cpu=cpu@entry=0x5740c790, > mmu_idx=mmu_idx@entry=0x1, addr=addr@entry=0x21e400, > full=full@entry=0x7fffafffe010) at ../accel/tcg/cputlb.c:1169 > > #5 0x55d2b5fa in arm_cpu_tlb_fill > > (cs=0x5740c790, address=0x21e400, size=, > access_type=MMU_DATA_LOAD, mmu_idx=0x1, probe=, > retaddr=0x7fffb004b3c5) at ../target/arm/tcg/tlb_helper.c:364 > > I am really struggling to understand what is going wrong with my very > limited knowledge of qemu. Hard to say just from this. (a) Are you using current head-of-git QEMU? (b) Can you reproduce on a stock upstream QEMU which doesn't have your local changes? (I suspect you're running into issues related to that odd-sized RAM region. QEMU is a lot more efficient when RAM areas are a multiple of 4K and 4K aligned, and that's by far the more tested codepath. Funny sized and funny aligned RAM regions are supposed to work, but you're much more likely to run into bugs in that codepath.) thanks -- PMM
Re: No 'PCI' bus found for device 'ivshmem-plain'
On Thu, 21 Mar 2024 at 08:16, Sanjeev Kumar wrote: > > Hi, > our kernel is build with aarch64le. it is 64 bit ARM architecture. Such a kernel cannot possibly boot on the vexpress-a15 machine that you say you are using. So something doesn't seem right... > when i am trying to use virt as machine, then qemu isn't starting. it is > being stuck after entering command, You probably didn't build your kernel correctly to have all the support needed for the virt machine's devices. I recommend finding a tutorial on how to boot Linux on the virt board. This one is a bit old but the basic process will still work with newer Debian versions: https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/ thanks -- PMM
Re: No 'PCI' bus found for device 'ivshmem-plain'
On Wed, 20 Mar 2024 at 13:06, Sanjeev Kumar wrote: > > Hi Peter, > Thanks for your detailed review. > ifs.bin is our custom build and the linux kernel is booting fine with this > file. If it is, then it must be a 32-bit kernel. So trying to run it on the cortex-a57 will not work at all, because that is a 64-bit CPU and will only boot 64-bit kernels. (QEMU emulation does not allow booting a guest kernel in 32-bit mode for CPUs that in hardware support both 32-bit and 64-bit, I'm afraid.) > "this board doesn't have a PCI bus" - can you please suggest some board which > can support PCI bus? I just did: try the "virt" board. You'll need to decide what CPU you actually want to run first, though. thanks -- PMM
Re: No 'PCI' bus found for device 'ivshmem-plain'
On Wed, 20 Mar 2024 at 06:40, Sanjeev Kumar wrote: > > Hi, > Sorry for incomplete command. > here is the complete command line. > > qemu-system-aarch64 -machine vexpress-a15 -cpu cortex-a57 -smp 4 -m 10G > -kernel ifs.bin -drive file=disk-qemu.vmdk,if=none,id=drv0 -device > virtio-blk-device,drive=drv0 -netdev > tap,id=mynet0,ifname=tap0,script=no,downscript=no -device > virtio-net-device,netdev=mynet0,mac=52:55:00:d1:55:01 -device > virtio-rng-device -device ivshmem-plain,memdev=hostmem -object > memory-backend-file,size=1M,share=on,mem-path=/dev/shm/ivshmem,id=hostmem > -nographic Thanks. This command line is very confused. It is trying to use the "vexpress-a15" board model with a Cortex-A57. As the board name suggests, vexpress-a15 only works with a Cortex-A15. This board also cannot support the 10G of memory you are trying to use with it. Finally, the reason for the error message is that this board doesn't have a PCI bus, so there is no way to plug in the ivshmem PCI device you are trying to create. Also, "ifs.bin" is an odd name for a kernel: is this really a file that expects to be booted the way a Linux kernel is booted? If you want a board model that can handle 64-bit CPUs, lots of memory and PCI devices, I would suggest looking at the "virt" board. You'll need to make sure your kernel is built for that board. thanks -- PMM
Re: No 'PCI' bus found for device 'ivshmem-plain'
On Tue, 19 Mar 2024 at 09:41, Sanjeev Kumar wrote: > > Hi, > I am starting QEMU as below. > qemu-system-aarch64 [] -device ivshmem-plain,memdev=hostmem -object > memory-backend-file,size=1M,share=on,mem-path=/dev/shm/ivshmem,id=hostmem Please give us the *full* command line, not the command line with half of it missing. I suspect the reason this is not working is going to be in the part you have [] omitted :-) thanks -- PMM
Re: QEMU Compatibility for Cortex-A55 AArch32 Firmware
On Thu, 7 Mar 2024 at 01:03, yb liu wrote: > > Thanks a lot for you respond me soon! > The exact instruction is mrc, and the exception happended in early boot > process. I have no idea to how to debug this error because it happended in > code_gen_prologue. That's a system register access. If you can tell us the entire instruction (in particular with all the opn/crn/crm/etc arguments) we can look at what register it is. thanks -- PMM
Re: QEMU Compatibility for Cortex-A55 AArch32 Firmware
On Wed, 6 Mar 2024 at 14:33, yb liu wrote: > > > Dear QEMU developers > > I hope this email finds you well. We are currently facing an issue related to > QEMU and the Cortex-A55 architecture. Specifically, we have compiled a > firmware for Cortex-A55 and would like it to run smoothly on QEMU A55 in > AArch32 mode. > > Despite our numerous attempts, we continue to encounter an "undefined > instruction" error when running the firmware in QEMU. Our question is whether > QEMU supports this particular use case—specifically, whether it can handle > A55 running AArch32 firmware. We have Cortex-A55 emulation, but you may be running into one of a few problems: * we might have a bug * firmware sometimes does very low level stuff that no other guest code does, so it might run into something we didn't get round to implementing (eg it is trying to touch one of the implementation specific system registers: we tend to implement these as "does nothing" stubs, but it looks like we didn't bother for the A55, presumably because Linux didn't care) * your guest code might be doing something that works on the real A55 hardware but which is architecturally UNPREDICTABLE: QEMU doesn't try to exactly match device-specific IMPDEF and UNPREDICTABLE things * your guest code might be assuming the presence of some feature that your real A55 has but which QEMU doesn't implement (for instance we implement only the absolute minimum RAS support required by the architecture, not the full RAS that hardware implements) The thing you'd need to do is look at exactly what the UNDEF instruction is (and what the guest code that causes it is trying to do) to figure out which of these is the problem. Some of these might be easy to fix; some would be harder. If you're in a position to be able to modify the firmware image then that would also allow you to work around missing QEMU functionality if necessary. The more usual reason guest firmware not working in QEMU is not the CPU emulation itself but lack of a model of the device/SoC/etc hardware that the firmware assumes it's running on. -- PMM
Re: Xilinx zcu102 machine is absent in list of supported machines
On Tue, 5 Mar 2024 at 18:31, Vadim Idelchuk via wrote: > The additional information about my build: Thanks for that. Yeah, you're missing only this machine type. I had a poke around in the config files, and I think this is because the machine has a dependency on pixman, so if configure doesn't find the pixman library dev files, it will disable all the optional things that need pixman, including this machine type. If you pass configure "--enable-pixman" it should produce an error if you're missing the necessary files to build the pixman related parts of QEMU. Depending on your host distro the required package name might vary, but on Debian/Ubuntu it is libpixman-1-dev. thanks -- PMM
Re: Xilinx zcu102 machine is absent in list of supported machines
On Mon, 4 Mar 2024 at 11:20, Vadim Idelchuk via wrote: > For building the products I run the following: > > ./configure > > make > > > > I tried these sequence number of times with the same result - machine type > xlnx-zcu102 is absent in the list of supported machines What is the exact command line you are running to check that the machine is not present? Are you definitely running qemu-system-aarch64 (not qemu-system-arm !), and is it definitely the version you just built? -- PMM
Re: Xilinx zcu102 machine is absent in list of supported machines
On Sun, 3 Mar 2024 at 11:01, Vadim Idelchuk wrote: > I built the latest version of QEMU - v8.2.0-1528-g5767815218. > But the machine xlnx-zcu102 is absent in the list of supported machines. > Is it need any additional definitions for building? It should build by default if you build the aarch64 targets and you haven't done something odd like use a non-default device config file. You should check that you're running the qemu-system-aarch64 executable that you just built (eg run qemu-system-aarch64 --version and check its version is right), and not some other older version on your PATH. What configure command did you use to build QEMU? thanks -- PMM
Re: Emulating multi core processor (ARM cortex M7) on QEMU
On Mon, 26 Feb 2024 at 10:59, ankita suman wrote: > I am trying to emulate multi core processor (dual core for now) on QEMU. The > processor I am targeting is cortex m7. I tried by running multiple instances > of QEMU to emulate multi cores, and use shared memory for communication, but > since I am working on a bare metal environment, I don't have the options of > libraries for synchronization. > Another approach I tried was using inter VM shared memory(ivshmem). But I am > facing the same problem. I am able to write and read from the ivshmem device > from two different QEMU instances, but it is not working for ARM. None of this is the right way to go. Running multiple QEMU instances is like having two separate Arm hardware boards connected to each other somehow, not like having an actual multi-CPU board. You need to either: (1) use one of QEMU's existing boards with multiple CPUs (unfortunately we have no dual-M7 board) (2) model some dual-M7 board in QEMU, by writing C code to do that. This will not be particularly simple, depending on what the board you're trying to model is. If you're OK with a pair of Cortex-M33 rather than M7 specifically, you can look at using the mps3-an521 or mps3-an524 board models. I would suggest doing that: it will be by far the easiest thing. thanks -- PMM
Re: Using -spice command
On Sat, 24 Feb 2024 at 22:02, Serdar Bahar wrote: > I'm trying to enable Spice in my virtual machine. In order to do that, I've > found that I should append my booting command line with an option like this : > "-spice port=3001...". However, when I try this, I get the error: > "qemu-system-x86_64: -spice: invalid option". I'm using an Apple Silicon > macOS. How can I solve this problem? I can see that -spice is included in > user documentation of QEMU and I'm sure that I'm using the correct version > (8.2.1). Check whether running qemu-system-x86_64 -spice help produces a list of "spice options" describing the sub-options. If it does, then there's some problem with the specific option string you're using (and you should tell us what your whole command line is). If it doesn't produce anything, then your QEMU binary was built without SPICE support, and you'll need to rebuild it from source. When you run configure, by default QEMU will build optional features like SPICE if it can find the libraries it needs for them, and if it can't find the libraries it won't build the optional feature. You can pass configure the "--enable-spice" option which will force configure to fail if it can't find the libraries it needs. Then you'll need to make sure you have those libraries available, and once you do QEMU will build with SPICE support enabled. thanks -- PMM
Re: Multiple UARTs using -chardev and -device instead of -serial
On Tue, 20 Feb 2024 at 21:26, Michael N. Moran wrote: > I really wanted a way to specify associations between front-end > (serial?) and back-end (chardev?) without the need for the > sequential assignment of front-ends, and the need to skip > unused front-ends by using the likes of -serial null. Unfortunately QEMU doesn't provide any mechanism for doing that (this is mostly true also for other kinds of hard-wired onboard devices like ethernet controllers). -- PMM
Re: Multiple UARTs using -chardev and -device instead of -serial
On Mon, 19 Feb 2024 at 20:57, Michael N. Moran wrote: > > I'm working on Linux with `qemu-system-arm -machine olimex-stm32-h405`, which > uses an `stm32f405-soc` that implements 8 USARTs(UARTs). > > I currently use two "-serial telnet" options which assigns the first two > USART ports sequentially and I can connect to both using telnet. This works > fine. > > I would like to avoid the sequential assignment and instead specify a subset > of the USARTs that is not sequential. > > The === Character Devices === section in qdev-device-use.txt alludes to a > "new way" to do this using "-chardev" and "-device" that I'm not able to make > work. The problem seems to be choosing an appropriate "-device" incantation. The -device works only where you are configuring a new device that you are plugging into the machine (e.g. an ISA or PCI serial adapter on an x86 PC machine type), not for configuring ones that are built in to it (like most embedded board UARTs). For configuring embedded serial devices, use the -serial option. Each -serial option configures one UART, so use several of them in order to configure more than one UART. If you don't care about the output from a particular UART then "-serial null" will throw it away. If you want the flexbility of the -chardev option for configuring the backend to a builtin uart, you can do it with something like: -chardev id=myserial,[options...] -serial chardev:myserial (i.e. create a chardev with ID 'myserial', and then you can use a -serial option that says "connect to this existing chardev".) -- PMM
Re: Linux AMBA-CLCD driver no longer works with Qemu versatilepb target. What to do?
On Fri, 9 Feb 2024 at 16:53, Christopher Davies
wrote:
> I've been down a bit of a rabbit hole trying to get the Linux AMBA-CLCD
> driver for versatilepb target's graphics to work with modern Linux kernels.
> After a good deal of reading of both the Linux kernel code and the qemu code,
> I discovered why it won't work and why it probably has never worked since the
> transition to devicetree in the kernel about a decade ago.
>
> The driver chooses between PL110 and PL111 mode by taking the identifier from
> the AMBA bus:
>
> if (amba_manf(fb->dev) == 0x41 && amba_part(fb->dev) == 0x111) {
> fb->off_ienb = CLCD_PL111_IENB;
> fb->off_cntl = CLCD_PL111_CNTL;
> } else {
> fb->off_ienb = CLCD_PL110_IENB;
> fb->off_cntl = CLCD_PL110_CNTL;
> }
This indeed doesn't sound right -- it ought to use a
dtb compatible property to indicate that it's the weird versatilepb
variant.
> While Qemu thinks that the PL110_versatile ought to have the PL110 device ID,
> but the PL111 behaviour.
>
> static const unsigned char *idregs[] = {
> pl110_id,
> /* The ARM documentation (DDI0224C) says the CLCDC on the Versatile board
> * has a different ID (0x93, 0x10, 0x04, 0x00, ...). However the hardware
> * itself has the same ID values as a stock PL110, and guests (in
> * particular Linux) rely on this. We emulate what the hardware does,
> * rather than what the docs claim it ought to do.
> */
> pl110_id,
> pl111_id
> };
>
> So the Linux driver writes the wrong control register and the device is never
> enabled.
>
> I'm at a loss to know what to do about this. This hardware emulation worked
> with pre-devicetree kernels, and possibly making this change will break that,
> I really don't know. I also don't own the real hardware so I can't observe
> what the real behaviour is.
The real hardware is almost all going to be in landfill at this
point, I'm pretty sure. But I'm fairly sure that back when I wrote
that comment I would have had access to a real board and I think
I would have tested its behaviour. In fact, checking my email archive
I found the patch email I originally sent:
https://lore.kernel.org/qemu-devel/1378399437-17615-1-git-send-email-peter.mayd...@linaro.org/
and there I said:
# I happened to have to check the h/w behaviour in this area today
# during a discussion about some kernel pl11x patches, so I thought
# I might as well record the info and clean up the #if-0 in the
# process.
which seems like pretty good evidence that QEMU here is
behaving like the hardware.
> I'm possibly the only person to actually care about this in about a decade,
> and the CLCD driver has recently been removed from Linux.
Are we talking something other than drivers/gpu/drm/pl111/ ?
> I'm happy to write a patch for Qemu if anyone can suggest an approach
> to fixing this, anyone have any ideas?
Generally QEMU goes with "behave as the hardware does", though
for these old boards that gets kind of tricky. My gut feeling is
"this is a guest kernel bug that should be fixed in the guest
kernel".
-- PMM
Re: I Failed to execute AARCH64 Linux kernel on the QEMU
On Wed, 31 Jan 2024 at 12:12, Minjun Hong wrote: > > Hello. > > I'm trying to execute AARCH64 Linux kernel on the QEMU. > > But,there was an error and the error log is: >> >> rom: requested regions overlap (rom bootloader. free=0x422c0a00, >> addr=0x4000) >> qemu-system-aarch64: rom check and register reset failed > > > And my development environment is: >> >> host: x86_64 Ubuntu 18.04 >> linux kernel source version: v5.19 >> busybox version(for initramfs): 1_36_stable You don't say what QEMU version you're using. If it's the version from Ubuntu 18.04, that is now really quite old, so I would start by trying a newer QEMU. You should also use a newer Ubuntu, because (a) 18.04 is no longer supported as a build platform for current QEMU and (b) 18.04 fell out of security support last year, so you're already overdue to migrate away from it. If nothing else, a newer QEMU has improved that particular error message so it gives better detail about exactly what binary blobs are overlapping and causing the problem. thanks -- PMM
Re: TCG Plugin Dynamic Load
On Tue, 9 Jan 2024 at 16:12, Stephen Bates via wrote: > > Hi > > I am exploring the rather awesome TCG Plugin feature of QEMU > (https://www.qemu.org/docs/master/devel/tcg-plugins.html#). The latest > documentation for this feature states: > > "This is a new feature for QEMU and it does allow people to develop > out-of-tree plugins that can be dynamically linked into a running QEMU > process". > > However all the examples given on the documentation page show cases where the > plugin is loaded at QEMU invocation time. Is there any documentation or > associated material that discusses how a plugin can be dynamically linked > into a running QEMU process? I would very much like to be able to experiment > with this capability. Also, if so, is there a way to unlink the plugin from > the running process if needed? I think when that document says "dynamically linking into a running QEMU process" what it means is exactly "loaded at invocation time": at the point when QEMU is processing the command line options it is already running. The idea is that this is a contrast from "you needed to compile this into QEMU when you built the QEMU binary", i.e. statically linked. Cc'd Alex to check whether I'm right. thanks -- PMM
Re: How to stop Qemu from resetting terminal?
On Mon, 18 Dec 2023 at 23:56, Dave Blanchard wrote: > > > Hmm. Well, we do put the terminal into raw mode (so that we > > get stuff like ^C), but that is supposed to be reset when > > QEMU exits. > > Can you please direct me to where in the source code this happens? It happens in different places depending on what your command line is, which is why I asked about that. For instance the ncurses frontend code is all in ui/curses.c. The parts in chardev/ are for when you set up a chardev that uses stdio (eg with "-serial stdio"). And there might be some generic terminal cleanup code somewhere, I forget. -- PMM
Re: How to stop Qemu from resetting terminal?
On Mon, 18 Dec 2023 at 13:36, Dave Blanchard wrote: > > > > If you're directing a guest's terminal to the console then things > > like line wrapping are entirely up to the guest -- QEMU is > > providing the equivalent of a piece of hardware like a serial > > terminal, and how the guest chooses to write to it is up to > > the guest's serial drivers and TTY layer. So it's the guest's > > settings that control eg truncation vs wrapping. > > No, QEMU is clearly sending some kind of control codes to the terminal which > are resetting my Xterm to crazy defaults. This happens immediately on > poweron, before the guest OS has even loaded. Same thing for a telnet > connection; control codes are transmitted first thing which screws up Xterm. > If I suspend telnet to the background, issue a terminal reset, then resume, > the output is fixed. Hmm. Well, we do put the terminal into raw mode (so that we get stuff like ^C), but that is supposed to be reset when QEMU exits. What command line are you using exactly? I think the curses UI is going to do more stuff to the terminal than if you just say "-serial stdio", for example. thanks -- PMM
Re: How to stop Qemu from resetting terminal?
On Sun, 17 Dec 2023 at 22:49, Dave Blanchard wrote: > > One particularly annoying trait of Qemu is how it nukes my terminal settings. > This is especially infuriating when booting Linux where the VM console is > redirected to the serial port, which is then displayed on the host console. > Among other things line wrapping is disabled, so compiler output for example > is truncated at the end of the line! Then after the VM exits the console is > kept in this screwed up state, so I have to reset it. > > How can this mis-feature be disabled? Preferably by command line, or > alternately, where in the code is this happening so I can patch it to > disable? I've tried in vain to find where it's happening in the code, with no > luck. If you're directing a guest's terminal to the console then things like line wrapping are entirely up to the guest -- QEMU is providing the equivalent of a piece of hardware like a serial terminal, and how the guest chooses to write to it is up to the guest's serial drivers and TTY layer. So it's the guest's settings that control eg truncation vs wrapping. For serial terminal emulation you also have to tell the guest what its terminal window size actually is, if your window isn't 80x25: getting that wrong usually causes messed up display output. thanks -- PMM
Re: Can't get multi-process qemu to work
On Mon, 11 Dec 2023 at 11:52, Shunsuke Mie wrote: > The steps taken are as follows: > > 1. build qemu v6.2.0-rc2 Is that a typo for "v8.2.0-rc2", or are you really building from a two year old release candidate ? thanks -- PMM
Re: VFS: Unable to mount root fs on unknown-block(0,0)
On Wed, 29 Nov 2023 at 15:08, 泰宇周 wrote: > > I tried to use febootstrap to make a roofs image for qemu-kvm. > It reported that > > [1.766919] Kernel panic - not syncing: VFS: Unable to mount root fs > on unknown-block(0,0) When the kernel tells you it can't mount the root filesystem, the interesting part of the log is the part above this line, which you haven't given us. There the kernel will tell you what block devices it has found and what filesystems it tried to load them with. The problem generally is either: * wrong command line (i.e. you asked the kernel to look for the rootfs in the wrong place) * the kernel doesn't have a driver for that block device in it * the kernel doesn't have a driver for that filesystem in it In this case, you seem to be using a distro kernel. Those are generally pretty stripped down with almost all their device and filesystem drivers kept in an initrd. You haven't told QEMU to load an initrd, and the kernel doesn't have the drivers to directly mount the rootfs. You should probably try passing the initrd to QEMU as well as the kernel (-initrd argument). thanks -- PMM
Re: Solutions for enabling KVM in muti-arch soc machine
On Wed, 8 Nov 2023 at 01:40, 陈朱叠(澜赆) wrote: > > Dear QEMU folks, > We have modeled our system using qemu, which includes multiple cortex-m > cores and multiple neoverse n1 cores, all running in TCG mode. Based on this, > we want to use KVM technology to accelerate the performance of the neoverse > n1 cores. However, the cortex-m cores cannot run in KVM mode. If I understand > correctly, this means that the whole system cannot benefit from KVM > acceleration. Correct, either the whole system uses KVM, or none of it does, and the Cortex-M cores can't use KVM. thanks -- PMM
Re: pci passhthrough device's pci mem cannot mapped
On Tue, 31 Oct 2023 at 06:51, Jiatong Shen wrote: > > Hello community experts, > > I am using a 4.2.0 versioned qemu and passthrough an A40 (48G GPU memory). > When I start the virtual machine with following option "-m > size=4096M,slots=2,maxmem=1T ", the virtual machine could boot but the in the > VM I saw lspci failed to find bar1 and kernel message attached in the end of > the mail. > I tried 6.2.0 with the same options and it works without problem. So my > question what might cause the problem and why. Thank you very much for help. (I assume when you say "a 4.2.0 versioned qemu" you mean that you're using version 4.2 of QEMU, not that you're using a 4.2-versioned machine type with a newer version of the QEMU binary, given the command line that you say you're using.) For problems of the form "this didn't work in QEMU version X, but it does work in newer QEMU Y", the obvious guess is "this was a bug, and we fixed it in the later version". So if the newer version works for you I would recommend using it -- 4.2 is now very old, and it's unlikely anybody will be particularly interested in doing the work to try to figure out what was going on in such an old version of QEMU, unless you have a support contract with them... thanks -- PMM
Re: [Qemu-discuss] Setting vendor and product ids to emulated USB storage device
On Sun, 24 Sept 2023 at 23:05, Igor Ordecha wrote: > I'm trying to emulate a USB thumb drive from a .img file. My current > arguments for that look like this: > > -drive file=/path/to/file.img,if=none,id=drive-usb0,format=raw -device > nec-usb-xhci,id=xhci -device > usb-storage,bus=xhci.0,id=drive-usb0,drive=drive-usb0,removable=on,serial=0123456789abcdef > > It works but the device shows up as 46f4:0001 (vendor="QEMU", product="QEMU > USB HARDDRIVE") which my guest really doesn't like. Is there a way to change > the vendor id and product id? I looked everywhere, the manpage, forums, I > even asked ChatGPT in desperation(which surprisingly kinda worked. It told me > about the "serial" parameter which I also needed to spoof.), nothing. > > All I found was an email on this mailing list: > https://lists.nongnu.org/archive/html/qemu-discuss/2015-07/msg00072.html (I > don't know how to properly link a thread, this is my first time using a > mailing list, sorry) > It contains a hacky(as described by the author themself) patch to take vid > and pid but it's from 2015 and uses "-usbdevice disk" which is deprecated, I > believe. > > Is there a way to set vid and pid in current versions of QEMU or do I need to > adjust that patch to "-drive usb-storage" myself? No, I don't think there is any way to set these -- they're in a bit of fixed C code: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/dev-storage.c?ref_type=heads#L165 (The right place to provide a command line override is probably similar to serial=, as a bus property defined in the list in hw/usb/bus.c which then affects the behaviour of the code in hw/usb/desc.c. But I'm not very familiar with the USB subsystem.) What is this guest which doesn't like it? I would have expected that since every random USB stick is going to be from a different vendor that any guest that checks for specific values here would not work on a lot of real-world hardware... thanks -- PMM
Re: Qemu Uninstall
On Sun, 10 Sept 2023 at 20:52, Narcis Garcia wrote: > > I do with this command: > > sudo apt --autoremove remove qemu qemu-system qemu-utils > > ...but probably your operating system provides a graphical package > manager that helps to do it with a single click. Yes, if you installed QEMU via your distro, uninstall it the same way. If you're on Windows and installed a Windows packaged QEMU, it should uninstall in the usual way for Windows packages. If you built from source and installed with 'make install' (which I don't really recommend unless you used a custom install directory), then 'make uninstall' from the same source/build tree should work. (In this respect QEMU is not much different from any other program, I think.) -- PMM
Re: ARM system emulator
On Thu, 17 Aug 2023 at 09:05, Swedha R wrote: > > Hi, > In the qemu website , under the section ARM system emulator, they mentioned > like, > > Secure-World-only devices if the CPU has TrustZone: > > A second PL011 UART > A second PL061 GPIO controller, with GPIO lines for triggering a system reset > or system poweroff > A secure flash memory > 16MB of secure RAM > > I need to know how to work with the PL061 GPIO controller. You seem to keep asking variants of this question, but the answer remains the same. That GPIO controller is there only to handle specific requirements of the virt board (triggering a power-off or reset). It is not usable for general purposes, so you don't need to work with it at all. The EL3 firmware will use it as it needs to (eg when you make an ACPI request for a power down). thanks -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 18:52, Mario Marietto wrote: > > ok. I could extract the kernel files (so,between the qemu parameters I should > put : initrd and vmlinuz,right ? How ? > > -enable-kvm -serial stdio -kernel vmlinux -what here initrd \ > > from the ubuntu 22.10 img,but I'm sure that it does not have any dtb file. I > never needed a dtb file when I booted my vms,neither with qemu,nor with bhyve. The option for the initrd is '-initrd'. You don't need a dtb file if you are using the "virt" machine type, because that machine type will create a suitable DTB within QEMU to pass to the kernel. You only need it with arm machine types that are emulating real hardware, like vexpress-a15. Here it matches how a real boot loader like uboot works -- uboot loads the kernel, initrd and dtb file. (A few boards in real hardware, like the raspberry pi, provide the dtb file with their firmware for the bootloader to pick up, rather than having the distro ship the dtb alongside the kernel image file. QEMU's emulation of those boards requires the user to provide the dtb file to it anyway. The vexpress hardware never did this in any case, you always had to build a kernel and a dtb file.) thanks -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 18:27, Mario Marietto wrote: > > ok. I've been lucky. Qemu compiled successfully. Now I'm going to execute > this command : > > qemu-system-arm \ > -enable-kvm -serial stdio -kernel zImage \ > -m 512 -M vexpress-a15 -cpu cortex-a15 \ > -drive > file=/mnt/fisso/bhyve/img/Linux/ubuntu2210.img,id=virtio-blk,if=none \ > -device virtio-blk,drive=virtio-blk,transport=virtio-mmio.0 \ > -device > virtio-net,transport=virtio-mmio.1,netdev=net0,mac="52:54:00:12:34:55" \ > -netdev type=user,id=net0 \ > -append "earlyprintk=ttyAMA0 console=ttyAMA0 mem=512M \ > virtio_mmio.device=1M@0x4e00:74:0 \ > virtio_mmio.device=1M@0x4e10:75:1 \ > root=/dev/vda rw ip=dhcp --no-log" > > I would ask you : let's assume that I have already installed ubuntu 22.10 and > that it is inside the file called "ubuntu2210.img". > I would like to know how to remove the parameter "-kernel zImage",because in > that case I don't need it. > The problem is that if I remove it without adding some other parameter,it > says that I should use it. > But I don't need it to declare the kernel within the qemu parameters because > it is inside the file "ubuntu2210.img". You can't do that. There is no guest BIOS image for that machine type which knows how to read disk images and boot from them. So you must manually extract (or otherwise provide) a suitable kernel (and perhaps also initrd and dtb file) and pass them to QEMU, because QEMU's "built in bootloader" is very simple and just loads the kernel file and jumps to it. thanks -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 17:05, Mario Marietto wrote: > > I made some progress,but unfortunately I've got an error : > > root@devuan:~/Desktop/qemu-v5.1.0# ./configure --target-list=arm-softmmu > --enable-opengl --enable-gtk --enable-kvm --enable-guest-agent --enable-spice > --audio-drv-list="oss pa" --enable-libusb > > no errors here. > > root@devuan:~/Desktop/qemu-v5.1.0# make > > ... > > CC hw/usb/hcd-xhci.o > hw/usb/hcd-xhci.c: In function ‘usb_xhci_realize’: > hw/usb/hcd-xhci.c:3358:66: error: ‘%d’ directive output may be truncated > writing between 1 and 8 bytes into a region of size 5 > [-Werror=format-truncation=] > 3358 | snprintf(port->name, sizeof(port->name), "usb2 port #%d", > i+1); > | ^~ > hw/usb/hcd-xhci.c:3358:54: note: directive argument in the range [1, 89478486] > 3358 | snprintf(port->name, sizeof(port->name), "usb2 port #%d", > i+1) > | ^~~ > In file included from /usr/include/stdio.h:867, > from /root/Desktop/qemu-v5.1.0/include/qemu/osdep.h:85, > from hw/usb/hcd-xhci.c:22: > /usr/include/arm-linux-gnueabihf/bits/stdio2.h:67:10: note: > ‘__builtin___snprintf_chk’ output between 13 and 20 bytes into a destination > of size 16 This is the kind of thing you get when you try to build an old QEMU on a newer compiler -- the new compiler complains about more things, and we fix them in new QEMU. Pass configure '--disable-werror', which will mean that these are all just warnings, not errors. Then see if there are any problems still remaining that are real compile failures. -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 14:44, Валентин via wrote: > > > I've thought to compile it directly on the devuan 4 installed on the ARM > > chromebook. > > If you have native Arm toolchain, it's even simpler then – just try to > "./configure" and "make". Specify a --target-list= option to configure unless you want to sit around forever while it compiles every single supported guest architecture :-) -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 13:30, Mario Marietto wrote: > > ok. Can you share the github address ? I found the source code for x86-x64 > but not for armhf. There is not, and has never been, a separate git tree for different guest architectures. It is all in the one git tree at https://gitlab.com/qemu-project/qemu NB that we use gitlab, not github; there is a github repo, but it is just a mirror of the official gitlab. Your screenshot shows nothing because you are looking at branches, not at tags. v5.1.0 is a tag. -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 12:19, Mario Marietto wrote: > Anyway,can you tell me where is the branch 5.1 for the qemu source code for > armhf ? You want the "v5.1.0" git tag. -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Fri, 11 Aug 2023 at 11:34, Mario Marietto wrote: > > ok. I will recompile a qemu version lower than 5.2. I've asked all around and > someone says that I should use 5.1,someone else 4.9. Which version should I > use ? And,please can you point me to a good tutorial that can teach me the > procedure to recompile it ? I might find it by myself,but what I need is the > place where I should grab the source code of qemu for armhf. I also need the > compilation parameters :) thanks... This is all ancient history which I can't remember. You might even find that QEMUs that old don't compile any more, depending on how new your userspace is. You can get older QEMUs either by source tarball from the QEMU project website or by checking out the appropriate git tag. You're trying to do something which is basically "travel back in time and use decade old hardware and decade old software to do something that is going to perform terribly and is no longer supported because it's just not worth it". There are not really going to be any tutorials or help for this -- if you want to do it you get to find out all the places where stuff doesn't quite work the way it used to and you need to fix or adjust them. -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Thu, 10 Aug 2023 at 18:28, Mario Marietto wrote: > > ---> You can't use KVM with the vexpress-a15 board. The only Arm guest > machine that will work with KVM is the "virt" board. > > point 1) > > On the virtual open systems website they used the vexpress-a15 board. You can > read by yourself what they say : This virtual open systems guide is absolutely ancient: it must be at least a decade old, and dates from the very early days of KVM on Arm. I can't read the whole document, but I would not be surprised if they were using a custom branch of QEMU, or they might have been using a QEMU from before we added emulation of TrustZone to that board (which KVM can't emulate). You can see in the instructions that they're using a custom branch of the guest kernel (and a very ancient kernel). It's not a very good guide to what will work today. > On the devuan 4 host os that I have installed I'm using kernel 5.4,that's > lower than 5.7,so the qemu support for it should be there. It's in the kernel, but you're using a QEMU which has dropped the support. -- PMM
Re: Invalid accelerator kvm / error: kvm run failed Function not implemented ERRORS trying to virtualize a guest OS on the ARM Chromebook running with a relatively recent kernel version and KVM enable
On Thu, 10 Aug 2023 at 17:52, Mario Marietto wrote: > I conducted some further experiments : > > In this example I've used qemu 5.2.0 installed by default by the devuan 4 : > > > qemu-system-arm \ > -enable-kvm -serial stdio -kernel zImage \ > -m 512 -M vexpress-a15 -cpu cortex-a15 \ > -drive > file=/mnt/fisso/bhyve/img/Linux/ubuntu2210.img,id=virtio-blk,if=none \ > -device virtio-blk,drive=virtio-blk,transport=virtio-mmio.0 \ > -device > virtio-net,transport=virtio-mmio.1,netdev=net0,mac="52:54:00:12:34:55" \ > -netdev type=user,id=net0 \ > -append "earlyprintk=ttyAMA0 console=ttyAMA0 mem=512M \ > virtio_mmio.device=1M@0x4e00:74:0 \ > virtio_mmio.device=1M@0x4e10:75:1 \ > root=/dev/vda rw ip=dhcp --no-log" > > qemu-system-arm: invalid accelerator kvm. You can't use KVM with the vexpress-a15 board. The only Arm guest machine that will work with KVM is the "virt" board. Further, it looks like your host CPU is 32-bit. QEMU 5.2 dropped support for running KVM on 32-bit hosts, because this support was dropped from host kernels in kernel version 5.7. Basically, 32-bit hosts are just too small to do anything sensible with virtual machines, which is why the kernel (and in turn QEMU) dropped that support. If you want to play around with Arm virtualization, use a 64-bit host. (64-bit hosts can still use KVM to virtualize 32-bit guests if you want 32-bit guests.) thanks -- PMM
Re: Doubts related to QEMU platform
On Sat, 5 Aug 2023 at 15:00, Lakshmana Reddy wrote: > I am working on an ubuntu machine and using the qemu platform for emulating > an x86 architecture .And i am having some doubts related to this work which > are mentioned as follows > > Can I emulate gpio driver pins inside the virtual environment running on qemu > ? QEMU emulates GPIO for the purposes of being able to implement its own machine models (eg where an SD card card-detect line is wired to a GPIO controller in a particular SoC). It doesn't support "let the user connect GPIO lines to whatever they want in some external program". > Inside the virtual environment I couldn't ping any network, so is there any > possible way through which the virtual environment could connect with the > host/external environment which needs to be specified during the virtual > startup ? What networking are you using? With the default 'usermode' networking, ping does not work out of the box, so don't try to use ping as your test of whether networking is working. On Linux hosts, if you have root access you can give other users (like the user who runs QEMU) permissions to send ping packets. But generally there's no actual need for ping, so it's not always worth bothering. See https://wiki.qemu.org/Documentation/Networking and in particular the "Enabling ping in the guest, on Linux hosts" section. If you're using some other form of networking (eg tap mode) you won't have that particular problem, but tap mode is more complicated to set up. thanks -- PMM
Re: GPIO support on QEMU
On Fri, 4 Aug 2023 at 11:02, Swedha R wrote: > > Hi , > Is qemu will support virtual GPIO drivers. How to work on GPIO in qemu? Broadly speaking, you seem to be trying to do something that QEMU is not set up to do. QEMU's support for GPIO controllers and GPIO lines is almost entirely there so we can emulate features of boards and SoCs which are implemented via internal GPIO controllers and GPIO lines. (For example, a board might wire up the SD card "card present" line to a GPIO controller: so to make the SD card work, QEMU needs to model that GPIO controller and that line.) QEMU does not have a framework for the equivalent of a board like a raspberry pi where GPIO lines are exposed directly to pins that the end-user can wire up to other boards, to sensors, to LEDs, or to push buttons. So if you are trying to model that sort of thing, or to generally take an existing QEMU model and "use the GPIO controller outputs", you are trying to push uphill, because the facilities are basically not there to help you. -- PMM
Re: GPIO interrupt on QEMU
On Fri, 4 Aug 2023 at 10:25, Swedha R wrote: > > Hi team, > I have arm64 up and running in Qemu, And I built kernel image, rootfs > everything via buildroot open source I cloned from git. > And I customized via make - menuconfig like enabling gpio support, libgpiod > module and in device drivers gpio chip named pl061 . > After that, I able to see gpiochip in the /dev directory inside arm running > in qemu. > I want to know , how to trigger the gpio line ( that is function for > poweroff) and it have to cach and service it in this case. > The gpiochip has 7 lines in it. How to find which line is a poweroff key , > the qemu-virt board has ) If your guest is Linux it in theory [*] should have already found the power-off key GPIO by looking in the device tree that QEMU passed it (the information is in the /gpio-keys/poweroff node). You can trigger the power-down button by using the "system_powerdown" command at the QEMU monitor (HMP) prompt. [*] The guest I have didn't power down in response to the system_powerdown command, but I might well have not compiled in all the necessary kernel options for it to work. QEMU definitely does raise the GPIO line when you use the system_powerdown command. thanks -- PMM
Re: GPIO interrupt on QEMU
On Thu, 3 Aug 2023 at 14:31, Swedha R wrote: > > Hi team, > I have arm64 up and running in Qemu, And I built kernel image, rootfs > everything via buildroot open source I cloned from git. > And I customized via make - menuconfig like enabling gpio support, libgpiod > module and in device drivers gpio chip named pl061 . > After that, I able to see gpiochip in the /dev directory inside arm running > in qemu. > I want to know , how to trigger the gpio line and cache and service it in > this case. > The gpiochip has 7 lines in it. > > This is the qemu-command we used, > qemu-system-aarch64 -M virt -cpu cortex-a53 -nographic -smp 1 -kernel Image > -append "rootwait root=/dev/vda console=ttyAMA0" -netdev user,id=eth0 -device > virtio-net-device,netdev=eth0 -drive > file=rootfs.ext4,if=none,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 The GPIO devices in the virt board are there for specific purposes: there is one in the non-secure world which has an input for the "power off" key, and one in the secure world (if enabled) which has outputs for the firmware to do reset and power-off. You can't use them for other things. (Linux running on the virt board and using the dtb it is provided should automatically be able to handle the power-off key input; UEFI/Trusted Firmware knows about the secure-world GPIO controller already.) thanks -- PMM
Re: No 'virtio-bus' bus found for device 'virtio-blk-device' - Error
On Sun, 30 Jul 2023 at 21:32, Swedha R wrote: > > Hi , > when I run this following command , I am facing this problem for all machine > types rather that virt. > > qemu-system-riscv64 -M sifive_u -bios fw_jump.elf -kernel Image -append > "rootwait root=/dev/vda ro" -drive file=rootfs.ext2,format=raw,id=hd0 -device > virtio-blk-pci,drive=hd0 -netdev user,id=net0 -device > virtio-net-device,netdev=net0 -nographic virtio devices come in two parts: * a backend which does the actual work (blk, net, etc) * a transport which handles how that is exposed to the guest (pci, mmio, s390 channel controller, etc) In some cases we also provide "convenience wrapper" devices which create both the backend and the transport with a single -device option. virtio-blk-pci is a wrapper device (as you can see from the name that has both 'blk' the backend and 'pci' the transport in it). virtio-net-device is a virtio backend only. The error message is telling you there was no transport to plug it into. As a -device option, it only works for either: * boards which support the virtio-mmio transport (of the riscv boards, only virt has this support) * command lines where you explicitly create a virtio-pci transport (this is such an odd thing to do that I forget if it even works ;-)) As a general rule of thumb, the PCI transport is the best for all situations where it will work (i.e. where the board has a PCI controller and the guest OS is happy with doing PCI enumeration etc). Since your command line has a virtio-blk-pci device on it, presumably you're OK with virtio-over-pci. So you should use -device virtio-net-pci and not use virtio-mmio at all (even on the virt board). Then your use of virtio is consistent for all the virtio devices you're using, rather than being oddly split between two transport types. thanks -- PMM
Re: Problem debugging kernel driver running on guest os
On Tue, 25 Jul 2023 at 12:50, Mark Wood-Patrick wrote: > > I am trying to debug a driver issue where the driver is running on the guest > os running under QEMU 7.1.0 using gdb running on the host & connecting to the > guest. When I try to attach I get a message "qemu-system-x86_64: > -s: gdbstub: KVM doesn't support guest debugging". This used to work on QEMU > 4.2, does anyone know what changed or what the issue is and how to fix it? I have a suspicion you may be running into a bug in your host kernel. QEMU used to unconditionally assume that you could do guest debug on KVM, but this isn't generally true across host architectures, so somewhere around QEMU 6.2 we started explicitly checking "does the kernel say it supports KVM_CAP_SET_GUEST_DEBUG" before trying to use it. Unfortunately a bug in the kernel meant that on x86 it wasn't actually advertising that capability even though it had supported it for a long time. You should check that your host kernel has commit b9b2782cd55aaf5a or some backport of that: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9b2782cd55aaf5a65573df99376cf391941cb66 thanks -- PMM
Re: Qemu with E1000 NIC causing segfault when compiled statically in Docker
On Tue, 11 Jul 2023 at 15:18, Weller, Nitzan wrote: > > Hello, > > We are trying to run Qemu with E1000 as the NIC. > The Qemu we use is compiled statically using a Docker, based on > https://github.com/ziglang/qemu-static. > When we boot a VM it causes a Segfault that crashes the VM during the boot > process, before reaching the prompt. > The Core dump indicated there is an issue in libslirp. > A few things we tried: > > Compiling locally - Running a VM using static Qemu that we compiled locally > on a computer doesn't cause the Segfault. > Updating the version of Qemu or libslirp - Didn't change the outcome. > Different NIC - Using virtio instead of E1000 doesn't cause a Segfault, but > we need E1000. > > Do you have an idea what might cause this issue or how to proceed in > investigating it? If I understand your bug report right then you have: * build QEMU locally, no segfault * build identical QEMU in docker, segfaults ? In that case you should try to narrow down exactly what the differences are between the two build environments (what dependent libraries are present, what configure options passed to QEMU, what compiler version, etc), because presumably one of those differences is affecting the outcome. The other thing that would be useful here is if you can build both (the latest versions of) QEMU and libslirp with debugging enabled and reproduce the backtrace -- optimization has removed most of the useful clues from the backtrace you list here, unfortunately. thanks -- PMM
Re: qemu aarch64 info registers PC register not changing
On Mon, 10 Jul 2023 at 09:12, Jiatong Shen wrote: > > Hello community experts, > > I am trying to learn some arm64 basics using qemu. I would like to > retrieve a register value > through hmp command info register. The output is > > virsh # qemu-monitor-command --hmp eefcdf53-2fd5-40ee-91a8-858b3e621fc5 info > registers -a > every time I issue the command, PC register is always the value. My question > is should PC value be changed every time an instruction completes? Thank you > very much. > > The qemu version is 4.2.1. And the virtual machine is accelerated by KVM. It's worth looking at what that PC is in the guest, and what the guest is doing. If the guest is not particularly doing much, then it's very likely that almost all of the time when you look at it you'll find that the guest PC is pointing to the WFI in the guest kernel's idle loop. Other than that, QEMU 4.2.1 is pretty old, especially in Arm terms (where KVM support has not been so mature for as long as x86); so you could check whether a newer QEMU also behaves the same way. thanks -- PMM
Re: Need help getting QEMU to run QNX ifs.bin for Raspberry Pi on QMEU
On Tue, 6 Jun 2023 at 02:07, Ahmed Elsaka wrote: > i am trying to run QNX ifs.bin for raspberry pi on qmeu but it is not working > : > > what i actually did : > > installed qemu-system-aarch64 > downloaded ifs-rpi4.bin file from qnx sw center 3- using the follwoing > command to run this "ifs-rpi4.bin" (image file system on qemu) using the > following command : > > qemu-system-aarch64 -M virt -m 2048 -smp 4 -cpu cortex-a72 -kernel > ifs-rpi4.bin -nographic This cannot work. In general, Arm boards are not the same as each other, and a binary built to work on one board (raspberry pi 4) will not boot on another. QEMU doesn't currently have any emulation of the rpi4 so you can't run the rpi4 QNX image on it. > I also tried to use board which is supported by qemu like > "mcimx6ul-evk Freescale i.MX6UL Evaluation Kit (Cortex-A7)" > but i still facing the same issue. This has a bit more chance of working if both QNX and QEMU support the board model. Here you are probably running into the problem that QEMU does not emulate the i.MX6's "boot off an sd card image" process. You probably will need to pick apart whatever disk image the QNX build gave you to find the actual guest binary. (If you're lucky somebody else will have done this before.) You might also run into issues if QNX tries to prod some devices on the SoC that QEMU doesn't have emulation of. thanks -- PMM
Re: qemu-arm 6.2.0 command line argument
On Wed, 31 May 2023 at 18:48, Tanmay Das wrote:
>
> Hi,
>
> Hope all is well with you!
>
> I am trying to use qemu-arm to run a binary and trying to pass a command line
> argument to the main method like below
>
> qemu-arm -cpu cortex-m3 path-to-the-binary
This is the correct syntax. It works for me:
$ cat hello.c
#include
int main(int argc, char **argv) {
if (argc <= 1) {
printf("no arguments\n");
} else {
printf("argv[1] = %s\n", argv[1]);
}
return 0;
}
$ arm-linux-gnueabihf-gcc -g -o hello -static hello.c
$ qemu-arm -cpu cortex-a15 ./hello
no arguments
$ qemu-arm -cpu cortex-a15 ./hello foo
argv[1] = foo
I used cortex-a15 as the CPU because I don't have a cross
compiler that builds M-profile Linux binaries. But the
principle is the same.
If your binary isn't seeing the command line arguments
then it's likely something else is wrong. Some questions
to try to help in diagnosing what:
* Is your guest binary built for M-profile Linux?
* How exactly is the C runtime it's built against expecting
to get the command line arguments? (The other option that
can be made to work is semihosting.)
* Is the guest binary definitely successfully executing
main() and just not seeing the right command line arguments?
(i.e. check the problem is not that it is crashing before
it even gets to main, or that you're trying to print
the argument but the printing-output part goes wrong, etc.)
thanks
-- PMM
Re: arm64 disable some feature bit of ID_AA64ISAR0_EL1
On Wed, 17 May 2023 at 15:36, Jiatong Shen wrote: > > Thank you very much for the clarification. Although cpu type cannot be > changed, another > registers like aa64isar0, aa64isar1 could be changed through KVM_SET_ONE_REG > interface, > and then could potentially hide some cpu features from host. Am I right? No; as I say, the kernel does not support lying to the guest about the values of the ID registers currently. If you try this the kernel will return an EINVAL error code. > Another questions is why does arm64 have some invariant system registers? You can't from userspace change the value of an ID register because the kernel does not support lying to the guest about ID register values. You can't change it from the guest because it's architecturally a read-only register. This is not an in-principle impossible thing, it's just a feature the kernel doesn't implement. There are some interesting questions about how you handle CPU errata where the guest needs to install workarounds, which it currently does by looking at the ID registers that tell it what implementation it is running on. So there's a combination of some unanswered "how do we deal with this" questions, and the fact that it's not a small amount of work. Nobody so far who cares about having the feature implemented has stepped up to work through those questions and do the work. (The kvm-arm mailing list is the best place to talk about this for anybody who is interested in that.) -- PMM
Re: arm64 disable some feature bit of ID_AA64ISAR0_EL1
On Wed, 17 May 2023 at 14:06, Peter Maydell wrote: > > On Wed, 17 May 2023 at 03:23, Jiatong Shen wrote: > > > > Hello community Experts! > > > > I am doing some experiments with arm64 host machine. The host machine > > is kunpeng 920 5251k. I try to boot a virtual machine with the following > > command: > > > > qemu-system-aarch64 -cpu cortex-a53 -enable-kvm -smp 1 -m 4096 -M > > virt,gic-version=3 > > > > Here I have modified the code, and change kvm_target from > > QEMU_KVM_ARM_TARGET_CORTEX_A53 to 5(generic arm v8). > > This is part of what is confusing you: this is not a correct change. > > > when the vm boots, I try to use lscpu, but I still saw some feature flags > > like atomics exist. > > In a KVM VM you will always see in the guest the exact same > CPU type as the host. There is no support in the kernel for > showing the guest a different CPU type to what the hardware has. For clarity, I mean this specifically for the Arm architecture; x86 is different and will let you expose a different CPU type to the guest. -- PMM
Re: arm64 disable some feature bit of ID_AA64ISAR0_EL1
On Wed, 17 May 2023 at 03:23, Jiatong Shen wrote: > > Hello community Experts! > > I am doing some experiments with arm64 host machine. The host machine is > kunpeng 920 5251k. I try to boot a virtual machine with the following command: > > qemu-system-aarch64 -cpu cortex-a53 -enable-kvm -smp 1 -m 4096 -M > virt,gic-version=3 > > Here I have modified the code, and change kvm_target from > QEMU_KVM_ARM_TARGET_CORTEX_A53 to 5(generic arm v8). This is part of what is confusing you: this is not a correct change. > when the vm boots, I try to use lscpu, but I still saw some feature flags > like atomics exist. In a KVM VM you will always see in the guest the exact same CPU type as the host. There is no support in the kernel for showing the guest a different CPU type to what the hardware has. At the QEMU level, that means you should always use '-cpu host' when using KVM. (Or you can use '-cpu max' if you want the same command line to work without KVM. For KVM max and host do the same thing.) thanks -- PMM
Re: Why ARM CPU hot(un)plug is still unsupported?
On Mon, 8 May 2023 at 14:18, Zongyuan Li wrote: > > I’v noticed that there used to be a patch series working on it: > > https://patchew.org/QEMU/20200613213629.21984-1-salil.me...@huawei.com/ > > It seems to be working, any reason on why it is not merged? Is there any > difficulty > to implement cpu hot(un)plug in qemu-arm(especially for kvm case)? Hope I can > find something I can help. Arm hotplug is unsupported for the usual reason any large feature isn't implemented: there has been nobody who: * cares about the feature * has sufficient time to work on it * has expertise to work on it (which you need from both the person sending the patches and also from people to review it). In this case Salil sent an RFC patchset, with a note that it also depended on some kernel changes. There was some minor discussion about it but as far as I can see Salil didn't move forward with it (and any RFC patchset needs further work before it will go in, that's why it's RFC). -- PMM
Re: Analyzing PCIe enumeration in u-boot or linux using qemu, is it possible?
On Thu, 27 Apr 2023 at 10:29, Chan Kim wrote: > I thought I would try to analyze u-boot's PCIe enumeration using qemu. > I used qemu-6.2 (old now) and built it for arm-softmmu. And I built > u-boot-v2022.07 using qemu_arm_defconfig and built linux-5.15.68 using > integrator_defconfig(just because I saw CONFIG_PCI=y). The linux image > doesn' matter much because I'm only interested in u-boot now.(but if I can > analyze linux too, it will be fantastic). The Integrator is a twenty year old development board. This is a terrible choice for doing just about anything with today. It is unsurprising that it only supports base PCI, not PCIe, because the PCIe spec was published after this board was made. The docs you have found tell you which board types to use if you want PCIe and not just PCI, so do that. -- PMM
Re: Max memory on VM (debian bullseye)
On Wed, 19 Apr 2023 at 17:33, Wilm Boerhout wrote: > > Is there a Qemu/KVM live CD or such with the minimum 64-bit Debian set to > support it? The Debian official live CD image will probably do fine: https://www.debian.org/CD/live/ I don't know if QEMU is installed in it by default but if it isn't you should be able to install it from the network once you've booted the liveCD on your host. thanks -- PMM
Re: Max memory on VM (debian bullseye)
On Wed, 19 Apr 2023 at 17:27, Wilm Boerhout wrote: > (Bangs forehead to wall). I have been working too long > with Raspberry Pi's with 64 bit Debian. I never noticed > that the laptop runs a 32-bit version of Debian now. Yeah, if your *host* is running a 32-bit kernel I would definitely suggest switching that to 64-bit if you can :-) -- PMM
Re: Max memory on VM (debian bullseye)
On Wed, 19 Apr 2023 at 17:14, Wilm Boerhout wrote: > Thank you Narcis for your attention. Pc.ram is in the error message. And the > difference between GB and GiB is not the issue. > > I tried binging memory down from 12 GB, and only when it was 1 GB, it would > start the VM. Is there a restriction somewhere that I am not aware of? > Fout bij starten van domein: internal error: qemu unexpectedly closed the > monitor: 2023-04-19T16:11:28.206086Z qemu-system-i386: -object > memory-backend-ram,id=pc.ram,size=12884901888: cannot set up guest memory > 'pc.ram': Invalid argument qemu-system-i386 is the binary for 32-bit QEMU x86 targets. There is always going to be a restriction on the amount of memory it can use, because it's 32-bit. If you want as much as 12GB of RAM, don't you want qemu-system-x86_64 (and probably also a 64-bit guest) ? thanks -- PMM
Re: OpenGL 4
On Mon, 17 Apr 2023 at 18:04, Johannes Scheyerle wrote: > > Am 17.04.2023 um 19:03 schrieb Peter Maydell : > > > > On Mon, 17 Apr 2023 at 17:55, Johannes Scheyerle > > wrote: > >> > >> Hey PMM, > >> > >> thanks for the replay. But actually it doesn’t replay my question if it > >> even is possible with QEMU. Is it? It doesn't answer your question, but it does suggest that you might find that it's not worth doing a lot of effort to get accelerated graphics working if you don't think the overall VM speed will be good enough at the end of all that. -- PMM
Re: OpenGL 4
On Mon, 17 Apr 2023 at 15:53, Johannes Scheyerle wrote: > > Hey guys, > > I'm using an Macbook Air M1 and looking for a possibility to use Windows on > this computer. The most important thing is, that OpenGL 4 or higher > supported. Can your System do this? Bear in mind that on an M1 Windows will be running purely emulated (from x86 to arm) -- performance may not be good enough to meet your requirements, even if you get the graphics acceleration side sorted out. thanks -- PMM
Re: How to run different firmware in a machine with 2 cpu?
On Fri, 7 Apr 2023 at 17:05, Huang Canming wrote: > > Sorry for the wrong cmd. It'a typo after I edit the sample command. > my command is: ./qemu-system-arm -M mymachine -smp cpus=2 -kernel test1.elf > -bios test2.elf -serial stdio -serial tcp::5678,server=on,wait=off > which use 'kernel' and "bios" to load different firmwares to the 2 cpus. > >> You should only call armv7m_load_kernel() once, even if there >> is more than one CPU in the system. > > So I need to use generic loader to load file into cpu and then do cpu reset > by myself(which was done in armv7m_load_kernel). No, you don't need to do cpu reset yourself. Your board code must call armv7m_load_kernel() once and only once. > I have a few further question: > in such cases, do I need a second sysbus? or can the 2 cpus use the same > sysbus? "sysbus" is just an odd artefact of an old bit of QEMU's design. There is no "bus" there particularly - it only matters for ensuring that devices of type SYSBUS get reset. There is always exactly one sysbus. > and why the armv7m_load_kernel can only be called once? It must be called exactly once because it does some work like arranging for the CPUs to be reset. If you don't call it, the CPU reset doesn't work right; if you call it twice then it gets confused. -- PMM
Re: How to run different firmware in a machine with 2 cpu?
On Fri, 7 Apr 2023 at 11:41, Huang Canming wrote: > > hi, members. > > I'm trying to model a custom machine which has 2 cpus. Each cpu has its own > ram/rom. > > for now, I have create a different MemoryRegion for the 2 cpu. > > I want that the 2 cpu could run differnt firmware, so I use > > armv7m_load_kernel(ARM_CPU(cpu1),machine->firmware,0,0x1) > armv7m_load_kernel(ARM_CPU(cpu2),machine->kernel_filename,0,0x1) You should only call armv7m_load_kernel() once, even if there is more than one CPU in the system. If you want to do something more complex than "just load one file", then look at the "generic loader", which will allow you to specifically say "load this ELF file into the address space as seen by this particular CPU". https://www.qemu.org/docs/master/system/generic-loader.html > ./qemu-system-arm -M mymachine -smp cpus=2 -kernel test1.elf -test2.elf > -serial stdio -serial tcp::5678,server=on,wait=off This command line doesn't make sense and I'm surprised it didn't generate an error, because "-test2.elf" isn't a valid option. thanks -- PMM
Re: [QEMU 7.2.0] Emulating custom peripheral designed for qemu 4.0.0
On Thu, 30 Mar 2023 at 12:51, Fenix GDH wrote: > I am working on emulating some soho router firmwares, but most of them use > SoCs not supported by qemu. I found the Firmguide, where the authors > implemented some specific devices on QEMU 4.0.0 in order to emulate linux > kernel. I'm trying to import these devices to the latest QEMU, but I got > several compiling errors. > I noticed some functions syntax changed from version 4.0.0 to 7.2.0. > Now I'm trying to parse it manually, but is there any documentation > that can help this migration? No, we don't document internal API changes like this. You can usually find out how to change the code by looking through the git history or git blame information for where the change to the API was made to see how other boards were changed. And some fixes are simple -- for instance your issue with serial_hd() not being declared is likely just a missing #include line. thanks -- PMM
Re: Cross compilation of QEMU source code for ARM64
On Thu, 23 Mar 2023 at 19:57, Pedro Miguel Veiga de Almeida e Silva wrote: > > Hello, > > I am trying to cross compile the source code to deploy it in a xilinx ZCU106. > But every time I execute the ./configure --target-list=aarch64-softmmu > --enable-kvm and then make. > > But the file that compiles is a X86. --target-list specifies the target architecture, which to QEMU means the architecture the guest code runs. The architecture of the host (the machine QEMU runs on) is determined by what compiler you are building it with. If you run configure on an x86 machine and do not tell it "hey, you should build this with this cross compiler" then configure will just use 'gcc' and you will get x86 binaries. Typically you want to pass configure something like --cross-prefix=aarch64-linux-gnu- but this will only work if your host has the complete aarch64 cross-build environment set up, including the toolchain, pkg-config and all the necessary dependent libraries. thanks -- PMM
Re: Anyone can help me? I run KVM + QEMU failed
On Thu, 23 Mar 2023 at 06:59, Zheng Jian wrote: > > Dear Qemu technical experts: > > My question is whether QEMU also needs to support specific CPU models > when KVM is turned on? Here is the description of the problem I encountered. No, there's nothing particularly you need to enable in QEMU. > I want to run KVM+QEMU on my mobile phone, which is piexl7. Compiled > the corresponding qemu-system-aarch64 bin. > > Then put it into the mobile phone to run, and found that qemu would > hang, and then stopped running. The command line is as follows > > ./qemu-system-aarch64 -enable-kvm -m 1024 -M virt -cpu host \ >-nographic -kernel Image -drive if=none,file=disk_oe64.img,id=fs -device > virtio-blk-device,drive=fs \ > -append "earlyprintk console=ttyAMA0 mem=512M rootwait root=/dev/vda rw" There's nothing obviously wrong with this command line (well, the difference between the -m option and the mem= command line is weird but shouldn't hurt). Suggestions for debugging: * look for anything interesting in the host kernel logs * check whether 'earlycon' is any better for early kernel output than 'earlyprintk' * make sure you're using a recent QEMU * make sure you're using a recent host kernel * make sure you're using a recent guest kernel * enable QEMU's gdbstub and connect a gdb to it to see what's happening (if you're comfortable with trying to debug low-level boot issues) thanks -- PMM
Re: Generating host code in TCG mode
On Sat, 18 Mar 2023 at 23:54, 沈梦姣 wrote: > > > Thanks Peter > > > 在 2023年3月19日，上午2:52，Peter Maydell 写道： > > > > On Fri, 17 Mar 2023 at 21:01, 沈梦姣 wrote: > >> TCG knows what registers may be clobbered by a call into > >> host C code (this is set up in the tcg_target_call_clobber_regs > >> regset by code in tcg_target_init()), so the register allocator > >> will either avoid using those registers > >> > >> Look at tcg_target_reg_alloc_order in i386 host, it has these > >> clobber registers though it first allocates callee saved registers. > > > > Yes, that's the sensible order to allocate in. > > > >> for values that must > >> be preserved across the call, or else it will spill them to > >> memory. > >> > >> I didn’t see these clobber registers being saved to memory > >> before call/jmp Host C code in i386(x86-64) host, and copy > >> these memory value back to these registers > > > > If they were not saved to memory, then there must not have > > been a 'live' value in them in the example you were looking > > at. > > If TCG didn't correctly handle registers that are clobbered > > by calls, then it would not work at all. > Yes, but it will be helpful if someone provides some hints though I’m still > reviewing the code. Thanks I'm not sure what hints you want here. I've told you what the mechanism is that QEMU uses to work with registers that are trashed by calls to host C functions. If you think you see somewhere where a register isn't being saved and it needs to be, then the most likely possibility is that you've misread the debug log, and in fact TCG does not need the value in that register at that point in execution. -- PMM
Re: Generating host code in TCG mode
On Fri, 17 Mar 2023 at 21:01, 沈梦姣 wrote: > TCG knows what registers may be clobbered by a call into > host C code (this is set up in the tcg_target_call_clobber_regs > regset by code in tcg_target_init()), so the register allocator > will either avoid using those registers > > Look at tcg_target_reg_alloc_order in i386 host, it has these > clobber registers though it first allocates callee saved registers. Yes, that's the sensible order to allocate in. > for values that must > be preserved across the call, or else it will spill them to > memory. > > I didn’t see these clobber registers being saved to memory > before call/jmp Host C code in i386(x86-64) host, and copy > these memory value back to these registers If they were not saved to memory, then there must not have been a 'live' value in them in the example you were looking at. If TCG didn't correctly handle registers that are clobbered by calls, then it would not work at all. thanks -- PMM
Re: Generating host code in TCG mode
On Fri, 17 Mar 2023 at 15:17, 沈梦姣 wrote: > > Hi, > When generating host code, sometimes it has to jmp to qemu common > code(e.g. memory management code to get host virtual address), but > it seems before the jmp the caller saved registers haven’t been > pushed to stack, qemu common code is function so it can use caller > saved registers. TCG knows what registers may be clobbered by a call into host C code (this is set up in the tcg_target_call_clobber_regs regset by code in tcg_target_init()), so the register allocator will either avoid using those registers for values that must be preserved across the call, or else it will spill them to memory. -- PMM
Re: qemu running uefi problem
On Tue, 14 Mar 2023 at 11:36, Alyosha Shevandin wrote: > > Peter Maydell, > can I assume that It would be possible if there was the full emulation of the > Lenovo hardware, including the all firmware blobs and Intell ME? As a theoretical question, maybe. But that's never going to happen, so the practical answer is 'this will never work'. -- PMM
Re: qemu running uefi problem
On Sun, 12 Mar 2023 at 16:25, Ahlani Poacher wrote: > > Hello, sorry to bother you, I'm a qemu beginner. I want to use QEMU > to emulate Lenovo's UEFI firmware, but so far I have only found a > tutorial for QEMU to run EDK2 to implement UEFI. I would like to > ask how to convert the UEFI executable downloaded from Lenovo's > official website to a QEMU compliant format to emulate Lenovo UEFI > using QEMU. In general, you can't run a UEFI firmware image from real hardware on QEMU. The things the firmware will try to do are very low level and it will assume that it's running on a Lenovo laptop, which is not exactly the same hardware that QEMU provides. Even if you figured out how to extract a binary blob from whatever wrapper Lenovo puts it in for downloading, it would just crash if you tried to run it in QEMU. You should run a UEFI image that is compiled to know it is running on QEMU, like the EDK2 one. thanks -- PMM
Re: Failed to start qemu-system-aarch64 virt: qemu-system-aarch64: device requires ... bytes, block backend provides
On Thu, 9 Mar 2023 at 15:28, Alyosha Shevandin wrote: > > Hi, > I'm trying ti start virt emulation and fails with the follow error: > qemu-system-aarch64: device requires 67108864 bytes, block backend provides > 1112576 bytes > > What exactly does it mean and what could be done to prevent it? > I start it with the follow command line parameters: > qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a55 -smp > clusters=1,cores=1 -m 1024 -bios bl.bin semihosting-config > enable=on,target=native -drive if=pflash,file=fip.bin,format=raw,unit=1 The message means that the device you were trying to set up requires an image of exactly 64K in size, but the file you provided it (fip.bin in this case) is too small. You can fix this by padding out your image file with zeroes to be 64K in size. (The reason for this restriction is to deal with the question of "what happens if the guest writes to the last byte of the 64K flash device?". If the backing image is too small there's nowhere for QEMU to put that data.) thanks -- PMM
Re: Emulating graviton G3
On Fri, 3 Mar 2023 at 07:27, Robert Henry wrote: > > I cannot figure out how to make QEMU TCG emulate aarch64 Graviton G3. I'm > working against master/head of the QEMU source. > > I come up with feature names by consulting > https://marcin.juszkiewicz.com.pl/download/tables/arm-socs.html which is > compendium of the /proc/cpuinfo info crowd sourced from linux running on real > systems > > I'm trying to either (a) add features to QEMU's '-cpu neoverse-n1,...' or (b) > take features away from '-cpu max,...' > > Unfortunately, many names of implemented or unimplemented features are not > known by the -cpu mechanism. For example, from max I want to kill > "smeb16f32", or from neoverse-n1 I want to add in "svei8mm", but neither name > is known. Indeed, the only names known by -cpu are those exposed via the qmp > mechanism are of the form "sveNNN" for vector bit width NNN. > > Is there some trick I'm missing? Broadly speaking, we do not expose most architectural-level features via the '-cpu,+foo' option syntax. We only do that for features where it seems "important" to give users that level of control, or where we need to model multiple machine types that have differently-configured CPUs of the same type in real hardware. So your options are: * use one of the pre-defined CPU types * use 'max' to get everything * write a patch to define a new CPU model type that gets the ID registers and feature settings right. If there are features that we don't emulate yet then they need to be implemented first In this specific case, the Graviton G3 is a Neoverse-V1. That CPU is on Linaro's todo-list to implement: https://linaro.atlassian.net/browse/QEMU-422 The only missing pieces at the moment are: * FEAT_LSE2 support (there are patches on list for this, which might or might not make it into 8.0) * writing the function to define the CPU type (which is easy) thanks -- PMM
Re: Custom soc on ARM64, failed to load the firmware properly
On Mon, 27 Feb 2023 at 17:28, Alyosha Shevandin wrote: > > I'm building the custom SoC emulation that is based on the Cortext-a55. > > During the runtime $pc register contains 0 instead the address that is > provided in means of arm_boot_info.loader_start : > Then the quemu is started: > > qemu-system-aarch64 -s -S -nographic -machine custom-soc-machine -bios bl1.elf You're not passing a kernel. The loader_start address only applies when starting a Linux kernel directly (i.e. when not trying to run a guest BIOS blob). If you're not booting a kernel, then you get the default behaviour that the CPU has out of reset, which is that it starts at the address in the RVBAR register, which should be where your BIOS is. By default for QEMU that value is 0 -- if your SoC configures the CPU so it is something else then you can get QEMU to do the same with the "rvbar" QOM property on the CPU object. The .loader_start value should probably not be the same as the place where you put the BIOS: typically it is the base of the main RAM block, because that's where you would want to load a guest kernel. -- PMM
Re: Crash in memory_region_init_ram call chain, when --bios command line parameter is presented.
On Tue, 14 Feb 2023 at 11:54, Alyosha Shevandin
wrote:
>
> Thank you for your answer. I belive that 'owner' parameter is initialized: 1)
> without --bios parameter the code does not crash; 2) I check the the owner
> parameter before;
> Here is the fragment of my code:
>
> static void my_soc_init(MachineState *machine)
> {
>
> MySocState* state = OBJECT_CHECK(MySocState, machine, TYPE_MY_SOC);
This looks very confused. Generally in QEMU the 'board'
(inherits from MachineState) is a different object from
the SoC (inherits from DeviceState). This code seems to
think they are the same thing.
> if (!state) {
> error_report("failed to convert from the parent MachineState to
> derived MySocState");
> exit(1);
> }
>
> /*
> * Setup the memories.
> */
> memory_region_init_ram(>ram,
> OBJECT(state),
> "mysoc.ram",
> mysoc_memmap[MYSOCK_DEV_RAM].size,
> _abort);
The 'owner' argument to memory_region_init_ram() must be
either NULL or something that inherits from DeviceState.
We use the former for memory regions created by boards, and
the latter for memory regions created by SoC models.
The (cast) MachineState object you are passing is neither,
so you end up with an assertion when the code tries to do
something to it that only works with a DeviceState.
(I'm not sure why this didn't assert in memory_region_init_ram()
when it does the DEVICE() cast on the owner pointer.)
thanks
-- PMM
Re: Suitable API do build the custom SoC emulation
On Tue, 14 Feb 2023 at 10:40, Alyosha Shevandin wrote: > > I wonder if there is any other way to build emulation for the custom SoC > except using QEMU C API? I mean, the C API the one, that is used in a lot of > examples under /hw folder. The other way – the high level abstractions – > based: XML, Json, Python etc. No, at the moment the only way to write emulation of a new SoC is to do it in C as part of the main QEMU executable. -- PMM
Re: Crash in memory_region_init_ram call chain, when --bios command line parameter is presented.
On Tue, 14 Feb 2023 at 11:03, Alyosha Shevandin wrote: > > > I would appreciate any clue about the crash. > > When I start my custom SoC emulation and the –bios command line parameter us > presented, the QEMU processes crashes before the custom code even tries to > load the firmware. It crashes in the *memory_region_init_ram* call chain with > the follow stack: > > > #0 0x5613255a6932 in object_class_dynamic_cast_assert > > (class=0x56006f6b756b, typename=0x5613259e94ee "bus", file=0x5613259e94a8 > "/project/users/ashevandin/qemu-speedata/include/hw/qdev-core.h", line=217, > func=0x5613259e9828 <__func__.18> "BUS_GET_CLASS") > > at ../qom/object.c:963 > > #1 0x56132559e3a3 in BUS_GET_CLASS (obj=0x561326fd7830) at > /project/users/ashevandin/qemu-speedata/include/hw/qdev-core.h:217 > > #2 0x56132559f434 in qdev_get_dev_path (dev=0x561326d27800) at > ../hw/core/qdev.c:422 > > #3 0x5613254f489d in qemu_ram_set_idstr (new_block=0x56132710acc0, > name=0x5613270e1760 "speedata.callisto.ddr1", dev=0x561326d27800) at > ../softmmu/physmem.c:1766 > > #4 0x5613250a1069 in vmstate_register_ram (mr=0x561326d27950, > dev=0x561326d27800) at ../migration/savevm.c:3104 > > #5 0x5613254ee0c8 in memory_region_init_ram (mr=0x561326d27950, > owner=0x561326d27800, name=0x561325983052 "speedata.callisto.ddr1", > size=4294967296, errp=0x5613262c6178 ) > > at ../softmmu/memory.c:3543 Looking at the back trace, my guess is that you've passed in an 'owner' argument to memory_region_init_ram() that isn't a valid initialized device object. -- PMM
Re: migrate from qemu 2.11 to qemu 4.2 failed on arm machine
On Mon, 30 Jan 2023 at 06:53, Jiatong Shen wrote: > > Hello community experts, > >I am facing an issue to migrate a virtual machine from qemu 2.11 to qemu > 4.2 node. The command using on src node is > > qemu-system-aarch64 -M virt -vnc :2 -rtc base=utc,driftfix=slew -smp 2 -m > 4096 -cpu host -enable-kvm -nodefaults -incoming :4443 > > on the dst node, the command is > > qemu-system-aarch64 -M virt-2.11 -enable-kvm -cpu host -smp 2 -m 4096 > -incoming tcp::4443 -rtc base=utc,driftfix=slew -nodefaults > > after running migrate tcp:localhost:4443, the dest machine failed with > following message > > Segmentation fault (core dumped) > > I try to debug and find the following trace: 0xaaab0f07262c in > armv7m_nvic_neg_prio_requested (opaque=0x0, secure=false) at > /root/qemu-4.2.1/hw/intc/armv7m_nvic.c:391. > > After some investigation, I believe the issue is from > https://elixir.bootlin.com/qemu/v4.2.1/source/target/arm/helper.c#L11134 and > ARM_FEATURE_M 's value is changed from 2.11 to 4.2. > > My question is do we support migrating from 2.11 to 4.2 on aarch64 platform? > Thank you much for the help I think in theory it was supposed to work. In practice, both of those releases are very very old, and if it doesn't work then it doesn't work. This particular migration bug was fixed in commit af903caed9fc62cc in 2021 (there is no need to migrate the 'features' field at all). If you really need to run 4.2.1 then the patch should be easy to backport, but I would suggest running a newer QEMU anyway. thanks -- PMM
Re: What is the purpose for "none" machine?
On Mon, 23 Jan 2023 at 20:08, Thomas Huth wrote: > > On 23/01/2023 19.07, Matwey V. Kornilov wrote: > > пн, 23 янв. 2023 г. в 21:02, Peter Maydell : > >> > >> On Mon, 23 Jan 2023 at 17:36, Matwey V. Kornilov > >> wrote: > >>> I am playing with qemu-system-avr currently. > >>> I see that there is an "empty machine" called "none" in > >>> > >>> qemu-system-avr -M help > >>> > >>> list. > >>> > >>> Is it a real thing? I am failed to run any code with "none" machine. > >> > >> It is mostly for the benefit of management layer code (eg libvirt) > >> that wants to probe capabilities of QEMU[*], and secondarily used > >> in some of QEMU's own test suite. The 'none' machine has no CPU, > >> no devices and no RAM, which is why you can't run any code on it. > > > > Thanks for the explanation. Is there a way to manually add CPU, RAM > > and other devices in the command line if 'none' is used? > > It's doable on some targets, e.g. m68k. avr seems to be working, too: > > - You can specify a CPU with the "-cpu" command line option >(use "-cpu help" for a list) > > - You can specify a RAM region with the "-m" command line option >(it will be created at address 0) Oh, I didn't realize 'none' supported the -cpu and -m options... I suspect the limit of this thing will be the point at which you wanted a device like a UART or an interrupt controller. -- PMM
Re: What is the purpose for "none" machine?
On Mon, 23 Jan 2023 at 18:07, Matwey V. Kornilov wrote: > > пн, 23 янв. 2023 г. в 21:02, Peter Maydell : > > > > On Mon, 23 Jan 2023 at 17:36, Matwey V. Kornilov > > wrote: > > > I am playing with qemu-system-avr currently. > > > I see that there is an "empty machine" called "none" in > > > > > > qemu-system-avr -M help > > > > > > list. > > > > > > Is it a real thing? I am failed to run any code with "none" machine. > > > > It is mostly for the benefit of management layer code (eg libvirt) > > that wants to probe capabilities of QEMU[*], and secondarily used > > in some of QEMU's own test suite. The 'none' machine has no CPU, > > no devices and no RAM, which is why you can't run any code on it. > > Thanks for the explanation. Is there a way to manually add CPU, RAM > and other devices in the command line if 'none' is used? For a CPU and RAM, for some architectures where there is hotplug CPU and hotplug RAM support that might be possible (definitely not for AVR!) but I'm not sure if it's supported as an intended use case. For other devices, generally not. thanks -- PMM
Re: What is the purpose for "none" machine?
On Mon, 23 Jan 2023 at 17:36, Matwey V. Kornilov wrote: > I am playing with qemu-system-avr currently. > I see that there is an "empty machine" called "none" in > > qemu-system-avr -M help > > list. > > Is it a real thing? I am failed to run any code with "none" machine. It is mostly for the benefit of management layer code (eg libvirt) that wants to probe capabilities of QEMU[*], and secondarily used in some of QEMU's own test suite. The 'none' machine has no CPU, no devices and no RAM, which is why you can't run any code on it. [*] Management code can execute QEMU with the 'none' machine type, telling QEMU not to actually run the guest on startup, and query things via the QMP monitor protocol interface, for instance. thanks -- PMM
Re: Expected UART interrupt behavior on mps2_an521
On Thu, 5 Jan 2023 at 22:47, Eskowitz, Michael wrote: > I hope this is a simple question. I have been unable to find > documentation related to interrupt behavior on the UART of the > mps2_an521. Application note AN521 does not go into great depth > in this area and I am hoping that someone can either address my > question or point me in the right direction. > I have encountered what is possibly an emulation issue in Qemu > related to the receive interrupt of the UART. If I disable the > receive interrupt for the UART and a character arrives such that > the UART’s one byte buffer becomes full while the receive interrupt > is disabled, should an interrupt fire when I re-enable the receive > interrupt provided that the buffer is still full? The UART in the MPS2 boards is the CMSDK APB UART, which is documented in the Cortex-M System Design Kit Technical Reference Manual (ARM DDI0479): https://developer.arm.com/documentation/ddi0479/ Unfortunately it's not very detailed. It's possible we've implemented something that's not exactly what the hardware does, but you'd need to cross-check against the hardware behaviour to confirm that. thanks -- PMM
Re: Missing message from the mailing list (was: Fwd: qemu no sound)
On Tue, 20 Dec 2022 at 07:26, Paul Menzel wrote: > > Dear mailing list administrators. > > > Am 19.12.22 um 21:59 schrieb Helge Konetzka: > > […] > > > I already wrote an answer on qemu-devel list > > (https://lists.gnu.org/archive/html/qemu-devel/2022-12/msg02445.html). > > That message did not reach my inbox but is in the archive. I also do not > see any delivery attempt in the MTA logs. It’d be great, if you could > check, what went wrong. The mailing list server admins don't read this list -- we just use the GNU Savannah mailing list services (https://lists.nongnu.org/) which is a standard mailman setup. As an individual list admin I only get to see the usual list-level controls, not anything at the MTA logging level. thanks -- PMM
Re: Re:Re:Re: Fwd: qemu no sound
On Mon, 19 Dec 2022 at 16:20, wrote:> I noticed that many questions in the qemu-discus maling list are not answered here? Doesn't anyone use qemu on Windows and doesn't know the command how to start qemu-system-x86_64.exe with sound support? Where are the developers of Qemu? it would be very nice if you would give support for your project. qemu-discuss is mostly a "users can help other users" forum; some developers read it, but not all. Most QEMU upstream developers don't use Windows hosts, which is probably part of why you didn't get a response. thanks -- PMM
Re: how to connect commit to email patch
On Wed, 23 Nov 2022 at 06:12, Jiatong Shen wrote: >I am trying to investigate bug fixes and new features for qemu from 4.2. I > noticed qemu's commits are reviewed through email, but right now the only way > that I found to connect commits to a particular email is through googling. So > my question is, is there a command line tool to either obtain a patchset list > or build a relationship between commit and git-email? Generally not. You can look for the relevant patches either directly in a mailing list archive (the one with the best search facilities is https://lore.kernel.org/qemu-devel/ I think), or you can look for them in https://patchew.org/QEMU/ (which provides a web-view of patches sent to the mailing list). There are one or two command line tools for working with mailing list emails, but generally they're aimed at the use case of developers working with recently sent patches and turning them into commits, not archaeological work starting with commits from releases that are several years old and trying to work back to the mailing list emails. thanks -- PMM
Re: tftp related question
On Fri, 28 Oct 2022 at 07:57, Antonio Apostoliu wrote: > > Hello > >I use Qemu 6.2.0 on Windows 10. > I launch qemu with this script: > ..\qemu\qemu-system-x86_64.exe -m 512 -smp 1 -hda images/d.qcow2 ^ > -nic user,tftp=trf,hostfwd=tcp:127.0.0.1:-:22 > > > Before run script I typed > icacls .\trf /grant:r "%username%":(OI)(CI)F /T > > Downloads from host to vm works. > Uploads from vm to host does not works. This is expected. QEMU's built-in TFTP server is read-only: it is intended (together with the BOOTP support) for allowing guests that need to do a network boot to load the network-boot-files. It's not a general-purpose file-transfer mechanism. (We ought to document this in the docs somewhere.) thanks -- PMM
Re: Unable to make snapshots with "savevm" on OVMF guest
On Wed, 5 Oct 2022 at 23:53, wrote: > > There are no issues with "offline" snapshots with qemu-img with the > guest powered off. > > However, with "online" snapshots through QEMU monitor I get this: > > Error: Device 'pflash1' is writable but does not support snapshots > > Indeed, it's trying to use the OVMF-vars "disk", which is of course not > compatible. > > I already did internet search, but at most they suggest "just convert > the pflash1 to qcow2". > Hell! That's not what it is for. I think the problem here is that savevm will store device/CPU state on one specific QCOW2-attached storage, but any writable disks themselves must be able to support snapshots in order to be able to track "at this point when the machine was snapshotted the state of the disk contents is such-and-such". So I suspect that you need to either: * make the pflash be a non-writeable disk -- then there's no need to track what its state at the time of snapshot was, because it'll always be constant * make the pflash be backed by a qcow2 image or other snapshot-capable format, so that it can track its different contents for each snapshot point > Isn't there a way to tell savevm *which* storage to use? The monitor documentation https://www.qemu.org/docs/master/system/images.html#vm-005fsnapshots says "The VM state info is stored in the first qcow2 non removable and writable block device. The disk image snapshots are stored in every disk image." so I think the answer to that is "no", except by playing games with the command line to ensure that the disk image you want the VM state itself to be on is the "first" one. (And in any case the saved state for writeable disk images themselves must always go into each writeable disk image.) thanks -- PMM
Re: If your networking is failing after updating to the latest git version of QEMU...
On Mon, 3 Oct 2022 at 11:25, Alex Bennée wrote: > > > Peter Maydell writes: > > > On Mon, 3 Oct 2022 at 10:09, Alex Bennée wrote: > >> > >> > >> Thomas Huth writes: > >> > >> > On 29/09/2022 04.32, Jason Wang wrote: > >> >> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé > >> >> wrote: > >> >>> Jason, Marc-André, could we improve the buildsys check or display > >> >>> a more helpful information from the code instead? > >> >> It looks to me we need to improve the build. > >> > > >> > I'm not sure there is anything to improve in the build system - > >> > configure/meson.build are just doing what they should: Pick the > >> > default value for "slirp" if the user did not explicitly specify > >> > "--enable-slirp". > >> > >> Shouldn't it be the other way round and fail to configure unless the > >> user explicitly calls --disable-slirp? > > > > Our standard pattern for configure options is: > > --enable-foo : check for foo; if it can't be enabled, fail configure > > --disable-foo : don't even check for foo, and don't build it in > > no option given : check for foo, decide whether to build in support if > >it's present > > Don't we make a distinction between libs that are truly optional and > those you probably need. Yes. If something is truly mandatory then configure will always fail. This is true for zlib and glib, for instance... > It seems missing working networking is one of > those things we should be telling the user about unless explicitly > disabled. It is after all how we worked before, we would silently > checkout libslirp and build it for you. ...but building without libslirp is perfectly reasonable for some configurations, eg where you know you're going to be using QEMU in a TAP network config, and you don't want to have libslirp in your binary so you don't have to think about whether you need to act on security advisories relating to it. "no slirp" isn't like "no zlib", where you can't build a QEMU at all. I think it's more like gtk support, where we will happily configure without gtk/sdl/etc and only build in the VNC frontend -- that's a working configuration in some sense, but for the inexperienced user a QEMU which doesn't produce a GUI window is almost certainly not what they wanted. So we could: * say that we will opt for consistency, and have the slirp detection behave like every other optional library * say that slirp is a special case purely because we used to ship it as a submodule and so users are used to it being present * say that slirp is a special case because it's "optional but only experts will want to disable it", and think about what other configure options (like GUI support) we might want to move into this category I don't think there's an obvious right answer here... thanks -- PMM
Re: If your networking is failing after updating to the latest git version of QEMU...
On Mon, 3 Oct 2022 at 10:09, Alex Bennée wrote: > > > Thomas Huth writes: > > > On 29/09/2022 04.32, Jason Wang wrote: > >> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé > >> wrote: > >>> Jason, Marc-André, could we improve the buildsys check or display > >>> a more helpful information from the code instead? > >> It looks to me we need to improve the build. > > > > I'm not sure there is anything to improve in the build system - > > configure/meson.build are just doing what they should: Pick the > > default value for "slirp" if the user did not explicitly specify > > "--enable-slirp". > > Shouldn't it be the other way round and fail to configure unless the > user explicitly calls --disable-slirp? Our standard pattern for configure options is: --enable-foo : check for foo; if it can't be enabled, fail configure --disable-foo : don't even check for foo, and don't build it in no option given : check for foo, decide whether to build in support if it's present -- PMM
Re: qemu-i386 crash on signal handler return
On Sun, 2 Oct 2022 at 04:41, Tavis Ormandy wrote:
> Hello, I'm trying to use qemu-i386 on aarch64 to run an old binary and
> running into a crash.
>
> I've minimized it down to %esp getting corrupted after return from a
> signal handler return, but this seems so trivial that I must be doing
> something wrong?
>
> Here is a minimal reproducer:
>
> https://lock.cmpxchg8b.com/files/repro.s
>
> To compile it on an x86_64 machine:
>
> $ as --32 repro.s -o repro.o
> $ ld -melf_i386 repro.o -o repro
>
> # It runs totally fine on i386/x86_64:
>
> $ strace ./repro
> [ Process PID=1848 runs in 32 bit mode. ]
> sigaction(SIGALRM, {sa_handler=0x8049001, sa_mask=[],
> sa_flags=SA_INTERRUPT|SA_NODEFER|SA_RESETHAND}, NULL) = 0
> alarm(1)= 0
> pause() = ? ERESTARTNOHAND (To be restarted
> if no handler)
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> sigreturn({mask=[]})= -1 EINTR (Interrupted system call)
> exit(0) = ?
> +++ exited with 0 +++
>
> Now trying the same binary on aarch64:
> $ qemu-i386 -version
> qemu-i386 version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)
5.2 is a couple of years old now -- does the same bug still repro on
7.1 or head-of-git ?
thanks
-- PMM
Re: How I can get/dump full dtb file?
On Wed, 28 Sept 2022 at 18:27, Victor Martins wrote: > Peter Maydell escreveu no dia terça, 27/09/2022 > à(s) 16:52: >> >> > Any way, I have no problem use the -machine virt. My problem is know >> > how I can map my RISC-V SoC in the FPGA (like have control of the >> > modules map address) to can develop my applications in the future >> > using the QEMU as I use the FPGA board. >> >> You need to write a new QEMU machine model to do this (i.e. ignore >> the 'virt' board entirely). This is quite a lot of work (depending on >> how complicated your SoC is and whether it's using devices that >> QEMU already has a model of or if you need also to write models of >> all the devices) and requires some knowledge of QEMU internals. > > > But, is not possible, at least, use the dtb to force the map address? > Like Memory start at 0x700 with 32GB or UART it is at 0x10008000? > Because the new SoC in FPGA will be simple (CPU+RAM+Uart+IOs). But > I need a way to control que hardware address lines. No. QEMU never uses any of the DTB to determine what its hardware emulation should be. To change the hardware emulation you need to change the C code of QEMU itself. > And a stupid question: it is possible mount the uart from virt > machine in the host OS? And after can run a application in the > host OS that can communicate to the RISC-V SoC in the QEMU using > the serial port? QEMU emulated UARTs all connect to what QEMU calls a "chardev" interface. There are a wide variety of chardevs, including one to send data to/from a TCP socket, and one to send data/to from UNIX FIFOs. Those two are usually the easiest to use for automated communication to a host OS program. -- PMM
Re: How I can get/dump full dtb file?
On Tue, 27 Sept 2022 at 16:34, Victor Martins wrote: > Peter Maydell escreveu no dia terça, 27/09/2022 > à(s) 10:27: >> >> What are you trying to achieve by removing the "-machine virt" >> option? > Thanks Peter, you gave me a great first lesson. > I suppose the "dumpdtb" export all about the machine type and when I use the > -dtb the QEMU follow that instructions. > Basically my original plan was use this way to design my machine (using DTC > dts => dtb). All this because I wish to develop my RISC-V SoC in one FPGA. Yep, that won't work. If you want a new SoC/machine model in QEMU you need to write a lot of C code, I'm afraid. There is no magic quick route. > Any way if I do this (-machine and -dtb flags): > > $ qemu-system-riscv64 \ > -nographic \ > -machine virt \ > -kernel linux-5.19.1/arch/riscv/boot/Image \ > > -dtb ./riscv64-virt.dtb \ > > -append "root=/dev/vda ro console=ttyS0" \ > -drive file=busybox,format=raw,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -netdev user,id=eth0 \ > > -device virtio-net-device,netdev=eth0 > > > I receive this error: > qemu-system-riscv64: qemu_fdt_add_subnode: Failed to create subnode > /fw-cfg@101: FDT_ERR_EXISTS > > Im using exactly the dump dtb file. I know I´m not adding any new > information, but because this I expect will work in the same way as before :/ This is strictly speaking a bug in the virt board. What's happening is that the virt board code is trying to add an entry to the dtb, but it's already present (because it got added the first time around, when you used the dumpdtb option). But it's not a very important bug, because you're doing something weird anyway. > Any way, I have no problem use the -machine virt. My problem is know > how I can map my RISC-V SoC in the FPGA (like have control of the > modules map address) to can develop my applications in the future > using the QEMU as I use the FPGA board. You need to write a new QEMU machine model to do this (i.e. ignore the 'virt' board entirely). This is quite a lot of work (depending on how complicated your SoC is and whether it's using devices that QEMU already has a model of or if you need also to write models of all the devices) and requires some knowledge of QEMU internals. -- PMM
Re: How I can get/dump full dtb file?
On Mon, 26 Sept 2022 at 20:39, Victor Martins wrote: > And after I try use the dtb file and remove the virt board like this: > > $ qemu-system-riscv64 \ > -nographic \ > -dtb ./riscv64-virt.dtb \ > -kernel linux-5.19.1/arch/riscv/boot/Image \ > -append "root=/dev/vda ro console=ttyS0" \ > -drive file=busybox,format=raw,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -netdev user,id=eth0 \ > -device virtio-net-device,netdev=eth0 This command doesn't specify a machine type. That means you get whatever the default machine type for riscv64 is, which happens to be "spike". A kernel built for the "virt" board won't run on "spike", especially if it's passed a DTB for the "virt" board. What are you trying to achieve by removing the "-machine virt" option? In general: (1) you should always specify a machine type (even if there is a default, it's clearer to say what you want rather than relying on the default) (2) the guest kernel you pass should be built with support for that machine type (3) for machine types that automatically generate a DTB file, you should just let QEMU autogenerate and pass the DTB file; don't use the "-dtb" option on these machines > But don't work as before and I get this error: > > $ qemu-system-riscv64: -device virtio-blk-device, > > drive=hd0: No `virtio-bus´ bus found for device `virtio-blk-device´ This is because "spike" doesn't support virtio. > I feel that the dump operation dont extract the full Device > Tree. My idea is to try to use only the dtb/dts. Is that possible? -dumpdtb is giving you the complete device tree, but you seem to be confused about what QEMU does with the -dtb option. All QEMU does with the dtb file you provide is give it to the kernel you boot. The dtb file does not cause QEMU in any way to change what kind of hardware it is emulating. (dumpdtb is intended largely for debugging, so you can see what the dtb passed to the guest kernel is; there are also some rare use cases where you might want to edit it and then pass it back to QEMU. 99% of users don't need it at all.) thanks -- PMM
Re: Arm64 ELF not loading
On Sat, 3 Sept 2022 at 02:30, Little Tree wrote: > > Hi, > > I have built a simple hello world program for aarch64 like this > > $aarch64-none-elf-gcc -c -march=armv8-a -g hello.c hello.o > $aarch64-none-elf-gcc -specs=aem-ve.specs -Wl,-Map=linkmap.txt hello.o -o > hello.axf > > Then I tried to load and execute the file QEMU as given below > > $ qemu-system-aarch64 -semihosting -m 128M -nographic -monitor none -serial > stdio -machine virt,gic-version=2,secure=on,virtualization=on -cpu > cortex-a53 -kernel hello.axf -S -gdb tcp::9000 > > I have also tried another method for loading > $qemu-system-aarch64 -device loader,file=./hello.axf -machine virt -cpu max > -m 256M -S -gdb tcp::9000 > > In both the cases it looks like the binary is not loaded properly > > $ readelf -h hello.axf | grep Entry > Entry point address: 0x80001148 > > (gdb) target remote localhost:9000 > Remote debugging using localhost:9000 > 0x in ?? () > (gdb) disas _start > Dump of assembler code for function _start: >0x80001148 <+0>: .inst 0x ; undefined >0x8000114c <+4>: .inst 0x ; undefined >0x80001150 <+8>: .inst 0x ; undefined >0x80001154 <+12>: .inst 0x ; undefined >0x80001158 <+16>: .inst 0x ; undefined >0x8000115c <+20>: .inst 0x ; undefined > > > Could you please shed some light why this binary is not loading properly? The virt board has no RAM at address 0x8000_, so QEMU has successfully loaded your ELF file into nothing. You need to link your baremetal binary so that it is linked where the RAM is (or the flash, if you prefer)... -- PMM
Re: Segfault in hw/scsi/scsi-disk.c caused by null pointer
On Fri, 12 Aug 2022 at 15:41, Denis Krienbühl wrote:
>
> I’m not much further with my segfault, though I now know that the number of
> detaches likely does not matter and it seems to occur during the attach, not
> the detach part of the code.
>
> I adapted my change to be a bit more sane - I think it might make sense in
> general, as something is clearly wrong, the code can be reached somehow and
> in this case we probably just want to stop, instead of pretending everything
> is okay.
>
> So the following change also works for us, causing no segfaults:
>
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index efee6739f9..7273cd6c3d 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -775,6 +775,15 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req,
> uint8_t *outbuf)
> return -1;
> }
>
> +/* Avoid null-pointers leading to segfaults below */
> +if (!s->version) {
> +return -1;
> +}
> +
> +if (!s->vendor) {
> +return -1;
> +}
> +
> /* PAGE CODE == 0 */
> buflen = req->cmd.xfer;
> if (buflen > SCSI_MAX_INQUIRY_LEN) {
>
> I still hope to get some feedback from anyone that is familiar with hw/scsi.
> Hopefully this reaches someone who can shed some light on this.
As I said previously, this is still absolutely wrong.
If we ever get to this function with either of these
fields being NULL then there has been a serious problem,
probably a memory corruption or use-after-free, or
possibly an attempt to use a partially constructed object.
You need to find out why these fields have ended up NULL,
not just paper over the problem.
You could put in
assert(s->version);
assert(s->vendor);
if you like, though that doesn't really gain much over
just segfaulting.
thanks
-- PMM
Re: Segfault in hw/scsi/scsi-disk.c caused by null pointer
On Tue, 9 Aug 2022 at 17:26, Denis Krienbühl wrote: > On 9 Aug 2022, at 18:15, Peter Maydell wrote: >> My wild guess is that there's a race condition somewhere such >> that when you're doing this huge amount of detaches, very rarely >> a disk is detached and deleted but this INQUIRY request is >> incorrectly still sent to the disk (which being a freed object, >> might be overwritten with other stuff). But that is purely a guess. > > So.. should this be something I create a bug report for? > > >> If you can repro this on current head-of-git, or at least on >> the most recent release, then yes, file a bug report. > The best I can currently do is start to log what’s going on. Since > I’m not at all familiar with SCSI and this code-base, do you have > any tipps on what I should log to maybe find out where this > race-condition occurs? > > Or if there’s any kind of documentation I could read to understand > better what is going on in the hw/scsi subsystem and how I should > navigate the code. After reading your explanation we’ll probably > look for other workarounds, but I would love to understand what’s > going on. Paolo and Fam are the SCSI subsystem maintainers. They might know whether this sounds like a bug that's already been fixed at some point, or have other suggestions. Context (ie link to the start of this thread on the list archive): https://lists.gnu.org/archive/html/qemu-discuss/2022-08/msg00011.html thanks -- PMM
Re: Segfault in hw/scsi/scsi-disk.c caused by null pointer
On Tue, 9 Aug 2022 at 16:37, Denis Krienbühl wrote:
> We are running a Ceph 15.2.16 cluster at work, connect VMs to it using
> librbd1 14.2.22, running on the QEMU 4.2 release by Ubuntu’s Cloud Archive
> (4.2-3ubuntu6.23~cloud0).
>
> A few of our VMs randomly trigger a segfault in qemu-system-x86_64. This
> seems to only happen when lots of volume detach requests are executed in
> parallel. We can somewhat reliably reproduce this in our staging environment
> (it still takes thousands of detaches and sometimes hours of running tests
> until it occurs once). In production it is a lot rarer, but it does occur
> with some regularity.
>
> Using crash dumps and debug symbols I was able to pin-point the cause of the
> segfault to a problem with the `scsi_disk_emulate_inquiry` function. Within,
> QEMU tries to access two SCSIDiskState variables that are both `0x0`, when
> QEMU expects them to be characters.
>
> 1. `s->version`
> 2. `s->vendor`
>
> I found out that in other parts of the code (`scsi_block_realize`) those
> variables are not expected to always be valid characters, so I copied that
> over and created my own release of the distro package with this patch (here
> diffed against master):
>
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index efee6739f9..419d6e28f1 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -775,6 +775,14 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req,
> uint8_t *outbuf)
> return -1;
> }
>
> +/* Avoid null-pointers leading to segfaults below */
> +if (!s->version) {
> +s->version = g_strdup(qemu_hw_version());
> +}
> +if (!s->vendor) {
> +s->vendor = g_strdup("QEMU");
> +}
> +
> /* PAGE CODE == 0 */
> buflen = req->cmd.xfer;
> if (buflen > SCSI_MAX_INQUIRY_LEN) {
If these are NULL, then something has gone weirdly wrong (possibly
memory corruption or other Bad Things).
At least in the version of this code in upstream git, the
'realize' method does:
if (!s->version) {
s->version = g_strdup(qemu_hw_version());
}
if (!s->vendor) {
s->vendor = g_strdup("QEMU");
}
which is to say: when the device is created, if the user didn't
specify version/vendor strings via QOM properties, we set them to
these defaults. So at all points in execution after this, these
pointers can't be NULL.
> 1. I don’t have a way to reproduce this in the master.
> 2. I don’t know if this is safe.
> 3. I don’t know if this just masks the issue and the problem lies somewhere
> deeper.
Number 3.
My wild guess is that there's a race condition somewhere such
that when you're doing this huge amount of detaches, very rarely
a disk is detached and deleted but this INQUIRY request is
incorrectly still sent to the disk (which being a freed object,
might be overwritten with other stuff). But that is purely a guess.
> So.. should this be something I create a bug report for?
If you can repro this on current head-of-git, or at least on
the most recent release, then yes, file a bug report.
thanks
-- PMM
Re: how to prevent automatic dtb load?
On Thu, 4 Aug 2022 at 13:51, Chan Kim wrote: > Yes, you are right. I tried again with that -dtb option like this. > > qemu-system-aarch64 -machine > ab21q,gic-version=max,secure=on,virtualization=true -cpu max -kernel > u-boot-spl -m 8M -nographic -device loader,file=Image,addr=0x8020 -dtb > ab21m.dtb -chardev stdio,mux=on,id=char0 -serial chardev:char0 -serial > chardev:char0 > > And it proceeded with the linux booting. Thanks! > (I thought I tried this before and had the same error, but it works ok now. > Maybe I have done something wrong then.) > So I gather qemu loads the file I provide with -dtb option at the first > address of the memory(0x8000 in my case) and doesn't load the dtb it > generated instead. My virtual machine is a modified version of arm/virt). Yes, if you specify a -dtb command line option that overrides the autogenerated file. But generally you shouldn't do that. You should decide whether your new machine: * expects the user to provide a DTB, like almost all of the other boards QEMU has. This is the normal case, for when QEMU is modelling a specific fixed piece of hardware. The idea is the user passes QEMU the same dtb file that they would do to boot the kernel on real hardware. * expects to autogenerate the DTB matching whatever it does, like the virt board. This is the unusual case -- virt only does this because it is a purely "virtual" board that doesn't match any real physical hardware and which changes depending on what the user asked for. and then use it that way. More generally, if you're writing a new machine type, then 'virt' is a very bad choice for basing it on, because 'virt' is not a "normal" machine type, and does lots of things in ways that you wouldn't want to do for a straightforward "model of real bit of hardware". thanks -- PMM
Re: Snapshot customizing
On Wed, 27 Jul 2022 at 18:45, Jayakrishna Vadayath wrote: > Yes I did profile it afterwards and found that the majority of time is being > spent on loading the RAM. > I'm running QEMU with "-m 1G" and I do see that there's close to 1 gigabyte > of memory being loaded from the snapshot. > > In my use case, I need to repeatedly revert back to a snapshot after > executing a small user-space program. > I was wondering if it would be possible to identify the dirty pages in RAM > after this execution and only restore those pages from the snapshot when a > restore is encountered. > > I understand that this scenario might be very unique, but I just wanted to > know if such an idea would be feasible or not. Potentially most of the machinery is present for that (tracking dirty pages); but it would probably be a moderate development effort to get it connected up to handle the snapshot revert case correctly, and as you say it's for an extremely niche use case. thanks -- PMM
Re: Snapshot customizing
On Tue, 26 Jul 2022 at 23:11, Jayakrishna Vadayath wrote: > I'm very new to QEMU and I'm still trying to figure my way out through the > source code. > Currently I'm using the QEMU snapshot restore mechanism and I've noticed that > it usually takes close to 200 milliseconds to restore a small snapshot. > > I was thinking of ways to optimize this for my use case and I was wondering > if it would be possible to only snapshot and restore specific devices (for > example just the RAM). Have you profiled to find out where the time is being spent? For your average VM I would expect the RAM to be most of the time taken, because there's so much data to store to the snapshot. More generally, restoring only specific devices tends to result in the restored snapshot not working, because the virtual machine is no longer in a consistent state on restore. -- PMM
Re: linux shell comes out to qemu-monitor when I enter anything. (I have two uarts)
On Thu, 21 Jul 2022 at 03:46, Jakob Bohm wrote: > It would be a lot more helpful if your error message was explicit about > which items were conflicting rather than demanding the full configuration > from people affected. And don't fall for the temptation of printing out a > list of potential reasons in the fixed error text, actually print the > actual data triggering your error case. Yes, I agree. QEMU's command line handling and error messages often leave a lot to be desired. Unfortunately it's often difficult to produce good error messages, because by the time execution gets down to the point where you notice the problem it's a long way removed from the user's command line options. In this case, the stdio chardev is a self-contained object which can easily determine if another instance of it has already been created, but it doesn't know anything about what that other instance was or what the code creating that other instance was doing (or even about what the code creating this instance is doing, though at least in that case there's the opportunity for propagating an error up to the caller). -- PMM
Re: linux shell comes out to qemu-monitor when I enter anything. (I have two uarts)
On Wed, 20 Jul 2022 at 13:14, Chan Kim wrote: > > Hi, Peter Maydell, > > Thank you for the advice. > So I uncommented the stdio_in_use guard, and used this option > (because the second uart will be used) > > -chardev null,mux=off,id=char0 -serial chardev:char0 -chardev > stdio,mux=off,id=char1 -serial chardev:char1 > > And it gives me : > qemu-system-aarch64: cannot use stdio by multiple character devices That isn't a full QEMU command line. Either something else on your command line is also using 'stdio', or you've passed an option that implicitly says "use stdio" (maybe -nographic ?), or you have code in your device model that's hardwiring use of the stdio chardev. -- PMM
Re: linux shell comes out to qemu-monitor when I enter anything. (I have two uarts)
On Wed, 20 Jul 2022 at 11:27, Chan Kim wrote:
>
> Hello qemu experts,
>
> In my virtual machine I have two uart and I want to use the input/output in
> my host machine.
> For that I commented out these lines in qemu_chr_open_stdio function in
> chardev/char-stdio.c. (qemu-6.2.0)
>
> /*
> if (stdio_in_use) {
> error_setg(errp, "cannot use stdio by multiple character devices");
> return;
> }
> */
Don't do that, there is a reason why that guard is there.
If you want multiple chardevs connecting to stdio you need to
multiplex them (otherwise, which one should input from the
terminal go to?).
> And used this option for stdio.
>
> -chardev stdio,mux=on,id=char0 -serial chardev:char0 -serial chardev:char0
>
> And two serial ports are generated and is multiplexed into stdio backend.
> Actually in the software on the virtual machine, the first uart is never
> written and only the second uart is written to. But the dtb contains two
> uarts so I had to generate two frontends anyway.
If you don't care about one of the UARTs, then just don't connect
a chardev to it (or equivalently, connect an instance of the
'null' chardev, which throws away anything sent to it).
-- PMM
Re: issues with Qemu output in terminal
On Thu, 14 Jul 2022 at 20:43, James Miller wrote: > I would think the -nographic switch would be the one to get me > command-line access to the guest OS, since the man page says "Normally, if > QEMU is compiled with graphical window support, it displays output such as > guest graphics, guest console, and the QEMU monitor in a window. With this > option, you can totally disable graphical output so that QEMU is a simple > command line application. The emulated serial port is redirected on the > console and muxed with the monitor (unless redirected elsewhere > explicitly). Therefore, you can still use QEMU to debug a Linux kernel > with a serial console. Use C-a h for help on switching between the console > and monitor." I guess the terminal I start Qemu from is not being detected > as a console or something? '-nographic' just tells QEMU to emulate a machine with no graphics and with a serial terminal connected to your terminal window. It doesn't (and cannot) do anything to ensure that the software running on the machine is actually going to send text output to the serial terminal. This is like real hardware -- you can take a PC, and unplug the monitor, and connect a serial cable from the PC's serial port to a serial terminal. But unless the OS you're booting on the PC knows about the serial port, it will just try to display its output on the monitor that's not plugged in, and the serial terminal will not display anything. So generally you need both to use -nographic and *also* to use a suitably configured guest OS. How to configure the guest OS, and to what extent it can just figure out to use the serial port without much extra configuration, is entirely dependent on the guest OS. You should be able to use any howtos/documentation for how to get that guest OS to work with a real-hardware serial console. thanks -- PMM
