xen: features and fixes for 4.8-rc0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8-rc0-tag
xen: features and fixes for 4.8-rc0
- - ACPI support for guests on ARM platforms.
- - Generic steal time support for arm and x86.
- - Support cases where kernel cpu is not Xen VCPU number (e.g., if in-guest kexec is used).
- - Use the system workqueue instead of a custom workqueue in various places.
Thanks.
David
Documentation/devicetree/bindings/arm/xen.txt | 35 +++++ arch/arm/include/asm/xen/hypercall.h | 1 + arch/arm/include/asm/xen/xen-ops.h | 6 + arch/arm/kernel/setup.c | 2 +- arch/arm/xen/Makefile | 1 + arch/arm/xen/efi.c | 40 ++++++ arch/arm/xen/enlighten.c | 157 +++++++++++++++------ arch/arm/xen/hypercall.S | 1 + arch/arm64/include/asm/xen/xen-ops.h | 6 + arch/arm64/kernel/setup.c | 3 +- arch/arm64/xen/Makefile | 1 + arch/arm64/xen/hypercall.S | 1 + arch/x86/include/asm/cpu.h | 1 + arch/x86/include/asm/smp.h | 2 + arch/x86/include/asm/xen/cpuid.h | 5 +- arch/x86/kernel/acpi/boot.c | 16 ++- arch/x86/kernel/apic/apic.c | 2 + arch/x86/kernel/setup_percpu.c | 3 + arch/x86/xen/efi.c | 111 +++++++++++++++ arch/x86/xen/enlighten.c | 49 +++++-- arch/x86/xen/grant-table.c | 57 +------- arch/x86/xen/irq.c | 3 +- arch/x86/xen/pmu.c | 2 +- arch/x86/xen/smp.c | 18 ++- arch/x86/xen/time.c | 63 ++------- arch/x86/xen/xen-ops.h | 1 + drivers/acpi/scan.c | 74 ++++++++++ drivers/block/xen-blkback/xenbus.c | 20 +-- drivers/block/xen-blkfront.c | 43 +++--- drivers/firmware/efi/arm-runtime.c | 5 + drivers/firmware/efi/efi.c | 81 ++++++++--- drivers/of/fdt.c | 13 ++ drivers/xen/Kconfig | 2 +- drivers/xen/Makefile | 1 + drivers/xen/arm-device.c | 196 ++++++++++++++++++++++++++ drivers/xen/efi.c | 173 +++++------------------ drivers/xen/events/events_base.c | 13 +- drivers/xen/events/events_fifo.c | 2 +- drivers/xen/evtchn.c | 43 +++++- drivers/xen/gntalloc.c | 2 +- drivers/xen/gntdev.c | 2 +- drivers/xen/privcmd.c | 2 +- drivers/xen/time.c | 50 +++++-- drivers/xen/xen-pciback/conf_space.c | 22 ++- drivers/xen/xen-pciback/conf_space_header.c | 57 +++----- drivers/xen/xen-pciback/pciback.h | 1 - drivers/xen/xen-pciback/pciback_ops.c | 2 +- drivers/xen/xen-pciback/xenbus.c | 10 +- drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +- drivers/xen/xlate_mmu.c | 77 ++++++++++ include/linux/kernel_stat.h | 1 - include/linux/of_fdt.h | 2 + include/uapi/xen/evtchn.h | 15 ++ include/xen/interface/hvm/params.h | 40 +++++- include/xen/interface/memory.h | 1 + include/xen/interface/vcpu.h | 24 ++-- include/xen/interface/xen.h | 17 ++- include/xen/xen-ops.h | 40 ++++-- kernel/sched/cputime.c | 10 -- 59 files changed, 1150 insertions(+), 493 deletions(-)
Amitoj Kaur Chawla (1):
x86/xen: Use DIV_ROUND_UP
Bhaktipriya Shridhar (2):
xen: xen-pciback: Remove create_workqueue
xen: xenbus: Remove create_workqueue
Boris Ostrovsky (1):
xen/PMU: Log VPMU initialization error at lower level
David Vrabel (1):
xen/evtchn: add IOCTL_EVTCHN_RESTRICT
Jan Beulich (11):
xen-pciback: drop unused function parameter of read_dev_bar()
xen-pciback: drop rom_init()
xen-pciback: fold read_dev_bar() into its now single caller
xen-pciback: simplify determination of 64-bit memory resource
xen-pciback: use const and unsigned in bar_init()
xen-pciback: short-circuit read path used for merging write values
xen-pciback: drop superfluous variables
xen-blkback: prefer xenbus_scanf() over xenbus_gather()
xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
xen-blkback: constify instance of "struct attribute_group"
xen-blkback: really don't leak mode property
Juergen Gross (5):
xen: add steal_clock support on x86
xen: update xen headers
arm/xen: add support for vm_assist hypercall
xen: support runqueue steal time on xen
xen: add static initialization of steal_clock op to xen_time_ops
Muhammad Falak R Wani (1):
xen: use vma_pages().
Shannon Zhao (16):
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
Xen: ARM: Add support for mapping platform device mmio
Xen: ARM: Add support for mapping AMBA device mmio
Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
ARM: XEN: Move xen_early_init() before efi_init()
ARM: Xen: Document UEFI support on Xen ARM virtual platforms
XEN: EFI: Move x86 specific codes to architecture directory
ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
FDT: Add a helper to get the subnode by given name
Xen: EFI: Parse DT parameters for Xen specific UEFI
Vitaly Kuznetsov (9):
x86/xen: update cpuid.h from Xen-4.7
x86/acpi: store ACPI ids from MADT for future usage
xen: introduce xen_vcpu_id mapping
x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to shared_info xen/events: use xen_vcpu_id mapping in events_base xen/events: fifo: use xen_vcpu_id mapping
xen/evtchn: use xen_vcpu_id mapping
xen/pvhvm: run xen_vcpu_setup() for the boot CPU
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXmLsUAAoJEFxbo/MsZsTRxJgIAIIg3aT21aYVCqoC9mll5Lej mveypTYQ77hbluEwymjVXcxGt4Q3fabTp6tXEOzzIdHEXrxe17ltqaTpHjRWmoSu xzKLJSknJ+7XGeb1zfAtuXsR3Hq2DSkn1PmQKcZAHdJBgWugXPTESumS00UBvCLO +T7mCnWk+SYWlpMcIQannU1PLxiQWRlU/doLgjBGlzzLdy0LSIXDjRwnX2FrSJW+ PWEjasYnAqgPYtUQ/T7vzcX4ikFPqpBBQnIN1pJ+1EAh7zXD65eO/D7WNb9OMdd+ QY1dwnXYh7wLtIXqIKkMu6Ve8S+/eH8fAUNs0Y6zB6yTIepTfeKZ9OGTM3EoN9s= =U2jJ
-----END PGP SIGNATURE-----
Quoted 3 lines · David Vrabel
Shannon Zhao (16):
Xen: ACPI: Hide UART used by Xen
So this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy.
Should the device entry in ACPI really be hidden unconditionally? In particular, if we are *not* running under virtualization, it sounds wrong to hide it.
Comments? Am I missing something?
Linus
Quoted 7 lines · Linus Torvalds
Quoted 2 lines · David Vrabel
Shannon Zhao (16):
Xen: ACPI: Hide UART used by XenSo this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy.
Quoted 5 lines
Should the device entry in ACPI really be hidden unconditionally? In particular, if we are *not* running under virtualization, it sounds wrong to hide it.
Comments? Am I missing something?
The purpose of the ACPI STAO table (Status Override table, ratified in ACPI 6.0) is to list items elsewhere in the ACPI namespace which should be completely ignored. It is used in cases where it is impossible or prohibitive to edit the system AML.
The patch itself only hides the UART if instructed to do so by the STAO table (last hunk).
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 7 lines · Linus Torvalds
Quoted 2 lines · David Vrabel
Shannon Zhao (16):
Xen: ACPI: Hide UART used by XenSo this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy.
Quoted 5 lines
Should the device entry in ACPI really be hidden unconditionally? In particular, if we are *not* running under virtualization, it sounds wrong to hide it.
Comments? Am I missing something?
The purpose of the ACPI STAO table (Status Override table, ratified in ACPI 6.0) is to list items elsewhere in the ACPI namespace which should be completely ignored. It is used in cases where it is impossible or prohibitive to edit the system AML.
The patch itself only hides the UART if instructed to do so by the STAO table (last hunk).
~Andrew
Quoted 14 lines · Andrew Cooper
Quoted 7 lines · Linus Torvalds
Quoted 2 lines · David Vrabel
Shannon Zhao (16):
Xen: ACPI: Hide UART used by XenSo this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy.
Quoted 5 lines
Should the device entry in ACPI really be hidden unconditionally? In particular, if we are *not* running under virtualization, it sounds wrong to hide it.
Comments? Am I missing something?
Quoted 7 lines
The purpose of the ACPI STAO table (Status Override table, ratified in ACPI 6.0) is to list items elsewhere in the ACPI namespace which should be completely ignored. It is used in cases where it is impossible or prohibitive to edit the system AML.
The patch itself only hides the UART if instructed to do so by the STAO table (last hunk).
Right.
The STAO definition document:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Thanks,
Rafael
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 14 lines · Andrew Cooper
Quoted 7 lines · Linus Torvalds
Quoted 2 lines · David Vrabel
Shannon Zhao (16):
Xen: ACPI: Hide UART used by XenSo this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy.
Quoted 5 lines
Should the device entry in ACPI really be hidden unconditionally? In particular, if we are *not* running under virtualization, it sounds wrong to hide it.
Comments? Am I missing something?
Quoted 7 lines
The purpose of the ACPI STAO table (Status Override table, ratified in ACPI 6.0) is to list items elsewhere in the ACPI namespace which should be completely ignored. It is used in cases where it is impossible or prohibitive to edit the system AML.
The patch itself only hides the UART if instructed to do so by the STAO table (last hunk).
Right.
The STAO definition document:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Thanks,
Rafael
Quoted 6 lines · Rafael J. Wysocki
The STAO definition document:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Well, first off, documentation is one thing, actually changing behavior is something entirely different.
Theory and practice are *not* the same.
The other worry I have is that I'd be happier if it's still visible in /sys/bus/acpi/ etc. Again, it's one thing to not react to it programmatically, and another thing entirely to actually hide the information from the rest of the system.
If I read that patch right, it will be hidden from sysfs too. But Maybe I'm mistaken.
Linus
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 6 lines · Rafael J. Wysocki
The STAO definition document:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Well, first off, documentation is one thing, actually changing behavior is something entirely different.
Theory and practice are *not* the same.
The other worry I have is that I'd be happier if it's still visible in /sys/bus/acpi/ etc. Again, it's one thing to not react to it programmatically, and another thing entirely to actually hide the information from the rest of the system.
If I read that patch right, it will be hidden from sysfs too. But Maybe I'm mistaken.
Linus
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Rafael J. Wysocki
The STAO definition document:
Quoted 8 lines
Quoted 3 lines
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Well, first off, documentation is one thing, actually changing behavior is something entirely different.
Theory and practice are *not* the same.
Well, the STAO thing is totally new, so we have the documentation only ATM.
Quoted 7 lines
The other worry I have is that I'd be happier if it's still visible in
/sys/bus/acpi/etc. Again, it's one thing to not react to it programmatically, and another thing entirely to actually hide the information from the rest of the system.If I read that patch right, it will be hidden from sysfs too. But Maybe I'm mistaken.
You're right.
Avoiding to enumerate it entirely is somewhat simpler, because it allows us to avoid some special casing in a few places IIRC.
I guess we can ask the author of the commit in question to come up with a patch to unhide that device and we'll see how that looks like.
Thanks,
Rafael
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Rafael J. Wysocki
The STAO definition document:
Quoted 8 lines
Quoted 3 lines
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Well, first off, documentation is one thing, actually changing behavior is something entirely different.
Theory and practice are *not* the same.
Well, the STAO thing is totally new, so we have the documentation only ATM.
Quoted 7 lines
The other worry I have is that I'd be happier if it's still visible in
/sys/bus/acpi/etc. Again, it's one thing to not react to it programmatically, and another thing entirely to actually hide the information from the rest of the system.If I read that patch right, it will be hidden from sysfs too. But Maybe I'm mistaken.
You're right.
Avoiding to enumerate it entirely is somewhat simpler, because it allows us to avoid some special casing in a few places IIRC.
I guess we can ask the author of the commit in question to come up with a patch to unhide that device and we'll see how that looks like.
Thanks,
Rafael
Quoted 20 lines · Rafael J. Wysocki
Quoted 10 lines · Linus Torvalds
Quoted 5 lines · Rafael J. Wysocki
The STAO definition document:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
requires as to "operate as if that device does not exist", quite literally.
Well, first off, documentation is one thing, actually changing behavior is something entirely different.
Theory and practice are *not* the same.
Well, the STAO thing is totally new, so we have the documentation only ATM.
Quoted 7 lines
The other worry I have is that I'd be happier if it's still visible in
/sys/bus/acpi/etc. Again, it's one thing to not react to it programmatically, and another thing entirely to actually hide the information from the rest of the system.If I read that patch right, it will be hidden from sysfs too. But Maybe I'm mistaken.
Quoted 7 lines
You're right.
Avoiding to enumerate it entirely is somewhat simpler, because it allows us to avoid some special casing in a few places IIRC.
I guess we can ask the author of the commit in question to come up with a patch to unhide that device and we'll see how that looks like.
Well - the entire purpose of STAO is to list system resources which are genuinely in use by the hypervisor, and genuinely can't be mapped or used by the kernel (these latter two frequently resulting in crashes or hangs at early boot).
Identifying that such devices exist is reasonable (it is certainly possibly by dumping the raw acpi tables), but any sysfs tweakable is going to end in misery.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 3 lines · David Vrabel
Shannon Zhao (16):
Xen: ACPI: Hide UART used by Xen
So this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy.
Should the device entry in ACPI really be hidden unconditionally? In particular, if we are *not* running under virtualization, it sounds wrong to hide it.
Comments? Am I missing something?
Linus
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel