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

Re: [Xen-devel] Could Xen hyperviosr be able to invoke Linux systemcalls?





On Mon, Aug 17, 2015 at 12:16 AM Frediano Ziglio <freddy77@xxxxxxxxx> wrote:
2015-08-15 2:31 GMT+01:00 Kun Cheng <chengkunck@xxxxxxxxx>:
> Hi all,
>
> That might be a dumb question but I just not confident with it. I'm not
> familiar with Xen's memory management part. Currently I want to add some
> support (it should cope more with machine memory) to the hyperviosr to
> assist the management of the above VMs. Now the situation is there're some
> codes in the kernel which are supposed to be useful. but can Xen call Linux
> system calls or other kernel functions?
>
> I'm not pretty sure about this as in my understanding xen hyperviosr lies
> under the kernel, so it can't invoke a systemcall from the kernel (or let's
> say dom0's kernel) . Then if I want to use those codes, I suppose I have to
> implement them in the hyperviosr by myself, right?
>
> And does anyone know which one of xen's wiki pages explain the management &
> APIs of xen's memory?
>
> Thank you all.
>


Good question. However I would hardly see such stuff in an hypervisor.
Usually VM management is done inserting some cd/dvd/usb and managing
the installation or injecting files into the filesystem at storage
level. Xen emulate the hardware so is not that easy to do system
calls. Just an example you are not sure which kind of OS is running
(well... unless you are using PVs but even so you are not 100% sure).
Saying that you are able to detect OS from what is doing/looking at
storage/memory/whatever. Then you have to do the syscall. You could
trap syscall/int for the OS you detected to run send to the VM an
event that trigger a syscall from an high permission executable and
detect it and then start injecting syscalls to do whatever you want.
However you have also consider the "ethics" of doing so. Basically you
are hacking the OS from the hypervisor forcing the VM to do something
unexpected. I don't know if such a patch would be considered for
inclusion upstream. Surely not if you can easily disable it or better
if by default is disabled but you can enable and detect from the VMs.



What I'm planing is adding page migration support for NUMA aware scheduling. In such a case the most time I'll be dealing with Xen's memory management & scheduling part to make relevant pages migrate to another node with their VCPU. However, Linux kernel has already implemented some basic mechanisms so the whole work would be better by leveraging the kernel's Âexisting code or functions. More specifically, I want to confirm that could we use the code or functions in linux kernel to assist the hypervisor? My guess is not because in my understanding xen hypervisor lies under the linux kernel, i.e. dom0's kernel. Given that Dom0 is a special domain, if I want to manage & move all the machine memory pages, can the kernel be helpful?Â

Your example gave me some hints that injecting the systemcall could be useful to achieve vNUMA. However currently it is not in my plan.

Â
I don't know if something similar is possible from domain0 instead of
Xen. You can surely change memory of another domain from dom0 but
injecting syscall is another stuff. You can poll the VM to see if is
running in userspace (stopping the CPU), set a new context and change
code cpu is running but is even much more hacky then the Xen
suggestion.
Â
Hmm, "change the memory from dom0" means we can control the VM's memory by using a config file or xl command right? What if we goes to the code level? I'm really confused now. Is Xen's memory management complemented all by itsself or does it also receive help from the kernel?Â
Â

Well, actually are just some ideas, you could even change the callback
code once registered and use it to inject code. Still the ethic
question remain.

Frediano
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.