An error occurred fetching the project authors.
- 06 Jul, 2016 1 commit
-
-
Shannon Zhao authored
Add a bus_notifier for platform bus device in order to map the device mmio regions when DOM0 booting with ACPI. Signed-off-by:
Shannon Zhao <shannon.zhao@linaro.org> Acked-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Tested-by:
Julien Grall <julien.grall@arm.com>
-
- 24 May, 2016 1 commit
-
-
Arnd Bergmann authored
The XEN UEFI code has become available on the ARM architecture recently, but now causes a link-time warning: ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail This seems harmless, because the efi code only uses 2-byte characters when interacting with EFI, so we don't pass on those strings to elsewhere in the system, and we just need to silence the warning. It is not clear to me whether we actually need to build the file with the -fshort-wchar flag, but if we do, then we should also pass --no-wchar-size-warning to the linker, to avoid the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services")
-
- 21 Dec, 2015 1 commit
-
-
Stefano Stabellini authored
Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 23 Oct, 2015 1 commit
-
-
Stefano Stabellini authored
Build cpu_hotplug for ARM and ARM64 guests. Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an empty implementation on ARM and ARM64. On x86 just call arch_(un)register_cpu as we are already doing. Initialize cpu_hotplug on ARM. Signed-off-by:
Julien Grall <julien.grall@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com>
-
- 26 Mar, 2015 1 commit
-
-
Hanjun Guo authored
When ACPI is enabled on ARM64, XEN ACPI will also compiled into the kernel, but XEN ACPI is x86 dependent, so introduce CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is functional on ARM64. CC: Julien Grall <julien.grall@linaro.org> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com> CC: David Vrabel <david.vrabel@citrix.com> Acked-by:
Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
- 16 Mar, 2015 1 commit
-
-
David Vrabel authored
Auto-translated physmap guests (arm, arm64 and x86 PVHVM/PVH) map and unmap foreign GFNs using the same method (updating the physmap). Unify the two arm and x86 implementations into one commont one. Note that on arm and arm64, the correct error code will be returned (instead of always -EFAULT) and map/unmap failure warnings are no longer printed. These changes are required if the foreign domain is paging (-ENOENT failures are expected and must be propagated up to the caller). Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Reviewed-by:
-
- 23 Feb, 2015 1 commit
-
-
David Vrabel authored
Hypercalls submitted by user space tools via the privcmd driver can take a long time (potentially many 10s of seconds) if the hypercall has many sub-operations. A fully preemptible kernel may deschedule such as task in any upcall called from a hypercall continuation. However, in a kernel with voluntary or no preemption, hypercall continuations in Xen allow event handlers to be run but the task issuing the hypercall will not be descheduled until the hypercall is complete and the ioctl returns to user space. These long running tasks may also trigger the kernel's soft lockup detection. Add xen_preemptible_hcall_begin() and xen_preemptible_hcall_end() to bracket hypercalls that may be preempted. Use these in the privcmd driver. When returning from an upcall, call xen_maybe_preempt_hcall() which adds a schedule point if if the current task was within a preemptible hypercall. Since _cond_resched() can move the task to a different CPU, clear and set xen_in_preemptible_hcall around the call. Signed-off-by:
-
- 23 Sep, 2014 1 commit
-
-
Juergen Gross authored
Introduces the Xen pvSCSI backend. With pvSCSI it is possible for a Xen domU to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands are passed to the pvSCSI backend in a driver domain (usually Dom0) which is owner of the physical device. This allows e.g. to use SCSI tape drives in a Xen domU. The code is taken from the pvSCSI implementation in Xen done by Fujitsu based on Linux kernel 2.6.18. Changes from the original version are: - port to upstream kernel - put all code in just one source file - adapt to Linux style guide - use target core infrastructure instead doing pure pass-through - enable module unloading - support SG-list in grant page(s) - support task abort - remove redundant struct backend - allocate resources dynamically - correct minor error in scsiback_fast_flush_area - free allocated resources in case of error during I/O preparation - remove CDB emulation, now handled by target core infrastructure Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
- 18 Jul, 2014 1 commit
-
-
Daniel Kiper authored
This patch enables EFI usage under Xen dom0. Standard EFI Linux Kernel infrastructure cannot be used because it requires direct access to EFI data and code. However, in dom0 case it is not possible because above mentioned EFI stuff is fully owned and controlled by Xen hypervisor. In this case all calls from dom0 to EFI must be requested via special hypercall which in turn executes relevant EFI code in behalf of dom0. When dom0 kernel boots it checks for EFI availability on a machine. If it is detected then artificial EFI system table is filled. Native EFI callas are replaced by functions which mimics them by calling relevant hypercall. Later pointer to EFI system table is passed to standard EFI machinery and it continues EFI subsystem initialization taking into account that there is no direct access to EFI boot services, runtime, tables, structures, etc. After that system runs as usual. This patch is based on Jan Beulich and Tang Liang work. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Tang Liang <liang.tang@oracle.com> Signed-off-by:
Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by:
Matt Fleming <matt.fleming@intel.com>
-
- 11 Feb, 2014 1 commit
-
-
Paul Bolle authored
Commit d52eefb4 ("ia64/xen: Remove Xen support for ia64") removed the Kconfig symbol XEN_XENCOMM. But it didn't remove the code depending on that symbol. Remove that code now. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Acked-by:
-
- 06 Jan, 2014 1 commit
-
-
David Vrabel authored
events.c will be split into multiple files so move it into its own directory. Signed-off-by:
-
- 29 Jul, 2013 2 commits
-
-
Julien Grall authored
Enable lifecyle management (reboot, shutdown...) from the toolstack for ARM guests. Signed-off-by:
Julien Grall <julien.grall@linaro.org> Signed-off-by:
-
Julien Grall authored
On ARM64, when CONFIG_XEN=y, the compilation will fail because CPU hotplug is not yet supported with XEN. For now, disable it. Signed-off-by:
Mark Rutland <mark.rutland@arm.com>
-
- 20 Feb, 2013 3 commits
-
-
Liu Jinsong authored
This patch implement real Xen ACPI cpu hotplug driver as module. When loaded, it replaces Xen stub driver. For booting existed cpus, the driver enumerates them. For hotadded cpus, which added at runtime and notify OS via device or container event, the driver is invoked to add them, parsing cpu information, hypercalling to Xen hypervisor to add them, and finally setting up new /sys interface for them. Signed-off-by:
Liu Jinsong <jinsong.liu@intel.com> Signed-off-by:
-
Liu Jinsong authored
This patch implements real Xen acpi memory hotplug driver as module. When loaded, it replaces Xen stub driver. When an acpi memory device hotadd event occurs, it notifies OS and invokes notification callback, adding related memory device and parsing memory information, finally hypercall to xen hypervisor to add memory. Signed-off-by:
-
Liu Jinsong authored
This patch create a file (xen-stub.c) for Xen stub drivers. Xen stub drivers are used to reserve space for Xen drivers, i.e. memory hotplug and cpu hotplug, and to block native drivers loaded, so that real Xen drivers can be modular and loaded on demand. This patch is specific for Xen memory hotplug (other Xen logic can add stub drivers on their own). The xen stub driver will occupied earlier via subsys_initcall (than native memory hotplug driver via module_init and so blocking native). Later real Xen memory hotplug logic will unregister the stub driver and register itself to take effect on demand. Signed-off-by:
-
- 29 Nov, 2012 1 commit
-
-
Ian Campbell authored
The code is now in a state where can just enable it. Drop the *_xenballloned_pages duplicates since these are now supplied by the balloon code. Signed-off-by:
-
- 26 Nov, 2012 1 commit
-
-
Liu, Jinsong authored
PAD is acpi Processor Aggregator Device which provides a control point that enables the platform to perform specific processor configuration and control that applies to all processors in the platform. This patch is to implement Xen acpi pad logic. When running under Xen virt platform, native pad driver would not work. Instead Xen pad driver, a self-contained and thin logic level, would take over acpi pad logic. When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object to get the expected idle cpu number, and then hypercall to hypervisor. Xen hypervisor would then do the rest work, say, core parking, to idle specific number of cpus on its own policy. Signed-off-by:
-
- 07 Nov, 2012 1 commit
-
-
Konrad Rzeszutek Wilk authored
As there is no need for it (the fallback code is for older hypervisors and they only run under x86), and also b/c we get: drivers/xen/fallback.c: In function 'xen_event_channel_op_compat': drivers/xen/fallback.c:10:19: error: storage size of 'op' isn't known drivers/xen/fallback.c:15:2: error: implicit declaration of function '_hypercall1' [-Werror=implicit-function-declaration] drivers/xen/fallback.c:15:19: error: expected expression before 'int' drivers/xen/fallback.c:18:7: error: 'EVTCHNOP_close' undeclared (first use in this function) drivers/xen/fallback.c:18:7: note: each undeclared identifier is reported only once for each function it appears in .. and more [v1: Moved the enablement to be covered by CONFIG_X86 per Ian's suggestion] Signed-off-by:
-
- 04 Nov, 2012 1 commit
-
-
Jan Beulich authored
While copying the argument structures in HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local variable is sufficiently safe even if the actual structure is smaller than the container one, copying back eventual output values the same way isn't: This may collide with on-stack variables (particularly "rc") which may change between the first and second memcpy() (i.e. the second memcpy() could discard that change). Move the fallback code into out-of-line functions, and handle all of the operations known by this old a hypervisor individually: Some don't require copying back anything at all, and for the rest use the individual argument structures' sizes rather than the container's. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 02 Oct, 2012 1 commit
-
-
Stefano Stabellini authored
We need to add $(dom0-y) to obj-$(CONFIG_XEN_DOM0) after dom0-y is defined otherwise we end up adding nothing. Signed-off-by:
-
- 18 Sep, 2012 1 commit
-
-
Jan Beulich authored
Just like for the in-tree early console debug port driver, the hypervisor - when using a debug port based console - also needs to be told about controller resets, so it can suppress using and then re-initialize the debug port accordingly. Other than the in-tree driver, the hypervisor driver actually cares about doing this only for the device where the debug is port actually in use, i.e. it needs to be told the coordinates of the device being reset (quite obviously, leveraging the addition done for that would likely benefit the in-tree driver too). Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 Sep, 2012 1 commit
-
-
Stefano Stabellini authored
Changes in v4: - compile pcpu only on x86; - use "+=" instead of ":=" for dom0- targets. Changes in v2: - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI. Signed-off-by:
-
- 19 Jul, 2012 2 commits
-
-
Liu, Jinsong authored
This patch provide Xen physical cpus online/offline sys interface. User can use it for their own purpose, like power saving: by offlining some cpus when light workload it save power greatly. Its basic workflow is, user online/offline cpu via sys interface, then hypercall xen to implement, after done xen inject virq back to dom0, and then dom0 sync cpu status. Signed-off-by:
Jiang, Yunhong <yunhong.jiang@intel.com> Signed-off-by:
-
Liu, Jinsong authored
When MCA error occurs, it would be handled by Xen hypervisor first, and then the error information would be sent to initial domain for logging. This patch gets error information from Xen hypervisor and convert Xen format error into Linux format mcelog. This logic is basically self-contained, not touching other kernel components. By using tools like mcelog tool users could read specific error information, like what they did under native Linux. To test follow directions outlined in Documentation/acpi/apei/einj.txt Acked-and-tested-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
Ke, Liping <liping.ke@intel.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
- 07 May, 2012 1 commit
-
-
Konrad Rzeszutek Wilk authored
Provide the registration callback to call in the Xen's ACPI sleep functionality. This means that during S3/S5 we make a hypercall XENPF_enter_acpi_sleep with the proper PM1A/PM1B registers. Based of Ke Yu's <ke.yu@intel.com> initial idea. [ From http://xenbits.xensource.com/linux-2.6.18-xen.hg change c68699484a65 ] [v1: Added Copyright and license] [v2: Added check if PM1A/B the 16-bits MSB contain something. The spec only uses 16-bits but might have more in future] Signed-off-by:
-
- 14 Mar, 2012 1 commit
-
-
Konrad Rzeszutek Wilk authored
This driver solves three problems: 1). Parse and upload ACPI0007 (or PROCESSOR_TYPE) information to the hypervisor - aka P-states (cpufreq data). 2). Upload the the Cx state information (cpuidle data). 3). Inhibit CPU frequency scaling drivers from loading. The reason for wanting to solve 1) and 2) is such that the Xen hypervisor is the only one that knows the CPU usage of different guests and can make the proper decision of when to put CPUs and packages in proper states. Unfortunately the hypervisor has no support to parse ACPI DSDT tables, hence it needs help from the initial domain to provide this information. The reason for 3) is that we do not want the initial domain to change P-states while the hypervisor is doing it as well - it causes rather some funny cases of P-states transitions. For this to work, the driver parses the Power Management data and uploads said information to the Xen hypervisor. It also calls acpi_processor_notify_smm() to inhibit the other CPU frequency scaling drivers from being loaded. Everything revolves around the 'struct acpi_processor' structure which gets updated during the bootup cycle in different stages. At the startup, when the ACPI parser starts, the C-state information is processed (processor_idle) and saved in said structure as 'power' element. Later on, the CPU frequency scaling driver (powernow-k8 or acpi_cpufreq), would call the the acpi_processor_* (processor_perflib functions) to parse P-states information and populate in the said structure the 'performance' element. Since we do not want the CPU frequency scaling drivers from loading we have to call the acpi_processor_* functions to parse the P-states and call "acpi_processor_notify_smm" to stop them from loading. There is also one oddity in this driver which is that under Xen, the physical online CPU count can be different from the virtual online CPU count. Meaning that the macros 'for_[online|possible]_cpu' would process only up to virtual online CPU count. We on the other hand want to process the full amount of physical CPUs. For that, the driver checks if the ACPI IDs count is different from the APIC ID count - which can happen if the user choose to use dom0_max_vcpu argument. In such a case a backup of the PM structure is used and uploaded to the hypervisor. [v1-v2: Initial RFC implementations that were posted] [v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>] [v4: Added vCPU != pCPU support - aka dom0_max_vcpus support] [v5: Cleaned up the driver, fix bug under Athlon XP] [v6: Changed the driver to a CPU frequency governor] [v7: Jan Beulich <jbeulich@suse.com> suggestion to make it a cpufreq scaling driver made me rework it as driver that inhibits cpufreq scaling driver] [v8: Per Jan's review comments, fixed up the driver] [v9: Allow to continue even if acpi_processor_preregister_perf.. fails] Signed-off-by:
-
- 16 Dec, 2011 1 commit
-
-
Bastian Blank authored
Access to arbitrary hypercalls is currently provided via xenfs. This adds a standard character device to handle this. The support in xenfs remains for backward compatibility and uses the device driver code. Signed-off-by:
Bastian Blank <waldi@debian.org> Acked-by:
-
- 29 Sep, 2011 1 commit
-
-
Stefano Stabellini authored
Xen PVHVM needs xen-platform-pci, on the other hand xen-platform-pci is useless in any other cases. Therefore remove the XEN_PLATFORM_PCI config option and compile xen-platform-pci built-in if XEN_PVHVM is selected. Changes to v1: - remove xen-platform-pci.o and just use platform-pci.o since it is not externally visible anymore. Signed-off-by:
-
- 20 Jul, 2011 1 commit
-
-
Konrad Rzeszutek Wilk authored
This is the host side counterpart to the frontend driver in drivers/pci/xen-pcifront.c. The PV protocol is also implemented by frontend drivers in other OSes too, such as the BSDs. The PV protocol is rather simple. There is page shared with the guest, which has the 'struct xen_pci_sharedinfo' embossed in it. The backend has a thread that is kicked every-time the structure is changed and based on the operation field it performs specific tasks: XEN_PCI_OP_conf_[read|write]: Read/Write 0xCF8/0xCFC filtered data. (conf_space*.c) Based on which field is probed, we either enable/disable the PCI device, change power state, read VPD, etc. The major goal of this call is to provide a Physical IRQ (PIRQ) to the guest. The PIRQ is Xen hypervisor global IRQ value irrespective of the IRQ is tied in to the IO-APIC, or is a vector. For GSI type interrupts, the PIRQ==GSI holds. For MSI/MSI-X the PIRQ value != Linux IRQ number (thought PIRQ==vector). Please note, that with Xen, all interrupts (except those level shared ones) are injected directly to the guest - there is no host interaction. XEN_PCI_OP_[enable|disable]_msi[|x] (pciback_ops.c) Enables/disables the MSI/MSI-X capability of the device. These operations setup the MSI/MSI-X vectors for the guest and pass them to the frontend. When the device is activated, the interrupts are directly injected in the guest without involving the host. XEN_PCI_OP_aer_[detected|resume|mmio|slotreset]: In case of failure, perform the appropriate AER commands on the guest. Right now that is a cop-out - we just kill the guest. Besides implementing those commands, it can also - hide a PCI device from the host. When booting up, the user can specify xen-pciback.hide=(1:0:0)(BDF..) so that host does not try to use the device. The driver was lifted from linux-2.6.18.hg tree and fixed up so that it could compile under v3.0. Per suggestion from Jesse Barnes moved the driver to drivers/xen/xen-pciback. Signed-off-by:
-
- 08 Jul, 2011 1 commit
-
-
Dan Magenheimer authored
This patch introduces two in-kernel drivers for Xen transcendent memory ("tmem") functionality that complement cleancache and frontswap. Both use control theory to dynamically adjust and optimize memory utilization. Selfballooning controls the in-kernel Xen balloon driver, targeting a goal value (vm_committed_as), thus pushing less frequently used clean page cache pages (through the cleancache code) into Xen tmem where Xen can balance needs across all VMs residing on the physical machine. Frontswap-selfshrinking controls the number of pages in frontswap, driving it towards zero (effectively doing a partial swapoff) when in-kernel memory pressure subsides, freeing up RAM for other VMs. More detail is provided in the header comment of xen-selfballooning.c. Signed-off-by:Dan Magenheimer <dan.magenheimer@oracle.com> [v8: konrad.wilk@oracle.com: set default enablement depending on frontswap] [v7: konrad.wilk@oracle.com: fix capitalization and punctuation in comments] [v6: fix frontswap-selfshrinking initialization] [v6: konrad.wilk@oracle.com: fix init pr_infos; add comments about swap] [v5: konrad.wilk@oracle.com: add NULL to attr list; move inits up to decls] [v4: dkiper@net-space.pl: use strict_strtoul plus a few syntactic nits] [v3: konrad.wilk@oracle.com: fix potential divides-by-zero] [v3: konrad.wilk@oracle.com: add many more comments, fix nits] [v2: rebased to linux-3.0-rc1] [v2: Ian.Campbell@citrix.com: reorganize as new file (xen-selfballoon.c)] [v2: dkiper@net-space.pl: proper access to vm_committed_as] [v2: dkiper@net-space.pl: accounting fixes] Cc: Jan Beulich <JBeulich@novell.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: <xen-devel@lists.xensource.com>
-
- 17 Jun, 2011 1 commit
-
-
Dan Magenheimer authored
Provide the shim code for frontswap for Xen tmem even if the frontswap patchset is not present yet. (The egg is before the chicken.) Signed-off-by:
-
- 26 May, 2011 1 commit
-
-
Dan Magenheimer authored
This patch provides a shim between the kernel-internal cleancache API (see Documentation/mm/cleancache.txt) and the Xen Transcendent Memory ABI (see http://oss.oracle.com/projects/tmem). Xen tmem provides "hypervisor RAM" as an ephemeral page-oriented pseudo-RAM store for cleancache pages, shared cleancache pages, and frontswap pages. Tmem provides enterprise-quality concurrency, full save/restore and live migration support, compression and deduplication. A presentation showing up to 8% faster performance and up to 52% reduction in sectors read on a kernel compile workload, despite aggressive in-kernel page reclamation ("self-ballooning") can be found at: http://oss.oracle.com/projects/tmem/dist/documentation/presentations/TranscendentMemoryXenSummit2010.pdfSigned-off-by:
Jeremy Fitzhardinge <jeremy@goop.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Nick Piggin <npiggin@kernel.dk> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Rik Van Riel <riel@redhat.com> Cc: Jan Beulich <JBeulich@novell.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Andreas Dilger <adilger@sun.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <joel.becker@oracle.com> Cc: Nitin Gupta <ngupta@vflare.org>
-
- 12 May, 2011 1 commit
-
-
Ian Campbell authored
Various merges over time have led to rather a mish-mash of indentation. Signed-off-by:
-
- 18 Apr, 2011 1 commit
-
-
Konrad Rzeszutek Wilk authored
.. and modify the Makefile and Kconfig files appropriately. Signed-off-by:
-
- 14 Apr, 2011 1 commit
-
-
Konrad Rzeszutek Wilk authored
Signed-off-by:
-
- 16 Mar, 2011 1 commit
-
-
Daniel De Graaf authored
The basic functionality of ballooning pages is useful for Xen drivers in general. Rather than require a dependency on the balloon module, split the functionality that is reused into the core. The balloon module is still required to follow ballooning requests from xenstore or to view balloon statistics in sysfs. Acked-by:
Daniel De Graaf <dgdegra@tycho.nsa.gov> Signed-off-by:
-
- 14 Feb, 2011 1 commit
-
-
Daniel De Graaf authored
This allows a userspace application to allocate a shared page for implementing inter-domain communication or device drivers. These shared pages can be mapped using the gntdev device or by the kernel in another domain. Signed-off-by:
-
- 12 Jan, 2011 1 commit
-
-
Ian Campbell authored
platform-pci is rather generic for a modular distro style kernel. Signed-off-by:
-
- 11 Jan, 2011 1 commit
-
-
Gerd Hoffmann authored
The gntdev driver allows usermode to map granted pages from other domains. This is typically used to implement a Xen backend driver in user mode. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
