From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Xen's Linux kernel config options V2 Date: Sun, 8 Feb 2015 11:28:42 +0000 Message-ID: References: <54905BF1.2050608@suse.com> <54D1FA55.9000503@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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" Cc: Juergen Gross , "xen-devel@lists.xensource.com" , "Ian.Campbell@citrix.com" , Stefano Stabellini , David Vrabel , Jan Beulich , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On Fri, 6 Feb 2015, Luis R. Rodriguez wrote: > On Fri, Feb 6, 2015 at 4:07 AM, Stefano Stabellini > wrote: > > On Thu, 5 Feb 2015, Luis R. Rodriguez wrote: > >> On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini > >> wrote: > >> > On Wed, 4 Feb 2015, David Vrabel wrote: > >> >> On 16/12/14 16:21, Juergen Gross wrote: > >> >> > Hi, > >> >> > > >> >> > This is a design proposal for a rework of the config options on the > >> >> > Linux kernel which are related to Xen. > >> >> > > >> >> > The need to do so arose from the fact that it is currently not > >> >> > possible to build the Xen frontend drivers for a non-pvops kernel, > >> >> > e.g. to run them in a HVM-domain. There are more drawbacks in the > >> >> > current config options to which I'll come later. > >> >> > > >> >> > Option Selects Depends > >> >> > ---------------------------------------------------------------------- > >> >> > XEN > >> >> > XEN_PV(x86) XEN_HAVE_PVMMU > >> >> > PARAVIRT > >> >> > PARAVIRT_CLOCK > >> >> > XEN_PVH(x86) XEN_PVHVM > >> >> > PARAVIRT > >> >> > PARAVIRT_CLOCK > >> >> > XEN_PVHVM PARAVIRT > >> >> > PARAVIRT_CLOCK > >> > > >> > PARAVIRT_CLOCK and PARAVIRT are x86 specific. > >> > Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on > >> > arm and arm64 as there is just one type of guest, I would rather just > >> > have CONFIG_XEN there. > >> > >> Interesting, right now we have as part of the recommended change for > >> XEN_BACKEND: > >> > >> Option Selects Depends > >> ---------------------------------------------------------------------- > >> XEN > >> XEN_BACKEND SWIOTLB_XEN(arm,arm64) XEN_PV(x86) || > >> XEN_PVH(x86) || > >> XEN_PVHVM > >> > >> How would we ensure to enable XEN_BACKEND for arm then? > > > > I thought that you wanted to turn XEN_BACKEND into a user selectable > > option. On arm and arm64 this option wouldn't depend on anything > > (except CONFIG_XEN). > > OK sure, that maps to this dependency list then: > > ARM || ARM64 || ( X86 && (XEN_PV || XEN_PVH || XEN_PVHVM ) And CONFIG_XEN, right? > >> >> > XEN_BACKEND SWIOTLB_XEN(arm,arm64) XEN_PV(x86) || > >> >> > XEN_PVH(x86) || > >> >> > XEN_PVHVM > >> >> > XEN_BLKDEV_BACKEND > >> >> > XEN_PCIDEV_BACKEND(x86) > >> >> > XEN_SCSI_BACKEND > >> >> > XEN_NETDEV_BACKEND > >> >> > PCI_XEN(x86) SWIOTLB_XEN > >> >> > XEN_DOM0 XEN_BACKEND XEN_PV(x86) || > >> >> > PCI_XEN(x86) XEN_PVH(x86) > >> >> > XEN_ACPI_HOTPLUG_MEMORY XEN_STUB > >> >> > XEN_ACPI_HOTPLUG_CPU XEN_STUB > >> >> > XEN_MCE_LOG(x86) > >> >> > XEN_MAX_DOMAIN_MEMORY(x86) > >> >> > XEN_SAVE_RESTORE(x86) > >> >> > XEN_DEBUG_FS > >> >> > XEN_WDT > >> >> > XEN_BALLOON > >> >> > XEN_SELFBALLOONING XEN_TMEM > >> >> > XEN_BALLOON_MEMORY_HOTPLUG > >> >> > XEN_SCRUB_PAGES > >> >> > XENFS XEN_PRIVCMD > >> >> > XEN_COMPAT_XENFS > >> >> > XEN_SYS_HYPERVISOR > >> >> > XEN_DEV_EVTCHN > >> >> > XEN_GNTDEV > >> >> > XEN_GRANT_DEV_ALLOC > >> >> > SWIOTLB_XEN > >> >> > XEN_TMEM > >> > > >> > not available on arm and arm64 > >> > >> Can you clarify if you meant only XEN_TMEM or all the above here? > > > > Only TMEM, sorry for being terse > > That was listed as one of the example Kconfig entries which are > currently not available on other architectures despite not being > architecture specific, the other one being XEN_DEBUG_FS. So to be > clear -- do we not want XEN_TMEM for arm in the future ? Sure, but it is on nobody's roadmap at the moment.