Re: [PATCH v3 2/4] xen: make VMAP only support in MMU system

On 13.08.2024 19:13, Ayan Kumar Halder wrote: > From: Penny Zheng > > Introduced CONFIG_VMAP which is selected by the architectures that use > MMU. vm_init() does not do anything if CONFIG_VMAP is not enabled. > > VMAP is widely used in ALTERNATIVE feature to remap a range of memory > with new m

Re: AMD EPYC virtual network performances

On 14.08.24 00:36, Elliott Mitchell wrote: On Tue, Aug 13, 2024 at 08:55:42PM +0200, Jürgen Groß wrote: On 13.08.24 19:49, Elliott Mitchell wrote: On Tue, Aug 13, 2024 at 01:16:06PM +0200, Jürgen Groß wrote: I don't see a connection here, as spurious interrupts (as seen by the hypervisor in y

[xen-unstable-smoke test] 187234: tolerable all pass - PUSHED

flight 187234 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/187234/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 1

[xen-4.16-testing test] 187228: tolerable FAIL - PUSHED

flight 187228 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/187228/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186876 test-amd64-amd64-xl-qemut-win7-a

Re: [PATCH v1 04/10] hw/arm: xenpvh: Add support for SMP guests

On Tue, 13 Aug 2024, Edgar E. Iglesias wrote: > On Mon, Aug 12, 2024 at 06:47:17PM -0700, Stefano Stabellini wrote: > > On Mon, 12 Aug 2024, Edgar E. Iglesias wrote: > > > From: "Edgar E. Iglesias" > > > > > > Add SMP support for Xen PVH ARM guests. Create max_cpus ioreq > > > servers to handle h

Re: AMD EPYC virtual network performances

On Tue, Aug 13, 2024 at 08:55:42PM +0200, Jürgen Groß wrote: > On 13.08.24 19:49, Elliott Mitchell wrote: > > On Tue, Aug 13, 2024 at 01:16:06PM +0200, Jürgen Groß wrote: > > > > > > I don't see a connection here, as spurious interrupts (as seen by the > > > hypervisor in your case) and spurious e

Re: [PATCH v4] mm: introduce xvmalloc() et al and use for grant table allocations

Hi Jan, On 01/08/2024 07:30, Jan Beulich wrote: All of the array allocations in grant_table_init() can exceed a page's worth of memory, which xmalloc()-based interfaces aren't really suitable for after boot. We also don't need any of these allocations to be physically contiguous. Introduce inter

Re: [PATCH] tools/xenstored: switch stubdom live update to use file for state

Hi Juergen, On 31/07/2024 15:21, Juergen Gross wrote: With the introduction of 9pfs for Xenstore-stubdom it is now possible to use a file for saving the state when doing live update. This allows to move some environment specific actions back to the common source file lu.c. Signed-off-by: Juerg

Re: [PATCH] drivers: char: omap-uart: add "clock-hz" option

Hi Amneesh, Sorry for the late answer. On 06/08/2024 12:50, Amneesh Singh wrote: need to specify the clockspeed on the command line. I think we should investigate other approaches such as implementing partially clk_get_rate() (if this is how Linux manage to retrieve the clock speed without any

Re: [PATCH] xen/arm64: entry: Actually skip do_trap_*() when an SError is triggered

Hi, On 06/08/2024 14:30, Julien Grall wrote: On 06/08/2024 14:26, Michal Orzel wrote: Hi Julien, On 06/08/2024 14:48, Julien Grall wrote: From: Julien Grall For SErrors, we support two configurations:    * Every SErrors will result to a panic in Xen    * We will forward SErrors triggere

Re: [PATCH v1 1/1] xen/arm: smmuv3: Mark more init-only functions with __init

Hi Edgar, On 09/08/2024 11:23, Edgar E. Iglesias wrote: On Wed, Jun 5, 2024 at 11:55 AM Rahul Singh > wrote: Hi Edgar, > On 22 May 2024, at 2:28 PM, Edgar E. Iglesias mailto:edgar.igles...@gmail.com>> wrote: > > From: "Edgar E. Iglesias" mailt

Re: [PATCH v2] Arm: correct FIXADDR_TOP

Hi, On 13/08/2024 12:57, Michal Orzel wrote: On 13/08/2024 13:49, Jan Beulich wrote: While reviewing a RISC-V patch cloning the Arm code, I noticed an off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range and FIX_LAST being the same as FIX_PMAP_END, FIXADDR_TOP cannot derive from FIX

[xen-unstable-smoke test] 187227: regressions - FAIL

flight 187227 xen-unstable-smoke real [real] flight 187232 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/187227/ http://logs.test-lab.xenproject.org/osstest/logs/187232/ Regressions :-( Tests which did not succeed and are blocking, including tests which co

[xen-unstable test] 187224: tolerable FAIL - PUSHED

flight 187224 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/187224/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187220 test-amd64-amd64-xl-qemuu-ws16-amd64

[RFC-for-4.20 v2 1/1] x86/hvm: Introduce Xen-wide ASID allocator

Currently ASID generation and management is done per-PCPU. This scheme is incompatible with SEV technologies as SEV VMs need to have a fixed ASID associated with all vcpus of the VM throughout it's lifetime. This commit introduces a Xen-wide allocator which initializes the asids at the start of xe

[RFC-for-4.20 v2 0/1] x86/hvm: Introduce Xen-wide ASID allocator

Motivation: --- This is part of the effort to enable AMD SEV technologies in Xen. For AMD SEV support, we need a fixed ASID associated with all vcpus of the same domain throughout the domain's lifetime. This is because for SEV/ SEV-{ES,SNP} VM, the ASID is the index which is associated with

Re: AMD EPYC virtual network performances

On 13.08.24 19:49, Elliott Mitchell wrote: On Tue, Aug 13, 2024 at 01:16:06PM +0200, Jürgen Groß wrote: On 13.08.24 03:10, Elliott Mitchell wrote: On Tue, Jul 09, 2024 at 11:37:07AM +0200, Jürgen Groß wrote: In both directories you can see the number of spurious events by looking into the spu

Re: AMD EPYC virtual network performances

On Tue, Aug 13, 2024 at 01:16:06PM +0200, Jürgen Groß wrote: > On 13.08.24 03:10, Elliott Mitchell wrote: > > On Tue, Jul 09, 2024 at 11:37:07AM +0200, Jürgen Groß wrote: > > > > > > In both directories you can see the number of spurious events by looking > > > into the spurious_events file. > > >

Re: [PATCH v1 04/10] hw/arm: xenpvh: Add support for SMP guests

On 13/08/2024 6:02 pm, Edgar E. Iglesias wrote: > On Mon, Aug 12, 2024 at 06:47:17PM -0700, Stefano Stabellini wrote: >> On Mon, 12 Aug 2024, Edgar E. Iglesias wrote: >>> From: "Edgar E. Iglesias" >>> >>> Add SMP support for Xen PVH ARM guests. Create max_cpus ioreq >>> servers to handle hotplug.

[PATCH v3 3/4] xen: arm: Move the functions of domain_page to MMU specific

Moved init_domheap_mappings(), map_domain_page_global(), unmap_domain_page_global(), map_domain_page(), unmap_domain_page(), domain_page_map_to_mfn() to MMU specific folder. Signed-off-by: Ayan Kumar Halder --- Changes from :- v1 - Moved domain_page.c to mmu/domain_page.c. v2 - Updated arm/Make

[PATCH v3 4/4] xen: arm: Enclose access to EL2 MMU specific registers under CONFIG_MMU

All the EL2 MMU specific registers are enclosed within CONFIG_MMU. Signed-off-by: Ayan Kumar Halder --- Changes from : v1 - 1. 'vttbr_el2' field is enclosed with ifdef. 2. No movement of code. v2 - 1. Enclosed 'vttbr_el2' access in show_registers() and vcpu_show_registers(). xen/arch/arm/trap

[PATCH v3 1/4] xen: arm: Add a new helper update_boot_mapping()

update_boot_mapping() invokes update_identity_mapping() for the MMU specific code. Later when the MPU code is added, update_boot_mapping() would invoke the equivalent. The common code now invokes update_boot_mapping() instead of update_identity_mapping(). So, that there is clear abstraction betwee

[PATCH v3 2/4] xen: make VMAP only support in MMU system

From: Penny Zheng Introduced CONFIG_VMAP which is selected by the architectures that use MMU. vm_init() does not do anything if CONFIG_VMAP is not enabled. VMAP is widely used in ALTERNATIVE feature to remap a range of memory with new memory attributes. Since this is highly dependent on virtual

[PATCH v3 0/4] xen: arm: Split MMU code in preparation for MPU work (part 2)

Hi, In https://patchew.org/Xen/20231116145032.1651305-1-henry.w...@arm.com/, Henry has reorganized some of the code between the MMU specific and generic files. In this patch serie, we address the remaining code reorg so that MMU specific code is cleanly separated and we have added stubs wherever

Re: [PATCH v1 04/10] hw/arm: xenpvh: Add support for SMP guests

On Mon, Aug 12, 2024 at 06:47:17PM -0700, Stefano Stabellini wrote: > On Mon, 12 Aug 2024, Edgar E. Iglesias wrote: > > From: "Edgar E. Iglesias" > > > > Add SMP support for Xen PVH ARM guests. Create max_cpus ioreq > > servers to handle hotplug. > > > > Signed-off-by: Edgar E. Iglesias > > ---

Re: [PATCH] Fixed incorrect output in xl's "help" command.

On Mon, Aug 05, 2024 at 04:14:34PM +0200, Juergen Gross wrote: > On 05.08.24 16:11, John E. Krokes wrote: > > In "xl help", the output includes this line: > > > > vsnd-list List virtual display devices for a domain > > > > This should obviously say "sound devices" instead of "display

Re: [PATCH] libxl/disk: avoid aliasing of abs()

On Tue, Aug 06, 2024 at 10:40:14AM +0200, Jan Beulich wrote: > Tool chains with -Wshadow enabled by default won't like the function > parameter name "abs", for aliasing stdlib.h's abs(). Rename the > parameter to what other similar functions use. > > Fixes: a18b50614d97 ("libxl: Enable stubdom cdr

Re: [PATCH v3 2/2] x86/fpu: Split fpu_setup_fpu() in three

On Tue Aug 13, 2024 at 3:32 PM BST, Jan Beulich wrote: > On 13.08.2024 16:21, Alejandro Vallejo wrote: > > It was trying to do too many things at once and there was no clear way of > > defining what it was meant to do. This commit splits the function in three. > > > > 1. A function to return the

Re: [PATCH 04/22] x86/mm: ensure L4 idle_pg_table is not modified past boot

On 26.07.2024 17:21, Roger Pau Monne wrote: > The idle_pg_table L4 is cloned to create all the other L4 Xen uses, and hence > it shouldn't be modified once further L4 are created. Yes, but the window between moving into SYS_STATE_smp_boot and Dom0 having its initial page tables created is quite la

[linux-linus test] 187223: regressions - FAIL

flight 187223 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187223/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827 test-arm64-arm64-xl

Re: [PATCH] x86emul: fix UB multiplications in S/G handling

On 13.08.2024 17:16, Andrew Cooper wrote: > On 13/08/2024 2:19 pm, Andrew Cooper wrote: >> On 13/08/2024 1:43 pm, Jan Beulich wrote: >>> The conversion of the shifts to multiplications by the commits tagged >>> below still wasn't quite right: The multiplications (of signed values) >>> can overflow,

Re: [PATCH] x86emul: fix UB multiplications in S/G handling

On 13/08/2024 2:19 pm, Andrew Cooper wrote: > On 13/08/2024 1:43 pm, Jan Beulich wrote: >> The conversion of the shifts to multiplications by the commits tagged >> below still wasn't quite right: The multiplications (of signed values) >> can overflow, too. As of 298556c7b5f8 ("x86emul: correct 32-b

Re: [PATCH v3 2/2] x86/fpu: Split fpu_setup_fpu() in three

On 13.08.2024 16:21, Alejandro Vallejo wrote: > It was trying to do too many things at once and there was no clear way of > defining what it was meant to do. This commit splits the function in three. > > 1. A function to return the FPU to power-on reset values. > 2. A function to return the FP

[PATCH v3 2/2] x86/fpu: Split fpu_setup_fpu() in three

It was trying to do too many things at once and there was no clear way of defining what it was meant to do. This commit splits the function in three. 1. A function to return the FPU to power-on reset values. 2. A function to return the FPU to default values. 3. A x87/SSE state loader (equiva

[PATCH v3 0/2] x86: FPU handling cleanup

v2: https://lore.kernel.org/xen-devel/20240808134150.29927-1-alejandro.vall...@cloud.com/T/#t v2 -> v3: Cosmetic changes and wiped big comment about missing data in the migration stream. Details in each patch. v1: https://lore.kernel.org/xen-devel/cover.1720538832.git.alejandro.vall...

[PATCH v3 1/2] x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu

fpu_ctxt is either a pointer to the legacy x87/SSE save area (used by FXSAVE) or a pointer aliased with xsave_area that points to its fpu_sse subfield. Such subfield is at the base and is identical in size and layout to the legacy buffer. This patch merges the 2 pointers in the arch_vcpu into a si

Re: [PATCH v3] x86/msi: fix locking for SR-IOV devices

On 12.08.2024 22:39, Stewart Hildebrand wrote: > In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci > structure") a lock moved from allocate_and_map_msi_pirq() to the caller > and changed from pcidevs_lock() to read_lock(&d->pci_lock). However, one > call path wasn't updated to

[PATCH v2 0/3] mini-os: mm: use a generic page table walker

Instead of open coding a page table walk multiple times, use a generic page table walker instead. This new page table walker will be used later for kexec support, too. Changes in V2: - addressed comments Juergen Gross (3): mini-os: mm: introduce generic page table walk function mini-os: mm:

[PATCH v2 2/3] mini-os: mm: switch need_pgt() to use walk_pt()

Instead of open coding a page table walk, use walk_pt() in need_pgt(). Signed-off-by: Juergen Gross --- V2: - add comment and ASSERT() (Samuel Thibault) --- arch/x86/mm.c | 72 +-- 1 file changed, 30 insertions(+), 42 deletions(-) diff --git a/arc

[PATCH v2 3/3] mini-os: mm: convert set_readonly() to use walk_pt()

Instead of having another copy of a page table walk in set_readonly(), just use walk_pt(). As it will be needed later anyway, split out the TLB flushing into a dedicated function. Signed-off-by: Juergen Gross --- V2: - clear count after doing an mmu_update call (Samuel Thibault) - do final mmu_u

[PATCH v2 1/3] mini-os: mm: introduce generic page table walk function

In x86 mm code there are multiple instances of page table walks for different purposes. Introduce a generic page table walker being able to cover the current use cases. It will be used for other cases in future, too. The page table walker needs some per-level data, so add a table for that data. M

Re: [PATCH] x86emul: fix UB multiplications in S/G handling

On 13/08/2024 1:43 pm, Jan Beulich wrote: > The conversion of the shifts to multiplications by the commits tagged > below still wasn't quite right: The multiplications (of signed values) > can overflow, too. As of 298556c7b5f8 ("x86emul: correct 32-bit address > handling for AVX2 gathers") signed m

Re: [PATCH 22/22] x86/mm: zero stack on stack switch or reset

On 26.07.2024 17:22, Roger Pau Monne wrote: > With the stack mapped on a per-CPU basis there's no risk of other CPUs being > able to read the stack contents, but vCPUs running on the current pCPU could > read stack rubble from operations of previous vCPUs. > > The #DF stack is not zeroed because h

Re: [PATCH v2 2/2] x86/fpu: Split fpu_setup_fpu() in two

On 13.08.2024 14:40, Alejandro Vallejo wrote: > On Mon Aug 12, 2024 at 4:23 PM BST, Jan Beulich wrote: >> On 08.08.2024 15:41, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -1164,10 +1164,25 @@ static int cf_check hvm_load_cpu_ctxt(struct domain

[PATCH] x86emul: fix UB multiplications in S/G handling

The conversion of the shifts to multiplications by the commits tagged below still wasn't quite right: The multiplications (of signed values) can overflow, too. As of 298556c7b5f8 ("x86emul: correct 32-bit address handling for AVX2 gathers") signed multiplication wasn't necessary anymore, though: Th

Re: [PATCH v2 2/2] x86/fpu: Split fpu_setup_fpu() in two

On Mon Aug 12, 2024 at 4:23 PM BST, Jan Beulich wrote: > On 08.08.2024 15:41, Alejandro Vallejo wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -1164,10 +1164,25 @@ static int cf_check hvm_load_cpu_ctxt(struct domain > > *d, hvm_domain_context_t *h) > > seg.att

Re: [PATCH v2 1/2] x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu

On Mon Aug 12, 2024 at 4:16 PM BST, Jan Beulich wrote: > On 08.08.2024 15:41, Alejandro Vallejo wrote: > > --- a/xen/arch/x86/domctl.c > > +++ b/xen/arch/x86/domctl.c > > @@ -1344,7 +1344,10 @@ void arch_get_info_guest(struct vcpu *v, > > vcpu_guest_context_u c) > > #define c(fld) (c.nat->fld) >

Re: [PATCH v2] Arm: correct FIXADDR_TOP

On 13/08/2024 13:49, Jan Beulich wrote: > > > While reviewing a RISC-V patch cloning the Arm code, I noticed an > off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range and > FIX_LAST being the same as FIX_PMAP_END, FIXADDR_TOP cannot derive from > FIX_LAST alone, or else the BUG_ON() in

[PATCH v2] Arm: correct FIXADDR_TOP

While reviewing a RISC-V patch cloning the Arm code, I noticed an off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range and FIX_LAST being the same as FIX_PMAP_END, FIXADDR_TOP cannot derive from FIX_LAST alone, or else the BUG_ON() in virt_to_fix() would trigger if FIX_PMAP_END ended up bei

[libvirt test] 187221: tolerable all pass - PUSHED

flight 187221 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/187221/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187204 test-amd64-amd64-libvirt-xsm 15 migrate-s

Re: AMD EPYC virtual network performances

On 13.08.24 03:10, Elliott Mitchell wrote: On Tue, Jul 09, 2024 at 11:37:07AM +0200, Jürgen Groß wrote: In both directories you can see the number of spurious events by looking into the spurious_events file. In the end the question is why so many spurious events are happening. Finding the reas

Re: [REGRESSION] kernel NULL pointer dereference in xen-balloon with mem hotplug

On 08.08.24 12:31, Marek Marczykowski-Górecki wrote: Hi, When testing Linux 6.11-rc2, I've got the crash like below. It's a PVH guest started with 400MB memory, and then extended via mem hotplug (I don't know to what exact size it was at this time, but up to 4GB), it was quite early in the domU

Re: [PATCH v4 6/7] xen/riscv: page table handling

On 09.08.2024 18:19, Oleksii Kurochko wrote: > Implement map_pages_to_xen() which requires several > functions to manage page tables and entries: > - pt_update() > - pt_mapping_level() > - pt_update_entry() > - pt_next_level() > - pt_check_entry() > > To support these operations, add functions for

[xen-unstable test] 187220: tolerable FAIL

flight 187220 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/187220/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187215 test-amd64-amd64-xl-qemuu-ws16-amd64

Re: [RFC PATCH] xen: Remove -Wdeclaration-after-statement

On Fri, Aug 9, 2024 at 2:04 PM Alejandro Vallejo wrote: > > This warning only makes sense when developing using a compiler with C99 > support on a codebase meant to be built with C89 compilers too, and > that's no longer the case (nor should it be, as it's been 25 years since > C99 came out alread

Re: [PATCH] Arm: correct FIX_LAST

On 13/08/2024 10:36, Jan Beulich wrote: > > > While reviewing a RISC-V patch cloning the Arm code, I noticed an > off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range, FIX_LAST > cannot be the same as FIX_PMAP_END, or else the BUG_ON() in > virt_to_fix() would trigger if FIX_PMAP_END e

Re: [PATCH v4 5/7] xen/riscv: introduce and initialize SBI RFENCE extension

On 09.08.2024 18:19, Oleksii Kurochko wrote: > @@ -31,4 +65,34 @@ struct sbiret sbi_ecall(unsigned long ext, unsigned long > fid, > */ > void sbi_console_putchar(int ch); > > +/* > + * Check underlying SBI implementation has RFENCE > + * > + * @return 1 for supported AND 0 for not-supported >

Re: [PATCH v4 4/7] xen/riscv: introduce functionality to work with CPU info

On 09.08.2024 18:19, Oleksii Kurochko wrote: > Introduce struct pcpu_info to store pCPU-related information. > Initially, it includes only processor_id, but it will be extended > to include guest CPU information and temporary variables for > saving/restoring vCPU registers. > > Add set_processor_i

Re: [PATCH v4 3/7] xen/riscv: introduce asm/pmap.h header

On 09.08.2024 18:19, Oleksii Kurochko wrote: > Introduce arch_pmap_{un}map functions and select HAS_PMAP for CONFIG_RISCV. > > Add pte_from_mfn() for use in arch_pmap_map(). > > Introduce flush_xen_tlb_one_local() and use it in arch_pmap_{un}map(). > > Signed-off-by: Oleksii Kurochko Reviewed-

[PATCH] Arm: correct FIX_LAST

While reviewing a RISC-V patch cloning the Arm code, I noticed an off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range, FIX_LAST cannot be the same as FIX_PMAP_END, or else the BUG_ON() in virt_to_fix() would trigger if FIX_PMAP_END ended up being used. Fixes: 4f17357b52f6 ("xen/arm: add P

Re: [PATCH v4 2/7] xen/riscv: set up fixmap mappings

On 09.08.2024 18:19, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/config.h > +++ b/xen/arch/riscv/include/asm/config.h > @@ -74,6 +74,14 @@ > #error "unsupported RV_STAGE1_MODE" > #endif > > +#define XEN_VIRT_SIZE MB(2) > + > +#define BOOT_FDT_VIRT_START (XEN_VIRT_ST

Re: [XEN PATCH v1 2/2] x86/amd: optional build of amd.c

On 09.08.2024 12:11, Sergiy Kibrik wrote: > --- a/xen/arch/x86/include/asm/amd.h > +++ b/xen/arch/x86/include/asm/amd.h > @@ -158,13 +158,21 @@ > #define is_zen4_uarch() boot_cpu_has(X86_FEATURE_AUTO_IBRS) > > struct cpuinfo_x86; > +#ifdef CONFIG_AMD > int cpu_has_amd_erratum(const struct cp

Re: [XEN PATCH v1 1/2] x86/intel: optional build of intel.c

On 09.08.2024 12:09, Sergiy Kibrik wrote: > With specific config option INTEL in place and most of the code that depends > on intel.c now can be optionally enabled/disabled it's now possible to put > the whole intel.c under INTEL option as well. This will allow for a Xen build > without Intel CPU s

Re: [XEN PATCH v6 2/3] ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations

On 08.08.2024 12:10, Sergiy Kibrik wrote: > From: Xenia Ragiadakou > > VIO_realmode_completion is specific to vmx realmode and thus the function > arch_vcpu_ioreq_completion() has actual handling work only in VMX-enabled > build, > as for the rest x86 and ARM build configurations it is basically

Re: [XEN PATCH v6 1/3] x86/vmx: guard access to cpu_has_vmx_* in common code

On 08.08.2024 12:08, Sergiy Kibrik wrote: > There're several places in common code, outside of arch/x86/hvm/vmx, > where cpu_has_vmx_* get accessed without checking whether VMX supported first. > These macros rely on global variables defined in vmx code, so when VMX support > is disabled accesses t

Re: [PATCH v2 2/4] xen: arm: make VMAP only support in MMU system

On 12.08.2024 18:02, Ayan Kumar Halder wrote: > Hi Jan, > > On 09/08/2024 10:34, Jan Beulich wrote: >> On 08.08.2024 17:50, Ayan Kumar Halder wrote: >>> On 08/08/2024 13:49, Jan Beulich wrote: On 08.08.2024 14:09, Ayan Kumar Halder wrote: > @@ -58,9 +58,13 @@ config PADDR_BITS >

Re: [PATCH] x86: slightly simplify MB2/EFI "magic" check

On 12.08.2024 23:40, Andrew Cooper wrote: > On 08/08/2024 9:49 am, Jan Beulich wrote: >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -233,13 +233,11 @@ __efi64_mb2_start: >> >> /* Check for Multiboot2 bootloader. */ >> cmp $MULTIBOOT2_BOOTLOADER_MA