Calling disk I/O functions in qemu main loop
Hello all,
I am running QEMU version 5.0.1 in TCG mode. And I am looking for a
mechanism to actually run disk read and disk write functions in the TCG
guest execution loop. I am using the virtio-blk pci device and I am using a
qcow2 image file.
static inline tcg_target_ulong cpu_tb_exec(CPUState *cpu, TranslationBlock
*itb)
{
.
< disk I/O function here >
ret = tcg_qemu_tb_exec(env, tb_ptr);
.
}
I will run the disk I/O function based on some condition and I want it to
execute synchronously. After it finishes I will run the tcg execution loop
for that particular translated block.
Is it possible and acceptable to run disk I/O functions within the qemu
main loop?
What are the steps I need to follow in order to ensure the disk I/O
operation is complete before the execution of the current translated block?
If it matters, the host and target architecture is x86-64.
Thank you very much for all your help so far.
Best regards,
Arnabjyoti Kalita
Re: using bit-field to define a qom register
On Sat, 10 Jul 2021 at 03:02, Hiroko Shimizu wrote: > Anyway, if you access the second bit, does the read/write function > offset value become 1 bit automatically? If you mean the MemoryRegionOps read and write functions, those work only with byte offsets, because the guest CPU cannot make accesses to individual bits, only to bytes (for some devices, it may only be able to access word at a time). You have to write your read and write functions to do whatever the hardware would do for those byte or word accesses. -- PMM
Re: Open serial port to attach via GDB
On Sat, 10 Jul 2021 at 08:22, Dmitrii Bundin wrote: > > On Thu, Jul 8, 2021 at 12:13 PM Peter Maydell > wrote: > > The more usual way to connect to the QEMU gdbstub is to > > have it listen on a TCP port and connect gdb to that. You can > > do that by passing QEMU "-s -S" (and no -gdb option), which will > > make it pause on startup and use the default TCP port 1234. > > Yes, connecting to the gdbstub via TCP works fine. The source of > confusion was that the gdb manual page > https://qemu-project.gitlab.io/qemu/system/gdb.html#gdb-usage allows > us to use something other than TCP: > > > If you want to specify which TCP port to use or to use something other than > > TCP for the gdbstub connection, use the -gdb dev option instead of -s. > > So my first thought was to try to establish GDB connectionn using a > serial port. I'm not sure why your first thought wasn't "let's see if the recommended default works for me" ? We recommend that at the top of the gdb.html page because we expect that to be what 99% of users will want. > Or what is the potential use-case of such "other than > TCP" gdbstub connection? The default is TCP, because almost everybody wants to use that. Other types of connection are permitted mostly because the gdbstub uses the same "chardev" infrastructure that many other bits of QEMU do (allowing you to plumb not just the gdbstub but also emulated guest serial ports, the QEMU monitor, etc through to TCP, pipes, files, serial ports, parallel ports and lots of other things). Some of those choices are more likely to be useful for the gdbstub than others, but technically speaking they will all function if you need them. In theory it is perfectly possible to tell QEMU "connect the gdbstub to the host serial port", plug an RS232 cable into the back of the host machine, connect it to a totally different computer, and run gdb on that other machine telling it to talk to that machine's serial port. But unless you really need to do something that convoluted, it's a lot simpler to run gdb on the same host machine and talk to the stub with TCP :-) thanks -- PMM
After having stopped virtual-manager, I can't use command line QEMU: “Failed to get shared ”write“ lock Is another process using the image”
Hi! I've launched a virtual image through the software virtual-manager (it's a GUI allowing to launch your virtual images). I've stopped normally the image and close the software virtual-manager. But now, I can't use QEMU directly in commandline to start this virtual image (by doing /qemu-system-x86_64 /): * **Failed to get shared "write" lock** **Is another process using the image [./ubuntu.qcow2]?* I've tried to restart, I've stopped any services: /sudo systemctl stop virtlogd.service && sudo systemctl stop libvirtd.service.// / I've checked also the permissions (but it doesn't seem to be related): *-rw--- 1 thephi thephi 21G jul 10 05:24 ubuntu.qcow2* Thanks!
Re: Open serial port to attach via GDB
On Thu, Jul 8, 2021 at 12:13 PM Peter Maydell wrote: > The more usual way to connect to the QEMU gdbstub is to > have it listen on a TCP port and connect gdb to that. You can > do that by passing QEMU "-s -S" (and no -gdb option), which will > make it pause on startup and use the default TCP port 1234. Yes, connecting to the gdbstub via TCP works fine. The source of confusion was that the gdb manual page https://qemu-project.gitlab.io/qemu/system/gdb.html#gdb-usage allows us to use something other than TCP: > If you want to specify which TCP port to use or to use something other than > TCP for the gdbstub connection, use the -gdb dev option instead of -s. So my first thought was to try to establish GDB connectionn using a serial port. Or what is the potential use-case of such "other than TCP" gdbstub connection? Regards, Dmitrii
