Avi Kivity wrote:
Zhang, Xiantao wrote:
Avi Kivity wrote:
Wht about aliases? Aliases allow you go have two different physical
addresses for the same page. This is useful for mapping the
framebuffer on x86 (both at the pci region and at 0xa, the
traditional ISA location).
Are they
Izik Eidus wrote:
my idea was to let kvm register userspace memory that will hold the
guest memory,
and then much like qemu do with its cpu_register_physical_memory
function, run ioctls
that will tell the kernel how to map this memory,
what i wanted to achieved is making the memory
Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote:
As Xiantao pointed out, x86 and ia64 can share the same memory setup
code. But s390 and ppc don't. Therefore, I vote for putting it into
x86 for now, and come up with an approach to share
Zhang, Xiantao wrote:
Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote:
As Xiantao pointed out, x86 and ia64 can share the same memory setup
code. But s390 and ppc don't. Therefore, I vote for putting it into
x86 for now, and
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote:
As Xiantao pointed out, x86 and ia64 can share the same memory setup
code. But s390 and ppc don't. Therefore, I vote for putting it into
x86 for now, and come up with an approach to share between x86 and
Izik Eidus wrote:
btw, if you look at kvmctl, we already do it,
so it is good question if it better to leave this work to userspace
(like it do now)
or do the mapping to userspace from the kernel to userspace (using the
mmap syscall)
(i like the secoend option beacuse it would be easier
Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
ok i was thinking,
maybe we can rewrite the way kvm hold memory so more code would be shared,
lets say we throw away all the slots and arch depended stuff, and we let kvm
just hold the
Carsten Otte wrote:
That's why memory allocation/preparation needs to be arch dependent:
i386 needs a memory layout different from userspace page table due to
your argument, and s390 needs to use the userspace page table due to
hardware features we want to exploit.
As Xiantao pointed out,
Carsten Otte wrote:
Carsten Otte wrote:
That's why memory allocation/preparation needs to be arch dependent:
i386 needs a memory layout different from userspace page table due to
your argument, and s390 needs to use the userspace page table due to
hardware features we want to exploit.
Carsten Otte wrote:
Avi Kivity wrote:
I was talking about x86.
On x86, you need contiguous userspace, contiguous guest, but again,
what's the problem with one memory slot?
There is no problem with one memory slot: it works. It's just that
Izik's idea gives us the opportunity to have
Carsten Otte wrote:
Avi Kivity wrote:
Why aren't memory slots common too? Only their number is different,
while the implementation is the same.
Your approach makes the meaning of memory slot somewhat useless on
s390, if that one may be sparse and may be result of different
allocations:
Avi Kivity wrote:
Why aren't memory slots common too? Only their number is different,
while the implementation is the same.
Your approach makes the meaning of memory slot somewhat useless on
s390, if that one may be sparse and may be result of different
allocations: On x86, there has to be
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
ok i was thinking,
maybe we can rewrite the way kvm hold memory so more code would be shared,
lets say we throw away all the slots and arch depended stuff, and we let kvm
just hold the userspace allocated memory
On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
ok i was thinking,
maybe we can rewrite the way kvm hold memory so more code would be shared,
lets say we throw away all the slots and arch depended stuff, and we let kvm
just hold the userspace allocated memory address,
With that approach,
Izik Eidus wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
ok i was thinking,
maybe we can rewrite the way kvm hold memory so more code would be
shared,
lets say we throw away all the slots and arch depended stuff, and we
let kvm
just hold the
15 matches
Mail list logo
