Re: How does kvm achieve an 'advanced' process separation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>:
> On Thu, Jan 29, 2015 at 3:00 AM, Kun Cheng <chengkunck@xxxxxxxxx> 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@xxxxxxxxxx>:
>>> 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@xxxxxxxxxxxxxxx
>>>> 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@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux