Re: semihosting option
On Thu, 2025-02-27 at 09:55 +, Peter Maydell wrote: > On Thu, 27 Feb 2025 at 05:44, Yanfeng Liu wrote: > > I am wondering QEMU semihosting for ARM or RISCV targets allows user to > > control > > the set of functions available in semihosting? for example, I want give > > read- > > only host folder share and poweroff functions to a guest. Is this possible? > > No, these are not things that the semihosting ABI includes. > Semihosting does allow the guest to read and write *any* > file on the host, so you mustn't give it to an untrusted > guest. And there's no poweroff function in semihosting. > (There is a SYS_EXIT, but this will exit the whole of QEMU > in a pretty abrupt way; it's not like a powerdown.) > > The semihosting ABI is provision of a specific set of > functions defined in an external specification; it's not > something that we created in QEMU. The main aim of > semihosting is for debugging, especially debugging of > standalone or lowlevel guest code. It's not intended > or ever going to be something for providing arbitrary > VM services to a full-featured guest OS. > > -- PMM Thanks for the clarification. Regards, yf
QEMU arm boot all CPUs
Dear experts, With `qemu-system-arm -M virt -smp 2`, it seems that secondary core is halted upon boot and needs be brought up via PSCI later. I am wondering if there is a way to tell QEMU to boot all cores upon boot without having to use PSCI? I couldn't find an option in the manual yet. Regards, yf
Re: semihosting option
> On 27 Feb 2025, at 07:43, Yanfeng Liu wrote: > > Dear experts, > > I am wondering QEMU semihosting for ARM or RISCV targets allows user to > control > the set of functions available in semihosting? When it was done, a few years ago, the implementation of QEMU semihosting for ARM or RISCV targets tried to follow the semihosting specifications by Arm. - https://github.com/ARM-software/abi-aa/blob/main/semihosting/semihosting.rst There might be recent additions that need to be implemented, I did not check the current specs. Project maintainers have the final say, but, from my point of view, if your requirements are not yet implemented but are supported by the current Arm specs, contributions should be welcome. Regards, Liviu
Re: semihosting option
On Thu, 27 Feb 2025 at 05:44, Yanfeng Liu wrote: > I am wondering QEMU semihosting for ARM or RISCV targets allows user to > control > the set of functions available in semihosting? for example, I want give read- > only host folder share and poweroff functions to a guest. Is this possible? No, these are not things that the semihosting ABI includes. Semihosting does allow the guest to read and write *any* file on the host, so you mustn't give it to an untrusted guest. And there's no poweroff function in semihosting. (There is a SYS_EXIT, but this will exit the whole of QEMU in a pretty abrupt way; it's not like a powerdown.) The semihosting ABI is provision of a specific set of functions defined in an external specification; it's not something that we created in QEMU. The main aim of semihosting is for debugging, especially debugging of standalone or lowlevel guest code. It's not intended or ever going to be something for providing arbitrary VM services to a full-featured guest OS. -- PMM
QEMU Support for STM32G4
Hi , I was exploring options for STM32G4 emulator and found that QEMU supports STM32 I could not find support for STM32G4 though. Could you share the support package if available for STM32G4 and necessary documentation towards using the emulator for my development? Regards Shrijith N Sharma ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
