| Message ID | fdff8da7431ac6e8e44f08c3f95c897be23ec745.1701093907.git.oleksii.kurochko@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Introduce generic headers | expand |
On 27.11.2023 15:13, Oleksii Kurochko wrote: > --- a/xen/arch/ppc/include/asm/grant_table.h > +++ /dev/null > @@ -1,5 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0-only */ > -#ifndef __ASM_PPC_GRANT_TABLE_H__ > -#define __ASM_PPC_GRANT_TABLE_H__ > - > -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ Removing this header would be correct only if GRANT_TABLE had a "depends on !PPC", I'm afraid. Recall that the earlier randconfig adjustment in CI was actually requested to be undone, at which point what an arch's defconfig says isn't necessarily what a randconfig should use. Jan
On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: > On 27.11.2023 15:13, Oleksii Kurochko wrote: > > --- a/xen/arch/ppc/include/asm/grant_table.h > > +++ /dev/null > > @@ -1,5 +0,0 @@ > > -/* SPDX-License-Identifier: GPL-2.0-only */ > > -#ifndef __ASM_PPC_GRANT_TABLE_H__ > > -#define __ASM_PPC_GRANT_TABLE_H__ > > - > > -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ > > Removing this header would be correct only if GRANT_TABLE had a > "depends on > !PPC", I'm afraid. Recall that the earlier randconfig adjustment in > CI was > actually requested to be undone, at which point what an arch's > defconfig > says isn't necessarily what a randconfig should use. We can do depends on !PPC && !RISCV but shouldn't it be enough only to turn CONFIG_GRANT_TABLE off in defconfig and set CONFIG_GRANT_TABLE=n in EXTRA_XEN_CONFIG? Some time ago I also tried to redefine "Config GRANT_TABLE" in arch- specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works for me. Could it be solution instead of "depends on..." ? One more question I have do we really need this randconfig? On RISC-V side, I launched several time this patch series ( from v1 to v4 + runs during test of patch series ) and I haven't faced case when CONFIG_GRANT_TABLE=n. ( but I turned the config off in defconfig + EXTRA_XEN_CONFIG ). Also when it "Config GRANT_TABLE" was re-defined in arch-specific KConfig I haven't face an issue with CONFIG_GRANT_TABLE too. ~ Oleksii
On 27.11.2023 20:38, Oleksii wrote: > On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: >> On 27.11.2023 15:13, Oleksii Kurochko wrote: >>> --- a/xen/arch/ppc/include/asm/grant_table.h >>> +++ /dev/null >>> @@ -1,5 +0,0 @@ >>> -/* SPDX-License-Identifier: GPL-2.0-only */ >>> -#ifndef __ASM_PPC_GRANT_TABLE_H__ >>> -#define __ASM_PPC_GRANT_TABLE_H__ >>> - >>> -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ >> >> Removing this header would be correct only if GRANT_TABLE had a >> "depends on >> !PPC", I'm afraid. Recall that the earlier randconfig adjustment in >> CI was >> actually requested to be undone, at which point what an arch's >> defconfig >> says isn't necessarily what a randconfig should use. > We can do depends on !PPC && !RISCV but shouldn't it be enough only to > turn CONFIG_GRANT_TABLE off in defconfig and set CONFIG_GRANT_TABLE=n > in EXTRA_XEN_CONFIG? That _might_ be sufficient for CI, but we shouldn't take CI as the only thing in the world. Personally I consider any kind of overriding for, in particular, randconfig at bets bogus. Whatever may not be selected (or must be selected) should be arranged for by Kconfig files themselves. That said, there may be _rare_ exceptions. But what PPC's and RISC-V's defconfig-s have right now is more than "rare" imo. > Some time ago I also tried to redefine "Config GRANT_TABLE" in arch- > specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works for me. > Could it be solution instead of "depends on..." ? Why would we want to re-define an setting? There wants to be one single place where a common option is defined. Or maybe I don't understand what you're suggesting ... > One more question I have do we really need this randconfig? On RISC-V > side, I launched several time this patch series ( from v1 to v4 + runs > during test of patch series ) and I haven't faced case > when CONFIG_GRANT_TABLE=n. ( but I turned the config off in defconfig + > EXTRA_XEN_CONFIG ). That override is why in CI you wouldn't see an issue. But as said - CI isn't everything. Jan
On Tue, 2023-11-28 at 08:57 +0100, Jan Beulich wrote: > On 27.11.2023 20:38, Oleksii wrote: > > On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: > > > On 27.11.2023 15:13, Oleksii Kurochko wrote: > > > > --- a/xen/arch/ppc/include/asm/grant_table.h > > > > +++ /dev/null > > > > @@ -1,5 +0,0 @@ > > > > -/* SPDX-License-Identifier: GPL-2.0-only */ > > > > -#ifndef __ASM_PPC_GRANT_TABLE_H__ > > > > -#define __ASM_PPC_GRANT_TABLE_H__ > > > > - > > > > -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ > > > > > > Removing this header would be correct only if GRANT_TABLE had a > > > "depends on > > > !PPC", I'm afraid. Recall that the earlier randconfig adjustment > > > in > > > CI was > > > actually requested to be undone, at which point what an arch's > > > defconfig > > > says isn't necessarily what a randconfig should use. > > We can do depends on !PPC && !RISCV but shouldn't it be enough only > > to > > turn CONFIG_GRANT_TABLE off in defconfig and set > > CONFIG_GRANT_TABLE=n > > in EXTRA_XEN_CONFIG? > > That _might_ be sufficient for CI, but we shouldn't take CI as the > only > thing in the world. Personally I consider any kind of overriding for, > in particular, randconfig at bets bogus. Whatever may not be selected > (or must be selected) should be arranged for by Kconfig files > themselves. > That said, there may be _rare_ exceptions. But what PPC's and RISC- > V's > defconfig-s have right now is more than "rare" imo. > > > Some time ago I also tried to redefine "Config GRANT_TABLE" in > > arch- > > specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works for > > me. > > Could it be solution instead of "depends on..." ? > > Why would we want to re-define an setting? There wants to be one > single > place where a common option is defined. Or maybe I don't understand > what you're suggesting ... I just thought this change is temporary because grant_table.h will be introduced later or earlier, and it will be needed to remove "depends on !PPC && !RISCV". And not to litter common KConfig with the change which will be removed, it will be better to redefine it in arch- specific Kconfig with default n. But after your words about one place, I realized that it would be better to update a place where a common option is defined. The only thing I would like to change is probably it will be better to do the opposite, add "depends on" arches that support CONFIG_GRANT_TABLE now so it will not need to update "depends on" for new arches or arches that don't support CONFIG_GRANT_TABLE. > > > One more question I have do we really need this randconfig? On > > RISC-V > > side, I launched several time this patch series ( from v1 to v4 + > > runs > > during test of patch series ) and I haven't faced case > > when CONFIG_GRANT_TABLE=n. ( but I turned the config off in > > defconfig + > > EXTRA_XEN_CONFIG ). > > That override is why in CI you wouldn't see an issue. But as said - > CI > isn't everything. From this point of view it will be better to add "depends on !PPC && !RISCV" to "Config GRANT_TABLE". ~ Oleksii
On 28.11.2023 10:28, Oleksii wrote: > On Tue, 2023-11-28 at 08:57 +0100, Jan Beulich wrote: >> On 27.11.2023 20:38, Oleksii wrote: >>> On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: >>>> On 27.11.2023 15:13, Oleksii Kurochko wrote: >>>>> --- a/xen/arch/ppc/include/asm/grant_table.h >>>>> +++ /dev/null >>>>> @@ -1,5 +0,0 @@ >>>>> -/* SPDX-License-Identifier: GPL-2.0-only */ >>>>> -#ifndef __ASM_PPC_GRANT_TABLE_H__ >>>>> -#define __ASM_PPC_GRANT_TABLE_H__ >>>>> - >>>>> -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ >>>> >>>> Removing this header would be correct only if GRANT_TABLE had a >>>> "depends on >>>> !PPC", I'm afraid. Recall that the earlier randconfig adjustment >>>> in >>>> CI was >>>> actually requested to be undone, at which point what an arch's >>>> defconfig >>>> says isn't necessarily what a randconfig should use. >>> We can do depends on !PPC && !RISCV but shouldn't it be enough only >>> to >>> turn CONFIG_GRANT_TABLE off in defconfig and set >>> CONFIG_GRANT_TABLE=n >>> in EXTRA_XEN_CONFIG? >> >> That _might_ be sufficient for CI, but we shouldn't take CI as the >> only >> thing in the world. Personally I consider any kind of overriding for, >> in particular, randconfig at bets bogus. Whatever may not be selected >> (or must be selected) should be arranged for by Kconfig files >> themselves. >> That said, there may be _rare_ exceptions. But what PPC's and RISC- >> V's >> defconfig-s have right now is more than "rare" imo. >> >>> Some time ago I also tried to redefine "Config GRANT_TABLE" in >>> arch- >>> specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works for >>> me. >>> Could it be solution instead of "depends on..." ? >> >> Why would we want to re-define an setting? There wants to be one >> single >> place where a common option is defined. Or maybe I don't understand >> what you're suggesting ... > I just thought this change is temporary because grant_table.h will be > introduced later or earlier, and it will be needed to remove "depends > on !PPC && !RISCV". And not to litter common KConfig with the change > which will be removed, it will be better to redefine it in arch- > specific Kconfig with default n. Right. But if it's indeed temporary, what's the point of this patch? The entire series is (supposed to be) to improve code structure for longer term purposes. If a non-generic grant_table.h is going to appear for PPC and RISC-V, I don't see why the present dummy would need removing. That's only useful if an arch can be expected to live with GRANT_TABLE=n even when otherwise feature-complete, and at that point modifying the Kconfig dependencies would (imo) be appropriate. Jan
On Tue, 2023-11-28 at 10:58 +0100, Jan Beulich wrote: > On 28.11.2023 10:28, Oleksii wrote: > > On Tue, 2023-11-28 at 08:57 +0100, Jan Beulich wrote: > > > On 27.11.2023 20:38, Oleksii wrote: > > > > On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: > > > > > On 27.11.2023 15:13, Oleksii Kurochko wrote: > > > > > > --- a/xen/arch/ppc/include/asm/grant_table.h > > > > > > +++ /dev/null > > > > > > @@ -1,5 +0,0 @@ > > > > > > -/* SPDX-License-Identifier: GPL-2.0-only */ > > > > > > -#ifndef __ASM_PPC_GRANT_TABLE_H__ > > > > > > -#define __ASM_PPC_GRANT_TABLE_H__ > > > > > > - > > > > > > -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ > > > > > > > > > > Removing this header would be correct only if GRANT_TABLE had > > > > > a > > > > > "depends on > > > > > !PPC", I'm afraid. Recall that the earlier randconfig > > > > > adjustment > > > > > in > > > > > CI was > > > > > actually requested to be undone, at which point what an > > > > > arch's > > > > > defconfig > > > > > says isn't necessarily what a randconfig should use. > > > > We can do depends on !PPC && !RISCV but shouldn't it be enough > > > > only > > > > to > > > > turn CONFIG_GRANT_TABLE off in defconfig and set > > > > CONFIG_GRANT_TABLE=n > > > > in EXTRA_XEN_CONFIG? > > > > > > That _might_ be sufficient for CI, but we shouldn't take CI as > > > the > > > only > > > thing in the world. Personally I consider any kind of overriding > > > for, > > > in particular, randconfig at bets bogus. Whatever may not be > > > selected > > > (or must be selected) should be arranged for by Kconfig files > > > themselves. > > > That said, there may be _rare_ exceptions. But what PPC's and > > > RISC- > > > V's > > > defconfig-s have right now is more than "rare" imo. > > > > > > > Some time ago I also tried to redefine "Config GRANT_TABLE" in > > > > arch- > > > > specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works > > > > for > > > > me. > > > > Could it be solution instead of "depends on..." ? > > > > > > Why would we want to re-define an setting? There wants to be one > > > single > > > place where a common option is defined. Or maybe I don't > > > understand > > > what you're suggesting ... > > I just thought this change is temporary because grant_table.h will > > be > > introduced later or earlier, and it will be needed to remove > > "depends > > on !PPC && !RISCV". And not to litter common KConfig with the > > change > > which will be removed, it will be better to redefine it in arch- > > specific Kconfig with default n. > > Right. But if it's indeed temporary, what's the point of this patch? > The entire series is (supposed to be) to improve code structure for > longer term purposes. If a non-generic grant_table.h is going to > appear for PPC and RISC-V, I don't see why the present dummy would > need removing. That's only useful if an arch can be expected to live > with GRANT_TABLE=n even when otherwise feature-complete, and at that > point modifying the Kconfig dependencies would (imo) be appropriate. I agree. Let's proceed by adding the dependency in the KConfig file. So which one option will be better: 1. depends on !PPC && !RISCV 2. depends on ARM || X86 ~ Oleksii
On 28.11.2023 12:49, Oleksii wrote: > On Tue, 2023-11-28 at 10:58 +0100, Jan Beulich wrote: >> On 28.11.2023 10:28, Oleksii wrote: >>> On Tue, 2023-11-28 at 08:57 +0100, Jan Beulich wrote: >>>> On 27.11.2023 20:38, Oleksii wrote: >>>>> On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: >>>>>> On 27.11.2023 15:13, Oleksii Kurochko wrote: >>>>>>> --- a/xen/arch/ppc/include/asm/grant_table.h >>>>>>> +++ /dev/null >>>>>>> @@ -1,5 +0,0 @@ >>>>>>> -/* SPDX-License-Identifier: GPL-2.0-only */ >>>>>>> -#ifndef __ASM_PPC_GRANT_TABLE_H__ >>>>>>> -#define __ASM_PPC_GRANT_TABLE_H__ >>>>>>> - >>>>>>> -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ >>>>>> >>>>>> Removing this header would be correct only if GRANT_TABLE had >>>>>> a >>>>>> "depends on >>>>>> !PPC", I'm afraid. Recall that the earlier randconfig >>>>>> adjustment >>>>>> in >>>>>> CI was >>>>>> actually requested to be undone, at which point what an >>>>>> arch's >>>>>> defconfig >>>>>> says isn't necessarily what a randconfig should use. >>>>> We can do depends on !PPC && !RISCV but shouldn't it be enough >>>>> only >>>>> to >>>>> turn CONFIG_GRANT_TABLE off in defconfig and set >>>>> CONFIG_GRANT_TABLE=n >>>>> in EXTRA_XEN_CONFIG? >>>> >>>> That _might_ be sufficient for CI, but we shouldn't take CI as >>>> the >>>> only >>>> thing in the world. Personally I consider any kind of overriding >>>> for, >>>> in particular, randconfig at bets bogus. Whatever may not be >>>> selected >>>> (or must be selected) should be arranged for by Kconfig files >>>> themselves. >>>> That said, there may be _rare_ exceptions. But what PPC's and >>>> RISC- >>>> V's >>>> defconfig-s have right now is more than "rare" imo. >>>> >>>>> Some time ago I also tried to redefine "Config GRANT_TABLE" in >>>>> arch- >>>>> specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works >>>>> for >>>>> me. >>>>> Could it be solution instead of "depends on..." ? >>>> >>>> Why would we want to re-define an setting? There wants to be one >>>> single >>>> place where a common option is defined. Or maybe I don't >>>> understand >>>> what you're suggesting ... >>> I just thought this change is temporary because grant_table.h will >>> be >>> introduced later or earlier, and it will be needed to remove >>> "depends >>> on !PPC && !RISCV". And not to litter common KConfig with the >>> change >>> which will be removed, it will be better to redefine it in arch- >>> specific Kconfig with default n. >> >> Right. But if it's indeed temporary, what's the point of this patch? >> The entire series is (supposed to be) to improve code structure for >> longer term purposes. If a non-generic grant_table.h is going to >> appear for PPC and RISC-V, I don't see why the present dummy would >> need removing. That's only useful if an arch can be expected to live >> with GRANT_TABLE=n even when otherwise feature-complete, and at that >> point modifying the Kconfig dependencies would (imo) be appropriate. > I agree. Let's proceed by adding the dependency in the KConfig file. > > So which one option will be better: > 1. depends on !PPC && !RISCV > 2. depends on ARM || X86 Agreeing and then making this suggestion contradicts one another. Unless the long-term plan is for PPC and RISC-V to not use grant tables. Jan
On Tue, 2023-11-28 at 13:53 +0100, Jan Beulich wrote: > On 28.11.2023 12:49, Oleksii wrote: > > On Tue, 2023-11-28 at 10:58 +0100, Jan Beulich wrote: > > > On 28.11.2023 10:28, Oleksii wrote: > > > > On Tue, 2023-11-28 at 08:57 +0100, Jan Beulich wrote: > > > > > On 27.11.2023 20:38, Oleksii wrote: > > > > > > On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote: > > > > > > > On 27.11.2023 15:13, Oleksii Kurochko wrote: > > > > > > > > --- a/xen/arch/ppc/include/asm/grant_table.h > > > > > > > > +++ /dev/null > > > > > > > > @@ -1,5 +0,0 @@ > > > > > > > > -/* SPDX-License-Identifier: GPL-2.0-only */ > > > > > > > > -#ifndef __ASM_PPC_GRANT_TABLE_H__ > > > > > > > > -#define __ASM_PPC_GRANT_TABLE_H__ > > > > > > > > - > > > > > > > > -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ > > > > > > > > > > > > > > Removing this header would be correct only if GRANT_TABLE > > > > > > > had > > > > > > > a > > > > > > > "depends on > > > > > > > !PPC", I'm afraid. Recall that the earlier randconfig > > > > > > > adjustment > > > > > > > in > > > > > > > CI was > > > > > > > actually requested to be undone, at which point what an > > > > > > > arch's > > > > > > > defconfig > > > > > > > says isn't necessarily what a randconfig should use. > > > > > > We can do depends on !PPC && !RISCV but shouldn't it be > > > > > > enough > > > > > > only > > > > > > to > > > > > > turn CONFIG_GRANT_TABLE off in defconfig and set > > > > > > CONFIG_GRANT_TABLE=n > > > > > > in EXTRA_XEN_CONFIG? > > > > > > > > > > That _might_ be sufficient for CI, but we shouldn't take CI > > > > > as > > > > > the > > > > > only > > > > > thing in the world. Personally I consider any kind of > > > > > overriding > > > > > for, > > > > > in particular, randconfig at bets bogus. Whatever may not be > > > > > selected > > > > > (or must be selected) should be arranged for by Kconfig files > > > > > themselves. > > > > > That said, there may be _rare_ exceptions. But what PPC's and > > > > > RISC- > > > > > V's > > > > > defconfig-s have right now is more than "rare" imo. > > > > > > > > > > > Some time ago I also tried to redefine "Config GRANT_TABLE" > > > > > > in > > > > > > arch- > > > > > > specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it > > > > > > works > > > > > > for > > > > > > me. > > > > > > Could it be solution instead of "depends on..." ? > > > > > > > > > > Why would we want to re-define an setting? There wants to be > > > > > one > > > > > single > > > > > place where a common option is defined. Or maybe I don't > > > > > understand > > > > > what you're suggesting ... > > > > I just thought this change is temporary because grant_table.h > > > > will > > > > be > > > > introduced later or earlier, and it will be needed to remove > > > > "depends > > > > on !PPC && !RISCV". And not to litter common KConfig with the > > > > change > > > > which will be removed, it will be better to redefine it in > > > > arch- > > > > specific Kconfig with default n. > > > > > > Right. But if it's indeed temporary, what's the point of this > > > patch? > > > The entire series is (supposed to be) to improve code structure > > > for > > > longer term purposes. If a non-generic grant_table.h is going to > > > appear for PPC and RISC-V, I don't see why the present dummy > > > would > > > need removing. That's only useful if an arch can be expected to > > > live > > > with GRANT_TABLE=n even when otherwise feature-complete, and at > > > that > > > point modifying the Kconfig dependencies would (imo) be > > > appropriate. > > I agree. Let's proceed by adding the dependency in the KConfig > > file. > > > > So which one option will be better: > > 1. depends on !PPC && !RISCV > > 2. depends on ARM || X86 > > Agreeing and then making this suggestion contradicts one another. > Unless > the long-term plan is for PPC and RISC-V to not use grant tables. On RISC-V side, I can run guests in dom0less and still don't use grant_tables. And I am not sure when I'll start to implement it. Only one thing I defined in grant_table.h is: #define gnttab_dom0_frames() \ min_t(unsigned int, opt_max_grant_frames, PFN_DOWN(_etext - _stext)) But I think it can moved somewhere or dropped as it was defined because of: void __init create_dom0(void) { struct domain *dom0; struct xen_domctl_createdomain dom0_cfg = { .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap, .max_evtchn_port = -1, .max_grant_frames = gnttab_dom0_frames(), .max_maptrack_frames = -1, .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), }; ... Which was copied from Arm. Taking into account that opt_max_grant_frames is 0 in case when CONFIG_GRANT_TABLE=n then ".max_grant_frames =" will be 0 in case of !CONFIG_GRANT_TABLE so for time being the macros gnttab_dom0_frames can be dropped until CONFIG_GRANT_TABLE will be introduced. But I am not aware of PPC plans of usage this config. ~ Oleksii
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index a26cbff68e..646862b10e 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -34,6 +34,7 @@ #include <xen/irq.h> #include <xen/grant_table.h> +#include <asm/grant_table.h> #include <xen/serial.h> #define STATIC_EVTCHN_NODE_SIZE_CELLS 2 diff --git a/xen/arch/ppc/include/asm/grant_table.h b/xen/arch/ppc/include/asm/grant_table.h deleted file mode 100644 index d0ff58dd3d..0000000000 --- a/xen/arch/ppc/include/asm/grant_table.h +++ /dev/null @@ -1,5 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -#ifndef __ASM_PPC_GRANT_TABLE_H__ -#define __ASM_PPC_GRANT_TABLE_H__ - -#endif /* __ASM_PPC_GRANT_TABLE_H__ */ diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h index 85fe6b7b5e..50edfecfb6 100644 --- a/xen/include/xen/grant_table.h +++ b/xen/include/xen/grant_table.h @@ -26,7 +26,10 @@ #include <xen/mm-frame.h> #include <xen/rwlock.h> #include <public/grant_table.h> + +#ifdef CONFIG_GRANT_TABLE #include <asm/grant_table.h> +#endif struct grant_table;
Ifdef-ing inclusion of <asm/grant_table.h> allows to avoid generation of empty <asm/grant_table.h> for cases when CONFIG_GRANT_TABLE is not enabled. The following changes were done for Arm: <asm/grant_table.h> should be included directly because it contains gnttab_dom0_frames() macros which is unique for Arm and is used in arch/arm/domain_build.c. <asm/grant_table.h> is #ifdef-ed with CONFIG_GRANT_TABLE in <xen/grant_table.h> so in case of !CONFIG_GRANT_TABLE gnttab_dom0_frames won't be available for use in arch/arm/domain_build.c. Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> --- Changes in V4: - Nothing changed. Only rebase. --- Changes in V3: - Remove unnecessary comment. --- xen/arch/arm/domain_build.c | 1 + xen/arch/ppc/include/asm/grant_table.h | 5 ----- xen/include/xen/grant_table.h | 3 +++ 3 files changed, 4 insertions(+), 5 deletions(-) delete mode 100644 xen/arch/ppc/include/asm/grant_table.h