similar to: [PATCH] x86, Allow x2apic without IR on VMware platform.

On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote: > The x86_hyper pointer is only used for checking whether a virtual > device is supporting the hypervisor the system is running on. > > Use an enum for that purpose instead and drop the x86_hyper pointer. > > Cc: kys at microsoft.com > Cc: haiyangz at microsoft.com > Cc: sthemmin at microsoft.com > Cc:

On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote: > The x86_hyper pointer is only used for checking whether a virtual > device is supporting the hypervisor the system is running on. > > Use an enum for that purpose instead and drop the x86_hyper pointer. > > Cc: kys at microsoft.com > Cc: haiyangz at microsoft.com > Cc: sthemmin at microsoft.com > Cc:

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Juergen Gross <jgross at suse.com> commit f72e38e8ec8869ac0ba5a75d7d2f897d98a1454e upstream. Instead of x86_hyper being either NULL on bare metal or a pointer to a struct hypervisor_x86 in case of the kernel running as a guest merge the struct into x86_platform and x86_init. This will

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Juergen Gross <jgross at suse.com> commit 03b2a320b19f1424e9ac9c21696be9c60b6d0d93 upstream. The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor the system is running on. Use an enum for that purpose instead and drop the x86_hyper

The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor the system is running on. Use an enum for that purpose instead and drop the x86_hyper pointer. Cc: kys at microsoft.com Cc: haiyangz at microsoft.com Cc: sthemmin at microsoft.com Cc: akataria at vmware.com Cc: pbonzini at redhat.com Cc: rkrcmar at redhat.com Cc: boris.ostrovsky at oracle.com

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Signed-off-by: Juergen Gross <jgross at suse.com> --- V4: move this patch some places up in the series WARN_ONCE in

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Such a pinning should last as short as possible as it might block sensible vcpu scheduling and maybe other hypervisor functions

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Such a pinning should last as short as possible as it might block sensible vcpu scheduling and maybe other hypervisor functions

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

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 at vmware.com> Cc: Thomas Gleixner <tglx at linutronix.de> Cc: Ingo Molnar <mingo at redhat.com> Cc: "H. Peter Anvin" <hpa at zytor.com> Cc: x86 at kernel.org Cc: virtualization at lists.linux-foundation.org

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a