| Message ID | 08bca9a4158a190a0a953e5bc071a512cfe5f0f8.1703072575.git.oleksii.kurochko@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Introduce generic headers | expand |
Hi Oleksii, On 20/12/2023 14:08, Oleksii Kurochko wrote: > <asm/numa.h> is common through some archs so it is moved > to asm-generic. > > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > Reviewed-by: Michal Orzel <michal.orzel@amd.com> > Acked-by: Jan Beulich <jbeulich@suse.com> > Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> I think this patch will need to be rebased on top of the lastest staging as this should clash with 51ffb3311895. Cheers,
On 21.12.2023 20:09, Julien Grall wrote: > On 20/12/2023 14:08, Oleksii Kurochko wrote: >> <asm/numa.h> is common through some archs so it is moved >> to asm-generic. >> >> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >> Reviewed-by: Michal Orzel <michal.orzel@amd.com> >> Acked-by: Jan Beulich <jbeulich@suse.com> >> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> > > I think this patch will need to be rebased on top of the lastest staging > as this should clash with 51ffb3311895. No, and I'd like to withdraw my ack here. In this case a stub header isn't the right choice imo - the !NUMA case should be handled in common code. I would have submitted the patch I have, if only the first_valid_mfn patch hadn't been committed already (which I now need to re-base over). Jan
On Fri, 2023-12-22 at 09:22 +0100, Jan Beulich wrote: > On 21.12.2023 20:09, Julien Grall wrote: > > On 20/12/2023 14:08, Oleksii Kurochko wrote: > > > <asm/numa.h> is common through some archs so it is moved > > > to asm-generic. > > > > > > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > > > Reviewed-by: Michal Orzel <michal.orzel@amd.com> > > > Acked-by: Jan Beulich <jbeulich@suse.com> > > > Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> > > > > I think this patch will need to be rebased on top of the lastest > > staging > > as this should clash with 51ffb3311895. > > No, and I'd like to withdraw my ack here. In this case a stub header > isn't > the right choice imo - the !NUMA case should be handled in common > code. I > would have submitted the patch I have, if only the first_valid_mfn > patch > hadn't been committed already (which I now need to re-base over). I haven't seen your patch yet (waiting for it), but I assume that <asm/numa.h> will still be necessary and remain the same across Arm, PPC, and RISC-V. What am I missing? ~ Oleksii
On 22.12.2023 14:07, Oleksii wrote: > On Fri, 2023-12-22 at 09:22 +0100, Jan Beulich wrote: >> On 21.12.2023 20:09, Julien Grall wrote: >>> On 20/12/2023 14:08, Oleksii Kurochko wrote: >>>> <asm/numa.h> is common through some archs so it is moved >>>> to asm-generic. >>>> >>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >>>> Reviewed-by: Michal Orzel <michal.orzel@amd.com> >>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> >>> >>> I think this patch will need to be rebased on top of the lastest >>> staging >>> as this should clash with 51ffb3311895. >> >> No, and I'd like to withdraw my ack here. In this case a stub header >> isn't >> the right choice imo - the !NUMA case should be handled in common >> code. I >> would have submitted the patch I have, if only the first_valid_mfn >> patch >> hadn't been committed already (which I now need to re-base over). > I haven't seen your patch yet (waiting for it), but I assume that > <asm/numa.h> will still be necessary and remain the same across Arm, > PPC, and RISC-V. > > What am I missing? asm/numa.h will be necessary for an arch only if it actually has a way to have CONFIG_NUMA enabled. Below, for your reference, the patch in the not-yet-rebased form. As you can see, Arm's (and PPC's) header goes away. If and when they choose to support NUMA, they may need to regain one; whether at that point we can sort how an asm-generic/ form of the header might sensibly look like remains to be seen. Jan NUMA: no need for asm/numa.h when !NUMA There's no point in every architecture carrying the same stubs for the case when NUMA isn't enabled (or even supported). Move all of that to xen/numa.h; replace explicit uses of asm/numa.h in common code. Make inclusion of asm/numa.h dependent upon NUMA=y. Address the TODO regarding first_valid_mfn by making the variable static when NUMA=y, thus also addressing a Misrs C:2012 rule 8.4 concern. Drop the not really applicable "implement NUMA support" comment - in a !NUMA section this simply makes no sense. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- This is an alternative proposal to https://lists.xen.org/archives/html/xen-devel/2023-12/msg01586.html and its earlier forms. --- unstable.orig/xen/arch/arm/include/asm/numa.h +++ /dev/null @@ -1,37 +0,0 @@ -#ifndef __ARCH_ARM_NUMA_H -#define __ARCH_ARM_NUMA_H - -#include <xen/mm.h> - -typedef u8 nodeid_t; - -#ifndef CONFIG_NUMA - -/* Fake one node for now. See also node_online_map. */ -#define cpu_to_node(cpu) 0 -#define node_to_cpumask(node) (cpu_online_map) - -/* - * TODO: make first_valid_mfn static when NUMA is supported on Arm, this - * is required because the dummy helpers are using it. - */ -extern mfn_t first_valid_mfn; - -/* XXX: implement NUMA support */ -#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn)) -#define node_start_pfn(nid) (mfn_x(first_valid_mfn)) -#define __node_distance(a, b) (20) - -#endif - -#define arch_want_default_dmazone() (false) - -#endif /* __ARCH_ARM_NUMA_H */ -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * indent-tabs-mode: nil - * End: - */ --- unstable.orig/xen/arch/arm/smpboot.c +++ unstable/xen/arch/arm/smpboot.c @@ -42,7 +42,7 @@ integer_param("maxcpus", max_cpus); /* CPU logical map: map xen cpuid to an MPIDR */ register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID }; -/* Fake one node for now. See also asm/numa.h */ +/* Fake one node for now. See also xen/numa.h */ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } }; /* Xen stack for bringing up the first CPU. */ --- unstable.orig/xen/arch/ppc/include/asm/numa.h +++ /dev/null @@ -1,26 +0,0 @@ -#ifndef __ASM_PPC_NUMA_H__ -#define __ASM_PPC_NUMA_H__ - -#include <xen/types.h> -#include <xen/mm.h> - -typedef uint8_t nodeid_t; - -/* Fake one node for now. See also node_online_map. */ -#define cpu_to_node(cpu) 0 -#define node_to_cpumask(node) (cpu_online_map) - -/* - * TODO: make first_valid_mfn static when NUMA is supported on PPC, this - * is required because the dummy helpers are using it. - */ -extern mfn_t first_valid_mfn; - -/* XXX: implement NUMA support */ -#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn)) -#define node_start_pfn(nid) (mfn_x(first_valid_mfn)) -#define __node_distance(a, b) (20) - -#define arch_want_default_dmazone() (false) - -#endif /* __ASM_PPC_NUMA_H__ */ --- unstable.orig/xen/common/page_alloc.c +++ unstable/xen/common/page_alloc.c @@ -140,7 +140,6 @@ #include <xen/vm_event.h> #include <asm/flushtlb.h> -#include <asm/numa.h> #include <asm/page.h> #include <public/sysctl.h> @@ -256,10 +255,14 @@ static PAGE_LIST_HEAD(page_broken_list); * BOOT-TIME ALLOCATOR */ +#ifndef CONFIG_NUMA /* * first_valid_mfn is exported because it is use in ARM specific NUMA * helpers. See comment in arch/arm/include/asm/numa.h. */ +#else +static +#endif mfn_t first_valid_mfn = INVALID_MFN_INITIALIZER; struct bootmem_region { --- unstable.orig/xen/common/sysctl.c +++ unstable/xen/common/sysctl.c @@ -22,8 +22,8 @@ #include <asm/current.h> #include <xen/hypercall.h> #include <public/sysctl.h> -#include <asm/numa.h> #include <xen/nodemask.h> +#include <xen/numa.h> #include <xsm/xsm.h> #include <xen/pmstat.h> #include <xen/livepatch.h> --- unstable.orig/xen/include/xen/domain.h +++ unstable/xen/include/xen/domain.h @@ -2,6 +2,7 @@ #ifndef __XEN_DOMAIN_H__ #define __XEN_DOMAIN_H__ +#include <xen/numa.h> #include <xen/types.h> #include <public/xen.h> @@ -12,7 +13,6 @@ struct guest_area { }; #include <asm/domain.h> -#include <asm/numa.h> typedef union { struct vcpu_guest_context *nat; --- unstable.orig/xen/include/xen/numa.h +++ unstable/xen/include/xen/numa.h @@ -2,7 +2,13 @@ #define _XEN_NUMA_H #include <xen/mm-frame.h> + +#ifdef CONFIG_NUMA +#include <xen/pdx.h> #include <asm/numa.h> +#else +typedef uint8_t nodeid_t; +#endif #define NUMA_NO_NODE 0xFF #define NUMA_NO_DISTANCE 0xFF @@ -108,6 +114,18 @@ extern void numa_set_processor_nodes_par #else +/* Fake one node for now. See also node_online_map. */ +#define cpu_to_node(cpu) 0 +#define node_to_cpumask(node) cpu_online_map + +#define arch_want_default_dmazone() false + +extern mfn_t first_valid_mfn; + +#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn)) +#define node_start_pfn(nid) mfn_x(first_valid_mfn) +#define __node_distance(a, b) 20 + static inline nodeid_t mfn_to_nid(mfn_t mfn) { return 0; --- unstable.orig/xen/include/xen/pci.h +++ unstable/xen/include/xen/pci.h @@ -11,10 +11,10 @@ #include <xen/list.h> #include <xen/spinlock.h> #include <xen/irq.h> +#include <xen/numa.h> #include <xen/pci_regs.h> #include <xen/pfn.h> #include <asm/device.h> -#include <asm/numa.h> /* * The PCI interface treats multi-function devices as independent
Hi Jan, On 22/12/2023 13:20, Jan Beulich wrote: > On 22.12.2023 14:07, Oleksii wrote: >> On Fri, 2023-12-22 at 09:22 +0100, Jan Beulich wrote: >>> On 21.12.2023 20:09, Julien Grall wrote: >>>> On 20/12/2023 14:08, Oleksii Kurochko wrote: >>>>> <asm/numa.h> is common through some archs so it is moved >>>>> to asm-generic. >>>>> >>>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >>>>> Reviewed-by: Michal Orzel <michal.orzel@amd.com> >>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> >>>> >>>> I think this patch will need to be rebased on top of the lastest >>>> staging >>>> as this should clash with 51ffb3311895. >>> >>> No, and I'd like to withdraw my ack here. In this case a stub header >>> isn't >>> the right choice imo - the !NUMA case should be handled in common >>> code. I >>> would have submitted the patch I have, if only the first_valid_mfn >>> patch >>> hadn't been committed already (which I now need to re-base over). >> I haven't seen your patch yet (waiting for it), but I assume that >> <asm/numa.h> will still be necessary and remain the same across Arm, >> PPC, and RISC-V. >> >> What am I missing? > > asm/numa.h will be necessary for an arch only if it actually has a way > to have CONFIG_NUMA enabled. Below, for your reference, the patch in > the not-yet-rebased form. As you can see, Arm's (and PPC's) header goes > away. If and when they choose to support NUMA, they may need to regain > one; whether at that point we can sort how an asm-generic/ form of the > header might sensibly look like remains to be seen. > > Jan > > NUMA: no need for asm/numa.h when !NUMA > > There's no point in every architecture carrying the same stubs for the > case when NUMA isn't enabled (or even supported). Move all of that to > xen/numa.h; replace explicit uses of asm/numa.h in common code. Make > inclusion of asm/numa.h dependent upon NUMA=y. > > Address the TODO regarding first_valid_mfn by making the variable static > when NUMA=y, thus also addressing a Misrs C:2012 rule 8.4 concern. Drop > the not really applicable "implement NUMA support" comment - in a !NUMA > section this simply makes no sense. I have to admit, I am not really thrill with the approach you have taken. As I said before, I don't quite understand the problem of having first_valid_mfn exposed in all the circumstances. This is better than trying to do... > --- unstable.orig/xen/common/page_alloc.c > +++ unstable/xen/common/page_alloc.c > @@ -140,7 +140,6 @@ > #include <xen/vm_event.h> > > #include <asm/flushtlb.h> > -#include <asm/numa.h> > #include <asm/page.h> > > #include <public/sysctl.h> > @@ -256,10 +255,14 @@ static PAGE_LIST_HEAD(page_broken_list); > * BOOT-TIME ALLOCATOR > */ > > +#ifndef CONFIG_NUMA > /* > * first_valid_mfn is exported because it is use in ARM specific NUMA > * helpers. See comment in arch/arm/include/asm/numa.h. > */ > +#else > +static > +#endif ... this sort ugliness. I am not going to Nack the patch. But I am definitely not going to ack it. with this change. Cheers,
On 22/12/2023 13:58, Julien Grall wrote: > Hi Jan, > > On 22/12/2023 13:20, Jan Beulich wrote: >> On 22.12.2023 14:07, Oleksii wrote: >>> On Fri, 2023-12-22 at 09:22 +0100, Jan Beulich wrote: >>>> On 21.12.2023 20:09, Julien Grall wrote: >>>>> On 20/12/2023 14:08, Oleksii Kurochko wrote: >>>>>> <asm/numa.h> is common through some archs so it is moved >>>>>> to asm-generic. >>>>>> >>>>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >>>>>> Reviewed-by: Michal Orzel <michal.orzel@amd.com> >>>>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>>>> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> >>>>> >>>>> I think this patch will need to be rebased on top of the lastest >>>>> staging >>>>> as this should clash with 51ffb3311895. >>>> >>>> No, and I'd like to withdraw my ack here. In this case a stub header >>>> isn't >>>> the right choice imo - the !NUMA case should be handled in common >>>> code. I >>>> would have submitted the patch I have, if only the first_valid_mfn >>>> patch >>>> hadn't been committed already (which I now need to re-base over). >>> I haven't seen your patch yet (waiting for it), but I assume that >>> <asm/numa.h> will still be necessary and remain the same across Arm, >>> PPC, and RISC-V. >>> >>> What am I missing? >> >> asm/numa.h will be necessary for an arch only if it actually has a way >> to have CONFIG_NUMA enabled. Below, for your reference, the patch in >> the not-yet-rebased form. As you can see, Arm's (and PPC's) header goes >> away. If and when they choose to support NUMA, they may need to regain >> one; whether at that point we can sort how an asm-generic/ form of the >> header might sensibly look like remains to be seen. >> >> Jan >> >> NUMA: no need for asm/numa.h when !NUMA >> >> There's no point in every architecture carrying the same stubs for the >> case when NUMA isn't enabled (or even supported). Move all of that to >> xen/numa.h; replace explicit uses of asm/numa.h in common code. Make >> inclusion of asm/numa.h dependent upon NUMA=y. >> >> Address the TODO regarding first_valid_mfn by making the variable static >> when NUMA=y, thus also addressing a Misrs C:2012 rule 8.4 concern. Drop >> the not really applicable "implement NUMA support" comment - in a !NUMA >> section this simply makes no sense. > > I have to admit, I am not really thrill with the approach you have > taken. As I said before, I don't quite understand the problem of having > first_valid_mfn exposed in all the circumstances. > > This is better than trying to do... > >> --- unstable.orig/xen/common/page_alloc.c >> +++ unstable/xen/common/page_alloc.c >> @@ -140,7 +140,6 @@ >> #include <xen/vm_event.h> >> #include <asm/flushtlb.h> >> -#include <asm/numa.h> >> #include <asm/page.h> >> #include <public/sysctl.h> >> @@ -256,10 +255,14 @@ static PAGE_LIST_HEAD(page_broken_list); >> * BOOT-TIME ALLOCATOR >> */ >> +#ifndef CONFIG_NUMA >> /* >> * first_valid_mfn is exported because it is use in ARM specific NUMA >> * helpers. See comment in arch/arm/include/asm/numa.h. >> */ >> +#else >> +static >> +#endif > > ... this sort ugliness. Just to add more thoughts. My main concern here is that we likely have other variables that may only be exposed for a given arch. I would rather not like if we start sprinkling the code with #ifdef CONFIG_XXX static #else. If there is a desire for everyone to start reducing the scope of the variable. Then we should come up with a way to do what you did above on the same line rather than multiple one. Maybe: STATIC_IF(CONFIG_NUMA) unsigned long first_valid_mfn. Cheers,
Dear community, Wishing you a Happy New Year! I'd like to propose the release schedule for Xen 4.19. Based on the previous release schedules [1] and [2], it seems the next release date should be on Wednesday, July 10, 2024: ** Proposed option: Wed Jul 10, 2024 ** (+9 months from Xen 4.18 release) - Last posting date Fri Apr 26, 2024 Patches adding new features are expected to be posted to the mailing list by this date, although perhaps not in their final version. - Feature freeze Fri May 17, 2024 (+3 weeks from Last posting date) Patches adding new features should be committed by this date. Straightforward bugfixes may continue to be accepted by maintainers. - Code freeze Fri May 31, 2024 (+2 weeks from Feature freeze) Bugfixes only. - Hard code freeze Fri Jun 21, 2024 (+3 weeks from Code freeze) Bugfixes for serious bugs (including regressions), and low-risk fixes only. - Final commits Fri Jul 05, 2024 (+2 weeks from Hard code freeze) Branch off staging-4.19. - Release Wed Jul 10, 2024 If there are no objections, we will stick to the proposed schedule. One more thing I'd like to discuss is whether to add a file (RELEASE.md) with the release schedule to the source code or update an existing one (xen-release-management.pandoc). I think it will help to find the final release schedule for the nearest release. For example, for the previous release, there are a lot of emails with proposed schedules, polls of Xen release schedules, and I found the final release schedule in just one of the replies (but probably I missed something). I'll be happy to hear any comments from you. Thanks in advance. Best regards, Oleksii [1] https://lore.kernel.org/xen-devel/AS8PR08MB7991424A3167C70A9B29530C92929@AS8PR08MB7991.eurprd08.prod.outlook.com/ [2] https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html
Something went wrong, and this email wasn't sent as a separate topic, so I re-sent it. Sorry for any inconvenience. ~ Oleksii On Tue, 2024-01-02 at 18:59 +0200, Oleksii wrote: > Dear community, > > Wishing you a Happy New Year! > > I'd like to propose the release schedule for Xen 4.19. > > Based on the previous release schedules [1] and [2], it seems the > next > release date should be on Wednesday, July 10, 2024: > > ** Proposed option: Wed Jul 10, 2024 ** > (+9 months from Xen 4.18 release) > > - Last posting date Fri Apr 26, 2024 > > Patches adding new features are expected to be posted to the mailing > list by this date, although perhaps not in their final version. > > - Feature freeze Fri May 17, 2024 (+3 weeks from Last > posting date) > > Patches adding new features should be committed by this date. > Straightforward bugfixes may continue to be accepted by maintainers. > > - Code freeze Fri May 31, 2024 (+2 weeks from Feature > freeze) > > Bugfixes only. > > - Hard code freeze Fri Jun 21, 2024 (+3 weeks from Code > freeze) > > Bugfixes for serious bugs (including regressions), and low-risk fixes > only. > > - Final commits Fri Jul 05, 2024 (+2 weeks from Hard > code > freeze) > > Branch off staging-4.19. > > - Release Wed Jul 10, 2024 > > If there are no objections, we will stick to the proposed schedule. > > One more thing I'd like to discuss is whether to add a file > (RELEASE.md) with the release schedule to the source code or update > an > existing one (xen-release-management.pandoc). I think it will help to > find the final release schedule for the nearest release. For example, > for the previous release, there are a lot of emails with proposed > schedules, polls of Xen release schedules, and I found the final > release schedule in just one of the replies (but probably I missed > something). > > I'll be happy to hear any comments from you. Thanks in advance. > > Best regards, > Oleksii > > [1] > https://lore.kernel.org/xen-devel/AS8PR08MB7991424A3167C70A9B29530C92929@AS8PR08MB7991.eurprd08.prod.outlook.com/ > [2] > https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html
On 02.01.24 17:59, Oleksii wrote: > Dear community, > > Wishing you a Happy New Year! > > I'd like to propose the release schedule for Xen 4.19. > > Based on the previous release schedules [1] and [2], it seems the next > release date should be on Wednesday, July 10, 2024: > > ** Proposed option: Wed Jul 10, 2024 ** > (+9 months from Xen 4.18 release) > > - Last posting date Fri Apr 26, 2024 > > Patches adding new features are expected to be posted to the mailing > list by this date, although perhaps not in their final version. > > - Feature freeze Fri May 17, 2024 (+3 weeks from Last > posting date) > > Patches adding new features should be committed by this date. > Straightforward bugfixes may continue to be accepted by maintainers. > > - Code freeze Fri May 31, 2024 (+2 weeks from Feature > freeze) > > Bugfixes only. > > - Hard code freeze Fri Jun 21, 2024 (+3 weeks from Code > freeze) > > Bugfixes for serious bugs (including regressions), and low-risk fixes > only. > > - Final commits Fri Jul 05, 2024 (+2 weeks from Hard code > freeze) > > Branch off staging-4.19. > > - Release Wed Jul 10, 2024 > > If there are no objections, we will stick to the proposed schedule. > > One more thing I'd like to discuss is whether to add a file > (RELEASE.md) with the release schedule to the source code or update an > existing one (xen-release-management.pandoc). I think it will help to > find the final release schedule for the nearest release. For example, > for the previous release, there are a lot of emails with proposed > schedules, polls of Xen release schedules, and I found the final > release schedule in just one of the replies (but probably I missed > something). What about putting it into the wiki under Xen_Project_X.YY_Release_Notes? That way it would already be accessible via SUPPORT.md (in the wiki under https://xenbits.xen.org/docs/unstable-staging/support-matrix.html ). Juergen
On Wed, 2024-01-03 at 06:53 +0100, Juergen Gross wrote: > On 02.01.24 17:59, Oleksii wrote: > > Dear community, > > > > Wishing you a Happy New Year! > > > > I'd like to propose the release schedule for Xen 4.19. > > > > Based on the previous release schedules [1] and [2], it seems the > > next > > release date should be on Wednesday, July 10, 2024: > > > > ** Proposed option: Wed Jul 10, 2024 ** > > (+9 months from Xen 4.18 release) > > > > - Last posting date Fri Apr 26, 2024 > > > > Patches adding new features are expected to be posted to the > > mailing > > list by this date, although perhaps not in their final version. > > > > - Feature freeze Fri May 17, 2024 (+3 weeks from Last > > posting date) > > > > Patches adding new features should be committed by this date. > > Straightforward bugfixes may continue to be accepted by > > maintainers. > > > > - Code freeze Fri May 31, 2024 (+2 weeks from > > Feature > > freeze) > > > > Bugfixes only. > > > > - Hard code freeze Fri Jun 21, 2024 (+3 weeks from Code > > freeze) > > > > Bugfixes for serious bugs (including regressions), and low-risk > > fixes > > only. > > > > - Final commits Fri Jul 05, 2024 (+2 weeks from Hard > > code > > freeze) > > > > Branch off staging-4.19. > > > > - Release Wed Jul 10, 2024 > > > > If there are no objections, we will stick to the proposed schedule. > > > > One more thing I'd like to discuss is whether to add a file > > (RELEASE.md) with the release schedule to the source code or update > > an > > existing one (xen-release-management.pandoc). I think it will help > > to > > find the final release schedule for the nearest release. For > > example, > > for the previous release, there are a lot of emails with proposed > > schedules, polls of Xen release schedules, and I found the final > > release schedule in just one of the replies (but probably I missed > > something). > > What about putting it into the wiki under > Xen_Project_X.YY_Release_Notes? > That way it would already be accessible via SUPPORT.md (in the wiki > under > https://xenbits.xen.org/docs/unstable-staging/support-matrix.html ). It makes sense to me. Thanks. ~ Oleksii
On 02.01.2024 17:59, Oleksii wrote: > I'd like to propose the release schedule for Xen 4.19. > > Based on the previous release schedules [1] and [2], it seems the next > release date should be on Wednesday, July 10, 2024: > > ** Proposed option: Wed Jul 10, 2024 ** > (+9 months from Xen 4.18 release) Hmm, aren't we intending to be on a 8 month cadence? Jan
On 20.12.2023 15:08, Oleksii Kurochko wrote: > <asm/numa.h> is common through some archs so it is moved > to asm-generic. > > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > Reviewed-by: Michal Orzel <michal.orzel@amd.com> > Acked-by: Jan Beulich <jbeulich@suse.com> > Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> I'd like to withdraw my ack here. As said elsewhere (and see the respective patch), I don't think a generic header is wanted or needed here (nor in similar other cases). !NUMA logic ought to live in xen/numa.h. Jan > --- > Changes in V6: > - Rebase only. > --- > Changes in V5: > - Added Acked-by: Jan Beulich <jbeulich@suse.com> > - Updated the comment around first_valid_mfn. ( Arm -> GENERIC ) > - Added Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com> > --- > Changes in V4: > - Updated guards name: *ARCH_GENERIC* -> *ASM_GENERIC*. > - Moved inclusion of xen/mm-frame.h under "#ifndef CONFIG_NUMA". > - Added Reviewed-by: Michal Orzel <michal.orzel@amd.com>. > --- > Changes in V3: > - Remove old header inclusion in asm-generic numa.h and include > <xen/mm-frame.h> and <xen/stdint.h> > - Drop Arm and PPC's numa.h and use asm-generic version instead. > --- > Changes in V2: > - update the commit message. > - change u8 to uint8_t. > - add ifnded CONFIG_NUMA. > --- > xen/arch/arm/include/asm/Makefile | 1 + > xen/arch/ppc/include/asm/Makefile | 1 + > xen/arch/ppc/include/asm/numa.h | 26 ------------------- > .../asm => include/asm-generic}/numa.h | 16 +++++++----- > 4 files changed, 12 insertions(+), 32 deletions(-) > delete mode 100644 xen/arch/ppc/include/asm/numa.h > rename xen/{arch/arm/include/asm => include/asm-generic}/numa.h (67%) > > diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile > index 8221429c2c..0c855a798a 100644 > --- a/xen/arch/arm/include/asm/Makefile > +++ b/xen/arch/arm/include/asm/Makefile > @@ -2,6 +2,7 @@ > generic-y += altp2m.h > generic-y += hardirq.h > generic-y += iocap.h > +generic-y += numa.h > generic-y += paging.h > generic-y += percpu.h > generic-y += random.h > diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile > index a8e848d4d0..f09c5ea8a1 100644 > --- a/xen/arch/ppc/include/asm/Makefile > +++ b/xen/arch/ppc/include/asm/Makefile > @@ -4,6 +4,7 @@ generic-y += div64.h > generic-y += hardirq.h > generic-y += hypercall.h > generic-y += iocap.h > +generic-y += numa.h > generic-y += paging.h > generic-y += percpu.h > generic-y += random.h > diff --git a/xen/arch/ppc/include/asm/numa.h b/xen/arch/ppc/include/asm/numa.h > deleted file mode 100644 > index 7fdf66c3da..0000000000 > --- a/xen/arch/ppc/include/asm/numa.h > +++ /dev/null > @@ -1,26 +0,0 @@ > -#ifndef __ASM_PPC_NUMA_H__ > -#define __ASM_PPC_NUMA_H__ > - > -#include <xen/types.h> > -#include <xen/mm.h> > - > -typedef uint8_t nodeid_t; > - > -/* Fake one node for now. See also node_online_map. */ > -#define cpu_to_node(cpu) 0 > -#define node_to_cpumask(node) (cpu_online_map) > - > -/* > - * TODO: make first_valid_mfn static when NUMA is supported on PPC, this > - * is required because the dummy helpers are using it. > - */ > -extern mfn_t first_valid_mfn; > - > -/* XXX: implement NUMA support */ > -#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn)) > -#define node_start_pfn(nid) (mfn_x(first_valid_mfn)) > -#define __node_distance(a, b) (20) > - > -#define arch_want_default_dmazone() (false) > - > -#endif /* __ASM_PPC_NUMA_H__ */ > diff --git a/xen/arch/arm/include/asm/numa.h b/xen/include/asm-generic/numa.h > similarity index 67% > rename from xen/arch/arm/include/asm/numa.h > rename to xen/include/asm-generic/numa.h > index e2bee2bd82..7f95a77e89 100644 > --- a/xen/arch/arm/include/asm/numa.h > +++ b/xen/include/asm-generic/numa.h > @@ -1,18 +1,21 @@ > -#ifndef __ARCH_ARM_NUMA_H > -#define __ARCH_ARM_NUMA_H > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef __ASM_GENERIC_NUMA_H > +#define __ASM_GENERIC_NUMA_H > > -#include <xen/mm.h> > +#include <xen/stdint.h> > > -typedef u8 nodeid_t; > +typedef uint8_t nodeid_t; > > #ifndef CONFIG_NUMA > > +#include <xen/mm-frame.h> > + > /* Fake one node for now. See also node_online_map. */ > #define cpu_to_node(cpu) 0 > #define node_to_cpumask(node) (cpu_online_map) > > /* > - * TODO: make first_valid_mfn static when NUMA is supported on Arm, this > + * TODO: make first_valid_mfn static when NUMA is supported on GENERIC, this > * is required because the dummy helpers are using it. > */ > extern mfn_t first_valid_mfn; > @@ -26,7 +29,8 @@ extern mfn_t first_valid_mfn; > > #define arch_want_default_dmazone() (false) > > -#endif /* __ARCH_ARM_NUMA_H */ > +#endif /* __ASM_GENERIC_NUMA_H */ > + > /* > * Local variables: > * mode: C
On Thu, 2024-01-04 at 13:52 +0100, Jan Beulich wrote: > On 02.01.2024 17:59, Oleksii wrote: > > I'd like to propose the release schedule for Xen 4.19. > > > > Based on the previous release schedules [1] and [2], it seems the > > next > > release date should be on Wednesday, July 10, 2024: > > > > ** Proposed option: Wed Jul 10, 2024 ** > > (+9 months from Xen 4.18 release) > > Hmm, aren't we intending to be on a 8 month cadence? Considering that in July, there will be the Xen Developer Summit, we can aim for an 8-month cadence. However, in the Xen release document, there was mention of a discussion [1] about cadence: "With 18 months of full support and 36 months of security support, the number of concurrent supported releases will be the same with either 8 or 9 months release cycles, so I have chosen an 8-month cycle for now." I interpreted this as either an 8 or 9-month cycle, and it's not strict. If there's a strict requirement for a specific duration, I'll resend the Release Schedule Proposal. [1] https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html ~ Oleksii
On 08.01.2024 15:37, Oleksii wrote: > On Thu, 2024-01-04 at 13:52 +0100, Jan Beulich wrote: >> On 02.01.2024 17:59, Oleksii wrote: >>> I'd like to propose the release schedule for Xen 4.19. >>> >>> Based on the previous release schedules [1] and [2], it seems the >>> next >>> release date should be on Wednesday, July 10, 2024: >>> >>> ** Proposed option: Wed Jul 10, 2024 ** >>> (+9 months from Xen 4.18 release) >> >> Hmm, aren't we intending to be on a 8 month cadence? > Considering that in July, there will be the Xen Developer Summit, we > can aim for an 8-month cadence. July? Iirc I read June in the announcement. > However, in the Xen release document, there was mention of a discussion > [1] about cadence: > "With 18 months of full support and 36 months of security support, the > number of concurrent supported releases will be the same with either 8 > or 9 months release cycles, so I have chosen an 8-month cycle for now." > > I interpreted this as either an 8 or 9-month cycle, and it's not > strict. If there's a strict requirement for a specific duration, I'll > resend the Release Schedule Proposal. I'm not sure about "strict". Yet ... > [1] https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html ... this very mail worked out how overlap with larger holiday ranges could be minimized not only for a single release, but for any as long as the cadence is followed. Iirc this works out better with 8 months (as kind of to be expected, as then there are only 3 variants, whereas with 9 months it would be 4 of them). Just to clarify, personally I'm fine with 9 months or even longer, but it seemed to me that we had settled on 8. Jan
Hi all, I propose we raise this in the next community call (Thursday 1st Feb). We can decide on the official cadence then and any further feedback. Many thanks, Kelly Choi Community Manager Xen Project On Mon, Jan 8, 2024 at 2:58 PM Jan Beulich <jbeulich@suse.com> wrote: > On 08.01.2024 15:37, Oleksii wrote: > > On Thu, 2024-01-04 at 13:52 +0100, Jan Beulich wrote: > >> On 02.01.2024 17:59, Oleksii wrote: > >>> I'd like to propose the release schedule for Xen 4.19. > >>> > >>> Based on the previous release schedules [1] and [2], it seems the > >>> next > >>> release date should be on Wednesday, July 10, 2024: > >>> > >>> ** Proposed option: Wed Jul 10, 2024 ** > >>> (+9 months from Xen 4.18 release) > >> > >> Hmm, aren't we intending to be on a 8 month cadence? > > Considering that in July, there will be the Xen Developer Summit, we > > can aim for an 8-month cadence. > > July? Iirc I read June in the announcement. > > > However, in the Xen release document, there was mention of a discussion > > [1] about cadence: > > "With 18 months of full support and 36 months of security support, the > > number of concurrent supported releases will be the same with either 8 > > or 9 months release cycles, so I have chosen an 8-month cycle for now." > > > > I interpreted this as either an 8 or 9-month cycle, and it's not > > strict. If there's a strict requirement for a specific duration, I'll > > resend the Release Schedule Proposal. > > I'm not sure about "strict". Yet ... > > > [1] https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html > > ... this very mail worked out how overlap with larger holiday ranges > could be minimized not only for a single release, but for any as long > as the cadence is followed. Iirc this works out better with 8 months > (as kind of to be expected, as then there are only 3 variants, whereas > with 9 months it would be 4 of them). > > Just to clarify, personally I'm fine with 9 months or even longer, but > it seemed to me that we had settled on 8. > > Jan >
diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile index 8221429c2c..0c855a798a 100644 --- a/xen/arch/arm/include/asm/Makefile +++ b/xen/arch/arm/include/asm/Makefile @@ -2,6 +2,7 @@ generic-y += altp2m.h generic-y += hardirq.h generic-y += iocap.h +generic-y += numa.h generic-y += paging.h generic-y += percpu.h generic-y += random.h diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile index a8e848d4d0..f09c5ea8a1 100644 --- a/xen/arch/ppc/include/asm/Makefile +++ b/xen/arch/ppc/include/asm/Makefile @@ -4,6 +4,7 @@ generic-y += div64.h generic-y += hardirq.h generic-y += hypercall.h generic-y += iocap.h +generic-y += numa.h generic-y += paging.h generic-y += percpu.h generic-y += random.h diff --git a/xen/arch/ppc/include/asm/numa.h b/xen/arch/ppc/include/asm/numa.h deleted file mode 100644 index 7fdf66c3da..0000000000 --- a/xen/arch/ppc/include/asm/numa.h +++ /dev/null @@ -1,26 +0,0 @@ -#ifndef __ASM_PPC_NUMA_H__ -#define __ASM_PPC_NUMA_H__ - -#include <xen/types.h> -#include <xen/mm.h> - -typedef uint8_t nodeid_t; - -/* Fake one node for now. See also node_online_map. */ -#define cpu_to_node(cpu) 0 -#define node_to_cpumask(node) (cpu_online_map) - -/* - * TODO: make first_valid_mfn static when NUMA is supported on PPC, this - * is required because the dummy helpers are using it. - */ -extern mfn_t first_valid_mfn; - -/* XXX: implement NUMA support */ -#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn)) -#define node_start_pfn(nid) (mfn_x(first_valid_mfn)) -#define __node_distance(a, b) (20) - -#define arch_want_default_dmazone() (false) - -#endif /* __ASM_PPC_NUMA_H__ */ diff --git a/xen/arch/arm/include/asm/numa.h b/xen/include/asm-generic/numa.h similarity index 67% rename from xen/arch/arm/include/asm/numa.h rename to xen/include/asm-generic/numa.h index e2bee2bd82..7f95a77e89 100644 --- a/xen/arch/arm/include/asm/numa.h +++ b/xen/include/asm-generic/numa.h @@ -1,18 +1,21 @@ -#ifndef __ARCH_ARM_NUMA_H -#define __ARCH_ARM_NUMA_H +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef __ASM_GENERIC_NUMA_H +#define __ASM_GENERIC_NUMA_H -#include <xen/mm.h> +#include <xen/stdint.h> -typedef u8 nodeid_t; +typedef uint8_t nodeid_t; #ifndef CONFIG_NUMA +#include <xen/mm-frame.h> + /* Fake one node for now. See also node_online_map. */ #define cpu_to_node(cpu) 0 #define node_to_cpumask(node) (cpu_online_map) /* - * TODO: make first_valid_mfn static when NUMA is supported on Arm, this + * TODO: make first_valid_mfn static when NUMA is supported on GENERIC, this * is required because the dummy helpers are using it. */ extern mfn_t first_valid_mfn; @@ -26,7 +29,8 @@ extern mfn_t first_valid_mfn; #define arch_want_default_dmazone() (false) -#endif /* __ARCH_ARM_NUMA_H */ +#endif /* __ASM_GENERIC_NUMA_H */ + /* * Local variables: * mode: C