Hi Jidong, Thanks for the reply. I think I've gathered adequate explanation now. Many thanks to you guys!
Best regards, Kun Cheng 2015-01-30 9:53 GMT+08:00 Jidong Xiao <jidong.x...@gmail.com>: > On Thu, Jan 29, 2015 at 3:00 AM, Kun Cheng <chengku...@gmail.com> wrote: >> Hi, Fam >> Thanks for your reply. So a VM process cannot use IPC because it's not >> provided with certain abilities as the concerned resources or >> functions are hide (not virtualised or not provided) from it. But in >> another case, we do know VMs can interact with the host via hypercalls >> . This, however, makes a vm has potentials to communicate with each >> other (I've noticed some papers about inter-vm communication took >> advantages of such mechanism). And that can be seen as 'the hypervisor >> provides certain resources to the vm so the latter can use them to >> communicate', right? >> >> But, if the IPC concerned resources were virtualised, then those VM >> processes would have communicated with each other via IPC? >> >> ps: I never thought deeply about those things untils somebody asked >> me. Now I really got confused on some issues. >> >> > Hi, > > I think you can take a look at the original KVM paper. > > https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf > > That paper basically explain how Qemu/KVM based virtual machine is > working. Basically, the Guest OS is a part of the Qemu process, but > itself is not a process, from the host's perspective. The Qemu process > is a user-process running on the host, therefore, the Qemu process can > communicate with any other processes on the host, via various IPC > mechanisms. Qemu emulate everything, including various hardware, bios, > the Guest OS can see these emulated stuff, and thinks they are real > stuff, but it cannot see the external world, i.e., any other processes > running on the host, thus it could not communicate with other > processes. > > Indeed there are several research papers trying to provide the > inter-vm communication mechanisms, and yes, if the hypervisor wants to > achieve this, it surely can. The hypervisors can provide/create > various channels for the Guest OS. > > -Jidong > >> >> >> 2015-01-29 17:38 GMT+08:00 Fam Zheng <f...@redhat.com>: >>> On Thu, 01/29 16:51, Kun Cheng wrote: >>>> Hey guys, >>> >>> Hi! >>> >>>> >>>> That might be a dumb question, but currently I find myself unable to >>>> clearly explain that to others. As we all know how CPU and memory is >>>> virtualised, and how memory address space is translated using the >>>> shadow page table or EPT, that creates each VM an individual running >>>> space. However, as each VM process is essentially an Linux process, >>>> how are they unable to do IPC among them? >>>> >>>> I tried to answer that question, but I was not confident about my >>>> explanation. >>>> >>>> Here's what I thought about. >>>> >>>> First, VMM like Xen or KVM supports virtualised OSes (paravirtualised >>>> or hardware-assisted virtualised). OS provides IPC mechanism but >>>> itself cannot use it to communicate with another OS. Although they run >>>> in guest machines which are essentially host's processes , they still >>>> cannot do IPC with others. >>>> >>>> Second, each VM process runs in an individual virtualised platform, >>>> it's the only OS running dominantly on its own virtualised resources, >>>> so it's unable to be aware of others. >>>> (But as each VM process has its PID, their processes have the >>>> potentials to do IPC if another one's PID is notified? ) >>>> >>>> Finally, the question can be described as, how does KVM enhance the >>>> process isolation to prevent those VM processes to IPC with each >>>> other? >>> >>> Unlike a normal process on the host OS, a VM doesn't have any access to >>> host OS >>> resources, except those that are intentionally "virtualized", such as CPU, >>> memory and IO devices: basically all of which have a behavior that resembles >>> real hardware. >>> >>> IPC, in contrary, is usually supported by an OS in the form of system calls, >>> which is a totally different category of resources or functions, that is not >>> "virtualized" by the hypervisor, thus it is essentially not exposed to >>> guest. >>> >>> The hypervisor makes sure that the guest doesn't see the existence of host >>> process where the guest lives at all - it doesn't need to know, nor should >>> it. >>> >>> In order to communicate with outside, guest has to only use whatever are >>> provided to it - specifically, IO devices, be it a paravirtualized NIC or >>> emulated USB device. >>> >>>> >>>> I also notice that KVM seems to be benefited from cgroups, is that >>>> contributing to the isolation? >>> >>> It's not the fundamental of virtualization, although could possibly be >>> utilized >>> in some cases to enforce the isolation. >>> >>> Hope that helps. >>> >>> Fam >>> >>>> >>>> I hope someone could give me a perfect answer. However, any useful >>>> reply is appreciated. >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe kvm" in >>>> the body of a message to majord...@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
