Konrad Rzeszutek Wilk
2011-Mar-10 19:29 UTC
[Xen-devel] 2.6.39 merge window (git pulls and what is planned to go in)
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
Jeremy Fitzhardinge
2011-Mar-11 01:26 UTC
[Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Ian Campbell
2011-Mar-11 09:11 UTC
[Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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 HVMAre 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
Stefano Stabellini
2011-Mar-11 11:00 UTC
[Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Konrad Rzeszutek Wilk
2011-Mar-11 14:21 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Ian Campbell
2011-Mar-15 15:12 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Shriram Rajagopalan
2011-Mar-15 16:53 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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 onceI 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
Ian Campbell
2011-Mar-15 19:52 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Shriram Rajagopalan
2011-Mar-15 20:12 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Ian Campbell
2011-Mar-15 20:58 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Konrad Rzeszutek Wilk
2011-Mar-15 22:16 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
> > > 4/5 needs to be upstream (via Rafael) first though, doesn''t it? That''sYes...> > > 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 hisSo 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 alsoYup. 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
Ian Campbell
2011-Mar-16 09:40 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Konrad Rzeszutek Wilk
2011-Mar-16 14:29 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
> 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
Ian Campbell
2011-Mar-16 14:38 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Shriram Rajagopalan
2011-Mar-16 15:23 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Shriram Rajagopalan
2011-Mar-16 15:28 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Konrad Rzeszutek Wilk
2011-Mar-16 15:58 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
> > 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
Ian Campbell
2011-Mar-16 16:08 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Ian Campbell
2011-Mar-16 16:15 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Konrad Rzeszutek Wilk
2011-Mar-16 16:21 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Ian Campbell
2011-Mar-16 16:24 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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 supportThose 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
Shriram Rajagopalan
2011-Mar-16 17:12 UTC
Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)
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
Konrad Rzeszutek Wilk
2011-Mar-18 13:59 UTC
Re: [Xen-devel] Re: 2.6.39 merge window - git pulls and what went in.
> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stephan Seitz
2011-Mar-18 14:36 UTC
[Xen-devel] Re: 2.6.39 merge window - git pulls and what went in.
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 | _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-Mar-18 14:39 UTC
Re: [Xen-devel] Re: 2.6.39 merge window - git pulls and what went in.
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel