This patch series make kvm guest pages be able to be swapped out and
dynamically allocated. Without it, all guest memory is allocated at
guest start time.
patches are against latest git, and you need first patch Avi's kvm-sch
integration patch
(http://sourceforge.net/mailarchive/forum.php?thread_n
Shaohua Li wrote:
> This patch series make kvm guest pages be able to be swapped out and
> dynamically allocated. Without it, all guest memory is allocated at
> guest start time.
>
> patches are against latest git, and you need first patch Avi's kvm-sch
> integration patch
> (http://sourceforge.net
On Mon, Jul 23, 2007 at 01:27:40PM +0300, Avi Kivity wrote:
> Having an address_space (like your patch does) is remarkably simple, and
> requires few hooks from the current vm. However using existing vmas
> mapped by the user has many advantages:
Actually it requires lots of deep down VM intern
Christoph Hellwig wrote:
> On Mon, Jul 23, 2007 at 01:27:40PM +0300, Avi Kivity wrote:
>
>> Having an address_space (like your patch does) is remarkably simple, and
>> requires few hooks from the current vm. However using existing vmas
>> mapped by the user has many advantages:
>>
>
> Ac
On Mon, Jul 23, 2007 at 03:29:36PM +0300, Avi Kivity wrote:
> >Actually it requires lots of deep down VM internals symbols that'll never
> >get exported.
> >
> >
>
> What's "it" here? kvm-specific address space or generic vmas.
The patches in this thread.
> Generic vmas will be more intrusive
Christoph Hellwig wrote:
>
>> Generic vmas will be more intrusive AFAICT.
>>
>
> People use intrusive differently. Doing big changes to core code is not
> a problem if we actually get a proper interface. Just exporting core
> function without other changes and then writing code in modules th
On Mon, Jul 23, 2007 at 01:27:40PM +0300, Avi Kivity wrote:
> Having an address_space (like your patch does) is remarkably simple, and
> requires few hooks from the current vm. However using existing vmas
> mapped by the user has many advantages:
It's also needed for a SKAS-like UML client, whe
On Mon, 2007-07-23 at 13:27 +0300, Avi Kivity wrote:
> Having an address_space (like your patch does) is remarkably simple, and
> requires few hooks from the current vm. However using existing vmas
> mapped by the user has many advantages:
>
> - compatible with s390 requirements
> - allows the
On Mon, 2007-07-23 at 18:27 +0800, Avi Kivity wrote:
> Shaohua Li wrote:
> > This patch series make kvm guest pages be able to be swapped out and
> > dynamically allocated. Without it, all guest memory is allocated at
> > guest start time.
> >
> > patches are against latest git, and you need first
On Mon, 2007-07-23 at 20:34 +0800, Christoph Hellwig wrote:
> On Mon, Jul 23, 2007 at 03:29:36PM +0300, Avi Kivity wrote:
> > >Actually it requires lots of deep down VM internals symbols that'll
> never
> > >get exported.
> > >
> > >
> >
> > What's "it" here? kvm-specific address space or generic
Jeff Dike wrote:
> On Mon, Jul 23, 2007 at 01:27:40PM +0300, Avi Kivity wrote:
>
>> Having an address_space (like your patch does) is remarkably simple, and
>> requires few hooks from the current vm. However using existing vmas
>> mapped by the user has many advantages:
>>
>
> It's also
Rusty Russell wrote:
> On Mon, 2007-07-23 at 13:27 +0300, Avi Kivity wrote:
>
>> Having an address_space (like your patch does) is remarkably simple, and
>> requires few hooks from the current vm. However using existing vmas
>> mapped by the user has many advantages:
>>
>> - compatible with s
Shaohua Li wrote:
> On Mon, 2007-07-23 at 18:27 +0800, Avi Kivity wrote:
>
>> Shaohua Li wrote:
>>
>>> This patch series make kvm guest pages be able to be swapped out and
>>> dynamically allocated. Without it, all guest memory is allocated at
>>> guest start time.
>>>
>>> patches are again
On Tue, 2007-07-24 at 08:30 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Mon, 2007-07-23 at 13:27 +0300, Avi Kivity wrote:
> >
> >> Having an address_space (like your patch does) is remarkably simple, and
> >> requires few hooks from the current vm. However using existing vmas
> >>
Rusty Russell wrote:
> On Tue, 2007-07-24 at 08:30 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> On Mon, 2007-07-23 at 13:27 +0300, Avi Kivity wrote:
>>>
>>>
Having an address_space (like your patch does) is remarkably simple, and
requires few hooks from the
On Tue, 2007-07-24 at 09:21 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > Actually, get_user_pages() does that for you. You have to make R/O any
> > writable pte where the guest doesn't set the dirty bit (so you can trap
> > it later) but last I put a printk in there, Linux doesn't do that.
Rusty Russell wrote:
>
>>> If not, it does get harder. A callback in the mm struct to say "I want
>>> to swap your page out" is required if we don't take a reference to the
>>> page. Dirty bit handling would be an interesting issue (maybe the
>>> callback can say "No!" and dirty the page again?).
On Tue, 2007-07-24 at 09:59 +0300, Avi Kivity wrote:
> However, you can probably work around that by not setting an rmap for
> the kernel mappings, and instead have the guest teach the host where the
> kernel page tables live. You'd only be left with shared libraries,
> until the kernel can share
On Tue, Jul 24, 2007 at 08:22:53AM +0300, Avi Kivity wrote:
> Even in the current model, guest physical memory is mmap()ed into host
> userspace.
I want it to be identity-mapped, which a single address space would
guarantee. For things which change mappings, like vmalloc, I need to
be in the same
Jeff Dike wrote:
> I want it to be identity-mapped, which a single address space would
> guarantee. For things which change mappings, like vmalloc, I need to
> be in the same address space as the guest.
That'll also be mandatory required by hw when porting this to s390.
--
20 matches
Mail list logo
