From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [RFC v1 0/8] xen: kconfig changes Date: Tue, 17 Feb 2015 08:39:44 +0100 Message-ID: <54E2F040.5020807@suse.com> References: <1423720996-3332-1-git-send-email-mcgrof@do-not-panic.com> <54DC8974.5060908@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YNcl1-0004Q3-3Q for xen-devel@lists.xenproject.org; Tue, 17 Feb 2015 07:39:47 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" , David Vrabel , Konrad Rzeszutek Wilk Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 02/17/2015 01:20 AM, Luis R. Rodriguez wrote: > On Thu, Feb 12, 2015 at 3:07 AM, David Vrabel wrote: >> On 12/02/15 06:03, Luis R. Rodriguez wrote: >>> From: "Luis R. Rodriguez" >>> >>> Here's the first shot at the Kconfig changes for Xen as discussed >>> on the mailing list a little while ago [0]. Let me know if you spot >>> any issues or if you'd like things split differently. I tried to >>> make things as atomic as possible, but not being too rediculous >>> on the atomicity of the changes, for instance the HVC changes >>> were reasonable to just fold into the other change it touched. >>> >>> Haven't gone to war with testing the Kconfig changes yet given this >>> is just the first RFC. If things look good please look for major >>> issues and let me know.# >> >> Can you spin a v2 and make a git branch available, please? I would like >> people to be able to easily try out the changes rather than looking at >> the diffs. >> >> If I haven't comment on a specific patch it's because I thought it >> looked ok. > > Sure thing, before that I should address now what I have found as > issues with the Kconfig changes and what we need. What I see so far: > > 1) due to a recursive dependency it seems we should consider having > XEN_DOM0 select SWIOTLB_XEN instead of depend on it? That fixes it: > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > index d930574..c25e12b 100644 > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -14,7 +14,8 @@ config XEN > config XEN_DOM0 > def_bool y > select XEN_BACKEND > - depends on XEN && PCI_XEN && SWIOTLB_XEN > + select SWIOTLB_XEN > + depends on XEN && PCI_XEN > depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI > depends on XEN_PV || XEN_PVH I'm fine with this. > 2) due to a recursive-dependency it doesn't seem we should have > XEN_FRONTEND select on CONFIG_XEN -- with that in place we end up > with: > > arch/x86/xen/Kconfig:5:error: recursive dependency detected! > arch/x86/xen/Kconfig:5: symbol XEN is selected by XEN_FRONTEND > drivers/xen/Kconfig:82: symbol XEN_FRONTEND depends on XEN > > If we remove the select XEN from XEN_FRONTEND that fixes it. Not sure > what is ideal here though. > > XEN_FRONTEND does not depend on XEN but the select seems to imply it. > > 3) The simple memory setup build issue: > > As it is per our agreed upon changes we can in theory enable a > XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed > desirable this poses an issue at build time at > arch/x86/xen/enlighten.c on xen_start_kernel() here: > > if (xen_feature(XENFEAT_auto_translated_physmap)) > x86_init.resources.memory_setup = xen_auto_xlated_memory_setup; > else > x86_init.resources.memory_setup = xen_memory_setup; If we have neither XEN_PV nor XEN_PVH set, why do we have to build enlighten.c? It will never be used. Same should apply to several other files in arch/x86/xen. Juergen