Re: [PATCH] [104/223] KVM: Write protect memory after slot swap

[Paul Gortmaker]

On Mon, Dec 13, 2010 at 12:08 PM, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 12/13/2010 06:56 PM, Paul Gortmaker wrote:
>>
>> On Mon, Dec 13, 2010 at 4:16 AM, Avi Kivity<avi@xxxxxxxxxx>  wrote:
>> >  On 12/13/2010 11:12 AM, Andi Kleen wrote:
>> >>
>> >>  >    - Greg rejects kvm patches (but not virtio etc) pointing
>> >> submitters
>> >>  >    to the kvm maintainers
>> >>  >    - The kvm maintainers collect stable kvm patches and autotest
>> >> them
>> >>
>> >>  As I understand this patch came in this way for .36
>> >>  (I took it from .36-stable)
>> >
>> >  The patch was autotested for .36-stable, it wasn't autotested for
>> >  .35-stable.  It will very likely work (this isn't code that changes a
>> > lot),
>> >  but still.
>> >
>> >>  >    - They then submit the patches to stable@
>> >>
>> >>  Do you want to do the autotest explicitely for .35 too and no
>> >> automatic
>> >>  backports and do the same procedure as for newer kernels?
>> >>
>> >>  I can do that, but you would need to do it for a long time.
>> >
>> >  Yes.  In fact it gets more important as time goes by, since as time
>> > goes by
>> >  patches are more likely to cause regressions due to changes in the code
>> >  base.
>>
>> My workflow is largely the same as Andi's -- in that I'm using patches
>> that
>> have already been nominated for other stable releases and putting them
>> on the 34-lt (longterm) as appropriate.  Are you interested in also doing
>> the
>> same thing for 34-lt (i.e. you generating a 34 specific, pre-tested
>> patchset
>> instead of me doing the backports from other stable trees?)
>
> Wait, there's a 34-lt too?

There is also a 32-lt.

>
> I'd like to have all stable kvms pass some minimum acceptance test, but
> that's quiet a lot of trees to maintain.  Why do we have to have both 34-lt
> and 35-lt?

Well, ideally we'd all be aligned on one release, but that requires that it be
chosen somewhat in advance and communicated well, so that people have
time to align to it.  Without getting into details, different people had already
based projects and products off of 34, many months ago, at a point where
35 was not yet even being considered for extended maintenance.

Or you can go with Greg's shorter justification.  It is harder to
argue against. :)

P.

>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/