On 14/11/2024 11:41 am, Jan Beulich wrote:
> On 12.11.2024 22:19, Andrew Cooper wrote:
>> @@ -199,8 +198,8 @@ static bool microcode_fits_cpu(const struct
>> microcode_patch *patch)
>> return equiv.id == patch->processor_rev_id;
>> }
>>
>> -static enum microcode_match_result cf_check compar
On 14/11/2024 4:15 pm, Jan Beulich wrote:
> On 14.11.2024 16:59, Andrew Cooper wrote:
>> On 14/11/2024 11:11 am, Jan Beulich wrote:
>>> On 12.11.2024 22:19, Andrew Cooper wrote:
With the tangle of logic starting to come under control, it is now plain to
see that parse_blob()'s side effect
Hi,
I'd like to start a working group on the future of the toolstack.
The main objective would be have a way to managed domain that is common
to more project.
(The hidden goal would be to get rid of libxl, and replace it with a
new tool written in Rust.)
Right now, we have the CLI `xl` and the
On Thu, Nov 14, 2024 at 04:52:18PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 14, 2024 at 06:11:46AM +, Chen, Jiqian wrote:
> > On 2024/11/13 18:30, Roger Pau Monné wrote:
> > > On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
> > >> On 2024/11/13 17:30, Roger Pau Monné wrote:
> >
On 14.11.24 15:09, Julien Grall wrote:
On 14/11/2024 12:22, Michal Orzel wrote:
On 14/11/2024 13:04, Julien Grall wrote:
Hi Michal,
On 14/11/2024 11:48, Michal Orzel wrote:
On 14/11/2024 11:31, Julien Grall wrote:
Looking at the code, I think /memreserve/ and /reserved-memory are
On 15.11.24 01:11, Elliott Mitchell wrote:
On Wed, Nov 13, 2024 at 08:20:02PM +0100, Jürgen Groß wrote:
On 13.11.24 18:25, Elliott Mitchell wrote:
On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
After some investigations we notices a huge performances drop (perfs divided
by
fa
On Thu, Nov 14, 2024 at 06:11:46AM +, Chen, Jiqian wrote:
> On 2024/11/13 18:30, Roger Pau Monné wrote:
> > On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
> >> On 2024/11/13 17:30, Roger Pau Monné wrote:
> >>> On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
> So
On Thu, 14 Nov 2024, Julien Grall wrote:
> On 14/11/2024 12:22, Michal Orzel wrote:
> >
> >
> > On 14/11/2024 13:04, Julien Grall wrote:
> > >
> > >
> > > Hi Michal,
> > >
> > > On 14/11/2024 11:48, Michal Orzel wrote:
> > > >
> > > >
> > > > On 14/11/2024 11:31, Julien Grall wrote:
> > > >
On 2024/11/14 23:52, Roger Pau Monné wrote:
> On Thu, Nov 14, 2024 at 06:11:46AM +, Chen, Jiqian wrote:
>> On 2024/11/13 18:30, Roger Pau Monné wrote:
>>> On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
On 2024/11/13 17:30, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at
On 11/14/24 05:34, Jan Beulich wrote:
> On 12.11.2024 21:53, Stewart Hildebrand wrote:
>> Add links between a VF's struct pci_dev and its associated PF struct
>> pci_dev.
>>
>> The hardware domain is expected to add a PF first before adding
>> associated VFs. Similarly, the hardware domain is expec
On Thu, 14 Nov 2024, Jan Beulich wrote:
> On 14.11.2024 03:34, Stefano Stabellini wrote:
> > On Wed, 13 Nov 2024, Jan Beulich wrote:
> >> On 13.11.2024 04:15, Stefano Stabellini wrote:
> >>> It is challenging to create a solution that satisfies everyone for this
> >>> patch. However, we should add
On 14/11/2024 11:17 am, Andrew Cooper wrote:
> On 14/11/2024 10:48 am, Alejandro Vallejo wrote:
>> On Thu Nov 14, 2024 at 9:08 AM GMT, Andrew Cooper wrote:
>>> diff --git a/xen/arch/x86/include/asm/trampoline.h
>>> b/xen/arch/x86/include/asm/trampoline.h
>>> index 8c1e0b48c2c9..559111d2ccfc 100644
On 14.11.2024 19:50, Stewart Hildebrand wrote:
> On 11/14/24 05:34, Jan Beulich wrote:
>> On 12.11.2024 21:53, Stewart Hildebrand wrote:
>>> Add links between a VF's struct pci_dev and its associated PF struct
>>> pci_dev.
>>>
>>> The hardware domain is expected to add a PF first before adding
>>>
On Thu, Nov 14 2024 at 10:05, Philipp Stanner wrote:
> On Wed, 2024-11-13 at 17:22 +0100, Thomas Gleixner wrote:
>> On Wed, Nov 13 2024 at 13:41, Philipp Stanner wrote:
>> > pci_intx() is a hybrid function which can sometimes be managed
>> > through
>> > devres. This hybrid nature is undesirable.
>
On 14/11/2024 2:57 pm, Roger Pau Monne wrote:
> Hello,
>
> The attempt to fix destroy_xen_mappings() so that L2 tables are
> consistently freed uncovered some errors in the memory management code.
> The following series attempts to fix them.
>
> All patches except for 4/4 are new in v2, and 4/4 has
It may have taken a while, but it occurs to me that the mentioned commit fixed
a second problem too.
On entering trampoline_boot_cpu_entry(), %esp points at the trampoline stack,
but in a 32bit flat segment. It happens to be page aligned.
When dropping into 16bit mode, the stack segment operates
LibAFL, which is a part of AFL++ project is a instrument that allows
us to perform fuzzing on beremetal code (Xen hypervisor in this case)
using QEMU as an emulator. It employs QEMU's ability to create
snapshots to run many tests relatively quickly: system state is saved
right before executing a ne
On Wed, Nov 13, 2024 at 08:20:02PM +0100, Jürgen Groß wrote:
> On 13.11.24 18:25, Elliott Mitchell wrote:
> > On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
> > >
> > > After some investigations we notices a huge performances drop (perfs
> > > divided
> > > by
> > > factor of 5)
On 13.11.2024 19:51, Andrew Cooper wrote:
> --- a/xen/include/xen/multiboot.h
> +++ b/xen/include/xen/multiboot.h
> @@ -17,7 +17,7 @@
> #ifndef __MULTIBOOT_H__
> #define __MULTIBOOT_H__
>
> -#include "const.h"
> +#include
>
> /*
> * Multiboot header structure.
> @@ -45,41 +45,43 @@
>
>
Hi Michal,
On 14/11/2024 07:18, Michal Orzel wrote:
On 13/11/2024 23:41, Stefano Stabellini wrote:
On Wed, 13 Nov 2024, Julien Grall wrote:
On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Jul
On 14.11.2024 10:08, Andrew Cooper wrote:
> By checking that the permanent trampoline fits within 1k (at the time of
> writing, it's 0x229 bytes), we can simplify the wakeup_stack handling.
>
> Move the setup into wakeup.S, because it's rather out of place in
> trampoline.S, and change it to a loc
On 14.11.2024 10:08, Andrew Cooper wrote:
> This is, to the best of my knowledge, accurate. I am providing no comment on
> how sane I believe it to be.
>
> At the time of writing, the sizes of the regions are:
>
> offset size
> AP: 0x 0x00b0
> S3: 0x00b0 0x0229
> B
On 14.11.2024 10:08, Andrew Cooper wrote:
> The logic is far more sane to follow with a total size, and the position of
> the end of the heap. Remove or fix the remaining descriptions of how the
> trampoline is laid out.
>
> Move the relevant constants into trampoline.h, which requires making the
On 14.11.2024 10:08, Andrew Cooper wrote:
> This is a little safer than leaving it to hope.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Hi Michal,
On 14/11/2024 11:48, Michal Orzel wrote:
On 14/11/2024 11:31, Julien Grall wrote:
Looking at the code, I think /memreserve/ and /reserved-memory are not
mapped in Xen and everything in /reserved-memory is mapped to dom0.
Why do we forward /reserved-memory to dom0 fdt but /memreser
This allows to include other headers and avoid duplicated declarations.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/include/boot/public/xen.h | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 xen/arch/x86/include/boot/public/xen.h
diff --git a/xen/arch/x8
On 14/11/2024 12:22, Michal Orzel wrote:
On 14/11/2024 13:04, Julien Grall wrote:
Hi Michal,
On 14/11/2024 11:48, Michal Orzel wrote:
On 14/11/2024 11:31, Julien Grall wrote:
Looking at the code, I think /memreserve/ and /reserved-memory are not
mapped in Xen and everything in /reser
The current logic in modify_xen_mappings() allows for fully empty L2 tables to
not be freed and unhooked from the parent L3 if the last L2 slot is not
populated.
Ensure that even when an L2 slot is empty the logic to check whether the whole
L2 can be removed is not skipped.
Fixes: 4376c05c3113 ('
Hello,
The attempt to fix destroy_xen_mappings() so that L2 tables are
consistently freed uncovered some errors in the memory management code.
The following series attempts to fix them.
All patches except for 4/4 are new in v2, and 4/4 has no change from v1,
hence kept Jan's Reviewed-by tag in 4/
bootstrap_map_addr() needs to be careful to not remove existing page-table
structures when tearing down mappings, as such pagetable structures might be
needed to fulfill subsequent mappings requests. The comment ahead of the
function already notes that pagetable memory shouldn't be allocated.
Fix
On 14.11.2024 15:02, Frediano Ziglio wrote:
> On Tue, Nov 5, 2024 at 2:52 PM Jan Beulich wrote:
>>
>> On 19.08.2024 16:29, Frediano Ziglio wrote:
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -287,19 +287,36 @@ static bool __init match_guid(const EFI_GUID *guid1,
>>> cons
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latter range is clashing with the already recorded /memreserve/
ranges.
Furthermore, u-boot lists boot mo
Hi Stefano,
On 13/11/2024 22:41, Stefano Stabellini wrote:
On Wed, 13 Nov 2024, Julien Grall wrote:
On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
On 06/11/2024 15:07, Michal
On 12.11.2024 21:53, Stewart Hildebrand wrote:
> Add links between a VF's struct pci_dev and its associated PF struct
> pci_dev.
>
> The hardware domain is expected to add a PF first before adding
> associated VFs. Similarly, the hardware domain is expected to remove the
> associated VFs before re
By checking that the permanent trampoline fits within 1k (at the time of
writing, it's 0x229 bytes), we can simplify the wakeup_stack handling.
Move the setup into wakeup.S, because it's rather out of place in
trampoline.S, and change it to a local symbol.
Drop wakeup_stack_start and WAKEUP_STACK
On 14.11.2024 03:34, Stefano Stabellini wrote:
> On Wed, 13 Nov 2024, Jan Beulich wrote:
>> On 13.11.2024 04:15, Stefano Stabellini wrote:
>>> It is challenging to create a solution that satisfies everyone for this
>>> patch. However, we should add R8.3 to the clean list as soon as possible
>>> to
On 13.11.2024 14:32, Andrew Cooper wrote:
> On 13/11/2024 1:31 pm, Andrew Cooper wrote:
>> On 13/11/2024 8:01 am, Jan Beulich wrote:
>>> On 13.11.2024 01:24, Andrew Cooper wrote:
On 12/11/2024 3:00 pm, Jan Beulich wrote:
> While result values and other status flags are unaffected as long a
On 13.11.2024 12:39, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-11-12 at 12:22 +0100, Jan Beulich wrote:
>> On 11.11.2024 19:16, Oleksii Kurochko wrote:
>>> @@ -25,8 +27,11 @@
>>>
>>> static inline void *maddr_to_virt(paddr_t ma)
>>> {
>>> - BUG_ON("unimplemented");
>>> - return NUL
This is a little safer than leaving it to hope.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Daniel P. Smith
CC: Frediano Ziglio
CC: Alejandro Vallejo
v2:
* New.
---
xen/arch/x86/boot/trampoline.S | 2 ++
xen/arch/x86/xen.lds.S | 7 +++
2 files chan
This is, to the best of my knowledge, accurate. I am providing no comment on
how sane I believe it to be.
At the time of writing, the sizes of the regions are:
offset size
AP: 0x 0x00b0
S3: 0x00b0 0x0229
Boot: 0x02d9 0x1697
Heap: 0x1970 0xe690
Stack: 0xf
The logic is far more sane to follow with a total size, and the position of
the end of the heap. Remove or fix the remaining descriptions of how the
trampoline is laid out.
Move the relevant constants into trampoline.h, which requires making the
header safe to include in assembly files.
No funct
On Wed, Nov 13, 2024 at 4:49 PM Andrew Cooper wrote:
>
> Split out of yet-more microcode cleanup work.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> ---
> xen/include/xen/earlycpio.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/include/xen/e
On Wed, Nov 13, 2024 at 6:51 PM Andrew Cooper wrote:
>
> Both require xen/types.h.
>
> Change multiboot.h to include const.h by it's more normal path, and swap u32
> for uint32_t.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> ---
> xen/include/xen/multiboot.h
On Wed, 2024-11-13 at 17:22 +0100, Thomas Gleixner wrote:
> On Wed, Nov 13 2024 at 13:41, Philipp Stanner wrote:
> > pci_intx() is a hybrid function which can sometimes be managed
> > through
> > devres. This hybrid nature is undesirable.
> >
> > Since all users of pci_intx() have by now been port
On Thu Nov 14, 2024 at 9:08 AM GMT, Andrew Cooper wrote:
> This is, to the best of my knowledge, accurate. I am providing no comment on
> how sane I believe it to be.
>
> At the time of writing, the sizes of the regions are:
>
> offset size
> AP: 0x 0x00b0
> S3: 0x00b0
On Thu, Nov 14, 2024 at 06:11:46AM +, Chen, Jiqian wrote:
> On 2024/11/13 18:30, Roger Pau Monné wrote:
> > On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
> >> On 2024/11/13 17:30, Roger Pau Monné wrote:
> >>> On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
> So
On 14.11.2024 16:59, Andrew Cooper wrote:
> On 14/11/2024 11:11 am, Jan Beulich wrote:
>> On 12.11.2024 22:19, Andrew Cooper wrote:
>>> With the tangle of logic starting to come under control, it is now plain to
>>> see that parse_blob()'s side effect of re-gathering the signature/revision
>>> is
On Thu, 2024-11-14 at 10:49 +0100, Jan Beulich wrote:
> > > > @@ -423,3 +429,147 @@ void * __init early_fdt_map(paddr_t
> > > > fdt_paddr)
> > > >
> > > > return fdt_virt;
> > > > }
> > > > +
> > > > +vaddr_t __ro_after_init directmap_virt_start =
> > > > DIRECTMAP_VIRT_START;
> > > > +
> >
Split the code that detects whether the physical and linear address of a
mapping request are suitable to be used in an L3 or L2 slot.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v2:
- Fix parenthesization of macro parameter.
- Add a
INVALID_MFN is ~0, so by it having all bits as 1s it doesn't fulfill the
super-page address alignment checks for L3 and L2 entries. Skip the alignment
checks if the new entry is a non-present one.
This fixes a regression introduced by 0b6b51a69f4d, where the switch from 0 to
INVALID_MFN caused al
On 14/11/2024 11:11 am, Jan Beulich wrote:
> On 12.11.2024 22:19, Andrew Cooper wrote:
>> With the tangle of logic starting to come under control, it is now plain to
>> see that parse_blob()'s side effect of re-gathering the signature/revision is
>> pointless.
>>
>> The cpu_request_microcode() hook
On Thu, 2024-11-14 at 17:30 +0100, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-11-14 at 10:49 +0100, Jan Beulich wrote:
> > > > > @@ -423,3 +429,147 @@ void * __init early_fdt_map(paddr_t
> > > > > fdt_paddr)
> > > > >
> > > > > return fdt_virt;
> > > > > }
> > > > > +
> > > > > +vaddr
On 14.11.2024 17:30, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-11-14 at 10:49 +0100, Jan Beulich wrote:
> @@ -423,3 +429,147 @@ void * __init early_fdt_map(paddr_t
> fdt_paddr)
>
> return fdt_virt;
> }
> +
> +vaddr_t __ro_after_init directmap_virt_start =
On 12.11.2024 22:19, Andrew Cooper wrote:
> @@ -199,8 +198,8 @@ static bool microcode_fits_cpu(const struct
> microcode_patch *patch)
> return equiv.id == patch->processor_rev_id;
> }
>
> -static enum microcode_match_result cf_check compare_patch(
> -const struct microcode_patch *new,
On 14/11/2024 10:48 am, Alejandro Vallejo wrote:
> On Thu Nov 14, 2024 at 9:08 AM GMT, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/include/asm/trampoline.h
>> b/xen/arch/x86/include/asm/trampoline.h
>> index 8c1e0b48c2c9..559111d2ccfc 100644
>> --- a/xen/arch/x86/include/asm/trampoline.h
>>
On 14/11/2024 9:39 am, Jan Beulich wrote:
> On 13.11.2024 14:32, Andrew Cooper wrote:
>> On 13/11/2024 1:31 pm, Andrew Cooper wrote:
>>> On 13/11/2024 8:01 am, Jan Beulich wrote:
On 13.11.2024 01:24, Andrew Cooper wrote:
> On 12/11/2024 3:00 pm, Jan Beulich wrote:
>> While result value
On 13.11.2024 16:20, Andrew Cooper wrote:
> On 12/11/2024 1:00 pm, Jan Beulich wrote:
>> the release is due by the end of the month. Please point out backports you
>> find
>> missing from the respective staging branch, but which you consider relevant.
>
> Looking over the XenServer patchqueue:
F
Initialise multiboot_ptr and pvh_start_info_pa from C code.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/build32.lds.S | 3 +++
xen/arch/x86/boot/head.S | 10
xen/arch/x86/boot/reloc.c | 28 ++-
xen/arch/x86/include
Move some assembly code to C.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/build32.lds.S | 1 +
xen/arch/x86/boot/cmdline.c | 14 --
xen/arch/x86/boot/head.S| 9 +
xen/arch/x86/boot/trampoline.S | 2 +-
xen/arch/x86/incl
As a continuation of this series start sorting out the issue of headers
not compatible with 32 bit.
Instead of having to change headers which are almost only used for 64 bit
allows to override headers or move reusable definitions to new shared
headers.
This results in less changes.
Frediano Ziglio
Not all headers can be used by 32 bit boot code.
Allows to override some headers, we don't want to mess up with
main headers as most of the code is only 64 bit so the easy stuff should
be done for 64 bit declarations.
Boot headers should be 64 bit compatibles to avoid having multiple
declarations.
On 14/11/2024 13:04, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 14/11/2024 11:48, Michal Orzel wrote:
>>
>>
>> On 14/11/2024 11:31, Julien Grall wrote:
>>> Looking at the code, I think /memreserve/ and /reserved-memory are not
>>> mapped in Xen and everything in /reserved-memory is mapped to
On 14.11.24 13:26, Jan Beulich wrote:
On 13.11.2024 16:29, Jürgen Groß wrote:
On 13.11.24 16:20, Andrew Cooper wrote:
Looking over the XenServer patchqueue:
...
These are a SIGPIPE bugfix which happen to also have a perf
improvement. I cant remember if we discussed backporting them before.
On 13.11.2024 16:29, Jürgen Groß wrote:
> On 13.11.24 16:20, Andrew Cooper wrote:
>> Looking over the XenServer patchqueue:
>
> ...
>
>> These are a SIGPIPE bugfix which happen to also have a perf
>> improvement. I cant remember if we discussed backporting them before.
>> (Juergen/Anthony?)
>>
>
On 12.11.2024 22:19, Andrew Cooper wrote:
> microcode_update_cache() now has a single caller, but inlining it shows how
> unnecessarily complicated the logic really is.
>
> Outside of error paths, there is always one microcode patch to free. Its
> either result of parse_blob(), or it's the old ca
On 14.11.24 12:28, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latter range is clashing with the already recorded /memreserv
On 12.11.2024 22:19, Andrew Cooper wrote:
> With the tangle of logic starting to come under control, it is now plain to
> see that parse_blob()'s side effect of re-gathering the signature/revision is
> pointless.
>
> The cpu_request_microcode() hooks need the signature only. The BSP gathers
> thi
On 14/11/2024 11:31, Julien Grall wrote:
>
>
> Hi Stefano,
>
> On 13/11/2024 22:41, Stefano Stabellini wrote:
>> On Wed, 13 Nov 2024, Julien Grall wrote:
>>> On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
> On 13/11/2024 14:19, Michal Orzel wrote:
>
On 14/11/2024 12:30 pm, Jürgen Groß wrote:
> On 14.11.24 13:26, Jan Beulich wrote:
>> On 13.11.2024 16:29, Jürgen Groß wrote:
>>> On 13.11.24 16:20, Andrew Cooper wrote:
Looking over the XenServer patchqueue:
>>>
>>> ...
>>>
These are a SIGPIPE bugfix which happen to also have a perf
On Tue, Nov 5, 2024 at 2:52 PM Jan Beulich wrote:
>
> On 19.08.2024 16:29, Frediano Ziglio wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -287,19 +287,36 @@ static bool __init match_guid(const EFI_GUID *guid1,
> > const EFI_GUID *guid2)
> > /* generic routine for p
On 14/11/2024 12:46 pm, Jan Beulich wrote:
> On 13.11.2024 16:20, Andrew Cooper wrote:
>> On 12/11/2024 1:00 pm, Jan Beulich wrote:
>>> the release is due by the end of the month. Please point out backports you
>>> find
>>> missing from the respective staging branch, but which you consider relevan
71 matches
Mail list logo
