On Tue, 21 Oct 2014 10:11:43 +0200
Paolo Bonzini wrote:
>
>
> On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
> >> I agree with Dave (I thought I disagreed, but I changed my mind while
> >> writing down my thoughts). Just define mm_forbids_zeropage in
> >> arch/s390/include/asm, and make it
On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
I agree with Dave (I thought I disagreed, but I changed my mind while
writing down my thoughts). Just define mm_forbids_zeropage in
arch/s390/include/asm, and make it return mm->context.use_skey---with a
comment explaining how this is only for
On Mon, 20 Oct 2014 20:14:53 +0200
Paolo Bonzini wrote:
> On 10/18/2014 06:28 PM, Dave Hansen wrote:
> > > Currently it is an all or nothing thing, but for a future change we might
> > > want to just
> > > tag the guest memory instead of the complete user address space.
> >
> > I think it's a
On Mon, 20 Oct 2014 20:14:53 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
On 10/18/2014 06:28 PM, Dave Hansen wrote:
Currently it is an all or nothing thing, but for a future change we might
want to just
tag the guest memory instead of the complete user address space.
I think
On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
I agree with Dave (I thought I disagreed, but I changed my mind while
writing down my thoughts). Just define mm_forbids_zeropage in
arch/s390/include/asm, and make it return mm-context.use_skey---with a
comment explaining how this is only for
On Tue, 21 Oct 2014 10:11:43 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
I agree with Dave (I thought I disagreed, but I changed my mind while
writing down my thoughts). Just define mm_forbids_zeropage in
arch/s390/include/asm, and
On 10/18/2014 06:28 PM, Dave Hansen wrote:
> Currently it is an all or nothing thing, but for a future change we might
want to just
> tag the guest memory instead of the complete user address space.
I think it's a bad idea to reserve a flag for potential future use. If
you_need_ it in the
On 10/18/2014 06:28 PM, Dave Hansen wrote:
Currently it is an all or nothing thing, but for a future change we might
want to just
tag the guest memory instead of the complete user address space.
I think it's a bad idea to reserve a flag for potential future use. If
you_need_ it in the
On 10/18/2014 07:49 AM, Dominik Dingel wrote:
> On Fri, 17 Oct 2014 15:04:21 -0700
> Dave Hansen wrote:
>> Is there ever a time where the VMAs under an mm have mixed VM_NOZEROPAGE
>> status? Reading the patches, it _looks_ like it might be an all or
>> nothing thing.
>
> Currently it is an all
On Fri, 17 Oct 2014 15:04:21 -0700
Dave Hansen wrote:
> Is there ever a time where the VMAs under an mm have mixed VM_NOZEROPAGE
> status? Reading the patches, it _looks_ like it might be an all or
> nothing thing.
Currently it is an all or nothing thing, but for a future change we might want
On Fri, 17 Oct 2014 15:04:21 -0700
Dave Hansen dave.han...@intel.com wrote:
Is there ever a time where the VMAs under an mm have mixed VM_NOZEROPAGE
status? Reading the patches, it _looks_ like it might be an all or
nothing thing.
Currently it is an all or nothing thing, but for a future
On 10/18/2014 07:49 AM, Dominik Dingel wrote:
On Fri, 17 Oct 2014 15:04:21 -0700
Dave Hansen dave.han...@intel.com wrote:
Is there ever a time where the VMAs under an mm have mixed VM_NOZEROPAGE
status? Reading the patches, it _looks_ like it might be an all or
nothing thing.
Currently it
On 10/17/2014 07:09 AM, Dominik Dingel wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index cd33ae2..8f09c91 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -113,7 +113,7 @@ extern unsigned int kobjsize(const void *objp);
> #define VM_GROWSDOWN 0x0100
On 10/17/2014 07:09 AM, Dominik Dingel wrote:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index cd33ae2..8f09c91 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -113,7 +113,7 @@ extern unsigned int kobjsize(const void *objp);
#define VM_GROWSDOWN 0x0100 /*
14 matches
Mail list logo
