- 11 May, 2017 2 commits
-
-
Juergen Gross authored
When booted as pv-guest the p2m list presented by the Xen is already mapped to virtual addresses. In dom0 case the hypervisor might make use of 2M- or 1G-pages for this mapping. Unfortunately while being properly aligned in virtual and machine address space, those pages might not be aligned properly in guest physical address space. So when trying to obtain the guest physical address of such a page pud_pfn() and pmd_pfn() must be avoided as those will mask away guest physical address bits not being zero in this special case. Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
-
Juergen Gross authored
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem. The proper solution is to never set the bit in case of Xen. Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 05 May, 2017 2 commits
-
-
Boris Ostrovsky authored
Routines that are set by xen_init_time_ops() use shared_info's pvclock_vcpu_time_info area. This area is not properly available until shared_info is mapped in xen_setup_shared_info(). This became especially problematic due to commit dd759d93 ("x86/timers: Add simple udelay calibration") where we end up reading tsc_to_system_mul from xen_dummy_shared_info (i.e. getting zero value) and then trying to divide by it in pvclock_tsc_khz(). Signed-off-by:
-
Juergen Gross authored
Commit 690b7f10b4f9f ("x86/xen: use capabilities instead of fake cpuid values for xsave") introduced a regression as it tried to make use of the fixup feature before it being available. Fall back to the old variant testing via cpuid(). Signed-off-by:
-
- 03 May, 2017 1 commit
-
-
Boris Ostrovsky authored
Commit 84d582d2 ("xen: Revert commits da72ff5b and 72a9b186") defined xen_have_vector_callback in enlighten_hvm.c. Since guest-type-neutral code refers to this variable this causes build failures when CONFIG_XEN_PVHVM is not defined. Moving xen_have_vector_callback definition to enlighten.c resolves this issue. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
-
- 02 May, 2017 35 commits
-
-
Julien Grall authored
When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack trace [1]. This is happening because when EFI runtimes are enabled, the reset code (see machine_restart) will first try to use EFI restart method. However, the EFI restart code is expecting the reset_system callback to be always set. This is not the case for Xen and will lead to crash. The EFI restart helper is used in multiple places and some of them don't not have fallback (see machine_power_off). So implement reset_system callback as a call to xen_reboot when using EFI Xen. [ 36.999270] reboot: Restarting system [ 37.002921] Internal error: Attempting to execute userspace memory: 86000004 [#1] PREEMPT SMP [ 37.011460] Modules linked in: [ 37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.11.0-rc1-00003-g1e248b60a39b-dirty #506 [ 37.023903] Hardware name: (null) (DT) [ 37.027734] task: ffff800902068000 task.stack: ffff800902064000 [ 37.033739] PC is at 0x0 [ 37.036359] LR is at efi_reboot+0x94/0xd0 [ 37.040438] pc : [<0000000000000000>] lr : [<ffff00000880f2c4>] pstate: 404001c5 [ 37.047920] sp : ffff800902067cf0 [ 37.051314] x29: ffff800902067cf0 x28: ffff800902068000 [ 37.056709] x27: ffff000008992000 x26: 000000000000008e [ 37.062104] x25: 0000000000000123 x24: 0000000000000015 [ 37.067499] x23: 0000000000000000 x22: ffff000008e6e250 [ 37.072894] x21: ffff000008e6e000 x20: 0000000000000000 [ 37.078289] x19: ffff000008e5d4c8 x18: 0000000000000010 [ 37.083684] x17: 0000ffffa7c27470 x16: 00000000deadbeef [ 37.089079] x15: 0000000000000006 x14: ffff000088f42bef [ 37.094474] x13: ffff000008f42bfd x12: ffff000008e706c0 [ 37.099870] x11: ffff000008e70000 x10: 0000000005f5e0ff [ 37.105265] x9 : ffff800902067a50 x8 : 6974726174736552 [ 37.110660] x7 : ffff000008cc6fb8 x6 : ffff000008cc6fb0 [ 37.116055] x5 : ffff000008c97dd8 x4 : 0000000000000000 [ 37.121453] x3 : 0000000000000000 x2 : 0000000000000000 [ 37.126845] x1 : 0000000000000000 x0 : 0000000000000000 [ 37.132239] [ 37.133808] Process systemd-shutdow (pid: 1, stack limit = 0xffff800902064000) [ 37.141118] Stack: (0xffff800902067cf0 to 0xffff800902068000) [ 37.146949] 7ce0: ffff800902067d40 ffff000008085334 [ 37.154869] 7d00: 0000000000000000 ffff000008f3b000 ffff800902067d40 ffff0000080852e0 [ 37.162787] 7d20: ffff000008cc6fb0 ffff000008cc6fb8 ffff000008c7f580 ffff000008c97dd8 [ 37.170706] 7d40: ffff800902067d60 ffff0000080e2c2c 0000000000000000 0000000001234567 [ 37.178624] 7d60: ffff800902067d80 ffff0000080e2ee8 0000000000000000 ffff0000080e2df4 [ 37.186544] 7d80: 0000000000000000 ffff0000080830f0 0000000000000000 00008008ff1c1000 [ 37.194462] 7da0: ffffffffffffffff 0000ffffa7c4b1cc 0000000000000000 0000000000000024 [ 37.202380] 7dc0: ffff800902067dd0 0000000000000005 0000fffff24743c8 0000000000000004 [ 37.210299] 7de0: 0000fffff2475f03 0000000000000010 0000fffff2474418 0000000000000005 [ 37.218218] 7e00: 0000fffff2474578 000000000000000a 0000aaaad6b722c0 0000000000000001 [ 37.226136] 7e20: 0000000000000123 0000000000000038 ffff800902067e50 ffff0000081e7294 [ 37.234055] 7e40: ffff800902067e60 ffff0000081e935c ffff800902067e60 ffff0000081e9388 [ 37.241973] 7e60: ffff800902067eb0 ffff0000081ea388 0000000000000000 00008008ff1c1000 [ 37.249892] 7e80: ffffffffffffffff 0000ffffa7c4a79c 0000000000000000 ffff000000020000 [ 37.257810] 7ea0: 0000010000000004 0000000000000000 0000000000000000 ffff0000080830f0 [ 37.265729] 7ec0: fffffffffee1dead 0000000028121969 0000000001234567 0000000000000000 [ 37.273651] 7ee0: ffffffffffffffff 8080000000800000 0000800000008080 feffa9a9d4ff2d66 [ 37.281567] 7f00: 000000000000008e feffa9a9d5b60e0f 7f7fffffffff7f7f 0101010101010101 [ 37.289485] 7f20: 0000000000000010 0000000000000008 000000000000003a 0000ffffa7ccf588 [ 37.297404] 7f40: 0000aaaad6b87d00 0000ffffa7c4b1b0 0000fffff2474be0 0000aaaad6b88000 [ 37.305326] 7f60: 0000fffff2474fb0 0000000001234567 0000000000000000 0000000000000000 [ 37.313240] 7f80: 0000000000000000 0000000000000001 0000aaaad6b70d4d 0000000000000000 [ 37.321159] 7fa0: 0000000000000001 0000fffff2474ea0 0000aaaad6b5e2e0 0000fffff2474e80 [ 37.329078] 7fc0: 0000ffffa7c4b1cc 0000000000000000 fffffffffee1dead 000000000000008e [ 37.336997] 7fe0: 0000000000000000 0000000000000000 9ce839cffee77eab fafdbf9f7ed57f2f [ 37.344911] Call trace: [ 37.347437] Exception stack(0xffff800902067b20 to 0xffff800902067c50) [ 37.353970] 7b20: ffff000008e5d4c8 0001000000000000 0000000080f82000 0000000000000000 [ 37.361883] 7b40: ffff800902067b60 ffff000008e17000 ffff000008f44c68 00000001081081b4 [ 37.369802] 7b60: ffff800902067bf0 ffff000008108478 0000000000000000 ffff000008c235b0 [ 37.377721] 7b80: ffff800902067ce0 0000000000000000 0000000000000000 0000000000000015 [ 37.385643] 7ba0: 0000000000000123 000000000000008e ffff000008992000 ffff800902068000 [ 37.393557] 7bc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 37.401477] 7be0: 0000000000000000 ffff000008c97dd8 ffff000008cc6fb0 ffff000008cc6fb8 [ 37.409396] 7c00: 6974726174736552 ffff800902067a50 0000000005f5e0ff ffff000008e70000 [ 37.417318] 7c20: ffff000008e706c0 ffff000008f42bfd ffff000088f42bef 0000000000000006 [ 37.425234] 7c40: 00000000deadbeef 0000ffffa7c27470 [ 37.430190] [< (null)>] (null) [ 37.434982] [<ffff000008085334>] machine_restart+0x6c/0x70 [ 37.440550] [<ffff0000080e2c2c>] kernel_restart+0x6c/0x78 [ 37.446030] [<ffff0000080e2ee8>] SyS_reboot+0x130/0x228 [ 37.451337] [<ffff0000080830f0>] el0_svc_naked+0x24/0x28 [ 37.456737] Code: bad PC value [ 37.459891] ---[ end trace 76e2fc17e050aecd ]--- Signed-off-by:
Julien Grall <julien.grall@arm.com> -- Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org The x86 code has theoritically a similar issue, altought EFI does not seem to be the preferred method. I have only built test it on x86. This should also probably be fixed in stable tree. Changes in v2: - Implement xen_efi_reset_system using xen_reboot - Move xen_efi_reset_system in drivers/xen/efi.c Signed-off-by:
-
Julien Grall authored
Signed-off-by:
-
Julien Grall authored
The helper xen_reboot will be called by the EFI code in a later patch. Note that the ARM version does not yet exist and will be added in a later patch too. Signed-off-by:
-
Boris Ostrovsky authored
Recent code rework that split handling ov PV, HVM and PVH guests into separate files missed calling xen_smp_intr_init_pv() on CPU0. Add this call. Signed-off-by:
Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by:
-
Boris Ostrovsky authored
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741) established that commit 72a9b186 ("xen: Remove event channel notification through Xen PCI platform device") (and thus commit da72ff5b ("partially revert "xen: Remove event channel notification through Xen PCI platform device"")) are unnecessary and, in fact, prevent HVM guests from booting on Xen releases prior to 4.0 Therefore we revert both of those commits. The summary of that discussion is below: Here is the brief summary of the current situation: Before the offending commit (72a9b186): 1) INTx does not work because of the reset_watches path. 2) The reset_watches path is only taken if you have Xen > 4.0 3) The Linux Kernel by default will use vector inject if the hypervisor support. So even INTx does not work no body running the kernel with Xen > 4.0 would notice. Unless he explicitly disabled this feature either in the kernel or in Xen (and this can only be disabled by modifying the code, not user-supported way to do it). After the offending commit (+ partial revert): 1) INTx is no longer support for HVM (only for PV guests). 2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have vector injection support. Since the only other mode supported is INTx which. So based on this summary, I think before commit (72a9b186) we were in much better position from a user point of view. Signed-off-by:
-
Boris Ostrovsky authored
e820 map is updated with information from the zeropage (i.e. pvh_bootparams) by default_machine_specific_memory_setup(). With the way things are done now, we end up with a duplicated e820 map. Signed-off-by:
-
Geliang Tang authored
Use offset_in_page() macro instead of open-coding. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Reviewed-by:
-
Stefano Stabellini authored
Now that __generic_dma_ops is a xen specific function, rename it to xen_get_dma_ops. Change all the call sites appropriately. Signed-off-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: linux@armlinux.org.uk CC: catalin.marinas@arm.com CC: will.deacon@arm.com CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: Julien Grall <julien.grall@arm.com>
-
Stefano Stabellini authored
The following commit: commit 815dd187 Author: Bart Van Assche <bart.vanassche@sandisk.com> Date: Fri Jan 20 13:04:04 2017 -0800 treewide: Consolidate get_dma_ops() implementations rearranges get_dma_ops in a way that xen_dma_ops are not returned when running on Xen anymore, dev->dma_ops is returned instead (see arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and include/linux/dma-mapping.h:get_dma_ops). Fix the problem by storing dev->dma_ops in dev_archdata, and setting dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from dev_archdata when needed. It also allows us to remove __generic_dma_ops from common headers. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
-
Arnd Bergmann authored
All Xen frontends need to select this symbol to avoid a link error: net/built-in.o: In function `p9_trans_xen_init': :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend' Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Juergen Gross authored
There is no user of x86_hyper->set_cpu_features() any more. Remove it. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Signed-off-by:
-
Juergen Gross authored
There is no need to set the same capabilities for each cpu individually. This can be done for all cpus in platform initialization. Cc: Alok Kataria <akataria@vmware.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by:
Alok Kataria <akataria@vmware.com> Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the xsave feature availability is indicated by special casing the related cpuid leaf. Instead of delivering fake cpuid values set or clear the cpu capability bits for xsave instead. Signed-off-by:
Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the x2apic feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for x2apic instead. Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the mwait feature is indicated to be present or not by special casing the related cpuid leaf. Instead of delivering fake cpuid values use the cpu capability bit for mwait instead. Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the acpi feature is indicated as not being present by special casing the related cpuid leaf in case we are not the initial domain. Instead of delivering fake cpuid values clear the cpu capability bit for acpi instead. Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the acc feature (thermal monitoring) is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for acc instead. Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the mtrr feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for mtrr instead. Signed-off-by:
-
Juergen Gross authored
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for aperf/mperf instead. Signed-off-by:
-
Juergen Gross authored
Xen doesn't support DCA (direct cache access) for pv domains. Clear the corresponding capability indicator. Signed-off-by:
-
Juergen Gross authored
There is no need to set the same capabilities for each cpu individually. This can easily be done for all cpus when starting the kernel. Signed-off-by:
-
Stefano Stabellini authored
In order to use "len" to check for xenbus_read errors properly, we need to initialize len to 0 before passing it to xenbus_read. CC: dan.carpenter@oracle.com CC: jgross@suse.com CC: boris.ostrovsky@oracle.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by:
Stefano Stabellini <stefano@aporeto.com> Reviewed-by:
-
Juergen Gross authored
For kdump to work correctly it needs the physical address of vmcoreinfo_note. When running as dom0 this means the virtual address has to be translated to the related machine address. paddr_vmcoreinfo_note() is meant to do the translation via __pa_symbol() only, but being attributed "weak" it can be replaced easily in Xen case. Signed-off-by:
Petr Tesarik <ptesarik@suse.com> Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by:
-
Oleksandr Andrushchenko authored
This is the ABI for the two halves of a para-virtualized display driver. This protocol aims to provide a unified protocol which fits more sophisticated use-cases than a framebuffer device can handle. At the moment basic functionality is supported with the intention to extend: o multiple dynamically allocated/destroyed framebuffers o buffers of arbitrary sizes o better configuration options including multiple display support Note: existing fbif can be used together with displif running at the same time, e.g. on Linux one provides framebuffer and another DRM/KMS Future extensions to the existing protocol may include: o allow display/connector cloning o allow allocating objects other than display buffers o add planes/overlays support o support scaling o support rotation Note, that this protocol doesn't use ring macros for bi-directional exchange (PV calls/9pfs) bacause: o it statically defines the use of a single page for the ring buffer o it uses direct memory access to ring's contents w/o memory copying o re-uses the same idea that kbdif/fbif use which for this use-case seems to be appropriate ================================================== Rationale for introducing this protocol instead of using the existing fbif: ================================================== 1. In/out event sizes o fbif - 40 octets o displif - 40 octets This is only the initial version of the displif protocol which means that there could be requests which will not fit (WRT introducing some GPU related functionality later on). In that case we cannot alter fbif sizes as we need to be backward compatible an will be forced to handle those apart of fbif. 2. Shared page Displif doesn't use anything like struct xenfb_page, but DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct xendispl_resp) which is a better and more common way. Output events use a shared page which only has in_cons and in_prod and all the rest is used for incoming events. Here struct xenfb_page could probably be used as is despite the fact that it only has a half of a page for incoming events which is only 50 events. (consider something like 60Hz display) 3. Amount of changes. fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE events, so it looks like it is easier to get fb support into displif than vice versa. displif at the moment has 6 requests and 1 event, multiple connector support, etc. Signed-off-by:Oleksandr Grytsov <oleksandr_grytsov@epam.com> Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by:
-
Oleksandr Andrushchenko authored
Add ABI for the two halves of a para-virtualized sound driver to communicate with each other. The ABI allows implementing audio playback and capture as well as volume control and possibility to mute/unmute audio sources. Note: depending on the use-case backend can expose more sound cards and PCM devices/streams than the underlying HW physically has by employing SW mixers, configuring virtual sound streams, channels etc. Thus, allowing fine tunned configurations per frontend. Signed-off-by:
Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com> Signed-off-by:
Iurii Konovalenko <iurii.konovalenko@globallogic.com> Acked-by:
-
Oleksandr Andrushchenko authored
Multi-touch fields re-use the page that is used by the other features which means that you can interleave multi-touch, motion, and key events. Signed-off-by:
-
Oleksandr Andrushchenko authored
The patch clarifies the protocol that is used by the PV keyboard drivers. Signed-off-by:
-
Stefano Stabellini authored
This patch adds a Kconfig option and Makefile support for building the 9pfs Xen driver. CC: groug@kaod.org CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by:
-
Stefano Stabellini authored
Upon receiving a notification from the backend, schedule the p9_xen_response work_struct. p9_xen_response checks if any responses are available, if so, it reads them one by one, calling p9_client_cb to send them up to the 9p layer (p9_client_cb completes the request). Handle the ring following the Xen 9pfs specification. CC: groug@kaod.org CC: jgross@suse.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by:
-
Stefano Stabellini authored
Implement struct p9_trans_module create and close functions by looking at the available Xen 9pfs frontend-backend connections. We don't expect many frontend-backend connections, thus walking a list is OK. Send requests to the backend by copying each request to one of the available rings (each frontend-backend connection comes with multiple rings). Handle the ring and notifications following the 9pfs specification. If there are not enough free bytes on the ring for the request, wait on the wait_queue: the backend will send a notification after consuming more requests. CC: groug@kaod.org CC: jgross@suse.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by:
-
Stefano Stabellini authored
Implement functions to handle the xenbus handshake. Upon connection, allocate the rings according to the protocol specification. Initialize a work_struct and a wait_queue. The work_struct will be used to schedule work upon receiving an event channel notification from the backend. The wait_queue will be used to wait when the ring is full and we need to send a new request. CC: groug@kaod.org CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by:
-
Stefano Stabellini authored
Introduce the Xen 9pfs transport driver: add struct xenbus_driver to register as a xenbus driver and add struct p9_trans_module to register as v9fs driver. All functions are empty stubs for now. CC: groug@kaod.org CC: jgross@suse.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by:
-
Stefano Stabellini authored
It uses the new ring.h macros to declare rings and interfaces. CC: konrad.wilk@oracle.com CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: groug@kaod.org Signed-off-by:
-
Stefano Stabellini authored
Sync the ring.h file with upstream Xen, to introduce the new ring macros. They will be used by the Xen transport for 9pfs. CC: konrad.wilk@oracle.com CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: groug@kaod.org Signed-off-by:
-
Juergen Gross authored
xen_call_function_interrupt() isn't used in smp_pv.c. Remove it. Signed-off-by:
-
