On 16:24-20240820, Anthony PERARD wrote:
> On Tue, Aug 20, 2024 at 01:34:17PM +0530, Amneesh Singh wrote:
> > diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> > index fee9345..722a5af 100644
> > --- a/tools/helpers/init-dom0less.c
> > +++ b/to
Hello,
On 10:03-20240820, Julien Grall wrote:
> Hi,
>
> On 20/08/2024 10:00, Michal Orzel wrote:
> > On 20/08/2024 10:22, Amneesh Singh wrote:
> >>
> >>
> >> Quite a few TI K3 devices do not have clock-frequency specified in their
> >> respecti
On Tue, 20 Aug 2024, Anthony PERARD wrote:
> On Mon, Aug 19, 2024 at 06:56:47PM -0700, Stefano Stabellini wrote:
> > On Mon, 19 Aug 2024, Anthony PERARD wrote:
> > > On Mon, Aug 19, 2024 at 09:21:22AM +0200, Michal Orzel wrote:
> > > > On 17/08/2024 01:46, Stefano Stabellini wrote:
> > > > > diff -
On Tue, 20 Aug 2024, Federico Serafini wrote:
> Update ECLAIR configuration to deviate more cases where an
> unintentional fallthrough cannot happen.
>
> Tag Rule 16.3 as clean for arm.
>
> Signed-off-by: Federico Serafini
> ---
> Hi, v4 of this patch has been on hold due to discussion on whethe
flight 187293 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187293/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187286
test-amd64-amd64-xl-qemuu-ws16-amd64
On Tue, 20 Aug 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add support for optionally creating a PCIe/GPEX controller.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> hw/xen/xen-pvh-common.c | 76 +
> i
On Tue, 20 Aug 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a Xen PVH x86 machine based on the abstract PVH Machine.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> hw/i386/xen/meson.build | 1 +
> hw/i386/xen/xen-pvh.c | 121
On Tue, 20 Aug 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Break out a common Xen PVH machine in preparation for
> adding a x86 Xen PVH machine.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> hw/arm/trace-events | 5 -
> hw/arm
On Tue, 20 Aug 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> hw/arm/meson.build | 5 -
> hw/arm/xen-stubs.c | 32
> hw/arm/xen_arm.c | 20
>
On Tue, 20 Aug 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> hw/arm/xen_arm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
> index fda65
On Tue, 20 Aug 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add SMP support for Xen PVH ARM guests.
> Create ms->smp.max_cpus ioreq servers to handle hotplug.
>
> Note that ms->smp.max_cpus will be passed to us by the
> user (Xen tools) set to the guests maxvcpus.
>
> The valu
Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with this, fix the following warning:
drivers/xen/pci.c:48:55: warning: structure contain
On Tue, 20 Aug 2024, Chen, Jiqian wrote:
> On 2024/8/19 17:16, Jan Beulich wrote:
> > On 16.08.2024 13:08, Jiqian Chen wrote:
> >> The gsi of a passthrough device must be configured for it to be
> >> able to be mapped into a hvm domU.
> >> But When dom0 is PVH, the gsis may not get registered(see b
On 8/20/24 03:01, Jan Beulich wrote:
> On 20.08.2024 08:00, Chen, Jiqian wrote:
>> On 2024/8/19 17:04, Jan Beulich wrote:
>>> On 16.08.2024 13:08, Jiqian Chen wrote:
@@ -67,6 +68,57 @@ ret_t pci_physdev_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
flight 187292 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187292/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187285
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Juergen,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/x86/core]
[also build test ERROR on rafael-pm/linux-next rafael-pm/bleeding-edge
linus/master v6.11-rc4 next-20240820]
[cannot apply to xen-tip/linux-next]
[If your patch is applied to the wrong git
From: Victor Lira
Change xen command line parameters to support new test board.
Abstract serial port device name and tftp boot directory.
Signed-off-by: Victor Lira
---
Cc: Stefano Stabellini
---
.../scripts/xilinx-smoke-dom0-x86_64.sh | 29 +++
.../scripts/xilinx-smoke-
Hi Juergen,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/x86/core]
[also build test ERROR on rafael-pm/linux-next rafael-pm/bleeding-edge
linus/master v6.11-rc4 next-20240820]
[cannot apply to xen-tip/linux-next]
[If your patch is applied to the wrong git
flight 187290 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187290/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187265
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 16/08/2024 7:11 am, Jan Beulich wrote:
> On 15.08.2024 18:34, Andrew Cooper wrote:
>> On 15/08/2024 4:41 pm, Jan Beulich wrote:
>>> On 15.08.2024 15:15, Andrew Cooper wrote:
Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB
is
buggy. The architectural beh
On 20.08.2024 16:42, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-20 at 15:47 +0200, Jan Beulich wrote:
>> On 20.08.2024 15:18, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
From all I can determine we also get here when making brand new
>>>
On Tue, Aug 20, 2024 at 01:34:17PM +0530, Amneesh Singh wrote:
> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> index fee9345..722a5af 100644
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-dom0less.c
> @@ -167,15 +167,20 @@ retry_transaction:
> /
flight 187289 qemu-mainline real [real]
flight 187294 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187289/
http://logs.test-lab.xenproject.org/osstest/logs/187294/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Tue, 2024-08-20 at 15:47 +0200, Jan Beulich wrote:
> On 20.08.2024 15:18, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
> > > > + * Sanity check of the entry
> > > > + * mfn is not valid and we are not populating page table. This
> > > > means
> > >
From: "Edgar E. Iglesias"
Add support for optionally creating a PCIe/GPEX controller.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-pvh-common.c | 76 +
include/hw/xen/xen-pvh-common.h | 29 +
2 files changed, 105 insertions(+)
diff --git
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
MAINTAINERS | 1 +
docs/system/i386/xenpvh.rst | 49 +
docs/system/target-i386.rst | 1 +
3 files changed, 51 insertions(+)
create mode 100644 d
From: "Edgar E. Iglesias"
Rename xen_arm.c -> xen-pvh.c to better express that this
is a PVH machine and to align with x86 HVM and future PVH
machine filenames:
hw/i386/xen/xen-hvm.c
hw/i386/xen/xen-pvh.c (in preparation)
No functional changes.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Ste
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
---
hw/arm/meson.build | 5 -
hw/arm/xen-stubs.c | 32
hw/arm/xen_arm.c | 20
3 files changed, 36 insertions(+), 21 deletions(-)
create mode 100644 hw/arm/xen-stubs.c
diff -
From: "Edgar E. Iglesias"
Add SMP support for Xen PVH ARM guests.
Create ms->smp.max_cpus ioreq servers to handle hotplug.
Note that ms->smp.max_cpus will be passed to us by the
user (Xen tools) set to the guests maxvcpus.
The value in mc->max_cpus is an absolute maximum for the
-smp option and
From: "Edgar E. Iglesias"
Add a Xen PVH x86 machine based on the abstract PVH Machine.
Signed-off-by: Edgar E. Iglesias
---
hw/i386/xen/meson.build | 1 +
hw/i386/xen/xen-pvh.c | 121
2 files changed, 122 insertions(+)
create mode 100644 hw/i386/xe
From: "Edgar E. Iglesias"
We've been creating the virtio-mmio devices in forwards order
but since the qbus lists prepend (rather than append) entries,
the virtio busses end up with decreasing base address order.
Xen enables virtio-mmio nodes in forwards order so there's been
a missmatch. So far,
From: "Edgar E. Iglesias"
This series breaks out parts of the ARM PVH support into an abstract
machine that other targets can reuse.. There's a bit of refactoring
and some bug-fixes along the way.
Finally we add a new x86 xen-pvh machine.
The corresponding changes in Xen for PVH x86 are work in
From: "Edgar E. Iglesias"
Update file header to use SPDX and remove stray empty
comment line.
No functional changes.
Signed-off-by: Edgar E. Iglesias
Acked-by: Stefano Stabellini
---
hw/arm/xen_arm.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/hw/a
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
---
hw/arm/xen_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
index fda65d0d8d..16b3f00992 100644
--- a/hw/arm/xen_arm.c
+++ b/hw/arm/xen_arm.c
@@ -165,7 +165,7 @@ static vo
From: "Edgar E. Iglesias"
Break out a common Xen PVH machine in preparation for
adding a x86 Xen PVH machine.
Signed-off-by: Edgar E. Iglesias
---
hw/arm/trace-events | 5 -
hw/arm/xen_arm.c| 198 +++
hw/xen/meson.build | 1 +
hw
From: "Edgar E. Iglesias"
Tweak machine description to better express that this is
a Xen PVH machine for ARM.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/arm/xen_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/xen_arm.c b/hw/arm/xen
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
Acked-by: Stefano Stabellini
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3584d6a6c6..c2fb0c2f42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -559,6 +559,7 @@ F: include/hw/xen/
On 20.08.24 16:17, Jan Beulich wrote:
On 20.08.2024 13:52, Samuel Thibault wrote:
Juergen Gross, le mar. 13 août 2024 15:41:56 +0200, a ecrit:
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 c
Jan Beulich, le mar. 20 août 2024 16:17:26 +0200, a ecrit:
> On 20.08.2024 13:52, Samuel Thibault wrote:
> > Juergen Gross, le mar. 13 août 2024 15:41:56 +0200, a ecrit:
> >> In x86 mm code there are multiple instances of page table walks for
> >> different purposes.
> >>
> >> Introduce a generic p
On 20.08.2024 13:52, Samuel Thibault wrote:
> Juergen Gross, le mar. 13 août 2024 15:41:56 +0200, a ecrit:
>> 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
On Tue, 2024-08-20 at 09:01 +0200, Jan Beulich wrote:
> I further question the related part of [2]: Why did the stub need
> moving?
The following stub could be return to Arm's asm/pci.h:
```
static inline bool is_pci_passthrough_enabled(void)
{
return false;
}
```
As at the moment it used only
On Sat, Aug 17, 2024 at 2:45 AM Jason Andryuk wrote:
> On 2024-08-16 12:53, Stefano Stabellini wrote:
> > On Fri, 16 Aug 2024, Edgar E. Iglesias wrote:
> >> On Thu, Aug 15, 2024 at 2:30 AM Stefano Stabellini <
> sstabell...@kernel.org> wrote:
> >>On Wed, 14 Aug 2024, Edgar E. Iglesias wro
On 20.08.2024 15:18, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
>>> + * Sanity check of the entry
>>> + * mfn is not valid and we are not populating page table. This
>>> means
>>
>> How does this fit with ...
>>
>>> + * we either modify entry or remove
On 14.08.2024 10:34, Frediano Ziglio wrote:
> Testing this feature in preparation for UEFI CA memory mitigation
> requirements I found some issues causing the loading to fail and
> other minor issues.
> Details in series commit messages.
> This is adding an additional way to boot Xen, using GrUB2+E
On 14.08.2024 10:34, Frediano Ziglio wrote:
> In case EFI not multiboot rolling back relocation is done in
> efi_arch_post_exit_boot, called by efi_start however this is
> not done in multiboot code path.
> Do it also for this path to make it work correctly.
>
> Signed-off-by: Frediano Ziglio
> -
On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
> > + * Sanity check of the entry
> > + * mfn is not valid and we are not populating page table. This
> > means
>
> How does this fit with ...
>
> > + * we either modify entry or remove an entry.
> > + */
> > +static bool pt_check_entry(pte_t
On 20.08.24 14:53, Jan Beulich wrote:
On 20.08.2024 13:57, Samuel Thibault wrote:
Juergen Gross, le mar. 13 août 2024 15:41:58 +0200, a ecrit:
+if ( ro->count == L1_PAGETABLE_ENTRIES )
+{
+ ro->count = 0;
+ if ( HYPERVISOR_mmu_update(mmu_updates, ro->count, NULL,
+
On 14.08.2024 10:34, Frediano Ziglio wrote:
> If code is loaded by EFI the loader will relocate the image
> under 4GB. This causes offsets in x86 code generated by
> sym_offs(SYMBOL) to be relocated too (basically they won't be
> offsets from image base).
In turn meaning that ...
> --- a/xen/arch
On 20.08.2024 13:57, Samuel Thibault wrote:
> Juergen Gross, le mar. 13 août 2024 15:41:58 +0200, a ecrit:
>> +if ( ro->count == L1_PAGETABLE_ENTRIES )
>> +{
>> + ro->count = 0;
>> + if ( HYPERVISOR_mmu_update(mmu_updates, ro->count, NULL,
>> +
On 20.08.2024 13:48, Ayan Kumar Halder wrote:
> So I will do :-
>
> 1. HARDEN_BRANCH_PREDICTOR will depend on MMU.
>
> 2. ARCH_VMAP will be selected by PPC and RISCV. The reason is below.
>
> 3. xen/common/vmap.c will be conditionally compiled on ARCH_VMAP and the
> "#ifdef VMAP_VIRT_START .. e
On Mon, Aug 19, 2024 at 06:56:47PM -0700, Stefano Stabellini wrote:
> On Mon, 19 Aug 2024, Anthony PERARD wrote:
> > On Mon, Aug 19, 2024 at 09:21:22AM +0200, Michal Orzel wrote:
> > > On 17/08/2024 01:46, Stefano Stabellini wrote:
> > > > diff --git a/automation/scripts/qemu-xtf-dom0less-arm64.sh
Juergen Gross, le mar. 13 août 2024 15:41:58 +0200, a ecrit:
> +if ( ro->count == L1_PAGETABLE_ENTRIES )
> +{
> + ro->count = 0;
> + if ( HYPERVISOR_mmu_update(mmu_updates, ro->count, NULL,
> +DOMID_SELF) < 0 )
You need to set ro->count *
Juergen Gross, le mar. 13 août 2024 15:41:57 +0200, a ecrit:
> Instead of open coding a page table walk, use walk_pt() in need_pgt().
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> V2:
> - add comment and ASSERT() (Samuel Thibault)
> ---
> arch/x86/mm.c | 72 +++
Juergen Gross, le mar. 13 août 2024 15:41:56 +0200, a ecrit:
> 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 p
Hi Julien/Jan,
On 19/08/2024 10:58, Julien Grall wrote:
On 19/08/2024 10:55, Julien Grall wrote:
Hi Ayan,
On 19/08/2024 10:45, Ayan Kumar Halder wrote:
I am ok with this. This has the benefit that the change can be
contained within arch/arm if we do the following :-
diff --git a/xen/arch/
On 14/08/2024 13:50, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 13/08/2024 19:13, Ayan Kumar Halder wrote:
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
From: Michal Orzel
Add the requirements for the use of generic timer by a domain
Signed-off-by: Michal Orzel
Signed-off-by: Ayan Kumar Halder
---
.../reqs/design-reqs/arm64/generic-timer.rst | 139 ++
docs/fusa/reqs/index.rst | 3 +
docs/fusa/reqs/intro
On 20.08.2024 10:20, Juergen Gross wrote:
> In order to minimize required special handling for running as Xen PV
> dom0, the memory layout is modified to match that of the host. This
> requires to have only RAM at the locations where Xen allocated memory
> is living. Unfortunately there seem to be
flight 187286 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187286/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187280
test-amd64-amd64-xl-qemuu-ws16-amd64
On 20.08.2024 10:20, Juergen Gross wrote:
> @@ -838,6 +839,31 @@ void __init xen_do_remap_nonram(void)
> pr_info("Remapped %u non-RAM page(s)\n", remapped);
> }
>
> +/*
> + * Xen variant of acpi_os_ioremap() taking potentially remapped non-RAM
> + * regions into acount.
> + * Any attempt t
On 20.08.2024 10:20, Juergen Gross wrote:
> When running as a Xen PV dom0 it can happen that the kernel is being
> loaded to a guest physical address conflicting with the host memory
> map.
>
> In order to be able to resolve this conflict, add the capability to
> remap non-RAM areas to different g
Hi,
On 20/08/2024 10:00, Michal Orzel wrote:
On 20/08/2024 10:22, Amneesh Singh wrote:
Quite a few TI K3 devices do not have clock-frequency specified in their
respective UART nodes. However hard-coding the frequency is not a
solution as the function clock input can differ between SoCs. So, u
On 20/08/2024 10:22, Amneesh Singh wrote:
>
>
> Quite a few TI K3 devices do not have clock-frequency specified in their
> respective UART nodes. However hard-coding the frequency is not a
> solution as the function clock input can differ between SoCs. So, use a
> default frequency of 48MHz if
On 20.08.2024 10:20, Juergen Gross wrote:
> Instead of having max_pfn as a local variable of xen_memory_setup(),
> make it a static variable in setup.c instead. This avoids having to
> pass it to subfunctions, which will be needed in more cases in future.
>
> Rename it to ini_nr_pages, as the valu
On 20.08.2024 10:20, Juergen Gross wrote:
> Move the checks for e820 memory map conflicts using the
> xen_chk_is_e820_usable() helper further up in order to prepare
> resolving some of the possible conflicts by doing some e820 map
> modifications, which must happen before evaluating the RAM layout.
On 20.08.2024 10:20, Juergen Gross wrote:
> When booting as a Xen PV dom0 the memory layout of the dom0 is
> modified to match that of the host, as this requires less changes in
> the kernel for supporting Xen.
>
> There are some cases, though, which are problematic, as it is the Xen
> hypervisor
On 20.08.2024 10:20, Juergen Gross wrote:
> When running as a Xen PV dom0 the kernel is loaded by the hypervisor
> using a different memory map than that of the host. In order to
> minimize the required changes in the kernel, the kernel adapts its
> memory map to that of the host. In order to do th
Quite a few TI K3 devices do not have clock-frequency specified in their
respective UART nodes. However hard-coding the frequency is not a
solution as the function clock input can differ between SoCs. So, use a
default frequency of 48MHz if the device tree does not specify one.
Signed-off-by: Amne
On 14.08.2024 10:34, Frediano Ziglio wrote:
> Instead of relocate the value at that position compute it
> entirely and write it.
> During EFI boots sym_offs(SYMBOL) are potentially relocated
> causing the values to be corrupted.
This requires quite a bit more explanation, also to understand why a
When running as a Xen PV dom0 the system needs to map ACPI data of the
host using host physical addresses, while those addresses can conflict
with the guest physical addresses of the loaded linux kernel.
This conflict can be solved by mapping the ACPI data to a different
guest physical address, bu
Instead of having max_pfn as a local variable of xen_memory_setup(),
make it a static variable in setup.c instead. This avoids having to
pass it to subfunctions, which will be needed in more cases in future.
Rename it to ini_nr_pages, as the value denotes the currently usable
number of memory page
In order to minimize required special handling for running as Xen PV
dom0, the memory layout is modified to match that of the host. This
requires to have only RAM at the locations where Xen allocated memory
is living. Unfortunately there seem to be some machines, where ACPI
NVS is located at 64 MB,
When running as a Xen PV dom0 it can happen that the kernel is being
loaded to a guest physical address conflicting with the host memory
map.
In order to be able to resolve this conflict, add the capability to
remap non-RAM areas to different guest PFNs. A function to use this
remapping informatio
When booting as a Xen PV dom0 the memory layout of the dom0 is
modified to match that of the host, as this requires less changes in
the kernel for supporting Xen.
There are some cases, though, which are problematic, as it is the Xen
hypervisor selecting the kernel's load address plus some other da
Move the checks for e820 memory map conflicts using the
xen_chk_is_e820_usable() helper further up in order to prepare
resolving some of the possible conflicts by doing some e820 map
modifications, which must happen before evaluating the RAM layout.
Signed-off-by: Juergen Gross
Tested-by: Marek M
There have been reports of failed boots with Xen due to an overlap of
the kernel's memory with ACPI NVS reported in the E820 map of the host.
This series fixes this issue by moving the NVS area in dom0 to some
higher address.
Changes in V2:
- split of v1 patch 5
- new patch 6
Juergen Gross (7):
When running as a Xen PV dom0 the kernel is loaded by the hypervisor
using a different memory map than that of the host. In order to
minimize the required changes in the kernel, the kernel adapts its
memory map to that of the host. In order to do that it is checking
for conflicts of its load addres
Update ECLAIR configuration to deviate more cases where an
unintentional fallthrough cannot happen.
Tag Rule 16.3 as clean for arm.
Signed-off-by: Federico Serafini
---
Hi, v4 of this patch has been on hold due to discussion on whether or not
to consider switch clauses ending with ASSERT_UNREACH
Currently, writing at cpu//availability in xenstore fails for a
couple of reasons: a trailing slash in the path and the fact that
cpupool isn't a bitmap but the cpupool id. This patch fixes this by
just getting libxl_vcpuinfo for each dom0less domain.
Signed-off-by: Amneesh Singh
---
tools/helpe
On 14.08.2024 10:34, Frediano Ziglio wrote:
> No reason to wait, if Xen image is loaded by EFI (not multiboot
> EFI path) these are set in efi_arch_load_addr_check, but
> not in the multiboot EFI code path.
> This change makes the 2 EFI code paths more similar and allows
> the usage of these variab
flight 187285 linux-linus real [real]
flight 187291 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187285/
http://logs.test-lab.xenproject.org/osstest/logs/187291/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 20.08.2024 08:12, Chen, Jiqian wrote:
> On 2024/8/19 17:08, Jan Beulich wrote:
>> On 16.08.2024 13:08, Jiqian Chen wrote:
>>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>>> a passthrough device by using gsi, see qemu code
>>> xen_pt_realize->xc_physdev_map_pirq and libxl code
On 20.08.2024 08:00, Chen, Jiqian wrote:
> On 2024/8/19 17:04, Jan Beulich wrote:
>> On 16.08.2024 13:08, Jiqian Chen wrote:
>>> @@ -67,6 +68,57 @@ ret_t pci_physdev_op(int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>> break;
>>> }
>>>
>>> +case PHYSDEVOP_pci_device_reset:
>>>
83 matches
Mail list logo
