On 24.09.2024 20:36, Andrew Cooper wrote:
> On 23/09/2024 2:03 pm, Jan Beulich wrote:
>> On 23.09.2024 12:14, Alejandro Vallejo wrote:
>>> On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote:
On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote:
> Moves sti directly afte
No need to have it coded in assembly.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- update some comments;
- explain why %ebx is saved before calling efi_parse_mbi2;
- move lea before test instruction;
- removed asmlinkage from efi_multiboot2 and add to efi_parse_mbi2;
- fix line length;
This series came from part of the work of removing duplications between
boot code and rewriting part of code from assembly to C.
First 2 patches rework BIOS/PVH paths to reuse some code.
Third patch rewrites EFI code in pure C.
Changes since v1, more details in specific commits:
- style updates;
-
Tag structure should contain at least the tag header.
Entire tag structure must be contained inside MBI2 data.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/efi/parse-mbi2.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/efi/parse-mbi2.c b/xen/arch/x86/efi
The 2 code paths were sharing quite some common code, reuse it instead
of having duplications.
Use %dl register to store boot type before running common code.
Using a 8 bit register reduces code size.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- use %dl instead of %ebp to reduce code si
Allows to call C code earlier.
In order to safely call C code we need to setup stack, selectors and BSS.
Signed-off-by: Frediano Ziglio
Reviewed-by: Andrew Cooper
---
Changes since v1:
- improve commit message;
- improve some comments;
- fix some code style (spacing);
- set trampoline_phys as 32
On 9/24/24 12:23, Edgar E. Iglesias wrote:
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 09b65e44ae..dab24fa9e2 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -586,6 +586,189 @@ static int __init domain_handle_dtb_bootm
flight 187841 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs.
187720
Tests whi
On Tue, Sep 10, 2024 at 01:17:03PM +0200, Takashi Iwai wrote:
> On Mon, 09 Sep 2024 22:02:08 +0200,
> Elliott Mitchell wrote:
> >
> > On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> > >
> > > Individual subsystems ought not to know or care about XENPV; it's a
> > > layering viola
On Tue, 24 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a background PCI ECAM mmio region always reading as all ones.
> This indicates to the OS that there are no PCI devices on the bus.
> Once the device-model's IOREQ client connects, the OS can rescan
> the bus and fin
On Tue, 24 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a read-const writes-ignored mmio handler. This is useful
> to for example register background regions that return a fixed
> value instead of raising data aborts.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by:
On Tue, 24 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add support for mmio background regions. These regions
> can be overlayed by IOREQ handlers and thus act as
> fallback handlers while IOREQ clients haven't registered.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by
On Tue, 24 Sep 2024, Edgar E. Iglesias wrote:
> From: Stewart Hildebrand
>
> When virtio-pci is specified in the dom0less domU properties, create a
> virtio-pci node in the guest's device tree. Set up an mmio handler with
> a register for the guest to poll when the backend has connected and
> vir
On Tue, Sep 24, 2024 at 04:34:16PM -0700, Stefano Stabellini wrote:
> On Tue, 24 Sep 2024, Julien Grall wrote:
> > Hi Edgar,
> >
> > On 24/09/2024 17:23, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias"
> > >
> > > The address range between 4G (32bit) and 1TB (40bit) is fully
> > > alloc
On Tue, 24 Sep 2024, Julien Grall wrote:
> Hi Edgar,
>
> On 24/09/2024 17:23, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > The address range between 4G (32bit) and 1TB (40bit) is fully
> > allocated. There's no more room for devices on ARM systems with
> > 40-bit physicall addr
On Tue, 24 Sep 2024, Julien Grall wrote:
> On 24/09/2024 18:11, Edgar E. Iglesias wrote:
> > On Tue, Sep 24, 2024 at 05:35:20PM +0100, Julien Grall wrote:
> > > Hi Edgar,
> > >
> > > On 24/09/2024 17:23, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias"
> > > >
> > > > Reserve memory ra
flight 187849 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187849/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b8122cc9d8b6c9017905ac5f4c846b4c0f535d01
baseline version:
ovmf a131839a3db7f933f51ef
On Mon, 23 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a way to enable/disable buffered IOREQs for PVH machines
> and disable them for ARM. ARM does not support buffered
> IOREQ's nor the legacy way to map IOREQ info pages.
>
> See the following for more details:
> htt
On Mon, 23 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Expose handle_bufioreq in xen_register_ioreq().
> This is to allow machines to enable or disable buffered ioreqs.
>
> No functional change since all callers still set it to
> HVM_IOREQSRV_BUFIOREQ_ATOMIC.
>
> Signed-o
flight 187850 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187850/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, 24 Sep 2024, Jiqian Chen wrote:
> On PVH dom0, when passthrough a device to domU, QEMU and xl tools
> want to use gsi number to do pirq mapping, see QEMU code
> xen_pt_realize->xc_physdev_map_pirq, and xl code
> pci_add_dm_done->xc_physdev_map_pirq, but in current codes, the gsi
> number is
flight 187839 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187839/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-pair 28 guest-migrate/dst_host/src_host/debian.repeat
fail in 187831 pass in 187839
t
flight 187842 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187842/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 23/09/2024 2:03 pm, Jan Beulich wrote:
> On 23.09.2024 12:14, Alejandro Vallejo wrote:
>> On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote:
>>> On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote:
Moves sti directly after the cr2 read and immediately after the #PF
>>>
On 24/09/2024 6:10 pm, Roger Pau Monné wrote:
> On Tue, Sep 24, 2024 at 06:21:47PM +0200, Jan Beulich wrote:
>> On 24.09.2024 18:14, Roger Pau Monné wrote:
>>> On Tue, Sep 24, 2024 at 04:27:36PM +0100, Andrew Cooper wrote:
On 24/09/2024 4:10 pm, Roger Pau Monné wrote:
> On Mon, Sep 23, 202
On 13/09/2024 6:56 pm, Jan Beulich wrote:
> On 13.09.2024 14:39, Andrew Cooper wrote:
>> Despite writing this code, it's not the easiest logic to follow.
>>
>> Shorten the UCODE_EQUIV_TYPE name, and provide more of an explanation of
>> what's going on.
>>
>> No functional change.
>>
>> Signed-off-b
Hi Bertrand,
On 24/09/2024 09:16, Bertrand Marquis wrote:
On 22 Sep 2024, at 11:07, Julien Grall wrote:
Hi,
On 19/09/2024 14:19, Bertrand Marquis wrote:
Store the list of ABI we need in a list and go through the list instead
of having a list of conditions inside the code.
No functional chang
Hi Edgar,
On 24/09/2024 18:11, Edgar E. Iglesias wrote:
On Tue, Sep 24, 2024 at 05:35:20PM +0100, Julien Grall wrote:
Hi Edgar,
On 24/09/2024 17:23, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Reserve memory ranges and interrupt lines for an externally
emulated PCI controller (e.g by
On Tue, Sep 24, 2024 at 05:35:20PM +0100, Julien Grall wrote:
> Hi Edgar,
>
> On 24/09/2024 17:23, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Reserve memory ranges and interrupt lines for an externally
> > emulated PCI controller (e.g by QEMU) dedicated to hosting
> > Virtio
Hi Ayan,
On 24/09/2024 12:32, Ayan Kumar Halder wrote:
On 19/09/2024 14:16, Julien Grall wrote:
Hi Ayan,
Hi Julien,
I need some clarifications.
On 18/09/2024 19:51, Ayan Kumar Halder wrote:
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot-time page table in MMU system,
On Tue, Sep 24, 2024 at 06:21:47PM +0200, Jan Beulich wrote:
> On 24.09.2024 18:14, Roger Pau Monné wrote:
> > On Tue, Sep 24, 2024 at 04:27:36PM +0100, Andrew Cooper wrote:
> >> On 24/09/2024 4:10 pm, Roger Pau Monné wrote:
> >>> On Mon, Sep 23, 2024 at 03:35:59PM +0100, Matthew Barnes wrote:
> >>
On 24/09/2024 5:42 pm, Oleksii Kurochko wrote:
> Introduce PERCPU_BSS macro which manages:
> * Alignment of the section start
> * Insertion of per-CPU data sections
> * Alignment and start/end markers for per-CPU data
> This change simplifies the linker script maintenance and ensures a unified
>
On 23/09/2024 12:22, Ayan Kumar Halder wrote:
On 19/09/2024 13:42, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 18/09/2024 19:51, Ayan Kumar Halder wrote:
From: Wei Chen
On Armv8-A, Xen has a fixed virtual start address (link address too)
for all
Armv8-A platforms. In an MMU based syste
Remove the device initialization code from `xen/arch/arm/device.c`
and move it to the common code to avoid duplication and make it accessible
for both ARM and other architectures.
device_get_class(), device_init(), _sdevice[] and _edevice[] are wrapped by
"#ifdef CONFIG_HAS_DEVICE_TREE" for the cas
Introduce a new `.dev.info` section in the RISC-V linker script to
handle device-specific information. This section is required by
common code (common/device.c: device_init(), device_get_class() ).
This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
marking the start and end
The {acpi_}device_init() and device_get_class() functions are identical across
Arm and RISC-V, and they are likely to remain the same for other architectures
like PPC.
Since there is no architecture-specific logic within these functions, they are
good candidates to be moved to the common codebase.
Centralize per-cpu area management to reduce code duplication and
enhance maintainability across architectures.
The per-cpu area management code, which is largely common among
architectures, is moved to a shared implementation in
xen/common/percpu.c. This change includes:
* Remove percpu.c from t
Introduce a new `.dev.info` section in the PPC linker script to
handle device-specific information. This section is required by
common code (common/device.c: device_init(), device_get_class() ).
This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
marking the start and end of
The per-CPU area management code, which is largely common across architectures,
is a strong candidate for consolidation into common code.
Currently, there is only one architectural-specific aspect:
1. INVALID_PERCPU_AREA:
ARM:
#define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
x86:
#
Refactor arm/xen.lds.S by replacing the inline definitions for
device info sections with the newly introduced {DT,ACPI}_DEV_INFO
macros from xen/xen.lds.h.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- use refactored ADEV_INFO and DT_DEV_INFO macros.
---
xen/arch/arm/xen.lds.S | 10 ++--
Introduce macros to define device information sections based on
the configuration of ACPI or device tree support. These sections
are required for common code of device initialization and getting
an information about a device.
These macros are expected to be used across different
architectures (Arm
Introduce PERCPU_BSS macro which manages:
* Alignment of the section start
* Insertion of per-CPU data sections
* Alignment and start/end markers for per-CPU data
This change simplifies the linker script maintenance and ensures a unified
approach for per-CPU sections across different architectur
On 23/09/2024 10:18, Ayan Kumar Halder wrote:
On 19/09/2024 13:33, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 18/09/2024 19:50, Ayan Kumar Halder wrote:
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (e
flight 187837 linux-linus real [real]
flight 187847 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187837/
http://logs.test-lab.xenproject.org/osstest/logs/187847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Hi Edgar,
On 24/09/2024 17:23, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Reserve memory ranges and interrupt lines for an externally
emulated PCI controller (e.g by QEMU) dedicated to hosting
Virtio devices and potentially other emulated devices.
Signed-off-by: Edgar E. Iglesias
---
Hi Edgar,
On 24/09/2024 17:23, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
The address range between 4G (32bit) and 1TB (40bit) is fully
allocated. There's no more room for devices on ARM systems with
40-bit physicall address width.
> > This decreases the size of the second RAM bank to
From: "Edgar E. Iglesias"
Add a background PCI ECAM mmio region always reading as all ones.
This indicates to the OS that there are no PCI devices on the bus.
Once the device-model's IOREQ client connects, the OS can rescan
the bus and find PV and emulated devices.
This avoids a race where domU'
From: "Edgar E. Iglesias"
Add support for mmio background regions. These regions
can be overlayed by IOREQ handlers and thus act as
fallback handlers while IOREQ clients haven't registered.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/include/asm/mmio.h | 11 ++-
xen/arch/arm/io.c
From: "Edgar E. Iglesias"
Add a read-const writes-ignored mmio handler. This is useful
to for example register background regions that return a fixed
value instead of raising data aborts.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/include/asm/mmio.h | 2 ++
xen/arch/arm/io.c
From: "Edgar E. Iglesias"
This series adds support for Virtio-PCI for dom0less on ARM.
Three parts:
1. Decrease size of second RAM bank to free up space in <40bit address range.
2. Add generation of virtio-pci FDT nodes for domU.
3. Add a background ECAM region always responding 0x (noth
From: "Edgar E. Iglesias"
Reserve memory ranges and interrupt lines for an externally
emulated PCI controller (e.g by QEMU) dedicated to hosting
Virtio devices and potentially other emulated devices.
Signed-off-by: Edgar E. Iglesias
---
xen/include/public/arch-arm.h | 17 +
1 f
From: Stewart Hildebrand
When virtio-pci is specified in the dom0less domU properties, create a
virtio-pci node in the guest's device tree. Set up an mmio handler with
a register for the guest to poll when the backend has connected and
virtio-pci bus is ready to be probed. Grant tables may be use
From: "Edgar E. Iglesias"
The address range between 4G (32bit) and 1TB (40bit) is fully
allocated. There's no more room for devices on ARM systems with
40-bit physicall address width.
This decreases the size of the second RAM bank to free up space
in preparation for virtio-pci and for future use
On 24.09.2024 18:14, Roger Pau Monné wrote:
> On Tue, Sep 24, 2024 at 04:27:36PM +0100, Andrew Cooper wrote:
>> On 24/09/2024 4:10 pm, Roger Pau Monné wrote:
>>> On Mon, Sep 23, 2024 at 03:35:59PM +0100, Matthew Barnes wrote:
With the introduction of mixed x2APIC mode (using cluster addressing
On Tue, Sep 24, 2024 at 04:27:36PM +0100, Andrew Cooper wrote:
> On 24/09/2024 4:10 pm, Roger Pau Monné wrote:
> > On Mon, Sep 23, 2024 at 03:35:59PM +0100, Matthew Barnes wrote:
> >> With the introduction of mixed x2APIC mode (using cluster addressing for
> >> IPIs and physical for external interr
On 23/09/2024 3:35 pm, Matthew Barnes wrote:
> With the introduction of mixed x2APIC mode (using cluster addressing for
> IPIs and physical for external interrupts) the use of pure cluster mode
> doesn't have any benefit.
>
> Remove the mode itself, leaving only the code required for logical
> addr
On 24/09/2024 4:10 pm, Roger Pau Monné wrote:
> On Mon, Sep 23, 2024 at 03:35:59PM +0100, Matthew Barnes wrote:
>> With the introduction of mixed x2APIC mode (using cluster addressing for
>> IPIs and physical for external interrupts) the use of pure cluster mode
>> doesn't have any benefit.
>>
>> R
On 24.09.2024 17:10, Roger Pau Monné wrote:
> On Mon, Sep 23, 2024 at 03:35:59PM +0100, Matthew Barnes wrote:
>> With the introduction of mixed x2APIC mode (using cluster addressing for
>> IPIs and physical for external interrupts) the use of pure cluster mode
>> doesn't have any benefit.
>>
>> Rem
On 24.09.2024 17:21, Frediano Ziglio wrote:
> On Mon, Sep 23, 2024 at 3:26 PM Jan Beulich wrote:
>>
>
> ... omissis ...
>
>>
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -17,7 +17,8 @@
> */
>
> void __init noreturn efi_multiboot2(EFI_HANDLE Imag
On Mon, Sep 23, 2024 at 3:26 PM Jan Beulich wrote:
>
... omissis ...
>
> >>> --- a/xen/arch/x86/efi/stub.c
> >>> +++ b/xen/arch/x86/efi/stub.c
> >>> @@ -17,7 +17,8 @@
> >>> */
> >>>
> >>> void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
> >>> -EF
On Mon, Sep 23, 2024 at 03:35:59PM +0100, Matthew Barnes wrote:
> With the introduction of mixed x2APIC mode (using cluster addressing for
> IPIs and physical for external interrupts) the use of pure cluster mode
> doesn't have any benefit.
>
> Remove the mode itself, leaving only the code require
On Mon, 2024-09-23 at 15:35 +0100, Matthew Barnes wrote:
> With the introduction of mixed x2APIC mode (using cluster addressing
> for
> IPIs and physical for external interrupts) the use of pure cluster
> mode
> doesn't have any benefit.
>
> Remove the mode itself, leaving only the code required f
On 23.09.2024 16:35, Matthew Barnes wrote:
> With the introduction of mixed x2APIC mode (using cluster addressing for
> IPIs and physical for external interrupts) the use of pure cluster mode
> doesn't have any benefit.
>
> Remove the mode itself, leaving only the code required for logical
> addre
On 24.09.2024 16:28, Frediano Ziglio wrote:
> On Tue, Sep 24, 2024 at 3:17 PM Jan Beulich wrote:
>>
>> On 24.09.2024 12:28, Frediano Ziglio wrote:
>>> No need to have it coded in assembly.
>>>
>>> Signed-off-by: Frediano Ziglio
>>> ---
>>> Changes since v1:
>>> - update some comments;
>>> - expla
On 24/09/2024 1:30 pm, Roger Pau Monné wrote:
> On Tue, Sep 24, 2024 at 12:23:43PM +0100, Andrew Cooper wrote:
>> The logic would be more robust disabling SMAP based on its precense in CR4,
>> rather than on certain features.
>>
>> A forthcoming feature, LASS, needs the same treatment here. Introd
On Tue, Sep 24, 2024 at 03:44:07PM +0200, Jan Beulich wrote:
> On 24.09.2024 13:23, Andrew Cooper wrote:
> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -1057,29 +1057,31 @@ int __init dom0_construct_pv(struct domain *d,
> > module_
On Tue, Sep 24, 2024 at 3:17 PM Jan Beulich wrote:
>
> On 24.09.2024 12:28, Frediano Ziglio wrote:
> > No need to have it coded in assembly.
> >
> > Signed-off-by: Frediano Ziglio
> > ---
> > Changes since v1:
> > - update some comments;
> > - explain why %ebx is saved before calling efi_parse_mb
On Tue, Sep 24, 2024 at 3:15 PM Andrew Cooper wrote:
>
> On 24/09/2024 11:28 am, Frediano Ziglio wrote:
> > Tag structure should contain at least the tag header.
> > Entire tag structure must be contained inside MBI2 data.
> >
> > Signed-off-by: Frediano Ziglio
> > ---
> > xen/arch/x86/efi/parse
On 24.09.2024 12:28, Frediano Ziglio wrote:
> No need to have it coded in assembly.
>
> Signed-off-by: Frediano Ziglio
> ---
> Changes since v1:
> - update some comments;
> - explain why %ebx is saved before calling efi_parse_mbi2;
> - move lea before test instruction;
> - removed asmlinkage from
On 24/09/2024 11:28 am, Frediano Ziglio wrote:
> Tag structure should contain at least the tag header.
> Entire tag structure must be contained inside MBI2 data.
>
> Signed-off-by: Frediano Ziglio
> ---
> xen/arch/x86/efi/parse-mbi2.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
On 24/09/2024 11:28 am, Frediano Ziglio wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 80bba6ff21..6d8eec554b 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -253,36 +244,30 @@ __efi64_mb2_start:
> shr $3, %ecx
>
On 24.09.2024 12:14, Bernhard Kaindl wrote:
> Fix a long-standing issue (known at since 2014) with the numainfo call.
>
> The Hypercall `XEN_SYSCTL_numainfo` returns `memsize` for each NUMA node:
>
> xl info -n:
> node:memsizememfreedistances
>0: -> 67584 <- 60672 10,21 <
On 24/09/2024 2:30 pm, Andrew Cooper wrote:
> On 24/09/2024 2:25 pm, Andrew Cooper wrote:
>> On 24/09/2024 11:28 am, Frediano Ziglio wrote:
>>> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
>>> index fa21024042..80bba6ff21 100644
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/a
On 24.09.2024 13:23, Andrew Cooper wrote:
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -1057,29 +1057,31 @@ int __init dom0_construct_pv(struct domain *d,
> module_t *initrd,
> const char *cmdline)
> {
>
On 24.09.2024 13:30, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-09-24 at 12:49 +0200, Jan Beulich wrote:
>> On 13.09.2024 17:57, Oleksii Kurochko wrote:
>>> +static int pt_next_level(bool alloc_tbl, pte_t **table, unsigned
>>> int offset)
>>> +{
>>> + pte_t *entry;
>>> + mfn_t mfn;
>>>
On 24/09/2024 2:25 pm, Andrew Cooper wrote:
> On 24/09/2024 11:28 am, Frediano Ziglio wrote:
>> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
>> index fa21024042..80bba6ff21 100644
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> ELFNOTE(Xen, XEN_ELFNOTE_PH
On 24.09.2024 14:22, Frediano Ziglio wrote:
> On Tue, Sep 24, 2024 at 1:17 PM Jan Beulich wrote:
>>
>> On 24.09.2024 13:09, Jan Beulich wrote:
>>> On 24.09.2024 12:22, Frediano Ziglio wrote:
4- .rodata for some reason is not marked as READONLY, even on ELF you
get the same issue.
>>>
>>>
On 24/09/2024 11:28 am, Frediano Ziglio wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index fa21024042..80bba6ff21 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start))
>
> __p
On 24/09/2024 11:28 am, Frediano Ziglio wrote:
> @@ -459,6 +460,20 @@ __pvh_start:
>
> #endif /* CONFIG_PVH_GUEST */
>
> +.Linitialise_bss:
> + /* Initialise the BSS. */
You've had some tabs sneak in here. I can drop on commit.
Also, I'd suggest:
/* Initialise the BSS. Preserv
flight 187840 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187840/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Sep 24, 2024 at 12:23:43PM +0100, Andrew Cooper wrote:
> The logic would be more robust disabling SMAP based on its precense in CR4,
> rather than on certain features.
>
> A forthcoming feature, LASS, needs the same treatment here. Introduce minimum
> enumeration information, although it
On Tue, Sep 24, 2024 at 1:17 PM Jan Beulich wrote:
>
> On 24.09.2024 13:09, Jan Beulich wrote:
> > On 24.09.2024 12:22, Frediano Ziglio wrote:
> >> 4- .rodata for some reason is not marked as READONLY, even on ELF you
> >> get the same issue.
> >
> > I can confirm this oddity, without having an ex
On 24.09.2024 13:54, Ayan Kumar Halder wrote:
> Hi Jan,
>
> On 23/09/2024 11:23, Jan Beulich wrote:
>> On 18.09.2024 19:51, Ayan Kumar Halder wrote:
>>> Secondary cpus initialization is not yet supported. Thus, we print an
>>> appropriate message and put the secondary cpus in WFE state.
>>>
>>> Si
On 24.09.2024 13:09, Jan Beulich wrote:
> On 24.09.2024 12:22, Frediano Ziglio wrote:
>> 4- .rodata for some reason is not marked as READONLY, even on ELF you
>> get the same issue.
>
> I can confirm this oddity, without having an explanation. It must be
> one of the inputs; I've checked that prel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-45817 / XSA-462
version 2
x86: Deadlock in vlapic_error()
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
Hi Jan,
On 23/09/2024 11:23, Jan Beulich wrote:
On 18.09.2024 19:51, Ayan Kumar Halder wrote:
Secondary cpus initialization is not yet supported. Thus, we print an
appropriate message and put the secondary cpus in WFE state.
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1 - 1. NR_CPU
On 19/09/2024 14:20, Julien Grall wrote:
Hi,
Hi Julien,
On 18/09/2024 19:51, Ayan Kumar Halder wrote:
Secondary cpus initialization is not yet supported. Thus, we print an
appropriate message and put the secondary cpus in WFE state.
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1
On 19/09/2024 14:16, Julien Grall wrote:
Hi Ayan,
Hi Julien,
I need some clarifications.
On 18/09/2024 19:51, Ayan Kumar Halder wrote:
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot-time page table in MMU system, we need a boot-time MPU
protection region configuration
On Tue, 2024-09-24 at 12:49 +0200, Jan Beulich wrote:
> On 13.09.2024 17:57, Oleksii Kurochko wrote:
>
>
> > @@ -68,6 +108,52 @@ static inline bool pte_is_valid(pte_t p)
> > return p.pte & PTE_VALID;
> > }
> >
> > +/*
> > + * From the RISC-V spec:
> > + * The V bit indicates whether the
The logic would be more robust disabling SMAP based on its precense in CR4,
rather than on certain features.
A forthcoming feature, LASS, needs the same treatment here. Introduce minimum
enumeration information, although it will take a bit more work to get LASS
fully usable in guests.
Signed-off
On 24.09.2024 12:16, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-09-23 at 16:43 +0200, Jan Beulich wrote:
>> On 17.09.2024 18:15, Oleksii Kurochko wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -12,6 +12,14 @@ config CORE_PARKING
>>> bool
>>> depends on NR_CPUS
On 24.09.2024 12:22, Frediano Ziglio wrote:
> There are indeed some oddities in the final executable(s):
>
> From "objdump -x":
>
> xen/normal/xen.efi: file format pei-x86-64
> xen/normal/xen.efi
> architecture: i386:x86-64, flags 0x013b:
> HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCA
On 13.09.2024 17:57, Oleksii Kurochko wrote:
> @@ -34,15 +39,50 @@
> #define PTE_LEAF_DEFAULT(PTE_VALID | PTE_READABLE | PTE_WRITABLE)
> #define PTE_TABLE (PTE_VALID)
>
> +#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE)
> #define PAGE_HYPERVISOR_RW
Tag structure should contain at least the tag header.
Entire tag structure must be contained inside MBI2 data.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/efi/parse-mbi2.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/efi/parse-mbi2.c b/xen/arch/x86/efi
Allows to call C code earlier.
In order to safely call C code we need to setup stack, selectors and BSS.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- improve commit message;
- improve some comments;
- fix some code style (spacing);
- set trampoline_phys as 32 bit value;
- use PAGE_SIZE
No need to have it coded in assembly.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- update some comments;
- explain why %ebx is saved before calling efi_parse_mbi2;
- move lea before test instruction;
- removed asmlinkage from efi_multiboot2 and add to efi_parse_mbi2;
- fix line length;
The 2 code paths were sharing quite some common code, reuse it instead
of having duplications.
Use %dl register to store boot type before running common code.
Using a 8 bit register reduces code size.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- use %dl instead of %ebp to reduce code si
This series came from part of the work of removing duplications between
boot code and rewriting part of code from assembly to C.
First 2 patches rework BIOS/PVH paths to reuse some code.
Third patch rewrites EFI code in pure C.
Changes since v1, more details in specific commits:
- style updates;
-
On Tue, Sep 24, 2024 at 9:14 AM Jan Beulich wrote:
>
> On 23.09.2024 18:06, Frediano Ziglio wrote:
> > On Mon, Sep 23, 2024 at 4:54 PM Jan Beulich wrote:
> >>
> >> On 19.09.2024 10:00, Frediano Ziglio wrote:
> >>> All loadable sections should be page aligned.
> >>
> >> What about .buildid? .reloc
On Mon, 2024-09-23 at 16:43 +0200, Jan Beulich wrote:
> On 17.09.2024 18:15, Oleksii Kurochko wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -12,6 +12,14 @@ config CORE_PARKING
> > bool
> > depends on NR_CPUS > 1
> >
> > +config DEVICE_INIT
> > + bool
> > + de
1 - 100 of 120 matches
Mail list logo
