[Public] > -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: Wednesday, April 30, 2025 11:17 PM > To: Penny, Zheng <penny.zh...@amd.com> > Cc: Huang, Ray <ray.hu...@amd.com>; Andrew Cooper > <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; > Anthony PERARD <anthony.per...@vates.tech>; Orzel, Michal > <michal.or...@amd.com>; Julien Grall <jul...@xen.org>; Stefano Stabellini > <sstabell...@kernel.org>; xen-devel@lists.xenproject.org > Subject: Re: [PATCH v3 01/20] xen/x86: remove "depends > on !PV_SHIM_EXCLUSIVE" > > On 21.04.2025 09:37, Penny Zheng wrote: > > Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally > > equivalent "if !...") in Kconfig file, since negative dependancy will > > badly affect allyesconfig. > > This commit is based on "x86: provide an inverted Kconfig control for > > shim-exclusive mode"[1] > > Recall me asking to avoid wording like "This commit" in commit messages? > Also personally I consider "is based on" ambiguous: It could also mean the > one here > needs to go on top of that other one. It's not entirely clear to me what kind > of > (relevant) information you're trying to convey with this sentence. Surely you > didn't > really need to even look at that patch of mine to find all the > !PV_SHIM_EXCLUSIVE; > that's a matter of a simply grep. > > > --- > > xen/arch/x86/Kconfig | 4 ---- > > xen/arch/x86/hvm/Kconfig | 1 - > > xen/drivers/video/Kconfig | 4 ++-- > > 3 files changed, 2 insertions(+), 7 deletions(-) > > With the changes here, what does this mean for the in-tree shim build, or any > others > using xen/arch/x86/configs/pvshim_defconfig as the basis? You aren't altering > that > file, so I expect the binary produced will change significantly (when it > shouldn't, > unless explicitly stated otherwise in the description, which may be warranted > for > SHADOW_PAGING). >
Yes, I've missed the changes in defconfig I'll explicitly state above options in xen/arch/x86/configs/pvshim_defconfig For SHADOW_PAGING and TBOOT, maybe we shall add back default y, otherwise x86_64_defconfig will change... > Jan
