Is there a simple way to monitor the syscalls of processes
running in a VM from the outside on the hypervisor (dom0) in a Xen setup?
In general, is that an easy task or are modifications on the hypervisor code necessary to do such a VM syscall monitoring?
Is it also possible with a HVM VM or only with a PV VM?
Not sure if you already looked at these link:
http://hal.archives-ouvertes.fr/docs/00/43/10/31/PDF/Technical_Report_Syscall_Interception.pdf
http://research.microsoft.com/pubs/153179/sim-ccs09.pdf
http://pages.cs.wisc.edu/~remzi/OSTEP/vmm-intro.pdf
With very limited knowledge on subject, I am making an attempt. one can emulate instruction used to make a syscall. e.g. sysenter, sysexit. Thus for any attempt by guest to use these instructions should trap for hypervisor to intervene. Once hypervisor comes into picture, you can copy syscall number and its arguments.
Related
I am using the libvirt/QEMU/KVM stack to run some VMs on an Ubuntu 20.04 host. I am using the virsh CLI tool for VM management. I'd like to allow multiple VMs to access the same device (FPGA) over PCIE. It seems that libvirt doesn't allow this, and when I attach the PCIE device to multiple VMs and try to power more than one on, I get the following error.
error: Failed to start domain ubuntu-guest-2
error: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain ubuntu-guest-1
This kinda makes sense to me, as there shouldn't be conflicting data sent over the PCIE bus. But nonetheless, does anyone know a workaround to make this happen?
There are a number of techniques to share a device across VMs. All of them require either device-specific software support in the VMM, hardware in the device to support sharing (SR-IOV), or both (Scalable IOV).
For a custom FPGA design, you would need to provide this.
SR-IOV is part of the PCIe specification, so there may be libraries available that you could incorporate into your FPGA design.
I wish I could connect to virtual machines started with QEMU.
Then I should extract the information about the registers (EIP, EBP, etc.)
In XEN for this, there is the function get_vcpu_context, also there are other functions through which you can connect to each virtual machine separately.
Is there any such support for QEMU, and where can I find QEMU hypercalls documentation?
You have a couple of options:
you can connect to the QEMU gdbstub and use the GDB remote protocol to query CPU state. This is probably the most reliable method.
you can connect to the QEMU monitor and use the "info registers" command. Note that the output format of this might change between QEMU releases, though (it is intended for human consumption, not other programs), so it will be less reliable long-term than using GDB remote protocol.
I hear a lot about "Hypervisors are not emulators. If you need to emulate another hardware specifications than you computer have, you need to use emulator, not hypervisor".
Well, but yesterday I saw this video on youtube - click here - which shows how to install Win 95 on modern macOS with VMware Fusion.
The strange thing for me is that on 17:39 you could see that Win 95 virtual machine is "Pentium Pro with 64 MB RAM".
Hmm! So, Fusion somehow faked processor and RAM, right? But it is not emulator, right? So, does it mean that any hypervisor can fake processor and RAM?
At the time of its release, Windows 95 only had code to recognize CPUIDs up to Pentium Pro. Any processor not lower than Pentium Pro is "called" Pentium Pro.
The main difference is the Hypervisor cannot emulate CPU code. All code must run on the original processor.
The hypervisor does emulate the BIOS, which in tells the OS the hardware specs available; including RAM, Boot order and peripherals attached.
When you are talking about VMWare Fusion the way this works depends on how virtualization is achieved. According to wikipedia VMWare Fusion utilizes hardware-assisted virtualization, dynamic binary translation, and para-virtualization.
In the hardware-assited virtualization case, #Strom is correct and guest instructions can be executed directly on the host CPU. Besides #Strom answer, you can fake the CPU type by trapping and emulating the cpuid instruction.
In the para-virtualization case you replace critical instructions by calls to the hypervisor which emulates the instruction on behalf of the guest. So again you emulate the cpuid instruction to "fake" the CPU type. Keep in mind that this requires a modified, hence para-virtualized, guest operating system.
Finally, dynamic binary translation scans the guest code for critical instructions during runtime and either replaces them by traps into the hypervisor achieving some kind of "live para-virtualization" or translating blocks of guest code into equivalent blocks of host code that modifies the VM state according to the original guest code (this is e.g. how the QEMU full system emulator works). As a result, again you are able to "fake" the CPU type by emulating the cpuid instruction. Notice that guest and host can be the same architecture in this case, but there is no need for this.
Of course a combination of above techniques is also feasible.
As for virtualization of main memory, the hypervisor is in full control of the hardware so you can simply configure a VM with just 64MB of main memory. The VM is not able to "see" more than this due to the techniques shortly discussed above.
Please keep in mind that this just gives a very short overview of virtualization and I tried to keep it short and informative, so I know my explanations are partially not very accurate. If you are really interested in virtualization I recommend reading "Virtual Machines: Versatile Platforms for Systems and Processes" or the papers on the topic by Popek & Goldberg and "Xen and the Art of Virtualization"
I've been looking at QEMU for a while now and I've been trying to find out if I can use it to simulate a device that we are developing.
The device will be powered by an ARM Cortex M3 and QEMU is well suited for emulation of its software.
What I want to know is if anyone has used QEMU in the past as a simulator?
The intent is to use QEMU to do black-box testing of the software before rolling it out to the devices in the field.
This would involve being able to monitor and modify the memory location in which your Parallel Input/Output (PIO) pins are configured and set and the memory locations of all other peripherals externally.
Now, considering that some of the peripherals would be PWM and UART, it is clear that there will be a need to resolve synchronization issues. However, I would like to avoid this topic for the time being and stick only to simple PIO.
The QEMU Monitor gets close but is not quite there yet.
So to summarize:
I need to know if there is a way to interrupt QEMU after each CPU clock cycle and read/write to a small number of memory locations in the code memory.
Did you try to use GDB stub ? You can use -s -S and connect through gdb by target remote :1234. This will give you control over program executed inside vm and access to registers and memory.
Is there anyway that you can expose local partition or disk image through your computer usb to another computer to appear like external drive on mac/linux/bsd system ?
I'm trying to play with something like kernel development and I need one system for compiling and other for restarting/testing.
With USB: Not a chance. USB is unidirectional, and your development system has no way of emulating a mass storage device, or any kind of other USB device.
With Firewire: Theoretically. (This is what Apple's target disk mode is using.) However, I can't find a readily available solution for that.
I'd advice you to try either virtualization or network boot. VirtualBox is free and open software, and has a variety of command line options, which means it can be scripted. Network boot takes a little effort to set up, but can work really well.
Yet another option, is to use a minimal Linux distribution as a bootstrap which sets up the environment you want, and then uses kexec to launch your kernel, possibly with GRUB as an intermediary step.
What kind of kernel are you fiddling with? If it's your own code, will the kernel operate in real or protected mode? Do you strictly need disk access, or do you just want to boot the actual kernel?