* [RFC v1 0/8] xen: kconfig changes
@ 2015-02-12 6:03 Luis R. Rodriguez
2015-02-12 6:03 ` [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 Luis R. Rodriguez
` (8 more replies)
0 siblings, 9 replies; 47+ messages in thread
From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw)
To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky
From: "Luis R. Rodriguez" <mcgrof@suse.com>
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.
[0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579
Luis R. Rodriguez (8):
xen: make dom0 specific changes depend on XEN_DOM0
xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU
xen: drivers: add XEN_FRONTEND and fold front end drivers under them
xen: x86: make XEN_PVH select XEN_PVHVM
xen: x86: add XEN_PV
xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK
xen: unwrap XEN_BACKEND from XEN_DOM0
xen: x86: remove CONFIG_XEN dependency PARAVIRT and PARAVIRT_CLOCK
arch/x86/xen/Kconfig | 26 +++++++++++++++++++-------
drivers/block/Kconfig | 3 +--
drivers/input/misc/Kconfig | 3 +--
drivers/net/Kconfig | 3 +--
drivers/pci/Kconfig | 3 +--
drivers/scsi/Kconfig | 3 +--
drivers/tty/hvc/Kconfig | 4 ++--
drivers/video/fbdev/Kconfig | 3 +--
drivers/watchdog/Kconfig | 2 +-
drivers/xen/Kconfig | 18 +++++++++++++++---
10 files changed, 43 insertions(+), 25 deletions(-)
--
2.2.2
^ permalink raw reply [flat|nested] 47+ messages in thread* [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-12 9:55 ` David Vrabel 2015-02-12 6:03 ` [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU Luis R. Rodriguez ` (7 subsequent siblings) 8 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> These are Kconfig options which are known to only make sense with Xen dom0 support. This is as per the agreed upon changes to Xen's kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 4 ++-- drivers/watchdog/Kconfig | 2 +- drivers/xen/Kconfig | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 6f615a3..490e43e 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -35,13 +35,13 @@ config XEN_MAX_DOMAIN_MEMORY config XEN_SAVE_RESTORE bool - depends on XEN + depends on XEN_DOM0 select HIBERNATE_CALLBACKS default y config XEN_DEBUG_FS bool "Enable Xen debug and tuning parameters in debugfs" - depends on XEN && DEBUG_FS + depends on XEN_DOM0 && DEBUG_FS default n help Enable statistics output and various tuning options in debugfs. diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 08f41ad..34af197 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1409,7 +1409,7 @@ config WATCHDOG_RIO config XEN_WDT tristate "Xen Watchdog support" - depends on XEN + depends on XEN_DOM0 help Say Y here to support the hypervisor watchdog capability provided by Xen 4.0 and newer. The watchdog timeout period is normally one diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index b812462..9350de02 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -222,7 +222,7 @@ config XEN_ACPI_HOTPLUG_CPU config XEN_ACPI_PROCESSOR tristate "Xen ACPI processor" - depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ + depends on XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ default m help This ACPI processor uploads Power Management information to the Xen -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 2015-02-12 6:03 ` [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 Luis R. Rodriguez @ 2015-02-12 9:55 ` David Vrabel 2015-02-12 20:44 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-12 9:55 UTC (permalink / raw) To: Luis R. Rodriguez, xen-devel Cc: jgross, mcgrof, david.vrabel, boris.ostrovsky On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > These are Kconfig options which are known to only make > sense with Xen dom0 support. This is as per the agreed > upon changes to Xen's kconfig changes [0]. [...] > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -35,13 +35,13 @@ config XEN_MAX_DOMAIN_MEMORY > > config XEN_SAVE_RESTORE > bool > - depends on XEN > + depends on XEN_DOM0 > select HIBERNATE_CALLBACKS > default y This breaks save/restore of domUs. > config XEN_DEBUG_FS > bool "Enable Xen debug and tuning parameters in debugfs" > - depends on XEN && DEBUG_FS > + depends on XEN_DOM0 && DEBUG_FS > default n > help > Enable statistics output and various tuning options in debugfs. This is useful for domUs. > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 08f41ad..34af197 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -1409,7 +1409,7 @@ config WATCHDOG_RIO > > config XEN_WDT > tristate "Xen Watchdog support" > - depends on XEN > + depends on XEN_DOM0 > help > Say Y here to support the hypervisor watchdog capability provided > by Xen 4.0 and newer. The watchdog timeout period is normally one Again, useful for domUs. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 2015-02-12 9:55 ` David Vrabel @ 2015-02-12 20:44 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 20:44 UTC (permalink / raw) To: David Vrabel; +Cc: jgross, xen-devel, boris.ostrovsky, Luis R. Rodriguez On Thu, Feb 12, 2015 at 09:55:18AM +0000, David Vrabel wrote: > On 12/02/15 06:03, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > These are Kconfig options which are known to only make > > sense with Xen dom0 support. This is as per the agreed > > upon changes to Xen's kconfig changes [0]. > [...] > > --- a/arch/x86/xen/Kconfig > > +++ b/arch/x86/xen/Kconfig > > @@ -35,13 +35,13 @@ config XEN_MAX_DOMAIN_MEMORY > > > > config XEN_SAVE_RESTORE > > bool > > - depends on XEN > > + depends on XEN_DOM0 > > select HIBERNATE_CALLBACKS > > default y > > This breaks save/restore of domUs. > > > config XEN_DEBUG_FS > > bool "Enable Xen debug and tuning parameters in debugfs" > > - depends on XEN && DEBUG_FS > > + depends on XEN_DOM0 && DEBUG_FS > > default n > > help > > Enable statistics output and various tuning options in debugfs. > > This is useful for domUs. > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > > index 08f41ad..34af197 100644 > > --- a/drivers/watchdog/Kconfig > > +++ b/drivers/watchdog/Kconfig > > @@ -1409,7 +1409,7 @@ config WATCHDOG_RIO > > > > config XEN_WDT > > tristate "Xen Watchdog support" > > - depends on XEN > > + depends on XEN_DOM0 > > help > > Say Y here to support the hypervisor watchdog capability provided > > by Xen 4.0 and newer. The watchdog timeout period is normally one > > Again, useful for domUs. OK that leaves only XEN_ACPI_PROCESSOR for the patch. Fixed. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-12 9:56 ` David Vrabel 2015-02-12 6:03 ` [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them Luis R. Rodriguez ` (6 subsequent siblings) 8 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> Although XEN currently selects XEN_HAVE_PVMMU that will not be the case in the near future so select this requirement explicitly as per the agreed upon Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 490e43e..4d3db19 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -28,7 +28,7 @@ config XEN_MAX_DOMAIN_MEMORY int default 500 if X86_64 default 64 if X86_32 - depends on XEN + depends on XEN && XEN_HAVE_PVMMU help This only affects the sizing of some bss arrays, the unused portions of which are freed. -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU 2015-02-12 6:03 ` [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU Luis R. Rodriguez @ 2015-02-12 9:56 ` David Vrabel 2015-02-12 20:45 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-12 9:56 UTC (permalink / raw) To: Luis R. Rodriguez, xen-devel Cc: jgross, mcgrof, david.vrabel, boris.ostrovsky On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > Although XEN currently selects XEN_HAVE_PVMMU that will not > be the case in the near future so select this requirement > explicitly as per the agreed upon Kconfig changes [0]. [...] > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -28,7 +28,7 @@ config XEN_MAX_DOMAIN_MEMORY > int > default 500 if X86_64 > default 64 if X86_32 > - depends on XEN > + depends on XEN && XEN_HAVE_PVMMU This can be just depends on XEN_HAVE_PVMMU David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU 2015-02-12 9:56 ` David Vrabel @ 2015-02-12 20:45 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 20:45 UTC (permalink / raw) To: David Vrabel; +Cc: jgross, xen-devel, boris.ostrovsky, Luis R. Rodriguez On Thu, Feb 12, 2015 at 09:56:30AM +0000, David Vrabel wrote: > On 12/02/15 06:03, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > Although XEN currently selects XEN_HAVE_PVMMU that will not > > be the case in the near future so select this requirement > > explicitly as per the agreed upon Kconfig changes [0]. > [...] > > --- a/arch/x86/xen/Kconfig > > +++ b/arch/x86/xen/Kconfig > > @@ -28,7 +28,7 @@ config XEN_MAX_DOMAIN_MEMORY > > int > > default 500 if X86_64 > > default 64 if X86_32 > > - depends on XEN > > + depends on XEN && XEN_HAVE_PVMMU > > This can be just > > depends on XEN_HAVE_PVMMU Fixed. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-12 11:01 ` David Vrabel 2015-02-12 6:03 ` [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM Luis R. Rodriguez ` (5 subsequent siblings) 8 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> Fold Xen front end drivers under their own Kconfig entry. You may want to for example only enable domU guests with pv-drivers. While at it make HVC_XEN_FRONTEND select HVC_XEN. This is a per the agreed upon Kconfig changes for Xen [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- drivers/block/Kconfig | 3 +-- drivers/input/misc/Kconfig | 3 +-- drivers/net/Kconfig | 3 +-- drivers/pci/Kconfig | 3 +-- drivers/scsi/Kconfig | 3 +-- drivers/tty/hvc/Kconfig | 4 ++-- drivers/video/fbdev/Kconfig | 3 +-- drivers/xen/Kconfig | 10 ++++++++++ 8 files changed, 18 insertions(+), 14 deletions(-) diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 014a1cf..8259879 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -482,9 +482,8 @@ config XILINX_SYSACE config XEN_BLKDEV_FRONTEND tristate "Xen virtual block device support" - depends on XEN + depends on XEN_FRONTEND default y - select XEN_XENBUS_FRONTEND help This driver implements the front-end of the Xen virtual block device driver. It communicates with a back-end driver diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 23297ab..71a736b 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -656,9 +656,8 @@ config INPUT_CMA3000_I2C config INPUT_XEN_KBDDEV_FRONTEND tristate "Xen virtual keyboard and mouse support" - depends on XEN + depends on XEN_FRONTEND default y - select XEN_XENBUS_FRONTEND help This driver implements the front-end of the Xen virtual keyboard and mouse device driver. It communicates with a back-end diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index d6607ee..0ae5cbc 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -333,8 +333,7 @@ source "drivers/net/ieee802154/Kconfig" config XEN_NETDEV_FRONTEND tristate "Xen network device frontend driver" - depends on XEN - select XEN_XENBUS_FRONTEND + depends on XEN_FRONTEND default y help This driver provides support for Xen paravirtual network diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 7a8f1c5..0120499 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -56,9 +56,8 @@ config PCI_STUB config XEN_PCIDEV_FRONTEND tristate "Xen PCI Frontend" - depends on PCI && X86 && XEN + depends on PCI && X86 && XEN_FRONTEND select PCI_XEN - select XEN_XENBUS_FRONTEND default y help The PCI device frontend driver allows the kernel to import arbitrary diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 9c92f41..e369f0b 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -588,8 +588,7 @@ config VMWARE_PVSCSI config XEN_SCSI_FRONTEND tristate "XEN SCSI frontend driver" - depends on SCSI && XEN - select XEN_XENBUS_FRONTEND + depends on SCSI && XEN_FRONTEND help The XEN SCSI frontend driver allows the kernel to access SCSI Devices within another guest OS (usually Dom0). diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig index 8902f9b..b9dec5f 100644 --- a/drivers/tty/hvc/Kconfig +++ b/drivers/tty/hvc/Kconfig @@ -70,8 +70,8 @@ config HVC_XEN config HVC_XEN_FRONTEND bool "Xen Hypervisor Multiple Consoles support" - depends on HVC_XEN - select XEN_XENBUS_FRONTEND + depends on XEN_FRONTEND + select HVC_XEN default y help Xen driver for secondary virtual consoles diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 4916c97..e0149d1 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2243,14 +2243,13 @@ config FB_VIRTUAL config XEN_FBDEV_FRONTEND tristate "Xen virtual frame buffer support" - depends on FB && XEN + depends on FB && XEN_FRONTEND select FB_SYS_FILLRECT select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT select FB_SYS_FOPS select FB_DEFERRED_IO select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC - select XEN_XENBUS_FRONTEND default y help This driver implements the front-end of the Xen virtual diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 9350de02..2af6f69 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -83,6 +83,16 @@ config XEN_BACKEND Support for backend device drivers that provide I/O services to other virtual machines. +config XEN_FRONTEND + bool "Frontend driver support" + select XEN + select XEN_XENBUS_FRONTEND + default y + help + Support for frontend device drivers for Xen. You want to enable + this if you want to run Xen guests. You can for instance enable + domU guests with pv-drivers. + config XENFS tristate "Xen filesystem" select XEN_PRIVCMD -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them 2015-02-12 6:03 ` [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them Luis R. Rodriguez @ 2015-02-12 11:01 ` David Vrabel 2015-02-12 20:48 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-12 11:01 UTC (permalink / raw) To: Luis R. Rodriguez, xen-devel Cc: jgross, mcgrof, david.vrabel, boris.ostrovsky On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > Fold Xen front end drivers under their own Kconfig entry. > You may want to for example only enable domU guests with > pv-drivers. > > While at it make HVC_XEN_FRONTEND select HVC_XEN. [...] > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -83,6 +83,16 @@ config XEN_BACKEND > Support for backend device drivers that provide I/O services > to other virtual machines. > > +config XEN_FRONTEND > + bool "Frontend driver support" > + select XEN > + select XEN_XENBUS_FRONTEND > + default y > + help > + Support for frontend device drivers for Xen. You want to enable > + this if you want to run Xen guests. You can for instance enable > + domU guests with pv-drivers. XEN_FRONTEND should appear before XEN_BACKEND. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them 2015-02-12 11:01 ` David Vrabel @ 2015-02-12 20:48 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 20:48 UTC (permalink / raw) To: David Vrabel; +Cc: jgross, xen-devel, boris.ostrovsky, Luis R. Rodriguez On Thu, Feb 12, 2015 at 11:01:52AM +0000, David Vrabel wrote: > On 12/02/15 06:03, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > Fold Xen front end drivers under their own Kconfig entry. > > You may want to for example only enable domU guests with > > pv-drivers. > > > > While at it make HVC_XEN_FRONTEND select HVC_XEN. > [...] > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -83,6 +83,16 @@ config XEN_BACKEND > > Support for backend device drivers that provide I/O services > > to other virtual machines. > > > > +config XEN_FRONTEND > > + bool "Frontend driver support" > > + select XEN > > + select XEN_XENBUS_FRONTEND > > + default y > > + help > > + Support for frontend device drivers for Xen. You want to enable > > + this if you want to run Xen guests. You can for instance enable > > + domU guests with pv-drivers. > > XEN_FRONTEND should appear before XEN_BACKEND. Fixed. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez ` (2 preceding siblings ...) 2015-02-12 6:03 ` [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-25 15:44 ` Stefano Stabellini 2015-02-12 6:03 ` [RFC v1 5/8] xen: x86: add XEN_PV Luis R. Rodriguez ` (4 subsequent siblings) 8 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> This lets us expose XEN_PVH and set what is required for it. This only exists on the x86 universe. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 4d3db19..b675e14 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -49,5 +49,6 @@ config XEN_DEBUG_FS config XEN_PVH bool "Support for running as a PVH guest" - depends on X86_64 && XEN && XEN_PVHVM + depends on X86_64 && XEN + select XEN_PVHVM def_bool n -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM 2015-02-12 6:03 ` [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM Luis R. Rodriguez @ 2015-02-25 15:44 ` Stefano Stabellini 2015-02-26 0:36 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Stefano Stabellini @ 2015-02-25 15:44 UTC (permalink / raw) To: Luis R. Rodriguez Cc: jgross, xen-devel, mcgrof, david.vrabel, boris.ostrovsky On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > This lets us expose XEN_PVH and set what is required for it. > This only exists on the x86 universe. This is as per the agreed > upon Xen Kconfig changes [0]. > > [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > --- > arch/x86/xen/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > index 4d3db19..b675e14 100644 > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -49,5 +49,6 @@ config XEN_DEBUG_FS > > config XEN_PVH > bool "Support for running as a PVH guest" > - depends on X86_64 && XEN && XEN_PVHVM > + depends on X86_64 && XEN > + select XEN_PVHVM > def_bool n As I wrote here alpine.DEB.2.02.1502251417360.23507@kaball.uk.xensource.com I think we should remove XEN_PVHVM as it is not adding much on top of XEN_FRONTEND. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM 2015-02-25 15:44 ` Stefano Stabellini @ 2015-02-26 0:36 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-26 0:36 UTC (permalink / raw) To: Stefano Stabellini Cc: jgross, xen-devel, boris.ostrovsky, david.vrabel, Luis R. Rodriguez On Wed, Feb 25, 2015 at 03:44:53PM +0000, Stefano Stabellini wrote: > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > This lets us expose XEN_PVH and set what is required for it. > > This only exists on the x86 universe. This is as per the agreed > > upon Xen Kconfig changes [0]. > > > > [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > > > > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > > --- > > arch/x86/xen/Kconfig | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > > index 4d3db19..b675e14 100644 > > --- a/arch/x86/xen/Kconfig > > +++ b/arch/x86/xen/Kconfig > > @@ -49,5 +49,6 @@ config XEN_DEBUG_FS > > > > config XEN_PVH > > bool "Support for running as a PVH guest" > > - depends on X86_64 && XEN && XEN_PVHVM > > + depends on X86_64 && XEN > > + select XEN_PVHVM > > def_bool n > > As I wrote here > alpine.DEB.2.02.1502251417360.23507@kaball.uk.xensource.com I think we > should remove XEN_PVHVM as it is not adding much on top of XEN_FRONTEND. Sure, so long as folks grep XEN_PVHVM and see no issues with a wide change for it, it works nicely so far for the goals discussed on my end. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 5/8] xen: x86: add XEN_PV 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez ` (3 preceding siblings ...) 2015-02-12 6:03 ` [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-12 11:03 ` David Vrabel 2015-02-12 6:03 ` [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez ` (3 subsequent siblings) 8 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> This lets us rip out under the general XEN config the XEN_HAVE_PVMMU dependency. This only exists on the x86 universe. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 7 ++++++- drivers/xen/Kconfig | 3 ++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index b675e14..9e0442f 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -7,7 +7,6 @@ config XEN depends on PARAVIRT select PARAVIRT_CLOCK select PARAVIRT_MMU - select XEN_HAVE_PVMMU depends on X86_64 || (X86_32 && X86_PAE) depends on X86_TSC help @@ -52,3 +51,9 @@ config XEN_PVH depends on X86_64 && XEN select XEN_PVHVM def_bool n + +config XEN_PV + bool "Support for running as a PV guest" + depends on XEN && X86 + select XEN_HAVE_PVMMU + def_bool n diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 2af6f69..31391bc 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -257,7 +257,8 @@ config XEN_MCE_LOG converting it into Linux mcelog format for mcelog tools config XEN_HAVE_PVMMU - bool + bool + depends on XEN_PV config XEN_EFI def_bool y -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 5/8] xen: x86: add XEN_PV 2015-02-12 6:03 ` [RFC v1 5/8] xen: x86: add XEN_PV Luis R. Rodriguez @ 2015-02-12 11:03 ` David Vrabel 2015-02-13 2:52 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-12 11:03 UTC (permalink / raw) To: Luis R. Rodriguez, xen-devel Cc: jgross, mcgrof, david.vrabel, boris.ostrovsky On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > This lets us rip out under the general XEN config the > XEN_HAVE_PVMMU dependency. This only exists on the x86 > universe. This is as per the agreed upon Xen Kconfig > changes [0]. [...] > @@ -52,3 +51,9 @@ config XEN_PVH > depends on X86_64 && XEN > select XEN_PVHVM > def_bool n > + > +config XEN_PV > + bool "Support for running as a PV guest" > + depends on XEN && X86 > + select XEN_HAVE_PVMMU > + def_bool n These options should be in this order: XEN_PV, XEN_PVHVM, XEN_PVH. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 5/8] xen: x86: add XEN_PV 2015-02-12 11:03 ` David Vrabel @ 2015-02-13 2:52 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-13 2:52 UTC (permalink / raw) To: David Vrabel; +Cc: jgross, xen-devel, boris.ostrovsky, Luis R. Rodriguez On Thu, Feb 12, 2015 at 11:03:26AM +0000, David Vrabel wrote: > On 12/02/15 06:03, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > This lets us rip out under the general XEN config the > > XEN_HAVE_PVMMU dependency. This only exists on the x86 > > universe. This is as per the agreed upon Xen Kconfig > > changes [0]. > [...] > > @@ -52,3 +51,9 @@ config XEN_PVH > > depends on X86_64 && XEN > > select XEN_PVHVM > > def_bool n > > + > > +config XEN_PV > > + bool "Support for running as a PV guest" > > + depends on XEN && X86 > > + select XEN_HAVE_PVMMU > > + def_bool n > > These options should be in this order: XEN_PV, XEN_PVHVM, XEN_PVH. OK I'll move them in order and also add a descrition to both XEN_PV and XEN_PVH, I cannot describe XEN_PVHVM as its a def_bool and the user does not get to select it or review it. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez ` (4 preceding siblings ...) 2015-02-12 6:03 ` [RFC v1 5/8] xen: x86: add XEN_PV Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-25 15:45 ` Stefano Stabellini 2015-02-12 6:03 ` [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 Luis R. Rodriguez ` (2 subsequent siblings) 8 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 universe. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 9e0442f..50e2fb4 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -21,6 +21,8 @@ config XEN_DOM0 config XEN_PVHVM def_bool y + select PARAVIRT + select PARAVIRT_CLOCK depends on XEN && PCI && X86_LOCAL_APIC config XEN_MAX_DOMAIN_MEMORY @@ -49,11 +51,15 @@ config XEN_DEBUG_FS config XEN_PVH bool "Support for running as a PVH guest" depends on X86_64 && XEN + select PARAVIRT + select PARAVIRT_CLOCK select XEN_PVHVM def_bool n config XEN_PV bool "Support for running as a PV guest" depends on XEN && X86 + select PARAVIRT + select PARAVIRT_CLOCK select XEN_HAVE_PVMMU def_bool n -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK 2015-02-12 6:03 ` [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez @ 2015-02-25 15:45 ` Stefano Stabellini 2015-02-26 0:54 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Stefano Stabellini @ 2015-02-25 15:45 UTC (permalink / raw) To: Luis R. Rodriguez Cc: jgross, xen-devel, mcgrof, david.vrabel, boris.ostrovsky On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK > from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 universe. > This is as per the agreed upon Xen Kconfig changes [0]. > > [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > --- > arch/x86/xen/Kconfig | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > index 9e0442f..50e2fb4 100644 > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -21,6 +21,8 @@ config XEN_DOM0 > > config XEN_PVHVM > def_bool y > + select PARAVIRT > + select PARAVIRT_CLOCK > depends on XEN && PCI && X86_LOCAL_APIC > > config XEN_MAX_DOMAIN_MEMORY > @@ -49,11 +51,15 @@ config XEN_DEBUG_FS > config XEN_PVH > bool "Support for running as a PVH guest" > depends on X86_64 && XEN > + select PARAVIRT > + select PARAVIRT_CLOCK > select XEN_PVHVM > def_bool n > > config XEN_PV > bool "Support for running as a PV guest" > depends on XEN && X86 > + select PARAVIRT > + select PARAVIRT_CLOCK > select XEN_HAVE_PVMMU > def_bool n Given that all select PARAVIRT and PARAVIRT_CLOCK, shouldn't we just move them under config XEN? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK 2015-02-25 15:45 ` Stefano Stabellini @ 2015-02-26 0:54 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-26 0:54 UTC (permalink / raw) To: Stefano Stabellini Cc: jgross, xen-devel, boris.ostrovsky, david.vrabel, Luis R. Rodriguez On Wed, Feb 25, 2015 at 03:45:56PM +0000, Stefano Stabellini wrote: > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK > > from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 universe. > > This is as per the agreed upon Xen Kconfig changes [0]. > > > > [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > > > > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > > --- > > arch/x86/xen/Kconfig | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > > index 9e0442f..50e2fb4 100644 > > --- a/arch/x86/xen/Kconfig > > +++ b/arch/x86/xen/Kconfig > > @@ -21,6 +21,8 @@ config XEN_DOM0 > > > > config XEN_PVHVM > > def_bool y > > + select PARAVIRT > > + select PARAVIRT_CLOCK > > depends on XEN && PCI && X86_LOCAL_APIC > > > > config XEN_MAX_DOMAIN_MEMORY > > @@ -49,11 +51,15 @@ config XEN_DEBUG_FS > > config XEN_PVH > > bool "Support for running as a PVH guest" > > depends on X86_64 && XEN > > + select PARAVIRT > > + select PARAVIRT_CLOCK > > select XEN_PVHVM > > def_bool n > > > > config XEN_PV > > bool "Support for running as a PV guest" > > depends on XEN && X86 > > + select PARAVIRT > > + select PARAVIRT_CLOCK > > select XEN_HAVE_PVMMU > > def_bool n > > Given that all select PARAVIRT and PARAVIRT_CLOCK, shouldn't we just > move them under config XEN? I believe this makes sense given that XEN_FRONTEND will now also select it if we remove XEN_PVHVM and instead fold what it provides under XEN_FRONTEND. I'll send a v4 kconfig changes as things look so far. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez ` (5 preceding siblings ...) 2015-02-12 6:03 ` [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-12 11:05 ` David Vrabel 2015-02-25 14:17 ` Stefano Stabellini 2015-02-12 6:03 ` [RFC v1 8/8] xen: x86: remove CONFIG_XEN dependency PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez 2015-02-12 11:07 ` [RFC v1 0/8] xen: kconfig changes David Vrabel 8 siblings, 2 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> This unwraps XEN_BACKEND from depending on XEN_DOM0, it instead makes it depend on the possible x86 backends and under what scenerios its allowed under ARM. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 2 ++ drivers/xen/Kconfig | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 50e2fb4..9298eb3 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -16,8 +16,10 @@ config XEN config XEN_DOM0 def_bool y + select XEN_BACKEND depends on XEN && PCI_XEN && SWIOTLB_XEN depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI + depends on XEN_PV || XEN_PVH config XEN_PVHVM def_bool y diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 31391bc..d8bd3f6 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN config XEN_BACKEND bool "Backend driver support" - depends on XEN_DOM0 + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) + select SWIOTLB_XEN if ARM || ARM64 default y help Support for backend device drivers that provide I/O services -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-12 6:03 ` [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 Luis R. Rodriguez @ 2015-02-12 11:05 ` David Vrabel 2015-02-12 20:54 ` Luis R. Rodriguez 2015-02-25 14:17 ` Stefano Stabellini 1 sibling, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-12 11:05 UTC (permalink / raw) To: Luis R. Rodriguez, xen-devel Cc: jgross, mcgrof, david.vrabel, boris.ostrovsky On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > This unwraps XEN_BACKEND from depending on XEN_DOM0, it > instead makes it depend on the possible x86 backends and > under what scenerios its allowed under ARM. This is as per > the agreed upon Xen Kconfig changes [0]. [...] > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN > > config XEN_BACKEND > bool "Backend driver support" > - depends on XEN_DOM0 > + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) You don't need X86 here. Just XEN_PV etc. is fine. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-12 11:05 ` David Vrabel @ 2015-02-12 20:54 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 20:54 UTC (permalink / raw) To: David Vrabel; +Cc: jgross, xen-devel, boris.ostrovsky, Luis R. Rodriguez On Thu, Feb 12, 2015 at 11:05:14AM +0000, David Vrabel wrote: > On 12/02/15 06:03, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > > > This unwraps XEN_BACKEND from depending on XEN_DOM0, it > > instead makes it depend on the possible x86 backends and > > under what scenerios its allowed under ARM. This is as per > > the agreed upon Xen Kconfig changes [0]. > [...] > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN > > > > config XEN_BACKEND > > bool "Backend driver support" > > - depends on XEN_DOM0 > > + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) > > You don't need X86 here. Just XEN_PV etc. is fine. Fixed. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-12 6:03 ` [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 Luis R. Rodriguez 2015-02-12 11:05 ` David Vrabel @ 2015-02-25 14:17 ` Stefano Stabellini 2015-02-25 14:30 ` David Vrabel 1 sibling, 1 reply; 47+ messages in thread From: Stefano Stabellini @ 2015-02-25 14:17 UTC (permalink / raw) To: Luis R. Rodriguez Cc: jgross, xen-devel, mcgrof, david.vrabel, boris.ostrovsky On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > This unwraps XEN_BACKEND from depending on XEN_DOM0, it > instead makes it depend on the possible x86 backends and > under what scenerios its allowed under ARM. This is as per > the agreed upon Xen Kconfig changes [0]. > > [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > --- > arch/x86/xen/Kconfig | 2 ++ > drivers/xen/Kconfig | 3 ++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > index 50e2fb4..9298eb3 100644 > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -16,8 +16,10 @@ config XEN > > config XEN_DOM0 > def_bool y > + select XEN_BACKEND > depends on XEN && PCI_XEN && SWIOTLB_XEN > depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI > + depends on XEN_PV || XEN_PVH > > config XEN_PVHVM > def_bool y > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index 31391bc..d8bd3f6 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN > > config XEN_BACKEND > bool "Backend driver support" > - depends on XEN_DOM0 > + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) > + select SWIOTLB_XEN if ARM || ARM64 > default y > help > Support for backend device drivers that provide I/O services If you do this people could enable XEN_BACKEND without XEN on ARM. I think it needs to be: depends on (XEN && (ARM || ARM64)) || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-25 14:17 ` Stefano Stabellini @ 2015-02-25 14:30 ` David Vrabel 2015-02-25 14:33 ` Stefano Stabellini 0 siblings, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-25 14:30 UTC (permalink / raw) To: Stefano Stabellini, Luis R. Rodriguez Cc: jgross, xen-devel, mcgrof, david.vrabel, boris.ostrovsky On 25/02/15 14:17, Stefano Stabellini wrote: > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" <mcgrof@suse.com> >> >> This unwraps XEN_BACKEND from depending on XEN_DOM0, it >> instead makes it depend on the possible x86 backends and >> under what scenerios its allowed under ARM. This is as per >> the agreed upon Xen Kconfig changes [0]. >> >> [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 >> >> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> >> --- >> arch/x86/xen/Kconfig | 2 ++ >> drivers/xen/Kconfig | 3 ++- >> 2 files changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig >> index 50e2fb4..9298eb3 100644 >> --- a/arch/x86/xen/Kconfig >> +++ b/arch/x86/xen/Kconfig >> @@ -16,8 +16,10 @@ config XEN >> >> config XEN_DOM0 >> def_bool y >> + select XEN_BACKEND >> depends on XEN && PCI_XEN && SWIOTLB_XEN >> depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI >> + depends on XEN_PV || XEN_PVH >> >> config XEN_PVHVM >> def_bool y >> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig >> index 31391bc..d8bd3f6 100644 >> --- a/drivers/xen/Kconfig >> +++ b/drivers/xen/Kconfig >> @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN >> >> config XEN_BACKEND >> bool "Backend driver support" >> - depends on XEN_DOM0 >> + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) >> + select SWIOTLB_XEN if ARM || ARM64 >> default y >> help >> Support for backend device drivers that provide I/O services > > If you do this people could enable XEN_BACKEND without XEN on ARM. > I think it needs to be: > > depends on (XEN && (ARM || ARM64)) || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) It's this more sufficiently: depends on XEN ? David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-25 14:30 ` David Vrabel @ 2015-02-25 14:33 ` Stefano Stabellini 2015-02-26 1:08 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Stefano Stabellini @ 2015-02-25 14:33 UTC (permalink / raw) To: David Vrabel Cc: jgross, Luis R. Rodriguez, mcgrof, Stefano Stabellini, xen-devel, boris.ostrovsky On Wed, 25 Feb 2015, David Vrabel wrote: > On 25/02/15 14:17, Stefano Stabellini wrote: > > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > >> From: "Luis R. Rodriguez" <mcgrof@suse.com> > >> > >> This unwraps XEN_BACKEND from depending on XEN_DOM0, it > >> instead makes it depend on the possible x86 backends and > >> under what scenerios its allowed under ARM. This is as per > >> the agreed upon Xen Kconfig changes [0]. > >> > >> [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > >> > >> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > >> --- > >> arch/x86/xen/Kconfig | 2 ++ > >> drivers/xen/Kconfig | 3 ++- > >> 2 files changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > >> index 50e2fb4..9298eb3 100644 > >> --- a/arch/x86/xen/Kconfig > >> +++ b/arch/x86/xen/Kconfig > >> @@ -16,8 +16,10 @@ config XEN > >> > >> config XEN_DOM0 > >> def_bool y > >> + select XEN_BACKEND > >> depends on XEN && PCI_XEN && SWIOTLB_XEN > >> depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI > >> + depends on XEN_PV || XEN_PVH > >> > >> config XEN_PVHVM > >> def_bool y > >> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > >> index 31391bc..d8bd3f6 100644 > >> --- a/drivers/xen/Kconfig > >> +++ b/drivers/xen/Kconfig > >> @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN > >> > >> config XEN_BACKEND > >> bool "Backend driver support" > >> - depends on XEN_DOM0 > >> + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) > >> + select SWIOTLB_XEN if ARM || ARM64 > >> default y > >> help > >> Support for backend device drivers that provide I/O services > > > > If you do this people could enable XEN_BACKEND without XEN on ARM. > > I think it needs to be: > > > > depends on (XEN && (ARM || ARM64)) || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) > > It's this more sufficiently: > > depends on XEN ? Yeah :-) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 2015-02-25 14:33 ` Stefano Stabellini @ 2015-02-26 1:08 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-26 1:08 UTC (permalink / raw) To: Stefano Stabellini Cc: jgross, xen-devel, boris.ostrovsky, David Vrabel, Luis R. Rodriguez On Wed, Feb 25, 2015 at 02:33:40PM +0000, Stefano Stabellini wrote: > On Wed, 25 Feb 2015, David Vrabel wrote: > > On 25/02/15 14:17, Stefano Stabellini wrote: > > > On Wed, 11 Feb 2015, Luis R. Rodriguez wrote: > > >> From: "Luis R. Rodriguez" <mcgrof@suse.com> > > >> > > >> This unwraps XEN_BACKEND from depending on XEN_DOM0, it > > >> instead makes it depend on the possible x86 backends and > > >> under what scenerios its allowed under ARM. This is as per > > >> the agreed upon Xen Kconfig changes [0]. > > >> > > >> [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 > > >> > > >> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > > >> --- > > >> arch/x86/xen/Kconfig | 2 ++ > > >> drivers/xen/Kconfig | 3 ++- > > >> 2 files changed, 4 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > > >> index 50e2fb4..9298eb3 100644 > > >> --- a/arch/x86/xen/Kconfig > > >> +++ b/arch/x86/xen/Kconfig > > >> @@ -16,8 +16,10 @@ config XEN > > >> > > >> config XEN_DOM0 > > >> def_bool y > > >> + select XEN_BACKEND > > >> depends on XEN && PCI_XEN && SWIOTLB_XEN > > >> depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI > > >> + depends on XEN_PV || XEN_PVH > > >> > > >> config XEN_PVHVM > > >> def_bool y > > >> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > >> index 31391bc..d8bd3f6 100644 > > >> --- a/drivers/xen/Kconfig > > >> +++ b/drivers/xen/Kconfig > > >> @@ -77,7 +77,8 @@ config XEN_DEV_EVTCHN > > >> > > >> config XEN_BACKEND > > >> bool "Backend driver support" > > >> - depends on XEN_DOM0 > > >> + depends on ARM || ARM64 || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) > > >> + select SWIOTLB_XEN if ARM || ARM64 > > >> default y > > >> help > > >> Support for backend device drivers that provide I/O services > > > > > > If you do this people could enable XEN_BACKEND without XEN on ARM. > > > I think it needs to be: > > > > > > depends on (XEN && (ARM || ARM64)) || (X86 && (XEN_PV || XEN_PVH || XEN_PVHVM)) > > > > It's this more sufficiently: > > > > depends on XEN ? > > Yeah :-) We already only expose this option on the top of the Kconfig file with 'if XEN' language, folding XEN_PVHVM under XEN_FRONTEND might not suffice to ensure everything builds fine here given CONFIG_XEN does not implicate XEN_FRONTEND. Because of this I think the above is still required. Let me know though, I'll send a v4 of what things look like (no code changes) right now before moving on again. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* [RFC v1 8/8] xen: x86: remove CONFIG_XEN dependency PARAVIRT and PARAVIRT_CLOCK 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez ` (6 preceding siblings ...) 2015-02-12 6:03 ` [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 Luis R. Rodriguez @ 2015-02-12 6:03 ` Luis R. Rodriguez 2015-02-12 11:07 ` [RFC v1 0/8] xen: kconfig changes David Vrabel 8 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-12 6:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, mcgrof, mcgrof, david.vrabel, boris.ostrovsky From: "Luis R. Rodriguez" <mcgrof@suse.com> Now that the respective PV modes have the specific requirements selectable just remove this from CONFIG_XEN This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> --- arch/x86/xen/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index 9298eb3..19b2d3d 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -4,8 +4,6 @@ config XEN bool "Xen guest support" - depends on PARAVIRT - select PARAVIRT_CLOCK select PARAVIRT_MMU depends on X86_64 || (X86_32 && X86_PAE) depends on X86_TSC -- 2.2.2 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez ` (7 preceding siblings ...) 2015-02-12 6:03 ` [RFC v1 8/8] xen: x86: remove CONFIG_XEN dependency PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez @ 2015-02-12 11:07 ` David Vrabel 2015-02-17 0:20 ` Luis R. Rodriguez 8 siblings, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-12 11:07 UTC (permalink / raw) To: Luis R. Rodriguez, xen-devel Cc: jgross, mcgrof, david.vrabel, boris.ostrovsky On 12/02/15 06:03, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > 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. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-12 11:07 ` [RFC v1 0/8] xen: kconfig changes David Vrabel @ 2015-02-17 0:20 ` Luis R. Rodriguez 2015-02-17 0:25 ` Luis R. Rodriguez 2015-02-17 7:39 ` Juergen Gross 0 siblings, 2 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-17 0:20 UTC (permalink / raw) To: David Vrabel, Juergen Gross, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky On Thu, Feb 12, 2015 at 3:07 AM, David Vrabel <david.vrabel@citrix.com> wrote: > On 12/02/15 06:03, Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" <mcgrof@suse.com> >> >> 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 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; The reason is that XENFEAT_auto_translated_physmap is statically set only if XEN_PVH is enabled. If you do not enable XEN_PVH then we have to call xen_memory_setup() and that routine requires CONFIG_XEN_MAX_DOMAIN_MEMORY defined which we only define when the XEN_PV is enabled now. A simple obvious fix is to enable XENFEAT_auto_translated_physmap when XEN_PVHVM is enabled but there are other features here to consider so its not clear to me which are PVH specific and which are desirable only for XEN_PVH. Now, at least for XENFEAT_auto_translated_physmap since it its a static flag set upon build time depending on whether or not XENPVHVM is enabled it means we can fold all of xen_memory_setup() code into its own file from setup.c. This file can then be built with a new defbool: +config XEN_BUILD_SIMPLE_MEMORY_SETUP + def_bool y if !XEN_PVHVM + And we'd build it: +obj-$(CONFIG_XEN_BUILD_SIMPLE_MEMORY_SETUP) += simple_mem_setup.o That cleans up setup.c pretty nicely and shoves all the simple memory setup stuff into its own file. That raises a few other questions about a few other routines we may want to review to in light of this that are only enabled when PVH is enabled upon init. This diff highlights the things to consider so far: diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 78a881b..736dc65 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1511,24 +1511,29 @@ void __ref xen_pvh_secondary_vcpu_init(int cpu) xen_pvh_set_cr_flags(cpu); } +/* this may need to be split up between XEN_PVHVM and XEN_PVH ? */ static void __init xen_pvh_early_guest_init(void) { if (!xen_feature(XENFEAT_auto_translated_physmap)) return; + /* XXX */ if (!xen_feature(XENFEAT_hvm_callback_vector)) return; + /* which are XEN_PVH and which are XEN_PVHM specific */ xen_have_vector_callback = 1; xen_pvh_early_cpu_init(0, false); xen_pvh_set_cr_flags(0); + /* XXX */ #ifdef CONFIG_X86_32 BUG(); /* PVH: Implement proper support. */ #endif } #endif /* CONFIG_XEN_PVH */ +/* XXX */ /* First C function to be called on Xen boot */ asmlinkage __visible void __init xen_start_kernel(void) @@ -1543,6 +1548,7 @@ asmlinkage __visible void __init xen_start_kernel(void) xen_domain_type = XEN_PV_DOMAIN; xen_setup_features(); + /* this may need to be split up between XEN_PVHVM and XEN_PVH ? */ #ifdef CONFIG_XEN_PVH xen_pvh_early_guest_init(); #endif @@ -1560,8 +1566,10 @@ asmlinkage __visible void __init xen_start_kernel(void) if (xen_feature(XENFEAT_auto_translated_physmap)) x86_init.resources.memory_setup = xen_auto_xlated_memory_setup; +#ifdef CONFIG_XEN_BUILD_SIMPLE_MEMORY_SETUP else x86_init.resources.memory_setup = xen_memory_setup; +#endif x86_init.oem.arch_setup = xen_arch_setup; x86_init.oem.banner = xen_banner; diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index adca9e2..34ee8fd 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1187,9 +1187,11 @@ static void __init xen_pagetable_init(void) /* Allocate and initialize top and mid mfn levels for p2m structure */ xen_build_mfn_list_list(); +#ifdef CONFIG_XEN_BUILD_SIMPLE_MEMORY_SETUP /* Remap memory freed due to conflicts with E820 map */ if (!xen_feature(XENFEAT_auto_translated_physmap)) xen_remap_memory(); +#endif xen_setup_shared_info(); } diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 55f388e..66ad53d 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -32,96 +32,6 @@ #include "p2m.h" #include "mmu.h" -/* Amount of extra memory space we add to the e820 ranges */ -struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; - -/* Number of pages released from the initial allocation. */ -unsigned long xen_released_pages; - -/* - * Buffer used to remap identity mapped pages. We only need the virtual space. - * The physical page behind this address is remapped as needed to different - * buffer pages. - */ -#define REMAP_SIZE (P2M_PER_PAGE - 3) -static struct { - unsigned long next_area_mfn; - unsigned long target_pfn; - unsigned long size; - unsigned long mfns[REMAP_SIZE]; -} xen_remap_buf __initdata __aligned(PAGE_SIZE); -static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY; - -/* - * The maximum amount of extra memory compared to the base size. The - * main scaling factor is the size of struct page. At extreme ratios - * of base:extra, all the base memory can be filled with page - * structures for the extra memory, leaving no space for anything - * else. - * - * 10x seems like a reasonable balance between scaling flexibility and - * leaving a practically usable system. - */ -#define EXTRA_MEM_RATIO (10) - -static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size) -{ - int i; - - for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { - /* Add new region. */ - if (xen_extra_mem[i].size == 0) { - xen_extra_mem[i].start = start; - xen_extra_mem[i].size = size; - break; - } - /* Append to existing region. */ - if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) { - xen_extra_mem[i].size += size; - break; - } - } - if (i == XEN_EXTRA_MEM_MAX_REGIONS) - printk(KERN_WARNING "Warning: not enough extra memory regions\n"); - - memblock_reserve(start, size); -} - -static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size) -{ - int i; - phys_addr_t start_r, size_r; - - for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { - start_r = xen_extra_mem[i].start; - size_r = xen_extra_mem[i].size; - - /* Start of region. */ - if (start_r == start) { - BUG_ON(size > size_r); - xen_extra_mem[i].start += size; - xen_extra_mem[i].size -= size; - break; - } - /* End of region. */ - if (start_r + size_r == start + size) { - BUG_ON(size > size_r); - xen_extra_mem[i].size -= size; - break; - } - /* Mid of region. */ - if (start > start_r && start < start_r + size_r) { - BUG_ON(start + size > start_r + size_r); - xen_extra_mem[i].size = start - start_r; - /* Calling memblock_reserve() again is okay. */ - xen_add_extra_mem(start + size, start_r + size_r - - (start + size)); - break; - } - } - memblock_free(start, size); -} - /* * Called during boot before the p2m list can take entries beyond the * hypervisor supplied p2m list. Entries in extra mem are to be regarded as @@ -160,563 +70,6 @@ void __init xen_inv_extra_mem(void) } /* - * Finds the next RAM pfn available in the E820 map after min_pfn. - * This function updates min_pfn with the pfn found and returns - * the size of that range or zero if not found. - */ -static unsigned long __init xen_find_pfn_range( - const struct e820entry *list, size_t map_size, - unsigned long *min_pfn) -{ - const struct e820entry *entry; - unsigned int i; - unsigned long done = 0; - - for (i = 0, entry = list; i < map_size; i++, entry++) { - unsigned long s_pfn; - unsigned long e_pfn; - - if (entry->type != E820_RAM) - continue; - - e_pfn = PFN_DOWN(entry->addr + entry->size); - - /* We only care about E820 after this */ - if (e_pfn < *min_pfn) - continue; - - s_pfn = PFN_UP(entry->addr); - - /* If min_pfn falls within the E820 entry, we want to start - * at the min_pfn PFN. - */ - if (s_pfn <= *min_pfn) { - done = e_pfn - *min_pfn; - } else { - done = e_pfn - s_pfn; - *min_pfn = s_pfn; - } - break; - } - - return done; -} - -static int __init xen_free_mfn(unsigned long mfn) -{ - struct xen_memory_reservation reservation = { - .address_bits = 0, - .extent_order = 0, - .domid = DOMID_SELF - }; - - set_xen_guest_handle(reservation.extent_start, &mfn); - reservation.nr_extents = 1; - - return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation); -} - -/* - * This releases a chunk of memory and then does the identity map. It's used - * as a fallback if the remapping fails. - */ -static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn, - unsigned long end_pfn, unsigned long nr_pages, unsigned long *released) -{ - unsigned long pfn, end; - int ret; - - WARN_ON(start_pfn > end_pfn); - - /* Release pages first. */ - end = min(end_pfn, nr_pages); - for (pfn = start_pfn; pfn < end; pfn++) { - unsigned long mfn = pfn_to_mfn(pfn); - - /* Make sure pfn exists to start with */ - if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn) - continue; - - ret = xen_free_mfn(mfn); - WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret); - - if (ret == 1) { - (*released)++; - if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY)) - break; - } else - break; - } - - set_phys_range_identity(start_pfn, end_pfn); -} - -/* - * Helper function to update the p2m and m2p tables and kernel mapping. - */ -static void __init xen_update_mem_tables(unsigned long pfn, unsigned long mfn) -{ - struct mmu_update update = { - .ptr = ((uint64_t)mfn << PAGE_SHIFT) | MMU_MACHPHYS_UPDATE, - .val = pfn - }; - - /* Update p2m */ - if (!set_phys_to_machine(pfn, mfn)) { - WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n", - pfn, mfn); - BUG(); - } - - /* Update m2p */ - if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) { - WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n", - mfn, pfn); - BUG(); - } - - /* Update kernel mapping, but not for highmem. */ - if (pfn >= PFN_UP(__pa(high_memory - 1))) - return; - - if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT), - mfn_pte(mfn, PAGE_KERNEL), 0)) { - WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n", - mfn, pfn); - BUG(); - } -} - -/* - * This function updates the p2m and m2p tables with an identity map from - * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the - * original allocation at remap_pfn. The information needed for remapping is - * saved in the memory itself to avoid the need for allocating buffers. The - * complete remap information is contained in a list of MFNs each containing - * up to REMAP_SIZE MFNs and the start target PFN for doing the remap. - * This enables us to preserve the original mfn sequence while doing the - * remapping at a time when the memory management is capable of allocating - * virtual and physical memory in arbitrary amounts, see 'xen_remap_memory' and - * its callers. - */ -static void __init xen_do_set_identity_and_remap_chunk( - unsigned long start_pfn, unsigned long size, unsigned long remap_pfn) -{ - unsigned long buf = (unsigned long)&xen_remap_buf; - unsigned long mfn_save, mfn; - unsigned long ident_pfn_iter, remap_pfn_iter; - unsigned long ident_end_pfn = start_pfn + size; - unsigned long left = size; - unsigned int i, chunk; - - WARN_ON(size == 0); - - BUG_ON(xen_feature(XENFEAT_auto_translated_physmap)); - - mfn_save = virt_to_mfn(buf); - - for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn; - ident_pfn_iter < ident_end_pfn; - ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) { - chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE; - - /* Map first pfn to xen_remap_buf */ - mfn = pfn_to_mfn(ident_pfn_iter); - set_pte_mfn(buf, mfn, PAGE_KERNEL); - - /* Save mapping information in page */ - xen_remap_buf.next_area_mfn = xen_remap_mfn; - xen_remap_buf.target_pfn = remap_pfn_iter; - xen_remap_buf.size = chunk; - for (i = 0; i < chunk; i++) - xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i); - - /* Put remap buf into list. */ - xen_remap_mfn = mfn; - - /* Set identity map */ - set_phys_range_identity(ident_pfn_iter, ident_pfn_iter + chunk); - - left -= chunk; - } - - /* Restore old xen_remap_buf mapping */ - set_pte_mfn(buf, mfn_save, PAGE_KERNEL); -} - -/* - * This function takes a contiguous pfn range that needs to be identity mapped - * and: - * - * 1) Finds a new range of pfns to use to remap based on E820 and remap_pfn. - * 2) Calls the do_ function to actually do the mapping/remapping work. - * - * The goal is to not allocate additional memory but to remap the existing - * pages. In the case of an error the underlying memory is simply released back - * to Xen and not remapped. - */ -static unsigned long __init xen_set_identity_and_remap_chunk( - const struct e820entry *list, size_t map_size, unsigned long start_pfn, - unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn, - unsigned long *released, unsigned long *remapped) -{ - unsigned long pfn; - unsigned long i = 0; - unsigned long n = end_pfn - start_pfn; - - while (i < n) { - unsigned long cur_pfn = start_pfn + i; - unsigned long left = n - i; - unsigned long size = left; - unsigned long remap_range_size; - - /* Do not remap pages beyond the current allocation */ - if (cur_pfn >= nr_pages) { - /* Identity map remaining pages */ - set_phys_range_identity(cur_pfn, cur_pfn + size); - break; - } - if (cur_pfn + size > nr_pages) - size = nr_pages - cur_pfn; - - remap_range_size = xen_find_pfn_range(list, map_size, - &remap_pfn); - if (!remap_range_size) { - pr_warning("Unable to find available pfn range, not remapping identity pages\n"); - xen_set_identity_and_release_chunk(cur_pfn, - cur_pfn + left, nr_pages, released); - break; - } - /* Adjust size to fit in current e820 RAM region */ - if (size > remap_range_size) - size = remap_range_size; - - xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn); - - /* Update variables to reflect new mappings. */ - i += size; - remap_pfn += size; - *remapped += size; - } - - /* - * If the PFNs are currently mapped, the VA mapping also needs - * to be updated to be 1:1. - */ - for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) - (void)HYPERVISOR_update_va_mapping( - (unsigned long)__va(pfn << PAGE_SHIFT), - mfn_pte(pfn, PAGE_KERNEL_IO), 0); - - return remap_pfn; -} - -static void __init xen_set_identity_and_remap( - const struct e820entry *list, size_t map_size, unsigned long nr_pages, - unsigned long *released, unsigned long *remapped) -{ - phys_addr_t start = 0; - unsigned long last_pfn = nr_pages; - const struct e820entry *entry; - unsigned long num_released = 0; - unsigned long num_remapped = 0; - int i; - - /* - * Combine non-RAM regions and gaps until a RAM region (or the - * end of the map) is reached, then set the 1:1 map and - * remap the memory in those non-RAM regions. - * - * The combined non-RAM regions are rounded to a whole number - * of pages so any partial pages are accessible via the 1:1 - * mapping. This is needed for some BIOSes that put (for - * example) the DMI tables in a reserved region that begins on - * a non-page boundary. - */ - for (i = 0, entry = list; i < map_size; i++, entry++) { - phys_addr_t end = entry->addr + entry->size; - if (entry->type == E820_RAM || i == map_size - 1) { - unsigned long start_pfn = PFN_DOWN(start); - unsigned long end_pfn = PFN_UP(end); - - if (entry->type == E820_RAM) - end_pfn = PFN_UP(entry->addr); - - if (start_pfn < end_pfn) - last_pfn = xen_set_identity_and_remap_chunk( - list, map_size, start_pfn, - end_pfn, nr_pages, last_pfn, - &num_released, &num_remapped); - start = end; - } - } - - *released = num_released; - *remapped = num_remapped; - - pr_info("Released %ld page(s)\n", num_released); -} - -/* - * Remap the memory prepared in xen_do_set_identity_and_remap_chunk(). - * The remap information (which mfn remap to which pfn) is contained in the - * to be remapped memory itself in a linked list anchored at xen_remap_mfn. - * This scheme allows to remap the different chunks in arbitrary order while - * the resulting mapping will be independant from the order. - */ -void __init xen_remap_memory(void) -{ - unsigned long buf = (unsigned long)&xen_remap_buf; - unsigned long mfn_save, mfn, pfn; - unsigned long remapped = 0; - unsigned int i; - unsigned long pfn_s = ~0UL; - unsigned long len = 0; - - mfn_save = virt_to_mfn(buf); - - while (xen_remap_mfn != INVALID_P2M_ENTRY) { - /* Map the remap information */ - set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL); - - BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]); - - pfn = xen_remap_buf.target_pfn; - for (i = 0; i < xen_remap_buf.size; i++) { - mfn = xen_remap_buf.mfns[i]; - xen_update_mem_tables(pfn, mfn); - remapped++; - pfn++; - } - if (pfn_s == ~0UL || pfn == pfn_s) { - pfn_s = xen_remap_buf.target_pfn; - len += xen_remap_buf.size; - } else if (pfn_s + len == xen_remap_buf.target_pfn) { - len += xen_remap_buf.size; - } else { - xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len)); - pfn_s = xen_remap_buf.target_pfn; - len = xen_remap_buf.size; - } - - mfn = xen_remap_mfn; - xen_remap_mfn = xen_remap_buf.next_area_mfn; - } - - if (pfn_s != ~0UL && len) - xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len)); - - set_pte_mfn(buf, mfn_save, PAGE_KERNEL); - - pr_info("Remapped %ld page(s)\n", remapped); -} - -static unsigned long __init xen_get_max_pages(void) -{ - unsigned long max_pages = MAX_DOMAIN_PAGES; - domid_t domid = DOMID_SELF; - int ret; - - /* - * For the initial domain we use the maximum reservation as - * the maximum page. - * - * For guest domains the current maximum reservation reflects - * the current maximum rather than the static maximum. In this - * case the e820 map provided to us will cover the static - * maximum region. - */ - if (xen_initial_domain()) { - ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); - if (ret > 0) - max_pages = ret; - } - - return min(max_pages, MAX_DOMAIN_PAGES); -} - -static void __init xen_align_and_add_e820_region(phys_addr_t start, - phys_addr_t size, int type) -{ - phys_addr_t end = start + size; - - /* Align RAM regions to page boundaries. */ - if (type == E820_RAM) { - start = PAGE_ALIGN(start); - end &= ~((phys_addr_t)PAGE_SIZE - 1); - } - - e820_add_region(start, end - start, type); -} - -static void __init xen_ignore_unusable(struct e820entry *list, size_t map_size) -{ - struct e820entry *entry; - unsigned int i; - - for (i = 0, entry = list; i < map_size; i++, entry++) { - if (entry->type == E820_UNUSABLE) - entry->type = E820_RAM; - } -} - -/** - * machine_specific_memory_setup - Hook for machine specific memory setup. - **/ -char * __init xen_memory_setup(void) -{ - static struct e820entry map[E820MAX] __initdata; - - unsigned long max_pfn = xen_start_info->nr_pages; - phys_addr_t mem_end; - int rc; - struct xen_memory_map memmap; - unsigned long max_pages; - unsigned long extra_pages = 0; - unsigned long remapped_pages; - int i; - int op; - - max_pfn = min(MAX_DOMAIN_PAGES, max_pfn); - mem_end = PFN_PHYS(max_pfn); - - memmap.nr_entries = E820MAX; - set_xen_guest_handle(memmap.buffer, map); - - op = xen_initial_domain() ? - XENMEM_machine_memory_map : - XENMEM_memory_map; - rc = HYPERVISOR_memory_op(op, &memmap); - if (rc == -ENOSYS) { - BUG_ON(xen_initial_domain()); - memmap.nr_entries = 1; - map[0].addr = 0ULL; - map[0].size = mem_end; - /* 8MB slack (to balance backend allocations). */ - map[0].size += 8ULL << 20; - map[0].type = E820_RAM; - rc = 0; - } - BUG_ON(rc); - BUG_ON(memmap.nr_entries == 0); - - /* - * Xen won't allow a 1:1 mapping to be created to UNUSABLE - * regions, so if we're using the machine memory map leave the - * region as RAM as it is in the pseudo-physical map. - * - * UNUSABLE regions in domUs are not handled and will need - * a patch in the future. - */ - if (xen_initial_domain()) - xen_ignore_unusable(map, memmap.nr_entries); - - /* Make sure the Xen-supplied memory map is well-ordered. */ - sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); - - max_pages = xen_get_max_pages(); - if (max_pages > max_pfn) - extra_pages += max_pages - max_pfn; - - /* - * Set identity map on non-RAM pages and prepare remapping the - * underlying RAM. - */ - xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn, - &xen_released_pages, &remapped_pages); - - extra_pages += xen_released_pages; - extra_pages += remapped_pages; - - /* - * Clamp the amount of extra memory to a EXTRA_MEM_RATIO - * factor the base size. On non-highmem systems, the base - * size is the full initial memory allocation; on highmem it - * is limited to the max size of lowmem, so that it doesn't - * get completely filled. - * - * In principle there could be a problem in lowmem systems if - * the initial memory is also very large with respect to - * lowmem, but we won't try to deal with that here. - */ - extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), - extra_pages); - i = 0; - while (i < memmap.nr_entries) { - phys_addr_t addr = map[i].addr; - phys_addr_t size = map[i].size; - u32 type = map[i].type; - - if (type == E820_RAM) { - if (addr < mem_end) { - size = min(size, mem_end - addr); - } else if (extra_pages) { - size = min(size, PFN_PHYS(extra_pages)); - extra_pages -= PFN_DOWN(size); - xen_add_extra_mem(addr, size); - xen_max_p2m_pfn = PFN_DOWN(addr + size); - } else - type = E820_UNUSABLE; - } - - xen_align_and_add_e820_region(addr, size, type); - - map[i].addr += size; - map[i].size -= size; - if (map[i].size == 0) - i++; - } - - /* - * Set the rest as identity mapped, in case PCI BARs are - * located here. - * - * PFNs above MAX_P2M_PFN are considered identity mapped as - * well. - */ - set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul); - - /* - * In domU, the ISA region is normal, usable memory, but we - * reserve ISA memory anyway because too many things poke - * about in there. - */ - e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, - E820_RESERVED); - - /* - * Reserve Xen bits: - * - mfn_list - * - xen_start_info - * See comment above "struct start_info" in <xen/interface/xen.h> - * We tried to make the the memblock_reserve more selective so - * that it would be clear what region is reserved. Sadly we ran - * in the problem wherein on a 64-bit hypervisor with a 32-bit - * initial domain, the pt_base has the cr3 value which is not - * neccessarily where the pagetable starts! As Jan put it: " - * Actually, the adjustment turns out to be correct: The page - * tables for a 32-on-64 dom0 get allocated in the order "first L1", - * "first L2", "first L3", so the offset to the page table base is - * indeed 2. When reading xen/include/public/xen.h's comment - * very strictly, this is not a violation (since there nothing is said - * that the first thing in the page table space is pointed to by - * pt_base; I admit that this seems to be implied though, namely - * do I think that it is implied that the page table space is the - * range [pt_base, pt_base + nt_pt_frames), whereas that - * range here indeed is [pt_base - 2, pt_base - 2 + nt_pt_frames), - * which - without a priori knowledge - the kernel would have - * difficulty to figure out)." - so lets just fall back to the - * easy way and reserve the whole region. - */ - memblock_reserve(__pa(xen_start_info->mfn_list), - xen_start_info->pt_base - xen_start_info->mfn_list); - - sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); - - return "Xen"; -} - -/* * Machine specific memory setup for auto-translated guests. */ char * __init xen_auto_xlated_memory_setup(void) diff --git a/arch/x86/xen/simple_mem_setup.c b/arch/x86/xen/simple_mem_setup.c new file mode 100644 index 0000000..9edd703 --- /dev/null +++ b/arch/x86/xen/simple_mem_setup.c @@ -0,0 +1,677 @@ +#include <linux/module.h> +#include <linux/sched.h> +#include <linux/mm.h> +#include <linux/pm.h> +#include <linux/memblock.h> +#include <linux/cpuidle.h> +#include <linux/cpufreq.h> + +#include <asm/elf.h> +#include <asm/vdso.h> +#include <asm/e820.h> +#include <asm/setup.h> +#include <asm/acpi.h> +#include <asm/numa.h> +#include <asm/xen/hypervisor.h> +#include <asm/xen/hypercall.h> + +#include <xen/xen.h> +#include <xen/page.h> +#include <xen/interface/callback.h> +#include <xen/interface/memory.h> +#include <xen/interface/physdev.h> +#include <xen/features.h> +#include "xen-ops.h" +#include "vdso.h" +#include "p2m.h" +#include "mmu.h" + +/* Number of pages released from the initial allocation. */ +unsigned long xen_released_pages; + +/* Amount of extra memory space we add to the e820 ranges */ +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; + +/* + * The maximum amount of extra memory compared to the base size. The + * main scaling factor is the size of struct page. At extreme ratios + * of base:extra, all the base memory can be filled with page + * structures for the extra memory, leaving no space for anything + * else. + * + * 10x seems like a reasonable balance between scaling flexibility and + * leaving a practically usable system. + */ +#define EXTRA_MEM_RATIO (10) + +/* + * Buffer used to remap identity mapped pages. We only need the virtual space. + * The physical page behind this address is remapped as needed to different + * buffer pages. + */ +#define REMAP_SIZE (P2M_PER_PAGE - 3) +static struct { + unsigned long next_area_mfn; + unsigned long target_pfn; + unsigned long size; + unsigned long mfns[REMAP_SIZE]; +} xen_remap_buf __initdata __aligned(PAGE_SIZE); +static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY; + + +/* + * Finds the next RAM pfn available in the E820 map after min_pfn. + * This function updates min_pfn with the pfn found and returns + * the size of that range or zero if not found. + */ +static unsigned long __init xen_find_pfn_range( + const struct e820entry *list, size_t map_size, + unsigned long *min_pfn) +{ + const struct e820entry *entry; + unsigned int i; + unsigned long done = 0; + + for (i = 0, entry = list; i < map_size; i++, entry++) { + unsigned long s_pfn; + unsigned long e_pfn; + + if (entry->type != E820_RAM) + continue; + + e_pfn = PFN_DOWN(entry->addr + entry->size); + + /* We only care about E820 after this */ + if (e_pfn < *min_pfn) + continue; + + s_pfn = PFN_UP(entry->addr); + + /* If min_pfn falls within the E820 entry, we want to start + * at the min_pfn PFN. + */ + if (s_pfn <= *min_pfn) { + done = e_pfn - *min_pfn; + } else { + done = e_pfn - s_pfn; + *min_pfn = s_pfn; + } + break; + } + + return done; +} + +static int __init xen_free_mfn(unsigned long mfn) +{ + struct xen_memory_reservation reservation = { + .address_bits = 0, + .extent_order = 0, + .domid = DOMID_SELF + }; + + set_xen_guest_handle(reservation.extent_start, &mfn); + reservation.nr_extents = 1; + + return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation); +} + +/* + * This releases a chunk of memory and then does the identity map. It's used + * as a fallback if the remapping fails. + */ +static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn, + unsigned long end_pfn, unsigned long nr_pages, unsigned long *released) +{ + unsigned long pfn, end; + int ret; + + WARN_ON(start_pfn > end_pfn); + + /* Release pages first. */ + end = min(end_pfn, nr_pages); + for (pfn = start_pfn; pfn < end; pfn++) { + unsigned long mfn = pfn_to_mfn(pfn); + + /* Make sure pfn exists to start with */ + if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn) + continue; + + ret = xen_free_mfn(mfn); + WARN(ret != 1, "Failed to release pfn %lx err=%d\n", pfn, ret); + + if (ret == 1) { + (*released)++; + if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY)) + break; + } else + break; + } + + set_phys_range_identity(start_pfn, end_pfn); +} + +/* + * This function updates the p2m and m2p tables with an identity map from + * start_pfn to start_pfn+size and prepares remapping the underlying RAM of the + * original allocation at remap_pfn. The information needed for remapping is + * saved in the memory itself to avoid the need for allocating buffers. The + * complete remap information is contained in a list of MFNs each containing + * up to REMAP_SIZE MFNs and the start target PFN for doing the remap. + * This enables us to preserve the original mfn sequence while doing the + * remapping at a time when the memory management is capable of allocating + * virtual and physical memory in arbitrary amounts, see 'xen_remap_memory' and + * its callers. + */ +static void __init xen_do_set_identity_and_remap_chunk( + unsigned long start_pfn, unsigned long size, unsigned long remap_pfn) +{ + unsigned long buf = (unsigned long)&xen_remap_buf; + unsigned long mfn_save, mfn; + unsigned long ident_pfn_iter, remap_pfn_iter; + unsigned long ident_end_pfn = start_pfn + size; + unsigned long left = size; + unsigned int i, chunk; + + WARN_ON(size == 0); + + BUG_ON(xen_feature(XENFEAT_auto_translated_physmap)); + + mfn_save = virt_to_mfn(buf); + + for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn; + ident_pfn_iter < ident_end_pfn; + ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) { + chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE; + + /* Map first pfn to xen_remap_buf */ + mfn = pfn_to_mfn(ident_pfn_iter); + set_pte_mfn(buf, mfn, PAGE_KERNEL); + + /* Save mapping information in page */ + xen_remap_buf.next_area_mfn = xen_remap_mfn; + xen_remap_buf.target_pfn = remap_pfn_iter; + xen_remap_buf.size = chunk; + for (i = 0; i < chunk; i++) + xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i); + + /* Put remap buf into list. */ + xen_remap_mfn = mfn; + + /* Set identity map */ + set_phys_range_identity(ident_pfn_iter, ident_pfn_iter + chunk); + + left -= chunk; + } + + /* Restore old xen_remap_buf mapping */ + set_pte_mfn(buf, mfn_save, PAGE_KERNEL); +} + +/* + * This function takes a contiguous pfn range that needs to be identity mapped + * and: + * + * 1) Finds a new range of pfns to use to remap based on E820 and remap_pfn. + * 2) Calls the do_ function to actually do the mapping/remapping work. + * + * The goal is to not allocate additional memory but to remap the existing + * pages. In the case of an error the underlying memory is simply released back + * to Xen and not remapped. + */ +static unsigned long __init xen_set_identity_and_remap_chunk( + const struct e820entry *list, size_t map_size, unsigned long start_pfn, + unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn, + unsigned long *released, unsigned long *remapped) +{ + unsigned long pfn; + unsigned long i = 0; + unsigned long n = end_pfn - start_pfn; + + while (i < n) { + unsigned long cur_pfn = start_pfn + i; + unsigned long left = n - i; + unsigned long size = left; + unsigned long remap_range_size; + + /* Do not remap pages beyond the current allocation */ + if (cur_pfn >= nr_pages) { + /* Identity map remaining pages */ + set_phys_range_identity(cur_pfn, cur_pfn + size); + break; + } + if (cur_pfn + size > nr_pages) + size = nr_pages - cur_pfn; + + remap_range_size = xen_find_pfn_range(list, map_size, + &remap_pfn); + if (!remap_range_size) { + pr_warning("Unable to find available pfn range, not remapping identity pages\n"); + xen_set_identity_and_release_chunk(cur_pfn, + cur_pfn + left, nr_pages, released); + break; + } + /* Adjust size to fit in current e820 RAM region */ + if (size > remap_range_size) + size = remap_range_size; + + xen_do_set_identity_and_remap_chunk(cur_pfn, size, remap_pfn); + + /* Update variables to reflect new mappings. */ + i += size; + remap_pfn += size; + *remapped += size; + } + + /* + * If the PFNs are currently mapped, the VA mapping also needs + * to be updated to be 1:1. + */ + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) + (void)HYPERVISOR_update_va_mapping( + (unsigned long)__va(pfn << PAGE_SHIFT), + mfn_pte(pfn, PAGE_KERNEL_IO), 0); + + return remap_pfn; +} + +static void __init xen_set_identity_and_remap( + const struct e820entry *list, size_t map_size, unsigned long nr_pages, + unsigned long *released, unsigned long *remapped) +{ + phys_addr_t start = 0; + unsigned long last_pfn = nr_pages; + const struct e820entry *entry; + unsigned long num_released = 0; + unsigned long num_remapped = 0; + int i; + + /* + * Combine non-RAM regions and gaps until a RAM region (or the + * end of the map) is reached, then set the 1:1 map and + * remap the memory in those non-RAM regions. + * + * The combined non-RAM regions are rounded to a whole number + * of pages so any partial pages are accessible via the 1:1 + * mapping. This is needed for some BIOSes that put (for + * example) the DMI tables in a reserved region that begins on + * a non-page boundary. + */ + for (i = 0, entry = list; i < map_size; i++, entry++) { + phys_addr_t end = entry->addr + entry->size; + if (entry->type == E820_RAM || i == map_size - 1) { + unsigned long start_pfn = PFN_DOWN(start); + unsigned long end_pfn = PFN_UP(end); + + if (entry->type == E820_RAM) + end_pfn = PFN_UP(entry->addr); + + if (start_pfn < end_pfn) + last_pfn = xen_set_identity_and_remap_chunk( + list, map_size, start_pfn, + end_pfn, nr_pages, last_pfn, + &num_released, &num_remapped); + start = end; + } + } + + *released = num_released; + *remapped = num_remapped; + + pr_info("Released %ld page(s)\n", num_released); +} + + +static unsigned long __init xen_get_max_pages(void) +{ + unsigned long max_pages = MAX_DOMAIN_PAGES; + domid_t domid = DOMID_SELF; + int ret; + + /* + * For the initial domain we use the maximum reservation as + * the maximum page. + * + * For guest domains the current maximum reservation reflects + * the current maximum rather than the static maximum. In this + * case the e820 map provided to us will cover the static + * maximum region. + */ + if (xen_initial_domain()) { + ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid); + if (ret > 0) + max_pages = ret; + } + + return min(max_pages, MAX_DOMAIN_PAGES); +} + +static void __init xen_align_and_add_e820_region(phys_addr_t start, + phys_addr_t size, int type) +{ + phys_addr_t end = start + size; + + /* Align RAM regions to page boundaries. */ + if (type == E820_RAM) { + start = PAGE_ALIGN(start); + end &= ~((phys_addr_t)PAGE_SIZE - 1); + } + + e820_add_region(start, end - start, type); +} + +static void __init xen_ignore_unusable(struct e820entry *list, size_t map_size) +{ + struct e820entry *entry; + unsigned int i; + + for (i = 0, entry = list; i < map_size; i++, entry++) { + if (entry->type == E820_UNUSABLE) + entry->type = E820_RAM; + } +} + +static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size) +{ + int i; + + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { + /* Add new region. */ + if (xen_extra_mem[i].size == 0) { + xen_extra_mem[i].start = start; + xen_extra_mem[i].size = size; + break; + } + /* Append to existing region. */ + if (xen_extra_mem[i].start + xen_extra_mem[i].size == start) { + xen_extra_mem[i].size += size; + break; + } + } + if (i == XEN_EXTRA_MEM_MAX_REGIONS) + printk(KERN_WARNING "Warning: not enough extra memory regions\n"); + + memblock_reserve(start, size); +} + +/** + * machine_specific_memory_setup - Hook for machine specific memory setup. + **/ +char * __init xen_memory_setup(void) +{ + static struct e820entry map[E820MAX] __initdata; + + unsigned long max_pfn = xen_start_info->nr_pages; + phys_addr_t mem_end; + int rc; + struct xen_memory_map memmap; + unsigned long max_pages; + unsigned long extra_pages = 0; + unsigned long remapped_pages; + int i; + int op; + + max_pfn = min(MAX_DOMAIN_PAGES, max_pfn); + mem_end = PFN_PHYS(max_pfn); + + memmap.nr_entries = E820MAX; + set_xen_guest_handle(memmap.buffer, map); + + op = xen_initial_domain() ? + XENMEM_machine_memory_map : + XENMEM_memory_map; + rc = HYPERVISOR_memory_op(op, &memmap); + if (rc == -ENOSYS) { + BUG_ON(xen_initial_domain()); + memmap.nr_entries = 1; + map[0].addr = 0ULL; + map[0].size = mem_end; + /* 8MB slack (to balance backend allocations). */ + map[0].size += 8ULL << 20; + map[0].type = E820_RAM; + rc = 0; + } + BUG_ON(rc); + BUG_ON(memmap.nr_entries == 0); + + /* + * Xen won't allow a 1:1 mapping to be created to UNUSABLE + * regions, so if we're using the machine memory map leave the + * region as RAM as it is in the pseudo-physical map. + * + * UNUSABLE regions in domUs are not handled and will need + * a patch in the future. + */ + if (xen_initial_domain()) + xen_ignore_unusable(map, memmap.nr_entries); + + /* Make sure the Xen-supplied memory map is well-ordered. */ + sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries); + + max_pages = xen_get_max_pages(); + if (max_pages > max_pfn) + extra_pages += max_pages - max_pfn; + + /* + * Set identity map on non-RAM pages and prepare remapping the + * underlying RAM. + */ + xen_set_identity_and_remap(map, memmap.nr_entries, max_pfn, + &xen_released_pages, &remapped_pages); + + extra_pages += xen_released_pages; + extra_pages += remapped_pages; + + /* + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO + * factor the base size. On non-highmem systems, the base + * size is the full initial memory allocation; on highmem it + * is limited to the max size of lowmem, so that it doesn't + * get completely filled. + * + * In principle there could be a problem in lowmem systems if + * the initial memory is also very large with respect to + * lowmem, but we won't try to deal with that here. + */ + extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), + extra_pages); + i = 0; + while (i < memmap.nr_entries) { + phys_addr_t addr = map[i].addr; + phys_addr_t size = map[i].size; + u32 type = map[i].type; + + if (type == E820_RAM) { + if (addr < mem_end) { + size = min(size, mem_end - addr); + } else if (extra_pages) { + size = min(size, PFN_PHYS(extra_pages)); + extra_pages -= PFN_DOWN(size); + xen_add_extra_mem(addr, size); + xen_max_p2m_pfn = PFN_DOWN(addr + size); + } else + type = E820_UNUSABLE; + } + + xen_align_and_add_e820_region(addr, size, type); + + map[i].addr += size; + map[i].size -= size; + if (map[i].size == 0) + i++; + } + + /* + * Set the rest as identity mapped, in case PCI BARs are + * located here. + * + * PFNs above MAX_P2M_PFN are considered identity mapped as + * well. + */ + set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul); + + /* + * In domU, the ISA region is normal, usable memory, but we + * reserve ISA memory anyway because too many things poke + * about in there. + */ + e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, + E820_RESERVED); + + /* + * Reserve Xen bits: + * - mfn_list + * - xen_start_info + * See comment above "struct start_info" in <xen/interface/xen.h> + * We tried to make the the memblock_reserve more selective so + * that it would be clear what region is reserved. Sadly we ran + * in the problem wherein on a 64-bit hypervisor with a 32-bit + * initial domain, the pt_base has the cr3 value which is not + * neccessarily where the pagetable starts! As Jan put it: " + * Actually, the adjustment turns out to be correct: The page + * tables for a 32-on-64 dom0 get allocated in the order "first L1", + * "first L2", "first L3", so the offset to the page table base is + * indeed 2. When reading xen/include/public/xen.h's comment + * very strictly, this is not a violation (since there nothing is said + * that the first thing in the page table space is pointed to by + * pt_base; I admit that this seems to be implied though, namely + * do I think that it is implied that the page table space is the + * range [pt_base, pt_base + nt_pt_frames), whereas that + * range here indeed is [pt_base - 2, pt_base - 2 + nt_pt_frames), + * which - without a priori knowledge - the kernel would have + * difficulty to figure out)." - so lets just fall back to the + * easy way and reserve the whole region. + */ + memblock_reserve(__pa(xen_start_info->mfn_list), + xen_start_info->pt_base - xen_start_info->mfn_list); + + sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); + + return "Xen"; +} + +static void __init xen_del_extra_mem(phys_addr_t start, phys_addr_t size) +{ + int i; + phys_addr_t start_r, size_r; + + for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++) { + start_r = xen_extra_mem[i].start; + size_r = xen_extra_mem[i].size; + + /* Start of region. */ + if (start_r == start) { + BUG_ON(size > size_r); + xen_extra_mem[i].start += size; + xen_extra_mem[i].size -= size; + break; + } + /* End of region. */ + if (start_r + size_r == start + size) { + BUG_ON(size > size_r); + xen_extra_mem[i].size -= size; + break; + } + /* Mid of region. */ + if (start > start_r && start < start_r + size_r) { + BUG_ON(start + size > start_r + size_r); + xen_extra_mem[i].size = start - start_r; + /* Calling memblock_reserve() again is okay. */ + xen_add_extra_mem(start + size, start_r + size_r - + (start + size)); + break; + } + } + memblock_free(start, size); +} + +/* + * Helper function to update the p2m and m2p tables and kernel mapping. + */ +static void __init xen_update_mem_tables(unsigned long pfn, unsigned long mfn) +{ + struct mmu_update update = { + .ptr = ((uint64_t)mfn << PAGE_SHIFT) | MMU_MACHPHYS_UPDATE, + .val = pfn + }; + + /* Update p2m */ + if (!set_phys_to_machine(pfn, mfn)) { + WARN(1, "Failed to set p2m mapping for pfn=%ld mfn=%ld\n", + pfn, mfn); + BUG(); + } + + /* Update m2p */ + if (HYPERVISOR_mmu_update(&update, 1, NULL, DOMID_SELF) < 0) { + WARN(1, "Failed to set m2p mapping for mfn=%ld pfn=%ld\n", + mfn, pfn); + BUG(); + } + + /* Update kernel mapping, but not for highmem. */ + if (pfn >= PFN_UP(__pa(high_memory - 1))) + return; + + if (HYPERVISOR_update_va_mapping((unsigned long)__va(pfn << PAGE_SHIFT), + mfn_pte(mfn, PAGE_KERNEL), 0)) { + WARN(1, "Failed to update kernel mapping for mfn=%ld pfn=%ld\n", + mfn, pfn); + BUG(); + } +} + + +/* + * Remap the memory prepared in xen_do_set_identity_and_remap_chunk(). + * The remap information (which mfn remap to which pfn) is contained in the + * to be remapped memory itself in a linked list anchored at xen_remap_mfn. + * This scheme allows to remap the different chunks in arbitrary order while + * the resulting mapping will be independant from the order. + */ +void __init xen_remap_memory(void) +{ + unsigned long buf = (unsigned long)&xen_remap_buf; + unsigned long mfn_save, mfn, pfn; + unsigned long remapped = 0; + unsigned int i; + unsigned long pfn_s = ~0UL; + unsigned long len = 0; + + mfn_save = virt_to_mfn(buf); + + while (xen_remap_mfn != INVALID_P2M_ENTRY) { + /* Map the remap information */ + set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL); + + BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]); + + pfn = xen_remap_buf.target_pfn; + for (i = 0; i < xen_remap_buf.size; i++) { + mfn = xen_remap_buf.mfns[i]; + xen_update_mem_tables(pfn, mfn); + remapped++; + pfn++; + } + if (pfn_s == ~0UL || pfn == pfn_s) { + pfn_s = xen_remap_buf.target_pfn; + len += xen_remap_buf.size; + } else if (pfn_s + len == xen_remap_buf.target_pfn) { + len += xen_remap_buf.size; + } else { + xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len)); + pfn_s = xen_remap_buf.target_pfn; + len = xen_remap_buf.size; + } + + mfn = xen_remap_mfn; + xen_remap_mfn = xen_remap_buf.next_area_mfn; + } + + if (pfn_s != ~0UL && len) + xen_del_extra_mem(PFN_PHYS(pfn_s), PFN_PHYS(len)); + + set_pte_mfn(buf, mfn_save, PAGE_KERNEL); + + pr_info("Remapped %ld page(s)\n", remapped); +} diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index 674b2225..ab4d07c 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -14,25 +14,36 @@ #include <xen/interface/features.h> #include <asm/xen/interface.h> +/* These are statically set */ #ifdef CONFIG_XEN_PVH #define PVH_FEATURES_STR "|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel" /* Note the lack of 'hvm_callback_vector'. Older hypervisor will * balk at this being part of XEN_ELFNOTE_FEATURES, so we put it in * XEN_ELFNOTE_SUPPORTED_FEATURES which older hypervisors will ignore. */ +/* the XEN_PVH features */ #define PVH_FEATURES ((1 << XENFEAT_writable_page_tables) | \ (1 << XENFEAT_auto_translated_physmap) | \ (1 << XENFEAT_supervisor_mode_kernel) | \ (1 << XENFEAT_hvm_callback_vector)) + /* The XENFEAT_writable_page_tables is not stricly neccessary as we set that * up regardless whether this CONFIG option is enabled or not, but it * clarifies what the right flags need to be. */ #else + +/* what else? */ +#ifdef CONFIG_XEN_PVHVM +#define PVH_FEATURES_STR "|auto_translated_physmap" +#define PVH_FEATURES (1 << XENFEAT_auto_translated_physmap) +#else #define PVH_FEATURES_STR "" #define PVH_FEATURES (0) #endif +#endif + __INIT ENTRY(startup_xen) cld ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 0:20 ` Luis R. Rodriguez @ 2015-02-17 0:25 ` Luis R. Rodriguez 2015-02-17 7:26 ` Juergen Gross 2015-02-17 7:39 ` Juergen Gross 1 sibling, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-17 0:25 UTC (permalink / raw) To: David Vrabel, Juergen Gross, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky, Luis R. Rodriguez On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote: > 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 And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 0:25 ` Luis R. Rodriguez @ 2015-02-17 7:26 ` Juergen Gross 2015-02-17 19:31 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Juergen Gross @ 2015-02-17 7:26 UTC (permalink / raw) To: Luis R. Rodriguez, David Vrabel, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky, Luis R. Rodriguez On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: > On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez > <mcgrof@do-not-panic.com> wrote: >> 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 > > And this also raises the question of whether or not we should make > XEN_PVHVM a user selectable option, right now it is a def_bool and is > therefore not human selectable. You can implicitly disable it by > disabling PCI for example though. If we want that to be exposed to the > user we can then enable some description of what that means, and the > user will then be able to read / select / enable XEN_PV., XEN_PVHVM, > XEN_PVH. Right now they'd only be able to select XEN_PV and/or > XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. Juergen ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 7:26 ` Juergen Gross @ 2015-02-17 19:31 ` Luis R. Rodriguez 2015-02-18 18:11 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-17 19:31 UTC (permalink / raw) To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, David Vrabel On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez >> <mcgrof@do-not-panic.com> wrote: >>> >>> 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 >> >> >> And this also raises the question of whether or not we should make >> XEN_PVHVM a user selectable option, right now it is a def_bool and is >> therefore not human selectable. You can implicitly disable it by >> disabling PCI for example though. If we want that to be exposed to the >> user we can then enable some description of what that means, and the >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or >> XEN_PVH, XEN_PVHVM is implicit. > > > I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 19:31 ` Luis R. Rodriguez @ 2015-02-18 18:11 ` Konrad Rzeszutek Wilk 2015-02-18 20:01 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-02-18 18:11 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: > On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: > > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: > >> > >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez > >> <mcgrof@do-not-panic.com> wrote: > >>> > >>> 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 > >> > >> > >> And this also raises the question of whether or not we should make > >> XEN_PVHVM a user selectable option, right now it is a def_bool and is > >> therefore not human selectable. You can implicitly disable it by > >> disabling PCI for example though. If we want that to be exposed to the > >> user we can then enable some description of what that means, and the > >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, > >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or > >> XEN_PVH, XEN_PVHVM is implicit. > > > > > > I think making XEN_PVHVM user selectable is okay. > > OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. There should be an history in the git tree behind the desire to make it non selectable. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 18:11 ` Konrad Rzeszutek Wilk @ 2015-02-18 20:01 ` Luis R. Rodriguez 2015-02-18 20:20 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-18 20:01 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel, Luis R. Rodriguez On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: >> >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez >> >> <mcgrof@do-not-panic.com> wrote: >> >>> >> >>> 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 >> >> >> >> >> >> And this also raises the question of whether or not we should make >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is >> >> therefore not human selectable. You can implicitly disable it by >> >> disabling PCI for example though. If we want that to be exposed to the >> >> user we can then enable some description of what that means, and the >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or >> >> XEN_PVH, XEN_PVHVM is implicit. >> > >> > >> > I think making XEN_PVHVM user selectable is okay. >> >> OK I'll enable this then. > > Please don't. We had bugs in the past because distros did not select > it (they made it an module) and the PV drivers were not loaded. Oy vey. > There should be an history in the git tree behind the desire to make > it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 20:01 ` Luis R. Rodriguez @ 2015-02-18 20:20 ` Konrad Rzeszutek Wilk 2015-02-18 21:11 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-02-18 20:20 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel, Luis R. Rodriguez On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: > On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: > >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: > >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: > >> >> > >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez > >> >> <mcgrof@do-not-panic.com> wrote: > >> >>> > >> >>> 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 > >> >> > >> >> > >> >> And this also raises the question of whether or not we should make > >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is > >> >> therefore not human selectable. You can implicitly disable it by > >> >> disabling PCI for example though. If we want that to be exposed to the > >> >> user we can then enable some description of what that means, and the > >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, > >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or > >> >> XEN_PVH, XEN_PVHVM is implicit. > >> > > >> > > >> > I think making XEN_PVHVM user selectable is okay. > >> > >> OK I'll enable this then. > > > > Please don't. We had bugs in the past because distros did not select > > it (they made it an module) and the PV drivers were not loaded. > > Oy vey. > > > There should be an history in the git tree behind the desire to make > > it non selectable. > > OK how about we enable the user selection only under CONFIG_EXPERT, > otherwise make it hidden. The CONFIG_EXPERT is gone from the kernel.. > > Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 20:20 ` Konrad Rzeszutek Wilk @ 2015-02-18 21:11 ` Luis R. Rodriguez 2015-02-18 21:24 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-18 21:11 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: >> On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: >> >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: >> >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: >> >> >> >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez >> >> >> <mcgrof@do-not-panic.com> wrote: >> >> >>> >> >> >>> 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 >> >> >> >> >> >> >> >> >> And this also raises the question of whether or not we should make >> >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is >> >> >> therefore not human selectable. You can implicitly disable it by >> >> >> disabling PCI for example though. If we want that to be exposed to the >> >> >> user we can then enable some description of what that means, and the >> >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, >> >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or >> >> >> XEN_PVH, XEN_PVHVM is implicit. >> >> > >> >> > >> >> > I think making XEN_PVHVM user selectable is okay. >> >> >> >> OK I'll enable this then. >> > >> > Please don't. We had bugs in the past because distros did not select >> > it (they made it an module) and the PV drivers were not loaded. >> >> Oy vey. >> >> > There should be an history in the git tree behind the desire to make >> > it non selectable. >> >> OK how about we enable the user selection only under CONFIG_EXPERT, >> otherwise make it hidden. > > The CONFIG_EXPERT is gone from the kernel.. I see it as of next-20150218, is there a proposal to remove it? Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 21:11 ` Luis R. Rodriguez @ 2015-02-18 21:24 ` Konrad Rzeszutek Wilk 2015-02-18 21:31 ` Luis R. Rodriguez 0 siblings, 1 reply; 47+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-02-18 21:24 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: > On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: > >> On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk > >> <konrad.wilk@oracle.com> wrote: > >> > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: > >> >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: > >> >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: > >> >> >> > >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez > >> >> >> <mcgrof@do-not-panic.com> wrote: > >> >> >>> > >> >> >>> 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 > >> >> >> > >> >> >> > >> >> >> And this also raises the question of whether or not we should make > >> >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is > >> >> >> therefore not human selectable. You can implicitly disable it by > >> >> >> disabling PCI for example though. If we want that to be exposed to the > >> >> >> user we can then enable some description of what that means, and the > >> >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, > >> >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or > >> >> >> XEN_PVH, XEN_PVHVM is implicit. > >> >> > > >> >> > > >> >> > I think making XEN_PVHVM user selectable is okay. > >> >> > >> >> OK I'll enable this then. > >> > > >> > Please don't. We had bugs in the past because distros did not select > >> > it (they made it an module) and the PV drivers were not loaded. > >> > >> Oy vey. > >> > >> > There should be an history in the git tree behind the desire to make > >> > it non selectable. > >> > >> OK how about we enable the user selection only under CONFIG_EXPERT, > >> otherwise make it hidden. > > > > The CONFIG_EXPERT is gone from the kernel.. > > I see it as of next-20150218, is there a proposal to remove it? I am misremembering what was . AH, http://lwn.net/Articles/421304/ CONFIG_EMBEDDED! Sorry about the noise. Hm, maybe I m > > Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 21:24 ` Konrad Rzeszutek Wilk @ 2015-02-18 21:31 ` Luis R. Rodriguez 2015-02-18 21:54 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-18 21:31 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel On Wed, Feb 18, 2015 at 1:24 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: >> On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> > On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: >> >> On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk >> >> <konrad.wilk@oracle.com> wrote: >> >> > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: >> >> >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: >> >> >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: >> >> >> >> >> >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez >> >> >> >> <mcgrof@do-not-panic.com> wrote: >> >> >> >>> >> >> >> >>> 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 >> >> >> >> >> >> >> >> >> >> >> >> And this also raises the question of whether or not we should make >> >> >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is >> >> >> >> therefore not human selectable. You can implicitly disable it by >> >> >> >> disabling PCI for example though. If we want that to be exposed to the >> >> >> >> user we can then enable some description of what that means, and the >> >> >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, >> >> >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or >> >> >> >> XEN_PVH, XEN_PVHVM is implicit. >> >> >> > >> >> >> > >> >> >> > I think making XEN_PVHVM user selectable is okay. >> >> >> >> >> >> OK I'll enable this then. >> >> > >> >> > Please don't. We had bugs in the past because distros did not select >> >> > it (they made it an module) and the PV drivers were not loaded. >> >> >> >> Oy vey. >> >> >> >> > There should be an history in the git tree behind the desire to make >> >> > it non selectable. >> >> >> >> OK how about we enable the user selection only under CONFIG_EXPERT, >> >> otherwise make it hidden. >> > >> > The CONFIG_EXPERT is gone from the kernel.. >> >> I see it as of next-20150218, is there a proposal to remove it? > > I am misremembering what was . AH, http://lwn.net/Articles/421304/ > CONFIG_EMBEDDED! > > Sorry about the noise. So whatyda think? If that is not enough to prevent *stupid* from doing something dumb by adding own CONFIG_XEN_BUILD_EXPERT which will depend on EXPERT but default to n. That will prevent folks that typically enable EXPERT from going on venturing to disable what is visible unless they *really* want it. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 21:31 ` Luis R. Rodriguez @ 2015-02-18 21:54 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 47+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-02-18 21:54 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky, David Vrabel On Wed, Feb 18, 2015 at 01:31:15PM -0800, Luis R. Rodriguez wrote: > On Wed, Feb 18, 2015 at 1:24 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: > >> On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk > >> <konrad.wilk@oracle.com> wrote: > >> > On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: > >> >> On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk > >> >> <konrad.wilk@oracle.com> wrote: > >> >> > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: > >> >> >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross <jgross@suse.com> wrote: > >> >> >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: > >> >> >> >> > >> >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez > >> >> >> >> <mcgrof@do-not-panic.com> wrote: > >> >> >> >>> > >> >> >> >>> 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 > >> >> >> >> > >> >> >> >> > >> >> >> >> And this also raises the question of whether or not we should make > >> >> >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is > >> >> >> >> therefore not human selectable. You can implicitly disable it by > >> >> >> >> disabling PCI for example though. If we want that to be exposed to the > >> >> >> >> user we can then enable some description of what that means, and the > >> >> >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, > >> >> >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or > >> >> >> >> XEN_PVH, XEN_PVHVM is implicit. > >> >> >> > > >> >> >> > > >> >> >> > I think making XEN_PVHVM user selectable is okay. > >> >> >> > >> >> >> OK I'll enable this then. > >> >> > > >> >> > Please don't. We had bugs in the past because distros did not select > >> >> > it (they made it an module) and the PV drivers were not loaded. > >> >> > >> >> Oy vey. > >> >> > >> >> > There should be an history in the git tree behind the desire to make > >> >> > it non selectable. > >> >> > >> >> OK how about we enable the user selection only under CONFIG_EXPERT, > >> >> otherwise make it hidden. > >> > > >> > The CONFIG_EXPERT is gone from the kernel.. > >> > >> I see it as of next-20150218, is there a proposal to remove it? > > > > I am misremembering what was . AH, http://lwn.net/Articles/421304/ > > CONFIG_EMBEDDED! > > > > Sorry about the noise. > > So whatyda think? If that is not enough to prevent *stupid* from doing > something dumb by adding own CONFIG_XEN_BUILD_EXPERT which will depend > on EXPERT but default to n. That will prevent folks that typically > enable EXPERT from going on venturing to disable what is visible > unless they *really* want it. I can't think of a reason somebody would want this disabled - they already have enabled CONFIG_HYPERVISOR so obviously they want PV drivers. And if one really really wants the PV drivers disabled there is an boot line command to disable it all. > > Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 0:20 ` Luis R. Rodriguez 2015-02-17 0:25 ` Luis R. Rodriguez @ 2015-02-17 7:39 ` Juergen Gross 2015-02-17 20:12 ` Luis R. Rodriguez 2015-02-18 10:03 ` David Vrabel 1 sibling, 2 replies; 47+ messages in thread From: Juergen Gross @ 2015-02-17 7:39 UTC (permalink / raw) To: Luis R. Rodriguez, David Vrabel, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky On 02/17/2015 01:20 AM, Luis R. Rodriguez wrote: > On Thu, Feb 12, 2015 at 3:07 AM, David Vrabel <david.vrabel@citrix.com> wrote: >> On 12/02/15 06:03, Luis R. Rodriguez wrote: >>> From: "Luis R. Rodriguez" <mcgrof@suse.com> >>> >>> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 7:39 ` Juergen Gross @ 2015-02-17 20:12 ` Luis R. Rodriguez 2015-02-18 2:32 ` Luis R. Rodriguez 2015-02-18 10:03 ` David Vrabel 1 sibling, 1 reply; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-17 20:12 UTC (permalink / raw) To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, David Vrabel On Mon, Feb 16, 2015 at 11:39 PM, Juergen Gross <jgross@suse.com> wrote: > On 02/17/2015 01:20 AM, Luis R. Rodriguez wrote: >> >> On Thu, Feb 12, 2015 at 3:07 AM, David Vrabel <david.vrabel@citrix.com> >> wrote: >>> >>> On 12/02/15 06:03, Luis R. Rodriguez wrote: >>>> >>>> From: "Luis R. Rodriguez" <mcgrof@suse.com> >>>> >>>> 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. OK I'll roll in this change. >> 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. This was caused for a few reasons for this, firstly because HVC_XEN depends on XEN and also the entire file drivers/xen/Kconfig is wrapped with "if XEN" so obviously dropping in XEN_FRONTEND there will make it depend on XEN. This means we need to expose XEN_FRONTEND outside of the "if XEN", but likewise we also need to do the same for XEN_BUS_FRONTEND. So although we can test building front end drivers without CONFIG_XEN right now I'd prefer to not do this as it doesn't work in the first place right now and just doing these changes: * Make HVC_XEN select XEN * Take out both XEN_XENBUS_FRONTEND and XEN_FRONTEND from "if XEN" roll on the Kconfig file. We upkeep the "select XEN" on XEN_FRONTEND, but users will still be able to see XEN_FRONTEND even if XEN hasn't been selected at least. I'll test building all front end drivers with this but so far am running into issues with just building XEN_FRONTEND so it seems there are other things that we need to address. The issues seem to be related to the item 3) below. >> 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. OK I'll keep xen_memory_setup() and its requirements then only if XEN_PV is enabled but not XEN_PVH. As for the rest of enlighten.c and friends -- this is just collateral. What files should we just need for just XEN_PVHVM when XEN_PV and XEN_PVH are both disabled? Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 20:12 ` Luis R. Rodriguez @ 2015-02-18 2:32 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-18 2:32 UTC (permalink / raw) To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, Luis R. Rodriguez, David Vrabel On Tue, Feb 17, 2015 at 12:12 PM, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote: > OK I'll keep xen_memory_setup() and its requirements then only if > XEN_PV is enabled but not XEN_PVH. As for the rest of enlighten.c and > friends -- this is just collateral. What files should we just need for > just XEN_PVHVM when XEN_PV and XEN_PVH are both disabled? I see we need x86_hyper_xen_hvm, I also see init_hvm_pv_info() uses hypercall_page so that needs at least the hypercall page set up. That means arch/x86/xen/xen-head.S needs some love in terms of enablement when XEN_PVHVM is enabled but not XEN_PV or XEN_PVH, also enlighten.c, time.c needs the XEN_PVHVM stuff split out and some common stuff set out for both. That's what I'm up to at least. Let me know if this seems right. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-17 7:39 ` Juergen Gross 2015-02-17 20:12 ` Luis R. Rodriguez @ 2015-02-18 10:03 ` David Vrabel 2015-02-18 10:12 ` Juergen Gross 1 sibling, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-18 10:03 UTC (permalink / raw) To: Juergen Gross, Luis R. Rodriguez, David Vrabel, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky On 17/02/15 07:39, Juergen Gross wrote: > > 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. Can we limit this series to only Kconfig changes? I don't really like scope-creep in patch series. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 10:03 ` David Vrabel @ 2015-02-18 10:12 ` Juergen Gross 2015-02-18 19:55 ` Luis R. Rodriguez 2015-02-20 13:55 ` David Vrabel 0 siblings, 2 replies; 47+ messages in thread From: Juergen Gross @ 2015-02-18 10:12 UTC (permalink / raw) To: David Vrabel, Luis R. Rodriguez, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky On 02/18/2015 11:03 AM, David Vrabel wrote: > On 17/02/15 07:39, Juergen Gross wrote: >> >> 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. > > Can we limit this series to only Kconfig changes? I don't really like > scope-creep in patch series. Are you sure this is possible? XEN will be configured in more cases as today: this is the result of being able to build pv-drivers for hvm domains. BTW: it was you who wanted XEN_PVHVM to be implying XEN. So today the complete directory arch/x86/xen isn't built for non-pv kernels. Do you really want to change this? I don't think this is acceptable. Juergen ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 10:12 ` Juergen Gross @ 2015-02-18 19:55 ` Luis R. Rodriguez 2015-02-20 13:55 ` David Vrabel 1 sibling, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-18 19:55 UTC (permalink / raw) To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, David Vrabel On Wed, Feb 18, 2015 at 2:12 AM, Juergen Gross <jgross@suse.com> wrote: > On 02/18/2015 11:03 AM, David Vrabel wrote: >> >> On 17/02/15 07:39, Juergen Gross wrote: >>> >>> >>> 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. >> >> >> Can we limit this series to only Kconfig changes? I don't really like >> scope-creep in patch series. > > > Are you sure this is possible? I do not think so. We can only do the smaller cleanups, the frontend stuff and the backend stuff however will remain constrained due to existing relationships being assumed under the big CONFIG_XEN. More details on this below. > XEN will be configured in more cases as > today: this is the result of being able to build pv-drivers for hvm > domains. > > BTW: it was you who wanted XEN_PVHVM to be implying XEN. > > So today the complete directory arch/x86/xen isn't built for non-pv > kernels. Do you really want to change this? I don't think this is > acceptable. A simple issue example to think about: The arch/x86/kernel/head_[64|32].S file includes arch/x86/xen/xen-head.S. Now this file is #ifdef's over CONFIG_XEN. As per our agreed upon changes the frontend drivers depend on CONFIG_XEN but without CONFIG_XEN_PV and CONFIG_XEN_PVH this won't build correctly after the other changes we've discussed. What I can do, if folks like, is to pursue the split only as expected RFCs only as evaluation just to get a better idea of what changes are really required for what we discussed, I am not sure the required code changes had been scoped out before. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-18 10:12 ` Juergen Gross 2015-02-18 19:55 ` Luis R. Rodriguez @ 2015-02-20 13:55 ` David Vrabel 2015-02-20 16:04 ` Luis R. Rodriguez 1 sibling, 1 reply; 47+ messages in thread From: David Vrabel @ 2015-02-20 13:55 UTC (permalink / raw) To: Juergen Gross, David Vrabel, Luis R. Rodriguez, Konrad Rzeszutek Wilk Cc: xen-devel, Boris Ostrovsky On 18/02/15 10:12, Juergen Gross wrote: > On 02/18/2015 11:03 AM, David Vrabel wrote: >> On 17/02/15 07:39, Juergen Gross wrote: >>> >>> 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. >> >> Can we limit this series to only Kconfig changes? I don't really like >> scope-creep in patch series. > > Are you sure this is possible? XEN will be configured in more cases as > today: this is the result of being able to build pv-drivers for hvm > domains. I mean there should be the minimum set of changes need for the Kconfig refactor to work, but any additional improvements to the build etc. should be via a different series. David ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [RFC v1 0/8] xen: kconfig changes 2015-02-20 13:55 ` David Vrabel @ 2015-02-20 16:04 ` Luis R. Rodriguez 0 siblings, 0 replies; 47+ messages in thread From: Luis R. Rodriguez @ 2015-02-20 16:04 UTC (permalink / raw) To: David Vrabel; +Cc: Juergen Gross, xen-devel, Boris Ostrovsky On Fri, Feb 20, 2015 at 5:55 AM, David Vrabel <david.vrabel@citrix.com> wrote: > On 18/02/15 10:12, Juergen Gross wrote: >> On 02/18/2015 11:03 AM, David Vrabel wrote: >>> On 17/02/15 07:39, Juergen Gross wrote: >>>> >>>> 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. >>> >>> Can we limit this series to only Kconfig changes? I don't really like >>> scope-creep in patch series. >> >> Are you sure this is possible? XEN will be configured in more cases as >> today: this is the result of being able to build pv-drivers for hvm >> domains. > > I mean there should be the minimum set of changes need for the Kconfig > refactor to work, but any additional improvements to the build etc. > should be via a different series. OK I can break down things into two series, one which deals with only Kconfig stuff first, and if that goes well a second one which starts to address some required code changes. Would that be a good step forward? Feedback on the other threads would also be useful. Luis ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2015-02-26 1:08 UTC | newest] Thread overview: 47+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-02-12 6:03 [RFC v1 0/8] xen: kconfig changes Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0 Luis R. Rodriguez 2015-02-12 9:55 ` David Vrabel 2015-02-12 20:44 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU Luis R. Rodriguez 2015-02-12 9:56 ` David Vrabel 2015-02-12 20:45 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them Luis R. Rodriguez 2015-02-12 11:01 ` David Vrabel 2015-02-12 20:48 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM Luis R. Rodriguez 2015-02-25 15:44 ` Stefano Stabellini 2015-02-26 0:36 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 5/8] xen: x86: add XEN_PV Luis R. Rodriguez 2015-02-12 11:03 ` David Vrabel 2015-02-13 2:52 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez 2015-02-25 15:45 ` Stefano Stabellini 2015-02-26 0:54 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0 Luis R. Rodriguez 2015-02-12 11:05 ` David Vrabel 2015-02-12 20:54 ` Luis R. Rodriguez 2015-02-25 14:17 ` Stefano Stabellini 2015-02-25 14:30 ` David Vrabel 2015-02-25 14:33 ` Stefano Stabellini 2015-02-26 1:08 ` Luis R. Rodriguez 2015-02-12 6:03 ` [RFC v1 8/8] xen: x86: remove CONFIG_XEN dependency PARAVIRT and PARAVIRT_CLOCK Luis R. Rodriguez 2015-02-12 11:07 ` [RFC v1 0/8] xen: kconfig changes David Vrabel 2015-02-17 0:20 ` Luis R. Rodriguez 2015-02-17 0:25 ` Luis R. Rodriguez 2015-02-17 7:26 ` Juergen Gross 2015-02-17 19:31 ` Luis R. Rodriguez 2015-02-18 18:11 ` Konrad Rzeszutek Wilk 2015-02-18 20:01 ` Luis R. Rodriguez 2015-02-18 20:20 ` Konrad Rzeszutek Wilk 2015-02-18 21:11 ` Luis R. Rodriguez 2015-02-18 21:24 ` Konrad Rzeszutek Wilk 2015-02-18 21:31 ` Luis R. Rodriguez 2015-02-18 21:54 ` Konrad Rzeszutek Wilk 2015-02-17 7:39 ` Juergen Gross 2015-02-17 20:12 ` Luis R. Rodriguez 2015-02-18 2:32 ` Luis R. Rodriguez 2015-02-18 10:03 ` David Vrabel 2015-02-18 10:12 ` Juergen Gross 2015-02-18 19:55 ` Luis R. Rodriguez 2015-02-20 13:55 ` David Vrabel 2015-02-20 16:04 ` Luis R. Rodriguez
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.