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.
-
To unsubscribe from this lis
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
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: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:
> 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 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 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
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
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
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 that
pokes i
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:
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 requir
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
13 matches
Mail list logo
