Re: [XEN v2] xen/arm64: io: Decode 32-bit ldr/str post-indexing instructions

On 29.11.2021 20:16, Ayan Kumar Halder wrote: > At the moment, Xen is only handling data abort with valid syndrome (i.e. > ISV=0). Unfortunately, this doesn't cover all the instructions a domain > could use to access MMIO regions. > > For instance, Xilinx baremetal OS will use: > > volati

Re: [PATCH] x86/boot: Drop incorrect mapping at l2_xenmap[0]

On 29.11.2021 18:42, Andrew Cooper wrote: > On 29/11/2021 17:26, Andrew Cooper wrote: >> It has been 4 years since the default load address changed from 1M to 2M, and >> _stext ceased residing in l2_xenmap[0]. We should not be inserting an unused >> mapping. >> >> To ensure we don't create/remove

Re: Xen on LFS

Ok, thanks for the reply. Will do that. On Tue, Nov 30, 2021 at 12:52 PM Jan Beulich wrote: > On 30.11.2021 07:50, Sai Kiran Kumar Reddy wrote: > > I am Sai Kiran. I am currently working on installing xen on Linux From > > Scratch(LFS) system. One of the dependencies of xen is "xorg" package. >

Re: Xen on LFS

On 30.11.2021 07:50, Sai Kiran Kumar Reddy wrote: > I am Sai Kiran. I am currently working on installing xen on Linux From > Scratch(LFS) system. One of the dependencies of xen is "xorg" package. This > package is present in Beyond > Lin

Re: [PATCH] Fixed an incorrect value

On 29.11.2021 20:44, Ayan Kumar Halder wrote: > GENMASK(30, 21) should be 0x07fe0 Please can this have a meaningful title? E.g. "bitops: fix incorrect value in comment"? > --- a/xen/include/xen/bitops.h > +++ b/xen/include/xen/bitops.h > @@ -5,7 +5,7 @@ > /* > * Create a contiguous bitmask

Xen on LFS

Hi, I am Sai Kiran. I am currently working on installing xen on Linux From Scratch(LFS) system. One of the dependencies of xen is "xorg" package. This package is present in Beyond Linux From Scratch(BLFS)

[qemu-mainline test] 166953: tolerable FAIL - PUSHED

flight 166953 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/166953/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166952 test-amd64-amd64-qemuu-nested-amd 2

Re: [patch 05/22] genirq/msi: Fixup includes

Cedric, On Mon, Nov 29 2021 at 08:33, Cédric Le Goater wrote: > On 11/27/21 02:18, Thomas Gleixner wrote: >> Remove the kobject.h include from msi.h as it's not required and add a >> sysfs.h include to the core code instead. >> >> Signed-off-by: Thomas Gleixner > > > This patch breaks compile on

[qemu-mainline test] 166952: tolerable FAIL - PUSHED

flight 166952 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/166952/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 166948 test-amd64-amd64-xl-qemuu-win7-amd6

[PATCH] Fixed an incorrect value

GENMASK(30, 21) should be 0x07fe0 Signed-off-by: Ayan Kumar Halder --- xen/include/xen/bitops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h index a64595f68e..2c8522d218 100644 --- a/xen/include/xen/bitops.h +++ b/xe

Re: [RFC PATCH] Added the logic to decode 32 bit ldr/str post-indexing instructions

Hi All, Thanks for giving your inputs. On 26/11/2021 17:39, Andre Przywara wrote: On Fri, 26 Nov 2021 15:28:06 + Ayan Kumar Halder wrote: Hi Ayan, Many thanks for your inputs. Apologies if I sound dumb, but I need a few clarifications. On 26/11/2021 13:14, Andre Przywara wrote: On Fri

[XEN v2] xen/arm64: io: Decode 32-bit ldr/str post-indexing instructions

At the moment, Xen is only handling data abort with valid syndrome (i.e. ISV=0). Unfortunately, this doesn't cover all the instructions a domain could use to access MMIO regions. For instance, Xilinx baremetal OS will use: volatile u32 *LocalAddr = (volatile u32 *)Addr; *LocalAddr

Re: Stable backports of Xen related patches

On Mon, Nov 29, 2021 at 04:15:31PM +0100, Juergen Gross wrote: > Hi Greg, > > attached are git bundles for some patches you merged into the 5.10 > stable kernel already this morning. > > Naming should be obvious, the patches are on the branch "back" in > each bundle. All now queued up, thanks!

Re: [PATCH] x86/boot: Drop incorrect mapping at l2_xenmap[0]

On 29/11/2021 17:26, Andrew Cooper wrote: > It has been 4 years since the default load address changed from 1M to 2M, and > _stext ceased residing in l2_xenmap[0]. We should not be inserting an unused > mapping. > > To ensure we don't create/remove mappings accidentally, loop from 0 and obey > _PA

Re: [XEN PATCH 0/1] Add support for SMBIOS tables 7,8,9,26,27,28.

On Mon, Nov 29, 2021 at 12:59:28PM +, Anton Belousov wrote: > This update is done to improve virtual machine stealth from malware. There > are AntiVM techniques that use WMI-queries to detect presence of this SMBIOS > tables. Example: > "https://github.com/LordNoteworthy/al-khaser/blob/maste

Re: [patch 03/10] genirq/msi: Make MSI descriptor alloc/free ready for range allocations

On Sun, Nov 28 2021 at 20:17, Thomas Gleixner wrote: > On Sun, Nov 28 2021 at 15:57, Marc Zyngier wrote: > Hrm. The stupid search should terminated nevertheless. Let me stare at > it again. Found it. Just my inability to read xarray documentation. Thanks, tglx

Re: [XEN PATCH 1/1] Add suport for SMBIOS tables 7,8,9,26,27,28 to improve virtual machine stealth from malware.

Hello, On Mon, Nov 29, 2021 at 12:59:29PM +, Anton Belousov wrote: Than ks for the patch, I'm afraid this requires a proper commit message and a Signed-off-by tag. See: https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Title_and_description_of_the_patch > --- > tools/firmware

[PATCH] x86/boot: Drop incorrect mapping at l2_xenmap[0]

It has been 4 years since the default load address changed from 1M to 2M, and _stext ceased residing in l2_xenmap[0]. We should not be inserting an unused mapping. To ensure we don't create/remove mappings accidentally, loop from 0 and obey _PAGE_PRESENT on all entries. Fixes: 7ed93f3a0dff ("x86

Re: ACPI/UEFI support for Xen/ARM status?

On Mon, Nov 15, 2021 at 07:09:45PM +, Julien Grall wrote: > On 15/11/2021 10:13, Jan Beulich wrote: > > On 12.11.2021 17:02, Julien Grall wrote: > >> On 12/11/2021 15:44, Elliott Mitchell wrote: > >>> > >>> Julien Grall and Stefano Stabellini had been proposing doing ACPI table > >>> parsing in

Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking

On 29.11.2021 16:09, Andrew Cooper wrote: > On 29/11/2021 14:44, Jan Beulich wrote: >> One question though: With the large number of __init functions gaining >> cf_check, wouldn't it be possible to turn on CET-IBT only when we're >> done using .init.text? > > 233 to be precise. > > GCC can't dist

Re: [RFC PATCH V3] xen/gnttab: Store frame GFN in struct page_info on Arm

Hi Julien [snip] ! Please note, there is still unresolved locking question here for which I failed to find a suitable solution. So, it is still an RFC ! According to the internal conversation: Now the GFN field in the struct page_info is accessed from gnttab_set_frame_gfn() in the gra

[PATCH v5 07/12] libs/guest: introduce helper set cpu topology in cpu policy

This logic is pulled out from xc_cpuid_apply_policy and placed into a separate helper. Note the legacy part of the introduced function, as long term Xen will require a proper topology setter function capable of expressing a more diverse set of topologies. No functional change intended. Signed-off

[PATCH v5 10/12] libs/{light,guest}: implement xc_cpuid_apply_policy in libxl

With the addition of the xc_cpu_policy_* now libxl can have better control over the cpu policy, this allows removing the xc_cpuid_apply_policy function and instead coding the required bits by libxl in libxl__cpuid_legacy directly. Remove xc_cpuid_apply_policy. Signed-off-by: Roger Pau Monné Revi

[PATCH v5 12/12] x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents

From: Jan Beulich Zapping leaf data for out of range leaves is just one half of it: To avoid guests (bogusly or worse) inferring information from mere leaf presence, also shrink maximum indicators such that the respective trailing entry is not all blank (unless of course it's the initial subleaf

[PATCH v5 11/12] libs/guest: (re)move xc_cpu_policy_apply_cpuid

Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the xc_cpu_policy_* helpers allow modifying a cpu policy. By moving such parsing into libxl directly we can get rid of xc_xend_cpuid, as libxl will now implement it's own private type for storing CPUID information, which currently m

[PATCH v5 08/12] libs/guest: rework xc_cpuid_xend_policy

Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it public. Modify the function internally to use the new xc_cpu_policy_* set of functions. Also don't apply the passed policy to a domain directly, and instead modify the provided xc_cpu_policy_t. The caller will be responsible of ap

[PATCH v5 09/12] libs/guest: apply a featureset into a cpu policy

Pull out the code from xc_cpuid_apply_policy that applies a featureset to a cpu policy and place it on it's own standalone function that's part of the public interface. No functional change intended. Signed-off-by: Roger Pau Monné --- tools/include/xenguest.h| 5 ++ tools/libs/guest/xg

[PATCH v5 05/12] libs/guest: allow fetching a specific MSR entry from a cpu policy

Introduce an interface that returns a specific MSR entry from a cpu policy in xen_msr_entry_t format. This is useful to callers can peek data from the opaque xc_cpu_policy_t type. No caller of the interface introduced on this patch. Signed-off-by: Roger Pau Monné --- Changes since v3: - Use x8

[PATCH v5 06/12] libs/guest: make a cpu policy compatible with older Xen versions

Older Xen versions used to expose some CPUID bits which are no longer exposed by default. In order to keep a compatible behavior with guests migrated from versions of Xen that don't encode the CPUID data on the migration stream introduce a function that sets the same bits as older Xen versions. Th

[PATCH v5 04/12] libx86: introduce helper to fetch msr entry

Use such helper in order to replace the code in x86_msr_copy_from_buffer. Note the introduced helper should not be directly called and instead x86_msr_get_entry should be used that will properly deal with const and non-const inputs. Note this requires making the raw fields uint64_t so that it can

[PATCH v5 03/12] libs/guest: allow fetching a specific CPUID leaf from a cpu policy

Introduce an interface that returns a specific leaf/subleaf from a cpu policy in xen_cpuid_leaf_t format. This is useful to callers can peek data from the opaque xc_cpu_policy_t type. No caller of the interface introduced on this patch. Note that callers of find_leaf need to be slightly adjusted

[PATCH v5 02/12] libx86: introduce helper to fetch cpuid leaf

Introduce a helper based on the current Xen guest_cpuid code in order to fetch a cpuid leaf from a policy. The newly introduced function in cpuid.c should not be directly called and instead the provided x86_cpuid_get_leaf macro should be used that will properly deal with const and non-const inputs.

[PATCH v5 01/12] libs/guest: move cpu policy related prototypes to xenguest.h

Do this before adding any more stuff to xg_cpuid_x86.c. The placement in xenctrl.h is wrong, as they are implemented by the xenguest library. Note that xg_cpuid_x86.c needs to include xg_private.h, and in turn also fix xg_private.h to include xc_bitops.h. The bitops definition of BITS_PER_LONG nee

[PATCH v5 00/12] libs/guest: new CPUID/MSR interface

Hello, The following series introduces a new CPUID/MSR interface for the xenguest library. Such interface handles both CPUID and MSRs using the same opaque object, and provides some helpers for the user to peek or modify such data without exposing the backing type. This is useful for future develo

Stable backports of Xen related patches

Hi Greg, attached are git bundles for some patches you merged into the 5.10 stable kernel already this morning. Naming should be obvious, the patches are on the branch "back" in each bundle. Juergen back-4.4 Description: Binary data back-4.9 Description: Binary data back-4.14 Description

Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking

On 29/11/2021 14:44, Jan Beulich wrote: > On 26.11.2021 13:33, Andrew Cooper wrote: >> CET Indirect Branch Tracking is a hardware feature designed to protect >> against >> forward-edge control flow hijacking (Call/Jump oriented programming), and is >> a >> companion feature to CET Shadow Stacks a

Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking

On 26.11.2021 13:33, Andrew Cooper wrote: > CET Indirect Branch Tracking is a hardware feature designed to protect against > forward-edge control flow hijacking (Call/Jump oriented programming), and is a > companion feature to CET Shadow Stacks added in Xen 4.14. > > This series depends on lots of

Re: [PATCH 54/65] x86/stack: Annotate fnptr targets

On 26.11.2021 13:34, Andrew Cooper wrote: > --- a/xen/include/asm-x86/current.h > +++ b/xen/include/asm-x86/current.h > @@ -173,7 +173,6 @@ unsigned long get_stack_dump_bottom (unsigned long sp); > #define switch_stack_and_jump(fn, instr, constr)\ > ({

Re: [PATCH 48/65] x86/aepi: Annotate fnptr targets

On 26.11.2021 13:34, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Nit: In the title I think you mean "x86/apei:". Jan

Re: [PATCH 30/65] x86/emul: Annotate fnptr targets

On 26.11.2021 13:34, Andrew Cooper wrote: > pv_emul_is_mem_write() only has a single user. Aiui you mean a single file using it; there I can spot three uses. > Having it as a static inline > is pointless because it can't be inlined to begin with. As long as it's only used to set function pointe

Re: [PATCH 28/65] x86/hvm: Annotate fnptr targets from hvm_funcs

On 26.11.2021 13:34, Andrew Cooper wrote: > In svm.c, make a few rearrangements. svm_update_guest_cr() has no external > callers so can become static, but needs moving along with svm_fpu_enter() to > avoid a forward declaration. Also move svm_update_guest_efer() to drop its > forward declaration.

[XEN PATCH 0/1] Add support for SMBIOS tables 7,8,9,26,27,28.

This update is done to improve virtual machine stealth from malware. There are AntiVM techniques that use WMI-queries to detect presence of this SMBIOS tables. Example: "https://github.com/LordNoteworthy/al-khaser/blob/master/al-khaser/AntiVM/Generic.cpp"; Anton Belousov (1): Add suport for S

[XEN PATCH 1/1] Add suport for SMBIOS tables 7,8,9,26,27,28 to improve virtual machine stealth from malware.

--- tools/firmware/hvmloader/smbios.c | 146 tools/firmware/hvmloader/smbios_types.h | 76 2 files changed, 222 insertions(+) diff --git a/tools/firmware/hvmloader/smbios.c b/tools/firmware/hvmloader/smbios.c index 97a054e9e3..f5e61c1159 100644 --- a/

Re: [PATCH 19/65] xen/tasklet: Annotate fnptr targets

On 26.11.2021 13:34, Andrew Cooper wrote: > The function pointer cast in hvm_vcpu_initialise() is undefined behaviour. > > While it happens to function correctly before this point, it is not > incompatible with control flow typechecking, DYM "is now incompatible" or "is not compatible"? > so int

Re: [PATCH 17/65] xen/evtchn: Annotate fnptr targets

On 26.11.2021 13:33, Andrew Cooper wrote: > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -99,7 +99,8 @@ static xen_event_channel_notification_t __read_mostly > xen_consumers[NR_XEN_CONSUMERS]; > > /* Default notification action: wake up from wait_on_xen_event_cha

[qemu-mainline test] 166950: tolerable FAIL - PUSHED

flight 166950 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/166950/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate fail in 166948 pass in 166950 test-arm64-arm64-libvirt-raw 12

Re: Patches for stable 5.10 kernel

On Mon, Nov 29, 2021 at 08:19:18AM +0100, Juergen Gross wrote: > Hi Greg, > > could you please add the following upstream patches to the stable 5.10 > kernel (I'll send separate mails for the older stable kernels as some > of the patches don't apply for those)? They are hardening Xen PV > frontend

[ovmf test] 166951: all pass - PUSHED

flight 166951 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/166951/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 76a1ce4d5fec7cd6906e6ea4ed6a4276b700e7ae baseline version: ovmf ef9a059cdb15844fe52a4

Re: [PATCH v2 28/45] mfd: rn5t618: Use devm_register_power_handler()

29.11.2021 14:55, Lee Jones пишет: > On Thu, 28 Oct 2021, Dmitry Osipenko wrote: > >> Use devm_register_power_handler() that replaces global pm_power_off >> variable and allows to register multiple power-off handlers. It also >> provides restart-handler support, i.e. all in one API. >> >> Signed-o

Re: [PATCH v2 28/45] mfd: rn5t618: Use devm_register_power_handler()

On Thu, 28 Oct 2021, Dmitry Osipenko wrote: > Use devm_register_power_handler() that replaces global pm_power_off > variable and allows to register multiple power-off handlers. It also > provides restart-handler support, i.e. all in one API. > > Signed-off-by: Dmitry Osipenko > --- > drivers/mf

Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API

29.11.2021 03:36, Michał Mirosław пишет: > On Mon, Nov 29, 2021 at 12:53:51AM +0300, Dmitry Osipenko wrote: >> 29.11.2021 00:17, Michał Mirosław пишет: I'm having trouble with parsing this comment. Could you please try to rephrase it? I don't see how you could check whether power-off hand

Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority

29.11.2021 03:26, Michał Mirosław пишет: > On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote: >> 28.11.2021 03:28, Michał Mirosław пишет: >>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote: Add sanity check which ensures that there are no two restart handlers >>>

Re: [PATCH 01/65] x86: Introduce support for CET-IBT

On 29/11/2021 09:27, Jan Beulich wrote: > On 26.11.2021 13:33, Andrew Cooper wrote: >> --- a/xen/arch/x86/arch.mk >> +++ b/xen/arch/x86/arch.mk >> @@ -46,6 +46,12 @@ CFLAGS-$(CONFIG_INDIRECT_THUNK) += >> -mindirect-branch=thunk-extern >> CFLAGS-$(CONFIG_INDIRECT_THUNK) += -mindirect-branch-regist

Re: [patch 09/22] MIPS: Octeon: Use arch_setup_msi_irq()

On Sat, Nov 27, 2021 at 02:18:48AM +0100, Thomas Gleixner wrote: > The core code provides the same loop code except for the MSI-X reject. Move > that to arch_setup_msi_irq() and remove the duplicated code. > > No functional change. > > Signed-off-by: Thomas Gleixner > Cc: Thomas Bogendoerfer >

Re: [PATCH 04/65] x86/hypercall: Annotate fnptr targets

On 29.11.2021 10:38, Jan Beulich wrote: > On 26.11.2021 15:28, Andrew Cooper wrote: >> On 26/11/2021 14:21, Jan Beulich wrote: >>> On 26.11.2021 13:33, Andrew Cooper wrote: --- a/xen/include/xen/hypercall.h +++ b/xen/include/xen/hypercall.h @@ -18,12 +18,12 @@ #include #

Re: [patch 00/22] genirq/msi, PCI/MSI: Spring cleaning - Part 1

On 11/27/21 02:18, Thomas Gleixner wrote: The [PCI] MSI code has gained quite some warts over time. A recent discussion unearthed a shortcoming: the lack of support for expanding PCI/MSI-X vectors after initialization of MSI-X. PCI/MSI-X has no requirement to setup all vectors when MSI-X is enab

Re: [PATCH 04/65] x86/hypercall: Annotate fnptr targets

On 26.11.2021 15:28, Andrew Cooper wrote: > On 26/11/2021 14:21, Jan Beulich wrote: >> On 26.11.2021 13:33, Andrew Cooper wrote: >>> Signed-off-by: Andrew Cooper >> I understand there's not much to say here, but the title saying just >> "annotate" without any context as to the purpose of the annot

Re: [patch 10/22] genirq/msi, treewide: Use a named struct for PCI/MSI attributes

Thomas Gleixner writes: > The unnamed struct sucks and is in the way of further cleanups. Stick the > PCI related MSI data into a real data structure and cleanup all users. > > No functional change. > > Signed-off-by: Thomas Gleixner > Cc: Greg Kroah-Hartman > Cc: sparcli...@vger.kernel.org > C

Re: [PATCH 01/65] x86: Introduce support for CET-IBT

On 26.11.2021 13:33, Andrew Cooper wrote: > --- a/xen/arch/x86/arch.mk > +++ b/xen/arch/x86/arch.mk > @@ -46,6 +46,12 @@ CFLAGS-$(CONFIG_INDIRECT_THUNK) += > -mindirect-branch=thunk-extern > CFLAGS-$(CONFIG_INDIRECT_THUNK) += -mindirect-branch-register > CFLAGS-$(CONFIG_INDIRECT_THUNK) += -fno-j

Re: [PATCH 01/65] x86: Introduce support for CET-IBT

On 26.11.2021 16:21, Andrew Cooper wrote: > On 26/11/2021 14:10, Jan Beulich wrote: >> On 26.11.2021 13:33, Andrew Cooper wrote: >>> @@ -124,6 +129,18 @@ config XEN_SHSTK >>> When CET-SS is active, 32bit PV guests cannot be used. Backwards >>> compatiblity can be provided via the PV Sh

Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking

On 27.11.2021 00:49, Andrew Cooper wrote: > Given that Marek has kindly hacked us up a check which should find any > arbitrary violations, and on a small sample of builds, there are no > violations, I suggest that we clean it up and put it as a check in the > real build and enable it by default see

[PATCH 3/3] x86/vPMU: move vpmu_ops to .init.data

Both vendors' code populates all hooks, so there's no need to have any NULL checks before invoking the hook functions. With that the only remaining uses of the object are in alternative_{,v}call(), i.e. none after alternatives patching. In vpmu_arch_initialise() the check gets replaced by an opt_v

[PATCH 2/3] x86/vPMU: invoke _vpmu_initialise() through a hook as well

I see little point in having an open-coded switch() statement to achieve the same; like other vendor-specific operations the function can be supplied in the respective ops structure instances. Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/vpmu.c +++ b/xen/arch/x86/cpu/vpmu.c @@ -455,21 +455,

[PATCH 1/3] x86/vPMU: convert vendor hook invocations to altcall

At least some vPMU functions will be invoked (and hence can further be speculated into) even in the vPMU-disabled case. Convert vpmu_ops to the standard single-instance model being a prerequisite to engaging the alternative_call() machinery, and convert all respective calls. Note that this requires

[PATCH 0/3] x86/vPMU: adjustements to vendor hooks treatment

In the context of [1] the 1st patch will be of interest, whereas the other changes are a result of observations while doing that conversion. 1: convert vendor hook invocations to altcall 2: invoke _vpmu_initialise() through a hook as well 3: move vpmu_ops to .init.data Jan [1] https://lists.xen.

[PATCH] x86/HVM: convert most remaining hvm_funcs hook invocations to alt-call

The aim being to have as few indirect calls as possible (see [1]), whereas during initial conversion performance was the main aspect and hence rarely used hooks didn't get converted. Apparently one use of get_interrupt_shadow() was missed at the time. While I've intentionally left alone the cpu_{u

Re: [PATCH 0/4] x86: Further harden function pointers

On 26.11.2021 22:22, Andrew Cooper wrote: > Slightly RFC, because patch 2 has some minor structure (ab)use, but the result > works alarmingly well. So far, this demonstrates converting two subsystems. > > hvm_funcs is the other area of especially low hanging fruit, but IOMMU, vPMU > also look lik

[ovmf test] 166949: all pass - PUSHED

flight 166949 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/166949/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ef9a059cdb15844fe52a49af2bf7d86b9dd3e9bf baseline version: ovmf bb1bba3d776733c41dbfa