I saw the following discussion and had some questions:
live resize of a NVMe drive
If the physical capacity of the nvme device changes (e.g., from 10GB to 20GB), how the operating system detect it without rebooting?
In the above link, re-scanning pci bus is solution.
When the re-scanning be executed, does the operating system ask the nvme device to update its meta-info (e.g., capacity, etc.) ?
How does OS interact with disk specifically? (How to read changed device parameters from the disk, not the old device parameters in memory?)
This is an AWS virtual-machine probably so the disk is actually a virtual-disk. You can't resize a physical disk like you upgrade its capacity physically (you'd need to change the disk).
With that said, this machine probably runs on top of a type 1 hypervisor. What I understand about these is that the virtual machines (VMs) run as processes on a different ring on top of a minimal operating-system (hypervisor). When the VMs execute privileged instructions, it will trigger a protection fault and the hypervisor can thus inspect who actually triggered the fault (was it the guest kernel or a user mode process within the guest kernel?). If it was the guest kernel than it can execute that instruction on behalf of the guest. Otherwise, it will probably do what a real kernel would do (trigger an exception). It can tell the difference because the guest kernel runs in a different ring than the ring 3 (user mode).
With that said, the NVME device isn't PCI it is NVME. The host controller of the NVME drive is PCI. To rescan the NVME drives, you will read/write to some registers that are memory mapped in RAM and ask the NVME PCI host controller what is the size of the different disks that are found. PCI is known to be hot pluggable (similarly to USB) in some cases but mostly not on consumer motherboards. I don't think you'll get any interrupt when a PCI device is hot plugged so you are left doing a rescan of the devices.
For NVME, it depends on the host controller if you'll get an interrupt when a disk is swapped/changes size. As to virtual-disks, it probably depends on a lot of different things. You could definitely be left doing a PCI rescan here. I guess it depends on the hypervisor, on the OS and on the host controller configurations.
Related
In a computer having two or more hdds(Hard disk drive, such as hard disks, cd-roms, usb disks), the bootloader uses bios int 13h/42h to load sectors from the booted hdd. When the os is loaded, I guess it will erase all the bios code and scan all the hdds available by itself. Before that, I think the os must know which hdd it booted from. The only way the os can know that is to ask bios, I think. For example, there are 3 usb disks, 3 hard disks(on the pci bus) attatched to the computer, the os must know which one it booted from. So I want to ask how the os gets that infomation?
First consider the situation when there is only one operating system installed. Now I run some executable. Processor reads instructions from the executable file and preforms these instructions. Even though I can put whatever instructions I want into the file, my program can't read arbitrary areas of HDD (and do many other potentially "bad" things).
It looks like magic, but I understand how this magic works. Operating system starts my program and puts the processor into some "unprivileged" state. "Unsafe" processor instructions are not allowed in this state and the only way to put the processor back to "privileged" state is give the control back to kernel. Kernel code can use all the processor's instructions, so it can do potentially unsafe things my program "asked" for if it decides it is allowed.
Now suppose we have VMWare or VirtualBox on Windows host. Guest operating system is Linux. I run a program in guest, it transfers control to guest Linux kernel. The guest Linux kernel's code is supposed to be run in processor's "privileged" mode (it must contain the "unsafe" processor instructions!). But I strongly doubt that it has an unlimited access to all the computer's resources.
I do not need too much technical details, I only want to understand how this part of magic works.
This is a great question and it really hits on some cool details regarding security and virtualization. I'll give a high-level overview of how things work on an Intel processor.
How are normal processes managed by the operating system?
An Intel processor has 4 different "protection rings" that it can be in at any time. The ring that code is currently running in determines the specific assembly instructions that may run. Ring 0 can run all of the privileged instructions whereas ring 3 cannot run any privileged instructions.
The operating system kernel always runs in ring 0. This ring allows the kernel to execute the privileged instructions it needs in order to control memory, start programs, write to the HDD, etc.
User applications run in ring 3. This ring does not permit privileged instructions (e.g. those for writing to the HDD) to run. If an application attempts to run a privileged instruction, the processor will take control from the process and raise an exception that the kernel will handle in ring 0; the kernel will likely just terminate the process.
Rings 1 and 2 tend not to be used, though they have a use.
Further reading
How does virtualization work?
Before there was hardware support for virtualization, a virtual machine monitor (such as VMWare) would need to do something called binary translation (see this paper). At a high level, this consists of the VMM inspecting the binary of the guest operating system and emulating the behavior of the privileged instructions in a safe manner.
Now there is hardware support for virtualization in Intel processors (look up Intel VT-x). In addition to the four rings mentioned above, the processor has two states, each of which contains four rings: VMX root mode and VMX non-root mode.
The host operating system and its applications, along with the VMM (such as VMWare), run in VMX root mode. The guest operating system and its applications run in VMX non-root mode. Again, both of these modes each have their own four rings, so the host OS runs in ring 0 of root mode, the host OS applications run in ring 3 of root mode, the guest OS runs in ring 0 of non-root mode, and the guest OS applications run in ring 3 of non-root mode.
When code that is running in ring 0 of non-root mode attempts to execute a privileged instruction, the processor will hand control back to the host operating system running in root mode so that the host OS can emulate the effects and prevent the guest from having direct access to privileged resources (or in some cases, the processor hardware can just emulate the effect itself without getting the host involved). Thus, the guest OS can "execute" privileged instructions without having unsafe access to hardware resources - the instructions are just intercepted and emulated. The guest cannot just do whatever it wants - only what the host and the hardware allow.
Just to clarify, code running in ring 3 of non-root mode will cause an exception to be sent to the guest OS if it attempts to execute a privileged instruction, just as an exception will be sent to the host OS if code running in ring 3 of root mode attempts to execute a privileged instruction.
I was looking for an answear but didn't find one.
I'm trying to create a new VM to develop a web application. What would be the optimal processor settings?
I have i7 (6th gen) with hyperthreading.
Host OS: Windows 10. Guest OS: CentOS.
Off topic: RAM that should I give to VM should be 50% of my memory? Would it be ok? (I have 16GB RAM)
Thanks!
This is referred to as 'right-sizing' a vm, and it is dependent on the application workload that will run inside it. Ideally, you want to provide the VM with the minimum amount of resources the app requires to run correctly. "Correctly" is subjective based upon your expectations.
Inside your VM (CentOS) you can run top to see how much memory and cpu % is being used. You can also install htop which you may find friendlier than top.
RAM
If you see a low % of RAM being used, you can probably reduce what you're giving the VM. If you are seeing any swap memory used (paging to disk), you may want to increase the RAM. Start with 2GB and see how the app behaves.
CPU
You'll may want to start with no more than 2vCPUs, checkout top to see how utilized the application is under load, and then make an assessment for more/less vCPUs.
The way a hosted hypervisor (VMware Workstation) handles guest CPU usage is through a CPU scheduler. When you give a vm x number of vCPUs, the VM will need to wait till that many cores are free on the CPU to do 'work'. The more vCPUs you give it, the more difficult (slower) it will be to schedule. It's more complicated than this, but I'm trying to keep it high level. CPU scheduling deep dive.
I am trying to understand how virtualization was performed in the past using shadow page tables. The articles I've read all talk about about the translation from Guest Virtual Memory to Host Physical Memory. I understand how the Shadow Page tables eliminate the need for a Guest Virtual to Guest Physical Translation. My question is, what happened to the Host Virtual to Host Physical step. (HVA --> HPA).
Do the Virtual Machine Managers in the cited articles, not use virtual memory in the host at all? Are they assumed to have direct access to the Physical memory of the host system? Is it even possible? I thought the TLB cache translation is implemented in hardware by the MMU and and every instruction's addresses are translated from virtual to physical by the MMU itself. But then again, I am not sure how kernel code works with TLB? Do kernel instructions not go through TLB?
I am not sure if I got your point accurately, I'm trying my best to answer your question.
There is no need for HVA->HPA because what guest wants is HPA instead of HVA. Which means HVA is useless for a guest accessing its guest memory region.
So the transfer flow you expected might be without considering shadow page table may be:
GVA -> GPA -> HVA -> HPA
But as most hypervisors are running in kernel mode, who knows how the host's and guest's memory is allocated, so it can map GPA to HPA directly and eliminate the need of HVA:
GVA -> GPA -> HPA
This guest memory translation flow is nothing related to the userspace of hyperviosr, whose flow is HVA -> HPA.
Not sure if above answers your question.
The answer can be yes or no. If yes, the hypervisor maps guest RAM into virtual memory on the host, so the host may swap it in and out of host RAM. If no, the hypervisor maps guest RAM into locked physical memory on the host.
VirtualBox is in the no group. VirtualBox runs a device driver in the host kernel, and uses this driver to allocate locked memory for guest RAM. Each page of guest RAM stays resident at a fixed host physical address, so the host can never swap out the page. Because of this, guest RAM must be smaller than host RAM. VirtualBox's manual says to spare at least 256 MB to 512 MB for the host.
The MMU can only map virtual addresses to physical addresses. In VirtualBox, the guest has an emulated MMU to map guest virtual addresses to guest physical addresses. VirtualBox has its own map of guest physical addresses to host physical addresses, and uses the host MMU to map guest virtual addresses to host physical addresses. Because of locked memory, the host physical addresses never become invalid.
Mac-on-Linux is in the yes group. I once used it to run a guest Mac OS 9 inside a host PowerPC Linux. I gave 256 MB of RAM to Mac OS 9, but my real Linux machine had only 64 MB of RAM. This worked because MOL maps guest RAM into host virtual memory, with an ordinary mmap() call in a user process. MOL then uses a Linux kernel module to control the host MMU.
But the host MMU can only map to host physical addresses, not virtual ones. The guest has an emulated MMU that maps guest virtual to guest physical. MOL adds a base address to translate guest physical to host virtual. MOL's kernel module uses the host map to translate host virtual to host physical, then uses the host MMU to map guest virtual to host physical.
If Linux swaps out a page of guest RAM, then the host physical address becomes invalid, and the guest system might overwrite someone else's memory and crash the host. There must be some way to notify MOL that Linux has swapped out the page. MOL solved this problem by patching an internal Linux kernel function named flush_map_page or flush_map_pages.
KVM is also in the yes group. Linux added a kernel feature called memory management notifiers to support KVM. When QEMU uses KVM for virtualization, it allocates guest RAM in host virtual memory. The MMU notifier tells KVM when the host is swapping out a page.
I am trying to understand hardware assisted virtualization for a project with ARM CortexA8 and using the ARM Trustzone feature. I am new to this topic therefore I started with Wiki entries to understand more.
Wikipedia explains hardware assisted virtialization and adds a line in the definitionas:
Full virtualization is used to simulate a complete hardware
environment, or virtual machine, in which an unmodified guest
operating system (using the same instruction set as the host machine)
executes in complete isolation.
The text in bold is a bit confusing. How is the same instruction set of the processor used to provide two isolated environment? Can someone explain it? ArmTrustzone manual also talk of a "virtual processor core" to provide security. Please throw some light.
thanks
The phrase "using the same instruction set as the host machine" means that the guest OS is not aware of the virtualization layer and behaves as if it is executed on a real machine (with the same instruction set). This is in contrast to the para-virtualization paradigm in which the guest OS is aware of virtualization and calls some specific VMM functions, i.e. hypercalls.
No, CPU has not additional instructions. Virtual machine instruction set is translated by a hypervisor component called VMM (virtual machine manager) to be executed on the physical CPU.
Physical CPU with assisted Virtualization introduced only a new ring 0 mode called VMX that allow the virtual machine to execute some instructions in ring 0.