Hi Linus,
Here's a set of patches to update paravirt_ops and Xen for 2.6.24
A quick overview of the patchset:
paravirt_ops:
Remove the monolithic paravirt_ops structure, and replace it with
smaller structures of related functions. Also, clean up the handling
of lazy mode to make it easier to implement.
x86/mm/init.c: remove a chunk of dead code
Xen:
- remove duplicate includes
- yield if the target vcpu of an IPI is not currently running
- add post-batch callbacks for multicalls [*]
- deal with unpinning pagetables when another vcpu still [*]
has a cr3 reference
- deal with split ptelocks by pinning each pte page
separately under lock
- determine the kernel/hypervisor address split dynamically
- use the right arg structure for register_vcpu_info [*]
- add extra debugging output for failed multicalls
XFS:
- eagerly unmap vmapped areas to avoid confict with Xen
[*] bugfix needed for 2.6.23. I've also cc:d them to [email protected]
Diffstat:
arch/x86/kernel/alternative.c | 4
arch/x86/kernel/asm-offsets_32.c | 14
arch/x86/kernel/entry_32.S | 2
arch/x86/kernel/paravirt_32.c | 234 ++++++++-----
arch/x86/kernel/vmi_32.c | 211 ++++++------
arch/x86/mm/init_32.c | 22 -
arch/x86/xen/enlighten.c | 295 +++++++++-------
arch/x86/xen/mmu.c | 149 ++++++--
arch/x86/xen/multicalls.c | 52 ++
arch/x86/xen/multicalls.h | 5
arch/x86/xen/smp.c | 14
arch/x86/xen/time.c | 6
arch/x86/xen/xen-ops.h | 10
drivers/char/hvc_lguest.c | 2
drivers/lguest/core.c | 6
drivers/lguest/lguest.c | 154 ++++----
drivers/lguest/lguest_bus.c | 2
fs/xfs/linux-2.6/xfs_buf.c | 13
include/asm-x86/paravirt.h | 507 ++++++++++++++++-------------
include/asm-x86/pgtable-3level-defs.h | 2
include/xen/interface/vcpu.h | 5
mm/Kconfig | 1
22 files changed, 1027 insertions(+), 683 deletions(-)
Thanks,
J
On Mon, Oct 15, 2007 at 01:48:40PM -0700, Jeremy Fitzhardinge wrote:
> Hi Linus,
>
> Here's a set of patches to update paravirt_ops and Xen for 2.6.24
>
> A quick overview of the patchset:
>
> paravirt_ops:
> Remove the monolithic paravirt_ops structure, and replace it with
> smaller structures of related functions. Also, clean up the handling
> of lazy mode to make it easier to implement.
>
> x86/mm/init.c: remove a chunk of dead code
>
> Xen:
> - remove duplicate includes
> - yield if the target vcpu of an IPI is not currently running
> - add post-batch callbacks for multicalls [*]
> - deal with unpinning pagetables when another vcpu still [*]
> has a cr3 reference
> - deal with split ptelocks by pinning each pte page
> separately under lock
> - determine the kernel/hypervisor address split dynamically
> - use the right arg structure for register_vcpu_info [*]
> - add extra debugging output for failed multicalls
>
> XFS:
> - eagerly unmap vmapped areas to avoid confict with Xen
>
> [*] bugfix needed for 2.6.23. I've also cc:d them to [email protected]
Yeah, but you cc:ed all 12 patches to stable@. The majority of which we
don't want to take, right? Which specific ones should stable@ care
about?
thanks,
greg k-h
Greg KH wrote:
> Yeah, but you cc:ed all 12 patches to stable@. The majority of which we
> don't want to take, right? Which specific ones should stable@ care
> about?
Crap, sorry about that. I'd just intended to send the overview and the
four patches, which have explicit CC: stable lines in the patch
descriptions. They are:
Subject: [PATCH 06/12] xen: add batch completion callbacks
Subject: [PATCH 07/12] xen: deal with stale cr3 values when unpinning
pagetables
Subject: [PATCH 10/12] xen: fix incorrect vcpu_register_vcpu_info
hypercall argument
Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
upsetting Xen
J
> Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
> upsetting Xen
This should be probably done unconditionally because it's a undefined
dangerous condition everywhere.
-Andi
On Tue, 2007-10-16 at 00:03 +0200, Andi Kleen wrote:
> > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
> > upsetting Xen
>
> This should be probably done unconditionally because it's a undefined
> dangerous condition everywhere.
Should be done unconditionally. One could remap the underlying physical
space to include an MMIO region, and speculative reads from the
cacheable virtual mapping of that region could move the robot arm,
destroying the world.
Zach
On Mon, Oct 15, 2007 at 02:59:50PM -0700, Jeremy Fitzhardinge wrote:
> Greg KH wrote:
> > Yeah, but you cc:ed all 12 patches to stable@. The majority of which we
> > don't want to take, right? Which specific ones should stable@ care
> > about?
>
> Crap, sorry about that. I'd just intended to send the overview and the
> four patches, which have explicit CC: stable lines in the patch
> descriptions. They are:
>
> Subject: [PATCH 06/12] xen: add batch completion callbacks
> Subject: [PATCH 07/12] xen: deal with stale cr3 values when unpinning
> pagetables
> Subject: [PATCH 10/12] xen: fix incorrect vcpu_register_vcpu_info
> hypercall argument
> Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
> upsetting Xen
These don't apply now due to the x86 merge. Care to backport them and
send them to the [email protected] address so we can apply them
properly?
thanks,
greg k-h
> > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
> > upsetting Xen
This patch was the wrong fix anyways as discussed; David Chinner
finally came up with a better one.
-Andi
On Wed, Nov 14, 2007 at 12:53:33AM +0100, Andi Kleen wrote:
>
> > > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid
> > > upsetting Xen
>
> This patch was the wrong fix anyways as discussed; David Chinner
> finally came up with a better one.
Ok, that's good to know, if someone wants to send me the correct one,
that would be appreciated.
Although, it's not like anyone actually uses the in-kernel Xen on
2.6.23, so it's probably not really worth it.
thanks,
greg k-h
Greg KH wrote:
> These don't apply now due to the x86 merge. Care to backport them and
> send them to the [email protected] address so we can apply them
> properly?
I'm a bit confused. The patches you mailed out are against arch/i386.
Won't they apply to the stable tree as-is?
> Although, it's not like anyone actually uses the in-kernel Xen on
> 2.6.23, so it's probably not really worth it.
>
To be fair, those fixes were in response to bug reports raised on the
released 2.6.23 kernel. But it isn't screamingly urgent.
J
On Wed, Nov 14, 2007 at 10:40:50AM -0800, Jeremy Fitzhardinge wrote:
> Greg KH wrote:
> > These don't apply now due to the x86 merge. Care to backport them and
> > send them to the [email protected] address so we can apply them
> > properly?
>
> I'm a bit confused. The patches you mailed out are against arch/i386.
> Won't they apply to the stable tree as-is?
Was this second series a new set, or a different one? I was assuming
they were new patches, and that they too needed to be applied.
These patches were sent against the merged x86 tree, not the -stable
tree with i386.
> > Although, it's not like anyone actually uses the in-kernel Xen on
> > 2.6.23, so it's probably not really worth it.
> >
>
> To be fair, those fixes were in response to bug reports raised on the
> released 2.6.23 kernel. But it isn't screamingly urgent.
Ok, that's fine, but can you send some patches that I can apply? :)
thanks,
greg k-h
Greg KH wrote:
> Ok, that's fine, but can you send some patches that I can apply? :)
The patches you've already queued for stable are all that's needed.
Including the xfs one, despite Andi's reservations about it; Dave
Chinner has a better fix, but as far as I know he hasn't submitted it
for stable, and the workaround is enough to get things going.
I have one additional patch; I'll send it shortly (once Linus picks it
up...).
J
On Wed, Nov 14, 2007 at 11:53:38AM -0800, Jeremy Fitzhardinge wrote:
> Greg KH wrote:
> > Ok, that's fine, but can you send some patches that I can apply? :)
>
> The patches you've already queued for stable are all that's needed.
> Including the xfs one, despite Andi's reservations about it; Dave
> Chinner has a better fix, but as far as I know he hasn't submitted it
> for stable, and the workaround is enough to get things going.
Great, thanks for verifying.
greg k-h