aboutsummaryrefslogtreecommitdiff
path: root/include/xen/interface/physdev.h
AgeCommit message (Collapse)Author
2013-11-08xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved for MCFG areas.Konrad Rzeszutek Wilk
The PCI MMCONFIG area is usually reserved via the E820 so the Xen hypervisor is aware of these regions. But they can also be enumerated in the ACPI DSDT which means the hypervisor won't know of them until the initial domain informs it of via PHYSDEVOP_pci_mmcfg_reserved. This is what this patch does for all of the MCFG regions that the initial domain is aware of (E820 enumerated and ACPI). Reported-by: Santosh Jodh <Santosh.Jodh@citrix.com> CC: Jan Beulich <JBeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> CC: David Vrabel <david.vrabel@citrix.com> CC: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [v1: Redid it a bit] [v2: Dropped the P2M 1-1 setting] [v3: Check for Xen in-case we are running under baremetal] [v4: Wrap with CONFIG_PCI_MMCONFIG]
2013-03-22xen-pciback: notify hypervisor about devices intended to be assigned to guestsJan Beulich
For MSI-X capable devices the hypervisor wants to write protect the MSI-X table and PBA, yet it can't assume that resources have been assigned to their final values at device enumeration time. Thus have pciback do that notification, as having the device controlled by it is a prerequisite to assigning the device to guests anyway. This is the kernel part of hypervisor side commit 4245d33 ("x86/MSI: add mechanism to fully protect MSI-X table from PV guest accesses") on the master branch of git://xenbits.xen.org/xen.git. CC: stable@vger.kernel.org Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-10-07Merge tag 'stable/for-linus-3.7-arm-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull ADM Xen support from Konrad Rzeszutek Wilk: Features: * Allow a Linux guest to boot as initial domain and as normal guests on Xen on ARM (specifically ARMv7 with virtualized extensions). PV console, block and network frontend/backends are working. Bug-fixes: * Fix compile linux-next fallout. * Fix PVHVM bootup crashing. The Xen-unstable hypervisor (so will be 4.3 in a ~6 months), supports ARMv7 platforms. The goal in implementing this architecture is to exploit the hardware as much as possible. That means use as little as possible of PV operations (so no PV MMU) - and use existing PV drivers for I/Os (network, block, console, etc). This is similar to how PVHVM guests operate in X86 platform nowadays - except that on ARM there is no need for QEMU. The end result is that we share a lot of the generic Xen drivers and infrastructure. Details on how to compile/boot/etc are available at this Wiki: http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions and this blog has links to a technical discussion/presentations on the overall architecture: http://blog.xen.org/index.php/2012/09/21/xensummit-sessions-new-pvh-virtualisation-mode-for-arm-cortex-a15arm-servers-and-x86/ * tag 'stable/for-linus-3.7-arm-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: (21 commits) xen/xen_initial_domain: check that xen_start_info is initialized xen: mark xen_init_IRQ __init xen/Makefile: fix dom-y build arm: introduce a DTS for Xen unprivileged virtual machines MAINTAINERS: add myself as Xen ARM maintainer xen/arm: compile netback xen/arm: compile blkfront and blkback xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen/arm: receive Xen events on ARM xen/arm: initialize grant_table on ARM xen/arm: get privilege status xen/arm: introduce CONFIG_XEN on ARM xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM xen/arm: Introduce xen_ulong_t for unsigned long xen/arm: Xen detection and shared_info page mapping docs: Xen ARM DT bindings xen/arm: empty implementation of grant_table arch specific functions xen/arm: sync_bitops xen/arm: page.h definitions xen/arm: hypercalls ...
2012-09-18USB EHCI/Xen: propagate controller reset information to hypervisorJan Beulich
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: Jan Beulich <jbeulich@suse.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-14xen/arm: Introduce xen_ulong_t for unsigned longStefano Stabellini
All the original Xen headers have xen_ulong_t as unsigned long type, however when they have been imported in Linux, xen_ulong_t has been replaced with unsigned long. That might work for x86 and ia64 but it does not for arm. Bring back xen_ulong_t and let each architecture define xen_ulong_t as they see fit. Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit. Changes in v3: - remove the incorrect changes to multicall_entry; - remove the change to apic_physbase. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-03-20xen: support pirq_eoi_mapStefano Stabellini
The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to be EOI'd without having to issue an hypercall every time. We use PHYSDEVOP_pirq_eoi_gmfn_v2 to map the bitmap, then if we succeed we use pirq_eoi_map to check whether pirqs need eoi. Changes in v3: - explicitly use PHYSDEVOP_pirq_eoi_gmfn_v2 rather than PHYSDEVOP_pirq_eoi_gmfn; - introduce pirq_check_eoi_map, a function to check if a pirq needs an eoi using the map; -rename pirq_needs_eoi into pirq_needs_eoi_flag; - introduce a function pointer called pirq_needs_eoi that is going to be set to the right implementation depending on the availability of PHYSDEVOP_pirq_eoi_gmfn_v2. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-01-12xen: Utilize the restore_msi_irqs hook.Tang Liang
to make a hypercall to restore the vectors in the MSI/MSI-X configuration space. Signed-off-by: Tang Liang <liang.tang@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-09-22xen/pci: support multi-segment systemsJan Beulich
Now that the hypercall interface changes are in -unstable, make the kernel side code not ignore the segment (aka domain) number anymore (which results in pretty odd behavior on such systems). Rather, if only the old interfaces are available, don't call them for devices on non-zero segments at all. Signed-off-by: Jan Beulich <jbeulich@suse.com> [v1: Edited git description] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2010-12-02xen: use PHYSDEVOP_get_free_pirq to implement find_unbound_pirqStefano Stabellini
Use the new hypercall PHYSDEVOP_get_free_pirq to ask Xen to allocate a pirq. Remove the unsupported PHYSDEVOP_get_nr_pirqs hypercall to get the amount of pirq available. This fixes find_unbound_pirq that otherwise would return a number starting from nr_irqs that might very well be out of range in Xen. The symptom of this bug is that when you passthrough an MSI capable pci device to a PV on HVM guest, Linux would fail to enable MSIs on the device. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2010-10-27xen: register xen pci notifierWeidong Han
Register a pci notifier to add (or remove) pci devices to Xen via hypercalls. Xen needs to know the pci devices present in the system to handle pci passthrough and even MSI remapping in the initial domain. Signed-off-by: Weidong Han <weidong.han@intel.com> Signed-off-by: Qing He <qing.he@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2010-10-22xen: remap GSIs as pirqs when running as initial domainJeremy Fitzhardinge
Implement xen_register_gsi to setup the correct triggering and polarity properties of a gsi. Implement xen_register_pirq to register a particular gsi as pirq and receive interrupts as events. Call xen_setup_pirqs to register all the legacy ISA irqs as pirqs. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2010-10-22xen: implement xen_hvm_register_pirqStefano Stabellini
xen_hvm_register_pirq allows the kernel to map a GSI into a Xen pirq and receive the interrupt as an event channel from that point on. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2010-10-22xen: get the maximum number of pirqs from xenStefano Stabellini
Use PHYSDEVOP_get_nr_pirqs to get the maximum number of pirqs from xen. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2007-07-18xen: Add Xen interface header filesJeremy Fitzhardinge
Add Xen interface header files. These are taken fairly directly from the Xen tree, but somewhat rearranged to suit the kernel's conventions. Define macros and inline functions for doing hypercalls into the hypervisor. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Ian Pratt <ian.pratt@xensource.com> Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk> Signed-off-by: Chris Wright <chrisw@sous-sol.org>