2.6.39 merge window (git pulls and what is planned to go in)

2.6.39 merge window (git pulls and what is planned to go in)

[Konrad Rzeszutek Wilk]

Probably over the weekend Linus is going to open the merge window.

This merge window is much more complicated than the previous
one b/c we got a lot of good stuff.

For my sanity and book-keeping I was thinking to email Linus
five git pull requests:

  for-2.6.39/e820
	[stable/p2m-identity-v4.9.1, stable/e820]
  for-2.6.39/irq
	[tip/for-xen, stable/irq.rework, stable/pcifront-fixes, stable/irq.cleanup]
  for-2.6.39/cleanup
	[stable/ia64, stable/blkfront-cleanup, stable/cleanup]
  for-2.6.39/drivers
	[stable/gntalloc.v6, stable/backends]

.. and then during the next week of the two weeks merge window:
  for-2.6.39/irq.phase.two
	[stable/irq.fairness, stable/irq.ween_of_nr_irqs]

In this order or so.

In other trees by other maintainers we have:

  git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git has
    stable/ttm.pci-api.v4 [Makes radeon,nouveau work under Xen]

  git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git has
    xen watchdog [Xen watchdog is watching you..]

 git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
    xen suspend cleanups
    PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM


The things that are not on this list are:

 devel/balloon [Daniel Kipers' cleanup of balloon code]
 devel/balloon.v2 [above, plus Daniel De Graaf's cleanup of balloon and using
		them in gntalloc]
 devel/gntalloc.v7 [cleanup in gntalloc]
 devel/fb_kb_front_use_page_gref [Daniel De Graaf's modifications]
 
Which we could squeeze in the end of the merge window if we
are comfortable with the patches.

The things that are not going in 2.6.39 are:

  devel/xen-pciback-0.4.driver [xen-pciback]
  devel/xen-blkback-v1 [xen-blkback]
  git://xenbits.xen.org/people/ianc/linux-2.6 upstream/dom0/backend/netback
	[xen-netback - well, it could if the network maintainers are comfortable
	 with the driver, but I think it is still going through the review]

The diffstat of those "for-2.6.39/*" is:

 arch/ia64/include/asm/xen/hypercall.h |    2 +-
 arch/x86/include/asm/xen/page.h       |   47 ++-
 arch/x86/include/asm/xen/pci.h        |    8 +-
 arch/x86/pci/xen.c                    |  192 +++++----
 arch/x86/xen/Kconfig                  |    8 +
 arch/x86/xen/enlighten.c              |    2 +-
 arch/x86/xen/mmu.c                    |   72 +++-
 arch/x86/xen/p2m.c                    |  330 ++++++++++++++-
 arch/x86/xen/setup.c                  |   68 +++-
 arch/x86/xen/time.c                   |    4 +-
 drivers/block/xen-blkfront.c          |    8 +-
 drivers/pci/xen-pcifront.c            |   31 +-
 drivers/xen/Kconfig                   |   10 +
 drivers/xen/Makefile                  |    2 +
 drivers/xen/balloon.c                 |    2 +-
 drivers/xen/events.c                  |  775 +++++++++++++++++----------------
 drivers/xen/gntalloc.c                |  545 +++++++++++++++++++++++
 drivers/xen/gntdev.c                  |  386 +++++++++++------
 drivers/xen/grant-table.c             |   10 +
 include/linux/interrupt.h             |    3 +-
 include/xen/events.h                  |   38 +-
 include/xen/gntalloc.h                |   82 ++++
 include/xen/gntdev.h                  |   31 ++
 include/xen/interface/io/blkif.h      |   16 +-
 kernel/irq/manage.c                   |   11 +-
 kernel/irq/pm.c                       |    3 -
 26 files changed, 2024 insertions(+), 662 deletions(-)

And shortlog:

Daniel De Graaf (14):
      xen-gntdev: Change page limit to be global instead of per-open
      xen-gntdev: Use find_vma rather than iterating our vma list manually
      xen-gntdev: Add reference counting to maps
      xen-gntdev: Support mapping in HVM domains
      xen-gntalloc: Userspace grant allocation driver
      xen/gntalloc,gntdev: Add unmap notify ioctl
      xen-gntdev: Fix memory leak when mmap fails
      xen-gntdev: Fix unmap notify on PV domains
      xen-gntdev: Use map->vma for checking map validity
      xen-gntdev: Avoid unmapping ranges twice
      xen-gntdev: Avoid double-mapping memory
      xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only mappings
      xen-gntdev: Fix incorrect use of zero handle
      xen-gntdev: Add cast to pointer

Ian Campbell (48):
      xen: handled remapped IRQs when enabling a pcifront PCI device.
      xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
      xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
      xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
      xen: events: do not free legacy IRQs
      xen: Fix compile error introduced by "switch to new irq_chip functions"
      xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
      xen: events: mark cpu_evtchn_mask_p as __refdata
      xen p2m: annotate variable which appears unused
      xen: annotate functions which only call into __init at start of day
      xen: pci: only define xen_initdom_setup_msi_irqs if CONFIG_XEN_DOM0
      xen: events: do not leak IRQ from xen_allocate_pirq_msi when no pirq available.
      xen: events: drop XEN_ALLOC_IRQ flag to xen_allocate_pirq_msi
      xen: events: return irq from xen_allocate_pirq_msi
      xen: pci: collapse apic_register_gsi_xen_hvm and xen_hvm_register_pirq
      xen: events: assume PHYSDEVOP_get_free_pirq exists
      xen: events: separate MSI PIRQ allocation from PIRQ binding to IRQ
      xen: events: refactor xen_create_msi_irq slightly
      xen: events: update pirq_to_irq in xen_create_msi_irq
      xen: events: push set_irq_msi down into xen_create_msi_irq
      xen: events: use xen_bind_pirq_msi_to_irq from xen_create_msi_irq
      xen: events: remove dom0 specific xen_create_msi_irq
      xen/irq: implement bind_interdomain_evtchn_to_irqhandler for backend drivers
      xen: ia64 build broken due to "xen: switch to new schedop hypercall by default."
      xen: handled remapped IRQs when enabling a pcifront PCI device.
      xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
      xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
      xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
      xen: events: do not free legacy IRQs
      xen: Fix compile error introduced by "switch to new irq_chip functions"
      xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
      xen/p2m/m2p/gnttab: do not add failed grant maps to m2p override
      xen: gntdev: fix build warning
      xen: events: Make last processed event channel a per-cpu variable.
      xen: events: separate two unrelated halves of if condition
      xen: events: simplify comment
      xen: events: fix xen_map_pirq_gsi error return
      xen: events: remove unused public functions
      xen: events: rename restore_cpu_pirqs -> restore_pirqs
      xen: events: refactor GSI pirq bindings functions
      xen: events: use per-cpu variable for cpu_evtchn_mask
      xen: events: turn irq_info constructors into initialiser functions
      xen: events: push setup of irq<->{evtchn,ipi,virq,pirq} maps into irq_info init functions
      xen: events: maintain a list of Xen interrupts
      xen: events: dynamically allocate irq info structures
      xen: events: remove use of nr_irqs as upper bound on number of pirqs
      xen: events: do not workaround too-small nr_irqs
      xen: events: propagate irq allocation failure instead of panicking

Keir Fraser (3):
      xen: events: Clean up round-robin evtchn scan.
      xen: events: Make round-robin scan fairer by snapshotting each l2 word once only
      xen: events: Remove redundant clear of l2i at end of round-robin loop

Konrad Rzeszutek Wilk (16):
      xen/irq: Don't fall over when nr_irqs_gsi > nr_irqs.
      xen/irq: Cleanup up the pirq_to_irq for DomU PV PCI passthrough guests as well.
      xen-pcifront: Sanity check the MSI/MSI-X values
      pci/xen: Use xen_allocate_pirq_msi instead of xen_allocate_pirq
      pci/xen: Cleanup: convert int** to int[]
      pci/xen: When free-ing MSI-X/MSI irq->desc also use generic code.
      xen: Mark all initial reserved pages for the balloon as INVALID_P2M_ENTRY.
      xen/mmu: Add the notion of identity (2-1) mapping.
      xen/mmu: Set _PAGE_IOMAP if PFN is an identity PFN.
      xen/mmu: WARN_ON when racing to swap middle leaf.
      xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
      xen/debugfs: Add 'p2m' file for printing out the P2M layout.
      xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set.
      xen/m2p: No need to catch exceptions when we know that there is no RAM
      xen/irq: Cleanup up the pirq_to_irq for DomU PV PCI passthrough guests as well.
      xen/e820: Don't mark balloon memory as E820_UNUSABLE when running as guest.

Owen Smith (1):
      xen: Union the blkif_request request specific fields

Scott Rixner (1):
      xen: events: Process event channels notifications in round-robin order.

Stefano Stabellini (2):
      xen: change xen/[gntdev/gntalloc] to default m
      xen/m2p: Check whether the MFN has IDENTITY_FRAME bit set..

Tejun Heo (1):
      xen-pcifront: don't use flush_scheduled_work()

Thomas Gleixner (7):
      genirq: Add IRQF_FORCE_RESUME
      xen: Remove stale irq_chip.end
      xen: Switch to new irq_chip functions
      xen: Use IRQF_FORCE_RESUME
      xen: Remove stale irq_chip.end
      xen: Switch to new irq_chip functions
      xen: Use IRQF_FORCE_RESUME

Zhang, Fengzhe (1):
      xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps.

Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Jeremy Fitzhardinge]

On 03/10/2011 11:29 AM, Konrad Rzeszutek Wilk wrote:
> Probably over the weekend Linus is going to open the merge window.
>
> This merge window is much more complicated than the previous
> one b/c we got a lot of good stuff.
>
> For my sanity and book-keeping I was thinking to email Linus
> five git pull requests:
>
>   for-2.6.39/e820
> 	[stable/p2m-identity-v4.9.1, stable/e820]
>   for-2.6.39/irq
> 	[tip/for-xen, stable/irq.rework, stable/pcifront-fixes, stable/irq.cleanup]
>   for-2.6.39/cleanup
> 	[stable/ia64, stable/blkfront-cleanup, stable/cleanup]
>   for-2.6.39/drivers
> 	[stable/gntalloc.v6, stable/backends]
>
> .. and then during the next week of the two weeks merge window:
>   for-2.6.39/irq.phase.two
> 	[stable/irq.fairness, stable/irq.ween_of_nr_irqs]
>

Good stuff.  And I guess it should all be about done by the time of the
hackathingy?

    J

> In this order or so.
>
> In other trees by other maintainers we have:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git has
>     stable/ttm.pci-api.v4 [Makes radeon,nouveau work under Xen]
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git has
>     xen watchdog [Xen watchdog is watching you..]
>
>  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
>     xen suspend cleanups
>     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
>
>
> The things that are not on this list are:
>
>  devel/balloon [Daniel Kipers' cleanup of balloon code]
>  devel/balloon.v2 [above, plus Daniel De Graaf's cleanup of balloon and using
> 		them in gntalloc]
>  devel/gntalloc.v7 [cleanup in gntalloc]
>  devel/fb_kb_front_use_page_gref [Daniel De Graaf's modifications]
>  
> Which we could squeeze in the end of the merge window if we
> are comfortable with the patches.
>
> The things that are not going in 2.6.39 are:
>
>   devel/xen-pciback-0.4.driver [xen-pciback]
>   devel/xen-blkback-v1 [xen-blkback]
>   git://xenbits.xen.org/people/ianc/linux-2.6 upstream/dom0/backend/netback
> 	[xen-netback - well, it could if the network maintainers are comfortable
> 	 with the driver, but I think it is still going through the review]
>
> The diffstat of those "for-2.6.39/*" is:
>
>  arch/ia64/include/asm/xen/hypercall.h |    2 +-
>  arch/x86/include/asm/xen/page.h       |   47 ++-
>  arch/x86/include/asm/xen/pci.h        |    8 +-
>  arch/x86/pci/xen.c                    |  192 +++++----
>  arch/x86/xen/Kconfig                  |    8 +
>  arch/x86/xen/enlighten.c              |    2 +-
>  arch/x86/xen/mmu.c                    |   72 +++-
>  arch/x86/xen/p2m.c                    |  330 ++++++++++++++-
>  arch/x86/xen/setup.c                  |   68 +++-
>  arch/x86/xen/time.c                   |    4 +-
>  drivers/block/xen-blkfront.c          |    8 +-
>  drivers/pci/xen-pcifront.c            |   31 +-
>  drivers/xen/Kconfig                   |   10 +
>  drivers/xen/Makefile                  |    2 +
>  drivers/xen/balloon.c                 |    2 +-
>  drivers/xen/events.c                  |  775 +++++++++++++++++----------------
>  drivers/xen/gntalloc.c                |  545 +++++++++++++++++++++++
>  drivers/xen/gntdev.c                  |  386 +++++++++++------
>  drivers/xen/grant-table.c             |   10 +
>  include/linux/interrupt.h             |    3 +-
>  include/xen/events.h                  |   38 +-
>  include/xen/gntalloc.h                |   82 ++++
>  include/xen/gntdev.h                  |   31 ++
>  include/xen/interface/io/blkif.h      |   16 +-
>  kernel/irq/manage.c                   |   11 +-
>  kernel/irq/pm.c                       |    3 -
>  26 files changed, 2024 insertions(+), 662 deletions(-)
>
> And shortlog:
>
> Daniel De Graaf (14):
>       xen-gntdev: Change page limit to be global instead of per-open
>       xen-gntdev: Use find_vma rather than iterating our vma list manually
>       xen-gntdev: Add reference counting to maps
>       xen-gntdev: Support mapping in HVM domains
>       xen-gntalloc: Userspace grant allocation driver
>       xen/gntalloc,gntdev: Add unmap notify ioctl
>       xen-gntdev: Fix memory leak when mmap fails
>       xen-gntdev: Fix unmap notify on PV domains
>       xen-gntdev: Use map->vma for checking map validity
>       xen-gntdev: Avoid unmapping ranges twice
>       xen-gntdev: Avoid double-mapping memory
>       xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only mappings
>       xen-gntdev: Fix incorrect use of zero handle
>       xen-gntdev: Add cast to pointer
>
> Ian Campbell (48):
>       xen: handled remapped IRQs when enabling a pcifront PCI device.
>       xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
>       xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
>       xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
>       xen: events: do not free legacy IRQs
>       xen: Fix compile error introduced by "switch to new irq_chip functions"
>       xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
>       xen: events: mark cpu_evtchn_mask_p as __refdata
>       xen p2m: annotate variable which appears unused
>       xen: annotate functions which only call into __init at start of day
>       xen: pci: only define xen_initdom_setup_msi_irqs if CONFIG_XEN_DOM0
>       xen: events: do not leak IRQ from xen_allocate_pirq_msi when no pirq available.
>       xen: events: drop XEN_ALLOC_IRQ flag to xen_allocate_pirq_msi
>       xen: events: return irq from xen_allocate_pirq_msi
>       xen: pci: collapse apic_register_gsi_xen_hvm and xen_hvm_register_pirq
>       xen: events: assume PHYSDEVOP_get_free_pirq exists
>       xen: events: separate MSI PIRQ allocation from PIRQ binding to IRQ
>       xen: events: refactor xen_create_msi_irq slightly
>       xen: events: update pirq_to_irq in xen_create_msi_irq
>       xen: events: push set_irq_msi down into xen_create_msi_irq
>       xen: events: use xen_bind_pirq_msi_to_irq from xen_create_msi_irq
>       xen: events: remove dom0 specific xen_create_msi_irq
>       xen/irq: implement bind_interdomain_evtchn_to_irqhandler for backend drivers
>       xen: ia64 build broken due to "xen: switch to new schedop hypercall by default."
>       xen: handled remapped IRQs when enabling a pcifront PCI device.
>       xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
>       xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
>       xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
>       xen: events: do not free legacy IRQs
>       xen: Fix compile error introduced by "switch to new irq_chip functions"
>       xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
>       xen/p2m/m2p/gnttab: do not add failed grant maps to m2p override
>       xen: gntdev: fix build warning
>       xen: events: Make last processed event channel a per-cpu variable.
>       xen: events: separate two unrelated halves of if condition
>       xen: events: simplify comment
>       xen: events: fix xen_map_pirq_gsi error return
>       xen: events: remove unused public functions
>       xen: events: rename restore_cpu_pirqs -> restore_pirqs
>       xen: events: refactor GSI pirq bindings functions
>       xen: events: use per-cpu variable for cpu_evtchn_mask
>       xen: events: turn irq_info constructors into initialiser functions
>       xen: events: push setup of irq<->{evtchn,ipi,virq,pirq} maps into irq_info init functions
>       xen: events: maintain a list of Xen interrupts
>       xen: events: dynamically allocate irq info structures
>       xen: events: remove use of nr_irqs as upper bound on number of pirqs
>       xen: events: do not workaround too-small nr_irqs
>       xen: events: propagate irq allocation failure instead of panicking
>
> Keir Fraser (3):
>       xen: events: Clean up round-robin evtchn scan.
>       xen: events: Make round-robin scan fairer by snapshotting each l2 word once only
>       xen: events: Remove redundant clear of l2i at end of round-robin loop
>
> Konrad Rzeszutek Wilk (16):
>       xen/irq: Don't fall over when nr_irqs_gsi > nr_irqs.
>       xen/irq: Cleanup up the pirq_to_irq for DomU PV PCI passthrough guests as well.
>       xen-pcifront: Sanity check the MSI/MSI-X values
>       pci/xen: Use xen_allocate_pirq_msi instead of xen_allocate_pirq
>       pci/xen: Cleanup: convert int** to int[]
>       pci/xen: When free-ing MSI-X/MSI irq->desc also use generic code.
>       xen: Mark all initial reserved pages for the balloon as INVALID_P2M_ENTRY.
>       xen/mmu: Add the notion of identity (2-1) mapping.
>       xen/mmu: Set _PAGE_IOMAP if PFN is an identity PFN.
>       xen/mmu: WARN_ON when racing to swap middle leaf.
>       xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
>       xen/debugfs: Add 'p2m' file for printing out the P2M layout.
>       xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set.
>       xen/m2p: No need to catch exceptions when we know that there is no RAM
>       xen/irq: Cleanup up the pirq_to_irq for DomU PV PCI passthrough guests as well.
>       xen/e820: Don't mark balloon memory as E820_UNUSABLE when running as guest.
>
> Owen Smith (1):
>       xen: Union the blkif_request request specific fields
>
> Scott Rixner (1):
>       xen: events: Process event channels notifications in round-robin order.
>
> Stefano Stabellini (2):
>       xen: change xen/[gntdev/gntalloc] to default m
>       xen/m2p: Check whether the MFN has IDENTITY_FRAME bit set..
>
> Tejun Heo (1):
>       xen-pcifront: don't use flush_scheduled_work()
>
> Thomas Gleixner (7):
>       genirq: Add IRQF_FORCE_RESUME
>       xen: Remove stale irq_chip.end
>       xen: Switch to new irq_chip functions
>       xen: Use IRQF_FORCE_RESUME
>       xen: Remove stale irq_chip.end
>       xen: Switch to new irq_chip functions
>       xen: Use IRQF_FORCE_RESUME
>
> Zhang, Fengzhe (1):
>       xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps.
>

Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
> Probably over the weekend Linus is going to open the merge window.
> 
> This merge window is much more complicated than the previous
> one b/c we got a lot of good stuff.
> 
> For my sanity and book-keeping I was thinking to email Linus
> five git pull requests:
[...]
> .. and then during the next week of the two weeks merge window:
[...]
> In this order or so.

Seems sane. I'm going to rebase my dev tree onto all these now (I think
I've got most of it already)

> In other trees by other maintainers we have:
[...]
>  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
>     xen suspend cleanups
>     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM

Are Shriram's suspend/checkpoint patches in the pipeline somewhere?

> The things that are not going in 2.6.39 are:
> 
>   devel/xen-pciback-0.4.driver [xen-pciback]

Targeting 2.6.40?

>   devel/xen-blkback-v1 [xen-blkback]

2.6.40 again?

>   git://xenbits.xen.org/people/ianc/linux-2.6 upstream/dom0/backend/netback
> 	[xen-netback - well, it could if the network maintainers are comfortable
> 	 with the driver, but I think it is still going through the review]

I've got another round of (minor) review feedback to address, I'm still
a little bit hopeful for a 2.6.39 merge.

Either way this will go through the net tree not us.

Ian.

Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Stefano Stabellini]

On Thu, 10 Mar 2011, Konrad Rzeszutek Wilk wrote:
> Probably over the weekend Linus is going to open the merge window.
> 
> This merge window is much more complicated than the previous
> one b/c we got a lot of good stuff.
> 
> For my sanity and book-keeping I was thinking to email Linus
> five git pull requests:
> 
>   for-2.6.39/e820
> 	[stable/p2m-identity-v4.9.1, stable/e820]
>   for-2.6.39/irq
> 	[tip/for-xen, stable/irq.rework, stable/pcifront-fixes, stable/irq.cleanup]
>   for-2.6.39/cleanup
> 	[stable/ia64, stable/blkfront-cleanup, stable/cleanup]
>   for-2.6.39/drivers
> 	[stable/gntalloc.v6, stable/backends]
> 
> .. and then during the next week of the two weeks merge window:
>   for-2.6.39/irq.phase.two
> 	[stable/irq.fairness, stable/irq.ween_of_nr_irqs]
> 
> In this order or so.
> 
> In other trees by other maintainers we have:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git has
>     stable/ttm.pci-api.v4 [Makes radeon,nouveau work under Xen]
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git has
>     xen watchdog [Xen watchdog is watching you..]
> 
>  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
>     xen suspend cleanups
>     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
> 
> 
> The things that are not on this list are:
> 
>  devel/balloon [Daniel Kipers' cleanup of balloon code]
>  devel/balloon.v2 [above, plus Daniel De Graaf's cleanup of balloon and using
> 		them in gntalloc]
>  devel/gntalloc.v7 [cleanup in gntalloc]
>  devel/fb_kb_front_use_page_gref [Daniel De Graaf's modifications]
>  
> Which we could squeeze in the end of the merge window if we
> are comfortable with the patches.

I am still tracking few critical bug fixes that should go in the tip
tree or the pci tree:

Stefano Stabellini (2):
      xen: set max_pfn_mapped to the last pfn mapped
      xen: update mask_rw_pte after kernel page tables init changes
      acpiphp: set current_state to D0 in register_slot

Yinghai Lu (1):
      x86: Cleanup highmap after brk is concluded

Ian Campbell (1):
      acpiphp: assume device is in state D0 after powering on a slot.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Konrad Rzeszutek Wilk]

On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
> On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
> > Probably over the weekend Linus is going to open the merge window.
> > 
> > This merge window is much more complicated than the previous
> > one b/c we got a lot of good stuff.
> > 
> > For my sanity and book-keeping I was thinking to email Linus
> > five git pull requests:
> [...]
> > .. and then during the next week of the two weeks merge window:
> [...]
> > In this order or so.
> 
> Seems sane. I'm going to rebase my dev tree onto all these now (I think
> I've got most of it already)

OK. #linux-next is you place then.
> 
> > In other trees by other maintainers we have:
> [...]
> >  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
> >     xen suspend cleanups
> >     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
> 
> Are Shriram's suspend/checkpoint patches in the pipeline somewhere?

<head smack> I knew I forgot something.

The last I heard he was battling PVonHVM shutdown issues during his
testing of his patches.

Shririam?

> 
> > The things that are not going in 2.6.39 are:
> > 
> >   devel/xen-pciback-0.4.driver [xen-pciback]
> 
> Targeting 2.6.40?

Yes.
> 
> >   devel/xen-blkback-v1 [xen-blkback]
> 
> 2.6.40 again?

Yeah, I think by that time any issues/failures would show up and I
can fix them.
> 
> >   git://xenbits.xen.org/people/ianc/linux-2.6 upstream/dom0/backend/netback
> > 	[xen-netback - well, it could if the network maintainers are comfortable
> > 	 with the driver, but I think it is still going through the review]
> 
> I've got another round of (minor) review feedback to address, I'm still
> a little bit hopeful for a 2.6.39 merge.
> 
> Either way this will go through the net tree not us.

<nods>
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
> > > Probably over the weekend Linus is going to open the merge window.
> > > 
> > > This merge window is much more complicated than the previous
> > > one b/c we got a lot of good stuff.
> > > 
> > > For my sanity and book-keeping I was thinking to email Linus
> > > five git pull requests:
> > [...]
> > > .. and then during the next week of the two weeks merge window:
> > [...]
> > > In this order or so.
> > 
> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
> > I've got most of it already)
> 
> OK. #linux-next is you place then.
> > 
> > > In other trees by other maintainers we have:
> > [...]
> > >  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
> > >     xen suspend cleanups
> > >     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
> > 
> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
> 
> <head smack> I knew I forgot something.
> 
> The last I heard he was battling PVonHVM shutdown issues during his
> testing of his patches.
> 
> Shririam?

He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
PM tree, it looked sane to me.

I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
time since it has no dependency on either the PVHVM or PM trees.

It also looks to me like patch 4/5 ("PM: Add visible
HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
PM tree whenever Rafael likes, since it doesn't depend on any of the
others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once
everything else has settled down.

Ian.

> 
> > 
> > > The things that are not going in 2.6.39 are:
> > > 
> > >   devel/xen-pciback-0.4.driver [xen-pciback]
> > 
> > Targeting 2.6.40?
> 
> Yes.
> > 
> > >   devel/xen-blkback-v1 [xen-blkback]
> > 
> > 2.6.40 again?
> 
> Yeah, I think by that time any issues/failures would show up and I
> can fix them.
> > 
> > >   git://xenbits.xen.org/people/ianc/linux-2.6 upstream/dom0/backend/netback
> > > 	[xen-netback - well, it could if the network maintainers are comfortable
> > > 	 with the driver, but I think it is still going through the review]
> > 
> > I've got another round of (minor) review feedback to address, I'm still
> > a little bit hopeful for a 2.6.39 merge.
> > 
> > Either way this will go through the net tree not us.
> 
> <nods>
> > 
> > Ian.
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Shriram Rajagopalan]

On Tue, Mar 15, 2011 at 8:12 AM, Ian Campbell
<Ian.Campbell@eu.citrix.com> wrote:
> On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
>> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
>> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
>> > > Probably over the weekend Linus is going to open the merge window.
>> > >
>> > > This merge window is much more complicated than the previous
>> > > one b/c we got a lot of good stuff.
>> > >
>> > > For my sanity and book-keeping I was thinking to email Linus
>> > > five git pull requests:
>> > [...]
>> > > .. and then during the next week of the two weeks merge window:
>> > [...]
>> > > In this order or so.
>> >
>> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
>> > I've got most of it already)
>>
>> OK. #linux-next is you place then.
>> >
>> > > In other trees by other maintainers we have:
>> > [...]
>> > >  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
>> > >     xen suspend cleanups
>> > >     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
>> >
>> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
>>
>> <head smack> I knew I forgot something.
>>
>> The last I heard he was battling PVonHVM shutdown issues during his
>> testing of his patches.
>>
>> Shririam?
>
> He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
> PM tree, it looked sane to me.
>
> I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
> time since it has no dependency on either the PVHVM or PM trees.
>
> It also looks to me like patch 4/5 ("PM: Add visible
> HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
> PM tree whenever Rafael likes, since it doesn't depend on any of the
> others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once

I wish it was that easy.  Rafael's tree carries a commit that is
missing from both
Konrad's and Stefano's tree.

"PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"

--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY

 config XEN_SAVE_RESTORE
        bool
-       depends on XEN && PM
+       depends on XEN
        default y

 config XEN_DEBUG_FS

5/5 is based on this patch and that is the reason I had to create a
hybrid tree and base
my patches on it. If this conflict can be easily resolved by whoever
is doing the
merging, then I can resend the 5/5 alone based on stefano's tree and
Ian's idea of
pushing 2,3,5/5 through xen tree would work.

> everything else has settled down.
>
This "everything else has settled down" phrase has been causing lot of
delays :P.

I asked Konrad to pull my git branch, hoping that his test setup(and
his kernel config) would
not face the same issue mine (PVonHVM not shutting down).

The puzzling part is, the same patch series worked neatly during rc4
(Ian's tree) - the first time I
submitted my patches.

shriram
> Ian.
>
>>
>> >
>> > > The things that are not going in 2.6.39 are:
>> > >
>> > >   devel/xen-pciback-0.4.driver [xen-pciback]
>> >
>> > Targeting 2.6.40?
>>
>> Yes.
>> >
>> > >   devel/xen-blkback-v1 [xen-blkback]
>> >
>> > 2.6.40 again?
>>
>> Yeah, I think by that time any issues/failures would show up and I
>> can fix them.
>> >
>> > >   git://xenbits.xen.org/people/ianc/linux-2.6 upstream/dom0/backend/netback
>> > >   [xen-netback - well, it could if the network maintainers are comfortable
>> > >    with the driver, but I think it is still going through the review]
>> >
>> > I've got another round of (minor) review feedback to address, I'm still
>> > a little bit hopeful for a 2.6.39 merge.
>> >
>> > Either way this will go through the net tree not us.
>>
>> <nods>
>> >
>> > Ian.
>> >
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>
>
>

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Tue, 2011-03-15 at 16:53 +0000, Shriram Rajagopalan wrote:
> On Tue, Mar 15, 2011 at 8:12 AM, Ian Campbell
> <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
> >> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
> >> > > Probably over the weekend Linus is going to open the merge window.
> >> > >
> >> > > This merge window is much more complicated than the previous
> >> > > one b/c we got a lot of good stuff.
> >> > >
> >> > > For my sanity and book-keeping I was thinking to email Linus
> >> > > five git pull requests:
> >> > [...]
> >> > > .. and then during the next week of the two weeks merge window:
> >> > [...]
> >> > > In this order or so.
> >> >
> >> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
> >> > I've got most of it already)
> >>
> >> OK. #linux-next is you place then.
> >> >
> >> > > In other trees by other maintainers we have:
> >> > [...]
> >> > >  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
> >> > >     xen suspend cleanups
> >> > >     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
> >> >
> >> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
> >>
> >> <head smack> I knew I forgot something.
> >>
> >> The last I heard he was battling PVonHVM shutdown issues during his
> >> testing of his patches.
> >>
> >> Shririam?
> >
> > He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
> > PM tree, it looked sane to me.
> >
> > I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
> > time since it has no dependency on either the PVHVM or PM trees.
> >
> > It also looks to me like patch 4/5 ("PM: Add visible
> > HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
> > PM tree whenever Rafael likes, since it doesn't depend on any of the
> > others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once
> 
> I wish it was that easy.  Rafael's tree carries a commit that is
> missing from both
> Konrad's and Stefano's tree.
> 
> "PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"
> 
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY
> 
>  config XEN_SAVE_RESTORE
>         bool
> -       depends on XEN && PM
> +       depends on XEN
>         default y
> 
>  config XEN_DEBUG_FS
> 
> 5/5 is based on this patch and that is the reason I had to create a
> hybrid tree and base my patches on it. If this conflict can be easily resolved by whoever
> is doing the merging, then I can resend the 5/5 alone based on stefano's tree and
> Ian's idea of pushing 2,3,5/5 through xen tree would work.

4/5 needs to be upstream (via Rafael) first though, doesn't it? That's
the keystone here, the rest appears to fall out nicely once that has
gone in.

Certainly the conflict above isn't (IMHO) worth worrying about in and of
itself, it will be trivially resolved when Linus does the pull. (doubly
so if the pull request warns him it's coming and says what to do...)

> > everything else has settled down.
> >
> This "everything else has settled down" phrase has been causing lot of
> delays :P.

It's unfortunately often the case when a change spans multiple
maintainers.

Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Shriram Rajagopalan]

On Tue, Mar 15, 2011 at 12:52 PM, Ian Campbell
<Ian.Campbell@eu.citrix.com> wrote:
> On Tue, 2011-03-15 at 16:53 +0000, Shriram Rajagopalan wrote:
>> On Tue, Mar 15, 2011 at 8:12 AM, Ian Campbell
>> <Ian.Campbell@eu.citrix.com> wrote:
>> > On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
>> >> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
>> >> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
>> >> > > Probably over the weekend Linus is going to open the merge window.
>> >> > >
>> >> > > This merge window is much more complicated than the previous
>> >> > > one b/c we got a lot of good stuff.
>> >> > >
>> >> > > For my sanity and book-keeping I was thinking to email Linus
>> >> > > five git pull requests:
>> >> > [...]
>> >> > > .. and then during the next week of the two weeks merge window:
>> >> > [...]
>> >> > > In this order or so.
>> >> >
>> >> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
>> >> > I've got most of it already)
>> >>
>> >> OK. #linux-next is you place then.
>> >> >
>> >> > > In other trees by other maintainers we have:
>> >> > [...]
>> >> > >  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
>> >> > >     xen suspend cleanups
>> >> > >     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
>> >> >
>> >> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
>> >>
>> >> <head smack> I knew I forgot something.
>> >>
>> >> The last I heard he was battling PVonHVM shutdown issues during his
>> >> testing of his patches.
>> >>
>> >> Shririam?
>> >
>> > He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
>> > PM tree, it looked sane to me.
>> >
>> > I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
>> > time since it has no dependency on either the PVHVM or PM trees.
>> >
>> > It also looks to me like patch 4/5 ("PM: Add visible
>> > HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
>> > PM tree whenever Rafael likes, since it doesn't depend on any of the
>> > others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once
>>
>> I wish it was that easy.  Rafael's tree carries a commit that is
>> missing from both
>> Konrad's and Stefano's tree.
>>
>> "PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"
>>
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY
>>
>>  config XEN_SAVE_RESTORE
>>         bool
>> -       depends on XEN && PM
>> +       depends on XEN
>>         default y
>>
>>  config XEN_DEBUG_FS
>>
>> 5/5 is based on this patch and that is the reason I had to create a
>> hybrid tree and base my patches on it. If this conflict can be easily resolved by whoever
>> is doing the merging, then I can resend the 5/5 alone based on stefano's tree and
>> Ian's idea of pushing 2,3,5/5 through xen tree would work.
>
> 4/5 needs to be upstream (via Rafael) first though, doesn't it? That's
> the keystone here, the rest appears to fall out nicely once that has
> gone in.
>
err, that was not the plan (though what you suggested would also work).
Look at thread
"Q: Clarification about extra option.."
http://lists.xensource.com/archives/html/xen-devel/2011-03/msg00267.html

The plan was that I would create a new tree by merging Rafael and
Stefano's trees. And then rebase my patches on this new tree, send out to
the list for review. Konrad meanwhile would pull this new tree+patches into his
tree and push it after Rafael & Stefano's trees have gone in.

The last I heard, Konrad was stuck on PVonHVM ballooning issue and was planning
to pull mine after resolving the issue.

shriram
> Certainly the conflict above isn't (IMHO) worth worrying about in and of
> itself, it will be trivially resolved when Linus does the pull. (doubly
> so if the pull request warns him it's coming and says what to do...)
>
>> > everything else has settled down.
>> >
>> This "everything else has settled down" phrase has been causing lot of
>> delays :P.
>
> It's unfortunately often the case when a change spans multiple
> maintainers.
>
> Ian.
>
>
>

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Tue, 2011-03-15 at 20:12 +0000, Shriram Rajagopalan wrote:
> On Tue, Mar 15, 2011 at 12:52 PM, Ian Campbell
> <Ian.Campbell@eu.citrix.com> wrote:
> > On Tue, 2011-03-15 at 16:53 +0000, Shriram Rajagopalan wrote:
> >> On Tue, Mar 15, 2011 at 8:12 AM, Ian Campbell
> >> <Ian.Campbell@eu.citrix.com> wrote:
> >> > On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
> >> >> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
> >> >> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
> >> >> > > Probably over the weekend Linus is going to open the merge window.
> >> >> > >
> >> >> > > This merge window is much more complicated than the previous
> >> >> > > one b/c we got a lot of good stuff.
> >> >> > >
> >> >> > > For my sanity and book-keeping I was thinking to email Linus
> >> >> > > five git pull requests:
> >> >> > [...]
> >> >> > > .. and then during the next week of the two weeks merge window:
> >> >> > [...]
> >> >> > > In this order or so.
> >> >> >
> >> >> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
> >> >> > I've got most of it already)
> >> >>
> >> >> OK. #linux-next is you place then.
> >> >> >
> >> >> > > In other trees by other maintainers we have:
> >> >> > [...]
> >> >> > >  git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
> >> >> > >     xen suspend cleanups
> >> >> > >     PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
> >> >> >
> >> >> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
> >> >>
> >> >> <head smack> I knew I forgot something.
> >> >>
> >> >> The last I heard he was battling PVonHVM shutdown issues during his
> >> >> testing of his patches.
> >> >>
> >> >> Shririam?
> >> >
> >> > He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
> >> > PM tree, it looked sane to me.
> >> >
> >> > I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
> >> > time since it has no dependency on either the PVHVM or PM trees.
> >> >
> >> > It also looks to me like patch 4/5 ("PM: Add visible
> >> > HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
> >> > PM tree whenever Rafael likes, since it doesn't depend on any of the
> >> > others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once
> >>
> >> I wish it was that easy.  Rafael's tree carries a commit that is
> >> missing from both
> >> Konrad's and Stefano's tree.
> >>
> >> "PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"
> >>
> >> --- a/arch/x86/xen/Kconfig
> >> +++ b/arch/x86/xen/Kconfig
> >> @@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY
> >>
> >>  config XEN_SAVE_RESTORE
> >>         bool
> >> -       depends on XEN && PM
> >> +       depends on XEN
> >>         default y
> >>
> >>  config XEN_DEBUG_FS
> >>
> >> 5/5 is based on this patch and that is the reason I had to create a
> >> hybrid tree and base my patches on it. If this conflict can be easily resolved by whoever
> >> is doing the merging, then I can resend the 5/5 alone based on stefano's tree and
> >> Ian's idea of pushing 2,3,5/5 through xen tree would work.
> >
> > 4/5 needs to be upstream (via Rafael) first though, doesn't it? That's
> > the keystone here, the rest appears to fall out nicely once that has
> > gone in.
> >
> err, that was not the plan (though what you suggested would also work).
> Look at thread
> "Q: Clarification about extra option.."
> http://lists.xensource.com/archives/html/xen-devel/2011-03/msg00267.html
> 
> The plan was that I would create a new tree by merging Rafael and
> Stefano's trees. And then rebase my patches on this new tree, send out to
> the list for review. Konrad meanwhile would pull this new tree+patches into his
> tree and push it after Rafael & Stefano's trees have gone in.

If Rafael is happy with that plan then fine, but I didn't see him ack it
in that thread (AFAICT he only acked the concept of what the patch would
do). Either way someone still needs to follow up with him to get an Ack
on the 4/5 patch since it is to the PM core, if he's subsequently also
ok with taking it through a tree other than his own then great.

Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Konrad Rzeszutek Wilk]

> > > 4/5 needs to be upstream (via Rafael) first though, doesn't it? That's

Yes...
> > > the keystone here, the rest appears to fall out nicely once that has
> > > gone in.
> > >
> > err, that was not the plan (though what you suggested would also work).
> > Look at thread
> > "Q: Clarification about extra option.."
> > http://lists.xensource.com/archives/html/xen-devel/2011-03/msg00267.html
> > 
> > The plan was that I would create a new tree by merging Rafael and
> > Stefano's trees. And then rebase my patches on this new tree, send out to
> > the list for review. Konrad meanwhile would pull this new tree+patches into his

So whatever I was hitting earlier on is gone (it also helps when I updated
my tools)

I took your tree, stuck it on top of my #linux-next and Stefano's #linux-next
and ran it with 'xm' (4.0) and 'xl' (4.1).

The 'xm save -c' and/or 'xm save' worked just great. The ping kept on going happily
doing these 'xm save -c'. 

The 'xl save -c' on the other hand, failed on me. I don't know what the failure is
but I see this state in the guest: 

test                                         8  1024     4     ---ss-       5.3

I should update my xen-uinstable tree just to make sure I am not missing something
obvious.

> > tree and push it after Rafael & Stefano's trees have gone in.
> 
> If Rafael is happy with that plan then fine, but I didn't see him ack it
> in that thread (AFAICT he only acked the concept of what the patch would
> do). Either way someone still needs to follow up with him to get an Ack
> on the 4/5 patch since it is to the PM core, if he's subsequently also

Yup. Please do ping him for his ACK. He needs to OK

      PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION


patch. Which btw, I looked in a kernel built before your patch
and had /sys/power/state contain "mem disk" (good). With your patch
and with 
CONFIG_HIBERNATION=y
# CONFIG_HIBERNATION_INTERFACE is not set

the /sys/power/state contained only "mem". Which is expected and
what the patch is suppose to do.

But what surprising is that I still had the /sys/power/disk attribute?

Also I saw this during compile:

/home/konrad/ssd/linux/kernel/power/hibernate.c:556: warning: ‘power_down’ defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:68: warning: ‘snapshot_open’ defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:128: warning: ‘snapshot_release’ defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:149: warning: ‘snapshot_read’ defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:182: warning: ‘snapshot_write’ defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:220: warning: ‘snapshot_ioctl’ defined but not used

Which you should address (you could send a follow-up patch for it).
Hadn't tried to compile this under i386 so no idea if there are any
warnings there either.

> ok with taking it through a tree other than his own then great.

I stuck it in #linux-next-kitchensink

Will re-organize it appropiately soon.
> 
> Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Tue, 2011-03-15 at 22:16 +0000, Konrad Rzeszutek Wilk wrote:

> > If Rafael is happy with that plan then fine, but I didn't see him ack it
> > in that thread (AFAICT he only acked the concept of what the patch would
> > do). Either way someone still needs to follow up with him to get an Ack
> > on the 4/5 patch since it is to the PM core, if he's subsequently also
> 
> Yup. Please do ping him for his ACK. He needs to OK
> 
>       PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
> 
> 
> patch. 

So I was chewing on this last night and I don't see why 2/5 "xen: use
freeze/restore/thaw PM events for suspend/resume/chkpt" needs to be
blocked by these core Kconfig changes.

The patch makes the Kconfig breakage different but it doesn't make it
any worse -- it just exchanges a false(/implicit?) dependency on
CONFIG_PM_SLEEP for one on CONFIG_HIBERNATE instead.

I suspect the change from CONFIG_PM_SLEEP->CONFIG_XEN_SAVE_RESTORE in
2/5 could be done as CONFIG_PM_SLEEP->CONFIG_HIBERNATE for now and only
switch to CONFIG_XEN_SAVE_RESTORE when the Kconfig stuff is sorted in
5/5.

So IMHO:

1/5 xen: xenbus PM events support

        Can go in now via a Xen tree. No brainer.

2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt

        Can go in now via a Xen tree. Contains a real bugfix and doesn't
        make the Kconfig situation any worse. Should probably have
        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
        time being (see 5/5).
        
3/5 PM: pm.h - Add comments about Xen save/restore/chkpt use case

        Can go in via the PM tree at leisure.

4/5 PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION

        Should go via PM tree once Rafael is happy with it.

5/5 xen: fix XEN_SAVE_RESTORE Kconfig dependencies

        Needs to follow both 2/5 and 4/5. Can most likely go via either
        tree with cross-maintainer agreement. Probably best via PM tree
        due to dependency on 4/5 since 2/5 can go in independently
        before then.
        
        Should incorporate the bit of 2/5 undone via the
        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/
        
Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
go in now...

Worst case is 2/5 makes it into 2.6.39 and 5/5 doesn't, in which case we
just need to remember to ask "Have you enabled CONFIG_HIBERNATE?"
instead of "Have you enabled CONFIG_PM_SLEEP?". In reality most kernel
configs are distro like and probably have both anyway.

Also the suspend changes which are already upstream make the error
reporting and toolstack behaviour when this happens better than
previously as well.

Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Konrad Rzeszutek Wilk]

> 1/5 xen: xenbus PM events support
> 
>         Can go in now via a Xen tree. No brainer.
> 
> 2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt
> 
>         Can go in now via a Xen tree. Contains a real bugfix and doesn't
>         make the Kconfig situation any worse. Should probably have
>         s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
>         time being (see 5/5).
>        
..snip..
>         
> Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
> go in now...

2/5 depends on Rafael tree so will have to wait until that gets merged in.
But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
has been merged.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Wed, 2011-03-16 at 14:29 +0000, Konrad Rzeszutek Wilk wrote:
> > 1/5 xen: xenbus PM events support
> > 
> >         Can go in now via a Xen tree. No brainer.
> > 
> > 2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt
> > 
> >         Can go in now via a Xen tree. Contains a real bugfix and doesn't
> >         make the Kconfig situation any worse. Should probably have
> >         s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
> >         time being (see 5/5).
> >        
> ..snip..
> >         
> > Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
> > go in now...
> 
> 2/5 depends on Rafael tree so will have to wait until that gets merged in.
> But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
> has been merged.

Does it? Why?

If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
in and let it get resolved at merge time.

Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Shriram Rajagopalan]

On 2011-03-16, at 2:40 AM, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:

> On Tue, 2011-03-15 at 22:16 +0000, Konrad Rzeszutek Wilk wrote:
> 
>>> If Rafael is happy with that plan then fine, but I didn't see him ack it
>>> in that thread (AFAICT he only acked the concept of what the patch would
>>> do). Either way someone still needs to follow up with him to get an Ack
>>> on the 4/5 patch since it is to the PM core, if he's subsequently also
>> 
>> Yup. Please do ping him for his ACK. He needs to OK
>> 
>>      PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
>> 
>> 
>> patch. 
> 
> So I was chewing on this last night and I don't see why 2/5 "xen: use
> freeze/restore/thaw PM events for suspend/resume/chkpt" needs to be
> blocked by these core Kconfig changes.
> 
> The patch makes the Kconfig breakage different but it doesn't make it
> any worse -- it just exchanges a false(/implicit?) dependency on
> CONFIG_PM_SLEEP for one on CONFIG_HIBERNATE instead.
> 
> I suspect the change from CONFIG_PM_SLEEP->CONFIG_XEN_SAVE_RESTORE in
> 2/5 could be done as CONFIG_PM_SLEEP->CONFIG_HIBERNATE for now and only
> switch to CONFIG_XEN_SAVE_RESTORE when the Kconfig stuff is sorted in
> 5/5.
> 
Why the change? The patch 2/5 currently currently makes the code block depend on the configuration that it actually corresponds to.
> So IMHO:
> 
> 1/5 xen: xenbus PM events support
> 
>        Can go in now via a Xen tree. No brainer.
> 
> 2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt
> 
>        Can go in now via a Xen tree. Contains a real bugfix and doesn't
>        make the Kconfig situation any worse. Should probably have
>        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
>        time being (see 5/5).
> 
> 3/5 PM: pm.h - Add comments about Xen save/restore/chkpt use case
> 
>        Can go in via the PM tree at leisure.
> 
> 4/5 PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
> 
>        Should go via PM tree once Rafael is happy with it.
> 
> 5/5 xen: fix XEN_SAVE_RESTORE Kconfig dependencies
> 
>        Needs to follow both 2/5 and 4/5.
Nope. I think it still can go in as is. All it does is to select HIBERNATION (not clean, unless 4 exists but not buggy either). See below for reasoning.
> Can most likely go via either
>        tree with cross-maintainer agreement. Probably best via PM tree
>        due to dependency on 4/5 since 2/5 can go in independently
>        before then.
> 
>        Should incorporate the bit of 2/5 undone via the
>        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/
> 
> Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
> go in now...
> 
> Worst case is 2/5 makes it into 2.6.39 and 5/5 doesn't, in which case we
> just need to remember to ask "Have you enabled CONFIG_HIBERNATE?"
> instead of "Have you enabled CONFIG_PM_SLEEP?". In reality most kernel
> configs are distro like and probably have both anyway.
> 
Exactly. Which means the current 5/5's (select HIBERNATION) would be a dud in most distro kernels. For those who configure by hand, in case "select HIBERNATION" fails, xen-save-restore would be disabled and things won't work.
 I agree that this is not aesthetic but your alternative would cause "pain" :).
 Common to both alternatives is the "feature" that sys/power/disk would be visible to the user and there would be folks attempting to "hibernate their vms". This would be the worst case, where we could say "it doest work".
> Also the suspend changes which are already upstream make the error
> reporting and toolstack behaviour when this happens better than
> previously as well.
> 
> Ian.
> 
We could avoid some more extra pain to users who use custom kernel configs. If they had disabled SWAP, then "select HIBERNATION" won't work. Could possibly happen in some distro kernel too (not sure which ones). 
 A solution for this would be to "select SWAP" too, under XEN_SAVE_RESTORE. This was in an earlier version of the patch series.
So when Rafael releases his own version of refactoring patch 4/5 (as he said he would do in a "while"), we could simply remove the "select SWAP" line from xen-save-restore kconfig.

So to summarize:
 1,2,5 could either go "as-is" now into the xen tree or with a little tweak to 5/5 (adding the select SWAP part)

Shriram

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Shriram Rajagopalan]

On 2011-03-16, at 7:38 AM, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:

> On Wed, 2011-03-16 at 14:29 +0000, Konrad Rzeszutek Wilk wrote:
>>> 1/5 xen: xenbus PM events support
>>> 
>>>        Can go in now via a Xen tree. No brainer.
>>> 
>>> 2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt
>>> 
>>>        Can go in now via a Xen tree. Contains a real bugfix and doesn't
>>>        make the Kconfig situation any worse. Should probably have
>>>        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
>>>        time being (see 5/5).
>>> 
>> ..snip..
>>> 
>>> Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
>>> go in now...
>> 
>> 2/5 depends on Rafael tree so will have to wait until that gets merged in.
>> But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
>> has been merged.
> 
> Does it? Why?
> 
> If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
> in and let it get resolved at merge time.
> 
> Ian.
> 
> 
I don't think 2/5 depends on Rafael's tree. 5/5 does, which could either follow Rafael's tree or let merge conflict resolve the issue. 2/5 is the bug fix, 5/5 is the icing

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Konrad Rzeszutek Wilk]

> > 2/5 depends on Rafael tree so will have to wait until that gets merged in.
> > But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
> > has been merged.
> 
> Does it? Why?
> 
> If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
> in and let it get resolved at merge time.

I get this rejection:
konrad@phenom:~/work/linux$ cat drivers/xen/xenbus/xenbus_probe_frontend.c.rej
--- drivers/xen/xenbus/xenbus_probe_frontend.c
+++ drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -86,9 +86,11 @@
 };
 
 static const struct dev_pm_ops xenbus_pm_ops = {
-       .suspend = xenbus_dev_suspend,
-       .resume  = xenbus_dev_resume,
-       .thaw  = xenbus_dev_cancel,
+       .suspend        = xenbus_dev_suspend,
+       .resume         = xenbus_dev_resume,
+       .freeze         = xenbus_dev_suspend,
+       .thaw           = xenbus_dev_cancel,
+       .restore        = xenbus_dev_resume,
 };
 
 static struct xen_bus_type xenbus_frontend = {


Which we could just omit this, but later we would still have to come up
with another patch to make up for this (I think, haven't loked in detail at
'restore' codepath in the PM core).

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Wed, 2011-03-16 at 15:58 +0000, Konrad Rzeszutek Wilk wrote:
> > > 2/5 depends on Rafael tree so will have to wait until that gets merged in.
> > > But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
> > > has been merged.
> > 
> > Does it? Why?
> > 
> > If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
> > in and let it get resolved at merge time.
> 
> I get this rejection:
[...]

Did you take 1/5? 2/5 needs it.

Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Wed, 2011-03-16 at 15:23 +0000, Shriram Rajagopalan wrote:
> On 2011-03-16, at 2:40 AM, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
> 
> > On Tue, 2011-03-15 at 22:16 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> >>> If Rafael is happy with that plan then fine, but I didn't see him ack it
> >>> in that thread (AFAICT he only acked the concept of what the patch would
> >>> do). Either way someone still needs to follow up with him to get an Ack
> >>> on the 4/5 patch since it is to the PM core, if he's subsequently also
> >> 
> >> Yup. Please do ping him for his ACK. He needs to OK
> >> 
> >>      PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
> >> 
> >> 
> >> patch. 
> > 
> > So I was chewing on this last night and I don't see why 2/5 "xen: use
> > freeze/restore/thaw PM events for suspend/resume/chkpt" needs to be
> > blocked by these core Kconfig changes.
> > 
> > The patch makes the Kconfig breakage different but it doesn't make it
> > any worse -- it just exchanges a false(/implicit?) dependency on
> > CONFIG_PM_SLEEP for one on CONFIG_HIBERNATE instead.
> > 
> > I suspect the change from CONFIG_PM_SLEEP->CONFIG_XEN_SAVE_RESTORE in
> > 2/5 could be done as CONFIG_PM_SLEEP->CONFIG_HIBERNATE for now and only
> > switch to CONFIG_XEN_SAVE_RESTORE when the Kconfig stuff is sorted in
> > 5/5.
> > 

> Why the change? The patch 2/5 currently currently makes the code block
> depend on the configuration that it actually corresponds to.

Well, apart from incorrectly mixing two fixes in one patch it just
fuzzes the issue and makes it harder to say that 2/5 is independently
OK.

5/5 is all about cleaning up the Kconfig stuff so lets leave it until
then and then there can be no argument about the correctness or
appropriateness of what remains 2/5 since only the obvious bugfix
remains.

> > So IMHO:
> > 
> > 1/5 xen: xenbus PM events support
> > 
> >        Can go in now via a Xen tree. No brainer.
> > 
> > 2/5 xen: use freeze/restore/thaw PM events for suspend/resume/chkpt
> > 
> >        Can go in now via a Xen tree. Contains a real bugfix and doesn't
> >        make the Kconfig situation any worse. Should probably have
> >        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/ done to it for the
> >        time being (see 5/5).
> > 
> > 3/5 PM: pm.h - Add comments about Xen save/restore/chkpt use case
> > 
> >        Can go in via the PM tree at leisure.
> > 
> > 4/5 PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION
> > 
> >        Should go via PM tree once Rafael is happy with it.
> > 
> > 5/5 xen: fix XEN_SAVE_RESTORE Kconfig dependencies
> > 
> >        Needs to follow both 2/5 and 4/5.

> Nope. I think it still can go in as is. All it does is to select
> HIBERNATION (not clean, unless 4 exists but not buggy either). See
> below for reasoning.

It's not allowed to "select" a user configurable option so I'm afraid it
is buggy. You cannot select HIBERNATION as it is, which is why it needs
the 4/5 refactoring.

> > Can most likely go via either
> >        tree with cross-maintainer agreement. Probably best via PM tree
> >        due to dependency on 4/5 since 2/5 can go in independently
> >        before then.
> > 
> >        Should incorporate the bit of 2/5 undone via the
> >        s/CONFIG_XEN_SAVE_RESTORE/CONFIG_HIBERNATION/
> > 
> > Basically 1/5..2/5 and 3/5..5/5 are two separate series and 1/5..2/5 can
> > go in now...
> > 
> > Worst case is 2/5 makes it into 2.6.39 and 5/5 doesn't, in which case we
> > just need to remember to ask "Have you enabled CONFIG_HIBERNATE?"
> > instead of "Have you enabled CONFIG_PM_SLEEP?". In reality most kernel
> > configs are distro like and probably have both anyway.
> > 
> Exactly. Which means the current 5/5's (select HIBERNATION) would be a
> dud in most distro kernels. For those who configure by hand, in case
> "select HIBERNATION" fails, xen-save-restore would be disabled and
> things won't work.

It breaks the converse case -- i.e. people who want to disable
HIBERNATION will not be able to and will have no clue why in the
configuration interface. This is why the convention against "select"ing
user visible options exists.

Ian.

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Konrad Rzeszutek Wilk]

On Wed, Mar 16, 2011 at 04:08:14PM +0000, Ian Campbell wrote:
> On Wed, 2011-03-16 at 15:58 +0000, Konrad Rzeszutek Wilk wrote:
> > > > 2/5 depends on Rafael tree so will have to wait until that gets merged in.
> > > > But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
> > > > has been merged.
> > > 
> > > Does it? Why?
> > > 
> > > If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
> > > in and let it get resolved at merge time.
> > 
> > I get this rejection:
> [...]
> 
> Did you take 1/5? 2/5 needs it.

Yes. I created a new branch based off linus/master, and did git am -s < ~/save

 cat ~/save | grep Message
Message-Id: <1299906435-30927-1-git-send-email-rshriram@cs.ubc.ca>
Message-Id: <1299906420-30885-1-git-send-email-rshriram@cs.ubc.ca>
konrad@phenom:~/work/linux$ cat ~/save | grep Subject:
Subject: [Xen-devel] [PATCH v3 2/5] xen: use freeze/restore/thaw PM events
Subject: [Xen-devel] [PATCH v3 1/5] xen: xenbus PM events support

> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Ian Campbell]

On Wed, 2011-03-16 at 16:21 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 16, 2011 at 04:08:14PM +0000, Ian Campbell wrote:
> > On Wed, 2011-03-16 at 15:58 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > 2/5 depends on Rafael tree so will have to wait until that gets merged in.
> > > > > But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
> > > > > has been merged.
> > > > 
> > > > Does it? Why?
> > > > 
> > > > If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
> > > > in and let it get resolved at merge time.
> > > 
> > > I get this rejection:
> > [...]
> > 
> > Did you take 1/5? 2/5 needs it.
> 
> Yes. I created a new branch based off linus/master, and did git am -s < ~/save
> 
>  cat ~/save | grep Message
> Message-Id: <1299906435-30927-1-git-send-email-rshriram@cs.ubc.ca>
> Message-Id: <1299906420-30885-1-git-send-email-rshriram@cs.ubc.ca>
> konrad@phenom:~/work/linux$ cat ~/save | grep Subject:
> Subject: [Xen-devel] [PATCH v3 2/5] xen: use freeze/restore/thaw PM events
> Subject: [Xen-devel] [PATCH v3 1/5] xen: xenbus PM events support

Those subjects look backwards?

> 
> > 
> > Ian.
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)

[Shriram Rajagopalan]

On Wed, Mar 16, 2011 at 9:24 AM, Ian Campbell
<Ian.Campbell@eu.citrix.com> wrote:
> On Wed, 2011-03-16 at 16:21 +0000, Konrad Rzeszutek Wilk wrote:
>> On Wed, Mar 16, 2011 at 04:08:14PM +0000, Ian Campbell wrote:
>> > On Wed, 2011-03-16 at 15:58 +0000, Konrad Rzeszutek Wilk wrote:
>> > > > > 2/5 depends on Rafael tree so will have to wait until that gets merged in.
>> > > > > But we can definitly push those two (1/5 and 2/5) right when Rafael's tree
>> > > > > has been merged.
>> > > >
>> > > > Does it? Why?
>> > > >
>> > > > If it's just the minor conflict in arch/x86/xen/Kconfig I say throw it
>> > > > in and let it get resolved at merge time.
>> > >
>> > > I get this rejection:
>> > [...]
>> >
>> > Did you take 1/5? 2/5 needs it.
>>
>> Yes. I created a new branch based off linus/master, and did git am -s < ~/save
>>
>>  cat ~/save | grep Message
>> Message-Id: <1299906435-30927-1-git-send-email-rshriram@cs.ubc.ca>
>> Message-Id: <1299906420-30885-1-git-send-email-rshriram@cs.ubc.ca>
>> konrad@phenom:~/work/linux$ cat ~/save | grep Subject:
>> Subject: [Xen-devel] [PATCH v3 2/5] xen: use freeze/restore/thaw PM events
>> Subject: [Xen-devel] [PATCH v3 1/5] xen: xenbus PM events support
>
> Those subjects look backwards?
>
>>
>> >
>> > Ian.
>> >
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>
>
>
Some thing is amiss. Anyway, I rebased my patches to linus's tree
(master) and it
still applies cleanly AFAICT. Konrad is pulling it now.

I will also resend the "v4 2/5", cc-ing Rafael, just so that he knows.

shriram

Re: Re: 2.6.39 merge window - git pulls and what went in.

[Konrad Rzeszutek Wilk]

> Some thing is amiss. Anyway, I rebased my patches to linus's tree
> (master) and it
> still applies cleanly AFAICT. Konrad is pulling it now.

And Linus applied most of the patches (yeey!). Thank you everybody!

I believe we only have these bug-fixes left:

Stefano Stabellini (3):
      xen: set max_pfn_mapped to the last pfn mapped
      xen: update mask_rw_pte after kernel page tables init changes
      acpiphp: set current_state to D0 in register_slot

Yinghai Lu (1):
      x86: Cleanup highmap after brk is concluded

Ian Campbell (1):
      acpiphp: assume device is in state D0 after powering on a slot.


I tried to apply Yinghai Lu's patch on top of linus/master today but
found that the cleanup_highmap had now been split in two different functions:
cleanup_highmap and cleanup_highmap_brk_end.

Is there a need to rebase those patches?

Here is the glory list of what is in 2.6.39-rc0 right now:
(git shortlog --grep="Xen" --grep="xen" v2.6.38..linus/master | grep -v netxen)

Alexander van Heukelum (1):
      x86, binutils, xen: Fix another wrong size directive

Daniel De Graaf (16):
      xen-gntdev: Change page limit to be global instead of per-open
      xen-gntdev: Use find_vma rather than iterating our vma list manually
      xen-gntdev: Add reference counting to maps
      xen-gntdev: Support mapping in HVM domains
      xen-gntalloc: Userspace grant allocation driver
      xen/gntalloc,gntdev: Add unmap notify ioctl
      xen-gntdev: Fix memory leak when mmap fails
      xen-gntdev: Fix unmap notify on PV domains
      xen-gntdev: Use map->vma for checking map validity
      xen-gntdev: Avoid unmapping ranges twice
      xen-gntdev: Avoid double-mapping memory
      xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only mappings
      xen-gntdev: Fix incorrect use of zero handle
      xen-gntdev: Add cast to pointer
      xen-balloon: Move core balloon functionality out of module
      xen-gntdev: Use ballooned pages for grant mappings

Daniel Kiper (3):
      xen/balloon: Removal of driver_pages
      xen/balloon: Migration from mod_timer() to schedule_delayed_work()
      xen/balloon: Protect against CPU exhaust by event/x process

Dave Airlie (1):
      Merge branch 'stable/ttm.pci-api.v5' of git://git.kernel.org/.../konrad/xen into drm-next

David S. Miller (1):
      Merge branch 'stable/backends' of git://git.kernel.org/.../konrad/xen

Eric Dumazet (1):
      xen: netfront: fix xennet_get_ethtool_stats()

Ian Campbell (55):
      xen: events: mark cpu_evtchn_mask_p as __refdata
      xen p2m: annotate variable which appears unused
      xen: annotate functions which only call into __init at start of day
      xen: do not respond to unknown xenstore control requests
      xen: use new schedop interface for suspend
      xen: switch to new schedop hypercall by default.
      xen: suspend: use HYPERVISOR_suspend for PVHVM case instead of open coding
      xen: suspend: refactor cancellation flag into a structure
      xen: suspend: pass extra hypercall argument via suspend_info struct
      xen: suspend: add "arch" to pre/post suspend hooks
      xen: suspend: refactor non-arch specific pre/post suspend hooks
      xen: suspend: move arch specific pre/post suspend hooks into generic hooks
      xen: suspend: pull pre/post suspend hooks out into suspend_info
      xen: suspend: remove xen_hvm_suspend
      xen/irq: implement bind_interdomain_evtchn_to_irqhandler for backend drivers
      xen: ia64 build broken due to "xen: switch to new schedop hypercall by default."
      xen: handled remapped IRQs when enabling a pcifront PCI device.
      xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
      xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
      xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
      xen: events: do not free legacy IRQs
      xen: Fix compile error introduced by "switch to new irq_chip functions"
      xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
      xen/p2m/m2p/gnttab: do not add failed grant maps to m2p override
      xen: gntdev: fix build warning
      xen: pci: only define xen_initdom_setup_msi_irqs if CONFIG_XEN_DOM0
      xen: events: do not leak IRQ from xen_allocate_pirq_msi when no pirq available.
      xen: events: drop XEN_ALLOC_IRQ flag to xen_allocate_pirq_msi
      xen: events: return irq from xen_allocate_pirq_msi
      xen: pci: collapse apic_register_gsi_xen_hvm and xen_hvm_register_pirq
      xen: events: assume PHYSDEVOP_get_free_pirq exists
      xen: events: separate MSI PIRQ allocation from PIRQ binding to IRQ
      xen: events: refactor xen_create_msi_irq slightly
      xen: events: update pirq_to_irq in xen_create_msi_irq
      xen: events: push set_irq_msi down into xen_create_msi_irq
      xen: events: use xen_bind_pirq_msi_to_irq from xen_create_msi_irq
      xen: events: remove dom0 specific xen_create_msi_irq
      xen: events: Make last processed event channel a per-cpu variable.
      xen: events: separate two unrelated halves of if condition
      xen: events: simplify comment
      xen: events: fix xen_map_pirq_gsi error return
      xen: events: remove unused public functions
      xen: events: rename restore_cpu_pirqs -> restore_pirqs
      xen: events: refactor GSI pirq bindings functions
      xen: events: use per-cpu variable for cpu_evtchn_mask
      xen: events: turn irq_info constructors into initialiser functions
      xen: events: push setup of irq<->{evtchn,ipi,virq,pirq} maps into irq_info init functions
      xen: events: maintain a list of Xen interrupts
      xen: events: dynamically allocate irq info structures
      xen: events: remove use of nr_irqs as upper bound on number of pirqs
      xen: events: do not workaround too-small nr_irqs
      xen: events: propagate irq allocation failure instead of panicking
      xen: events: correct locking in xen_irq_from_pirq
      xen: netfront: ethtool stats fields should be unsigned long
      xen network backend driver

Jan Beulich (1):
      watchdog: Xen watchdog driver

Javi Merino (1):
      kref: Fix typo in kref documentation

Kazuhiro SUZUKI (1):
      xen: xenbus PM events support

Keir Fraser (3):
      xen: events: Clean up round-robin evtchn scan.
      xen: events: Make round-robin scan fairer by snapshotting each l2 word once only
      xen: events: Remove redundant clear of l2i at end of round-robin loop

Konrad Rzeszutek Wilk (22):
      ttm: Utilize the DMA API for pages that have TTM_PAGE_FLAG_DMA32 set.
      xen-pcifront: Sanity check the MSI/MSI-X values
      pci/xen: Use xen_allocate_pirq_msi instead of xen_allocate_pirq
      pci/xen: Cleanup: convert int** to int[]
      pci/xen: When free-ing MSI-X/MSI irq->desc also use generic code.
      xen: Mark all initial reserved pages for the balloon as INVALID_P2M_ENTRY.
      Merge branch 'irq/for-xen' of git://git.kernel.org/.../tip/linux-2.6-tip into HEAD
      xen/irq: Cleanup up the pirq_to_irq for DomU PV PCI passthrough guests as well.
      xen/hvc: Disable probe_irq_on/off from poking the hvc-console IRQ line.
      Merge branch 'stable/irq.rework' into stable/irq.cleanup
      Merge branch 'stable/pcifront-fixes' into stable/irq.cleanup
      xen/e820: Don't mark balloon memory as E820_UNUSABLE when running as guest and fix overflow.
      xen/mmu: Add the notion of identity (1-1) mapping.
      xen/mmu: Set _PAGE_IOMAP if PFN is an identity PFN.
      xen/mmu: WARN_ON when racing to swap middle leaf.
      xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
      xen/debugfs: Add 'p2m' file for printing out the P2M layout.
      xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set.
      xen/m2p: No need to catch exceptions when we know that there is no RAM
      xen: events: Fix compile error if CONFIG_SMP is not defined.
      xen/balloon: Remove pr_info's and don't alter retry_count
      xen-balloon: Add interface to retrieve ballooned pages

Linus Torvalds (12):
      Merge branches 'stable/p2m-identity.v4.9.1' and 'stable/e820' of git://git.kernel.org/.../konrad/xen
      Merge branches 'stable/irq.rework' and 'stable/pcifront-fixes' of git://git.kernel.org/.../konrad/xen
      Merge branch 'stable/irq.cleanup' of git://git.kernel.org/.../konrad/xen
      Merge branches 'stable/ia64', 'stable/blkfront-cleanup' and 'stable/cleanup' of git://git.kernel.org/.../konrad/xen
      Merge branch 'for-linus' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm
      Merge branch 'x86-asm-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip
      Merge branch 'irq-core-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip
      Merge git://git.kernel.org/.../davem/net-next-2.6
      Merge git://git.kernel.org/.../wim/linux-2.6-watchdog
      Merge branches 'stable/hvc-console', 'stable/gntalloc.v6' and 'stable/balloon' of git://git.kernel.org/.../konrad/xen
      Merge branches 'stable/irq.fairness' and 'stable/irq.ween_of_nr_irqs' of git://git.kernel.org/.../konrad/xen
      Merge branch 'stable/xen.pm.bug-fixes' of git://git.kernel.org/.../konrad/xen

Owen Smith (1):
      xen: Union the blkif_request request specific fields

Scott Rixner (1):
      xen: events: Process event channels notifications in round-robin order.

Shriram Rajagopalan (1):
      xen: use freeze/restore/thaw PM events for suspend/resume/chkpt

Sony Chacko (2):

Stefano Stabellini (8):
      xen: change xen/[gntdev/gntalloc] to default m
      xen: no need to delay xen_setup_shutdown_event for hvm guests anymore
      xen: do not use xen_info on HVM, set pv_info name to "Xen HVM"
      xen-blkfront: handle Xen major numbers other than XENVBD
      xen: make the ballon driver work for hvm domains
      xen: PV on HVM: support PV spinlocks and IPIs
      xen: fix compile issue if XEN is enabled but XEN_PVHVM is disabled
      xen/m2p: Check whether the MFN has IDENTITY_FRAME bit set..

Tejun Heo (1):
      xen-pcifront: don't use flush_scheduled_work()

Thomas Gleixner (6):
      genirq: Add IRQF_FORCE_RESUME
      Merge branch 'irq/for-xen' into irq/core
      genirq: Make nr_irqs runtime expandable
      xen: Remove stale irq_chip.end
      xen: Switch to new irq_chip functions
      xen: Use IRQF_FORCE_RESUME

Yin Kangkai (1):
      serial-core: reset the console speed on resume

Zhang, Fengzhe (1):
      xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps.

Re: 2.6.39 merge window - git pulls and what went in.

[Stephan Seitz]

[-- Attachment #1.1: Type: text/plain, Size: 441 bytes --]

On Fri, Mar 18, 2011 at 09:59:06AM -0400, Konrad Rzeszutek Wilk wrote:
>And Linus applied most of the patches (yeey!). Thank you everybody!

Yes, thanks for your great work.

May I as normal user ask if this means I can use 2.6.39 as Dom0 kernel 
for PV DomUs?

Shade and sweet water!

	Stephan

-- 
| Stephan Seitz             E-Mail: stse@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Re: 2.6.39 merge window - git pulls and what went in.

[Stefano Stabellini]

On Fri, 18 Mar 2011, Konrad Rzeszutek Wilk wrote:
> > Some thing is amiss. Anyway, I rebased my patches to linus's tree
> > (master) and it
> > still applies cleanly AFAICT. Konrad is pulling it now.
> 
> And Linus applied most of the patches (yeey!). Thank you everybody!
> 
> I believe we only have these bug-fixes left:
> 
> Stefano Stabellini (3):
>       xen: set max_pfn_mapped to the last pfn mapped
>       xen: update mask_rw_pte after kernel page tables init changes
>       acpiphp: set current_state to D0 in register_slot
> 
> Yinghai Lu (1):
>       x86: Cleanup highmap after brk is concluded
> 
> Ian Campbell (1):
>       acpiphp: assume device is in state D0 after powering on a slot.
> 

we are also missing:

Olaf Hering (1):
        input/xen-fbfront: advertise either absolute or relative coordinates



> 
> I tried to apply Yinghai Lu's patch on top of linus/master today but
> found that the cleanup_highmap had now been split in two different functions:
> cleanup_highmap and cleanup_highmap_brk_end.
> 
> Is there a need to rebase those patches?
> 

yes, the rebased version is the tip branch (I have already submitted a
pull request for it):

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 2.6.38-tip-fixes