i am using qemu-system-arm to execute a bare-metal cortex-m3 binary using a custom machine populated with emulations of memory mapped devices.
To exchange data between host and the m3 binary running in qemu, I start qemu with
-chardev udp, id=ch0, port=x, localport=y -serial chardev:ch0
Then in qemu I bind a device to serial_hds[0]. Writing to the serial device, then results in udp packets sent to the host.
My question is: do I have to make the connection to -serial ? Can I in some way access the created chardevs without using the way via the -serial?
I want to setup qemu to listen on 10 udp ports, but what I understand, the -serial option is limited to max 4 devices.
QEMU's chardev abstraction has "front ends" and "back ends".
The "back end" is whatever you connect to on the host side (which might be a UDP port, stdin/stdout, a UNIX domain socket, etc). The -chardev option is what creates and configures this back end.
The "front end" is the part on the QEMU side of this. The most common use is a UART (serial port), but you can also use chardevs to specify how to talk to the QEMU monitor, or to a guest parallel port.
In this case your problem is "what are the N things that the guest sees", ie what are the front ends? There has to be something here, which means your board needs to actually create multiple UARTs or something. -serial is a limit of 4 (you can probably raise that with a local hack changing MAX_SERIAL_PORTS), but if your device model is written to take a QEMU chardev rather than to look directly at serial_hds[] it should be possible to configure it other than via -serial (either with -device ... or -global ... to set the chardev as the device property).
Related
qemu version is 7.1.0
I use qemu to simulate xlnx-zcu102. my qemu command is below, it can run OK:
./qemu-system-aarch64 -M xlnx-zcu102 -smp 4 -m 4G ......
but, when I add -device virtio-gpu or -device virtio-gpu-device,
(I added only one device: virtio-gpu)
qemu tell me ERROR like this:
qemu-system-aarch64: -device virtio-gpu: No 'PCI' bus found for device 'virtio-gpu-pci'
I don't know how to add a virtio-gpu device to xlnx-zcu102 in qemu command.
You can't add that device to that machine type. The xlnx-zcu102 machine type simulates a piece of real hardware that does not have a PCI bus, and so you cannot plug PCI devices into it. You need to either use a different machine type, or else not use virtio devices.
ARM AT91 can not startup in QEMU. I can't get any print on the console.
I am trying to use QEMU(latest code pulled by git) to simulate an ARM AT91 board. But when startup the QEMU, I got no print in the console. In my understanding, there would be two steps to achieve this:
1, Property setup with the memory address in QEMU, let the QEMU decompress zImage. In this step, I will see "Uncompressing Linux...done, booting the kernel."
2, Property setup the output device(eg: uart0). I will get the kernel startup message.
I've succeeded in starting up with the ARM versatilePB because the QEMU supports versatilePB itself. The difference between versatilePB and AT91 is they have different SDRAM address. I've tried to modify loader_start to 0x20000000 but it seems still not work.
hwaddr loader_start;//0x2000000, which is AT91 SDRAM address
memory_region_add_subregion(sysmem, 0x2000000, ram);
At least it should print Uncompressing Linux...done, booting the kernel., which indicates that the zImage is executed and decompressed.
QEMU (at least upstream QEMU) does not have a model of the AT91 SoCs. The differences between these systems and ones like the versatilePB that QEMU does support are greater than just "the RAM is at a different address" -- they will have different devices of all kinds (including the UART) which both behave differently and are found at different locations. It is impossible to run bare metal code intended for an AT91 without implementing in QEMU a model of the correct board and at least some of the AT91 devices. The changes required would be much much more substantial than just changing a few addresses for the RAM base address.
Now I make low level bare-metal tool for RPi.
And I need to get Secure Configuration Register value.
I wrote the following instruction mrc p15, 0, r0, c1, c1, 0 to get it.
But CPU goes into Undefined Exception Mode and CPSR value is 0x600001DB.
Instruction of reading SCR value is the first instruction being executed by CPU.
I'd read ARM1176JZF-S TRM r0p7 several times but I've not found any restriction on using SCR reading instruction except being CPU in the Secure Privileged Mode but according to TRM this CPU starts from Secure Privileged Mode. If to be more concrete the initial mode is Secure Supervisor Mode.
I use the following command to execute code with QEMU
qemu-system-arm -cpu arm1176 -M versatilepb -m 256 -nographic -kernel start.elf -s -S -monitor stdio
I can't understand what I overlooked?
QEMU's versatilepb board does not support TrustZone: it creates a CPU with that feature disabled.
Other QEMU board models do support TZ, if you want to play with it: for instance vexpress-a9, vexpress-a15 and raspi2; also "virt", if you pass -machine secure=on on the QEMU command line.
I've found I can have the guest write to the port specified by the command line flag isa-debug-exit, and the value written to the port gets used as the exit code of QEMU (after some predictable transformation).
Is there an equivalent mechanism for aarch64 / arm64?
You can use the semihosting API for that: see
qemu-system-aarch64 exit from within the guest system for details (and also the caveats about needing to trust the code in your guest if you use it).
I have been trying to set cpu affinity for a VM. Now, I edited the VM xml file present in /etc/libvirt/qemu/$VM.xml and put cpuset attribute. I have 4 cores and I put cpuset = '1,3'. But still when I did virsh vcpuinfo $VM, it showed that my VM's vcpus are still attached to pcpus 0 and 2. What am I doing wrong?
Would you mind pasting out the elements of your domain xml? you may refer to [CPU Allocation] to compare.
A handy tool is command taskset -p <your qemu process id> to see the CPU allocation on the KVM hypervisor.
BTW: you need qemu v0.8.5+ to get this feature.
Editing /etc/libvirt/qemu/$VM.xml under libvirt's hands is not what you should do, neither is setting the affinity without libvirt. In that case libvirt doesn't know about the settings.
The right thing to do is use 'virsh edit $VM', set what you want and stop and start the domain. You can also use virsh to pin each vCPU to particular host CPU(s):
for i in {1..X}; do # X is the number of VCPUs
virsh vcpupin $VM 0 1,3
done
virsh emulatorpin $VM 1,3
or
virsh numatune $VM --nodeset 1,3 # To pin to particular
You can use '--config' and '--live' to set it in config or for live domain respectively. For further options see the manual for comman virsh (man virsh).