Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Xen>
  3. Devel
2.6.39 merge window (git pulls and what is planned to go in)
konrad.wilk at oracle
Mar 10, 2011, 11:29 AM
Post #1 of 22 (2580 views)
Permalink
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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: 2.6.39 merge window (git pulls and what is planned to go in) [ In reply to ]
jeremy at goop
Mar 10, 2011, 5:26 PM
Post #2 of 22 (2555 views)
Permalink
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.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: 2.6.39 merge window (git pulls and what is planned to go in) [ In reply to ]
Ian.Campbell at eu
Mar 11, 2011, 1:11 AM
Post #3 of 22 (2549 views)
Permalink
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.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: 2.6.39 merge window (git pulls and what is planned to go in) [ In reply to ]
stefano.stabellini at eu
Mar 11, 2011, 3:00 AM
Post #4 of 22 (2548 views)
Permalink
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.

_______________________________________________
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) [ In reply to ]
konrad.wilk at oracle
Mar 11, 2011, 6:21 AM
Post #5 of 22 (2546 views)
Permalink
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

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 15, 2011, 8:12 AM
Post #6 of 22 (2528 views)
Permalink
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



_______________________________________________
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) [ In reply to ]
rshriram at cs
Mar 15, 2011, 9:53 AM
Post #7 of 22 (2532 views)
Permalink
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
>
>
>

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 15, 2011, 12:52 PM
Post #8 of 22 (2529 views)
Permalink
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.



_______________________________________________
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) [ In reply to ]
rshriram at cs
Mar 15, 2011, 1:12 PM
Post #9 of 22 (2524 views)
Permalink
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.
>
>
>

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 15, 2011, 1:58 PM
Post #10 of 22 (2524 views)
Permalink
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.


_______________________________________________
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) [ In reply to ]
konrad.wilk at oracle
Mar 15, 2011, 3:16 PM
Post #11 of 22 (2529 views)
Permalink
> > > 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.

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 16, 2011, 2:40 AM
Post #12 of 22 (2528 views)
Permalink
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.


_______________________________________________
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) [ In reply to ]
konrad.wilk at oracle
Mar 16, 2011, 7:29 AM
Post #13 of 22 (2528 views)
Permalink
> 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.

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 16, 2011, 7:38 AM
Post #14 of 22 (2533 views)
Permalink
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.



_______________________________________________
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) [ In reply to ]
rshriram at cs
Mar 16, 2011, 8:23 AM
Post #15 of 22 (2528 views)
Permalink
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
_______________________________________________
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) [ In reply to ]
rshriram at cs
Mar 16, 2011, 8:28 AM
Post #16 of 22 (2528 views)
Permalink
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
_______________________________________________
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) [ In reply to ]
konrad.wilk at oracle
Mar 16, 2011, 8:58 AM
Post #17 of 22 (2532 views)
Permalink
> > 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).

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 16, 2011, 9:08 AM
Post #18 of 22 (2528 views)
Permalink
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.



_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 16, 2011, 9:15 AM
Post #19 of 22 (2524 views)
Permalink
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.



_______________________________________________
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) [ In reply to ]
konrad.wilk at oracle
Mar 16, 2011, 9:21 AM
Post #20 of 22 (2533 views)
Permalink
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

_______________________________________________
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) [ In reply to ]
Ian.Campbell at eu
Mar 16, 2011, 9:24 AM
Post #21 of 22 (2529 views)
Permalink
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



_______________________________________________
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) [ In reply to ]
rshriram at cs
Mar 16, 2011, 10:12 AM
Post #22 of 22 (2532 views)
Permalink
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

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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal