| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen memory management
On Thu, Jun 23, 2011 at 8:37 PM, David Xu <davidxu06@xxxxxxxxx> wrote:
On a shared-memory system with multi-core cpu, can one VM occupy all cache and prevent other VMs using cache efficiently?
Thanks for reply from all of you. I am reading a paper which tells some secure problem of Xen VMM. I am not familiar with something that is related to those problems. So I really need your help. Of course, please feel free to post your opinion. Anybody is welcome to have a discuss.
2011/6/23 Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
On 24/06/2011 00:50, David Xu wrote:
2011/6/23 Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
On 23/06/2011 23:08, David Xu wrote:
Thanks. My concern is that if
several VMs are mapped to same memory, one VM may get
something from the memory which has ever been used by
another VM. This may cause some secure problems.
Someone correct me if I'm wrong, but I'm pretty sure that
a DomU kernel (If the flag is set correctly during compile
time) will scrub (i.e. "zero") RAM first before releasing
it to the Xen Hypervisor. Then hypervisor will then
subsequently assign that bit of RAM to another domain.
Sounds good. Does Xen VMM can control the mapping between a part
of memory and cache line? That is to say I wander whether Xen
can guarantee different VMs will use different cache line.
Thanks.
Regards,
Cong
Please don't top post :)
I'm not a Xen dev, so it would be great if a dev could let me know
if I'm talking rubbish or not. However from my very limited
knowledge of how CPU caches work (which comes from basic single CPU,
non VMM related system), common sense would tell me that the cache
line would be different for each DomU, as a CPUs cache is inherently
linked to main memory (RAM). I believe that the process used to
access data from memory is abstracted by the CPU, so assuming that
Xen prevents access to RAM from another DomU, I guess it would make
sense to say that any data that is cached in the CPU is protected.
Then again, I could be completly wrong......
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
Have a look at this:
_SDK
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home