* How does kvm achieve an 'advanced' process separation @ 2015-01-29 8:51 Kun Cheng 2015-01-29 9:38 ` Fam Zheng 0 siblings, 1 reply; 5+ messages in thread From: Kun Cheng @ 2015-01-29 8:51 UTC (permalink / raw) To: kvm Hey guys, 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? I also notice that KVM seems to be benefited from cgroups, is that contributing to the isolation? I hope someone could give me a perfect answer. However, any useful reply is appreciated. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How does kvm achieve an 'advanced' process separation 2015-01-29 8:51 How does kvm achieve an 'advanced' process separation Kun Cheng @ 2015-01-29 9:38 ` Fam Zheng 2015-01-29 11:00 ` Kun Cheng 0 siblings, 1 reply; 5+ messages in thread From: Fam Zheng @ 2015-01-29 9:38 UTC (permalink / raw) To: Kun Cheng; +Cc: kvm 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How does kvm achieve an 'advanced' process separation 2015-01-29 9:38 ` Fam Zheng @ 2015-01-29 11:00 ` Kun Cheng 2015-01-30 1:53 ` Jidong Xiao 0 siblings, 1 reply; 5+ messages in thread From: Kun Cheng @ 2015-01-29 11:00 UTC (permalink / raw) To: Fam Zheng; +Cc: kvm 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. 顺祝学习、工作顺利！ 程琨 2015-01-29 17:38 GMT+08:00 Fam Zheng <famz@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 majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How does kvm achieve an 'advanced' process separation 2015-01-29 11:00 ` Kun Cheng @ 2015-01-30 1:53 ` Jidong Xiao 2015-01-30 2:26 ` Kun Cheng 0 siblings, 1 reply; 5+ messages in thread From: Jidong Xiao @ 2015-01-30 1:53 UTC (permalink / raw) To: Kun Cheng; +Cc: Fam Zheng, KVM On Thu, Jan 29, 2015 at 3:00 AM, Kun Cheng <chengkunck@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 <famz@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 majordomo@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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How does kvm achieve an 'advanced' process separation 2015-01-30 1:53 ` Jidong Xiao @ 2015-01-30 2:26 ` Kun Cheng 0 siblings, 0 replies; 5+ messages in thread From: Kun Cheng @ 2015-01-30 2:26 UTC (permalink / raw) To: Jidong Xiao; +Cc: Fam Zheng, KVM 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.xiao@gmail.com>: > On Thu, Jan 29, 2015 at 3:00 AM, Kun Cheng <chengkunck@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 <famz@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 majordomo@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 majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-01-30 2:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-29 8:51 How does kvm achieve an 'advanced' process separation Kun Cheng 2015-01-29 9:38 ` Fam Zheng 2015-01-29 11:00 ` Kun Cheng 2015-01-30 1:53 ` Jidong Xiao 2015-01-30 2:26 ` Kun Cheng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.