On 17.02.2025 09:25, Roger Pau Monné wrote:
> On Fri, Feb 14, 2025 at 02:07:05PM +0100, Jan Beulich wrote:
>> On 14.02.2025 13:38, Roger Pau Monné wrote:
>>> On Fri, Feb 14, 2025 at 12:53:01PM +0100, Jan Beulich wrote:
On 14.02.2025 10:29, Roger Pau Monne wrote:
> +{
> +unsigned lo
On 14.02.2025 14:57, Roger Pau Monné wrote:
> On Fri, Feb 14, 2025 at 02:01:09PM +0100, Jan Beulich wrote:
>> On 12.02.2025 16:38, Roger Pau Monne wrote:
>>> There's also the following restriction noted in Intel VT-d:
>>>
Software must not program paging-structure entries to remap any address
On 17.02.25 09:31, Nicola Vetrini wrote:
On 2025-02-17 08:54, Jan Beulich wrote:
On 15.02.2025 00:04, Stefano Stabellini wrote:
On Fri, 14 Feb 2025, Nicola Vetrini wrote:
Rule 8.2 states: "Function types shall be in prototype form with
named parameters".
The parameter name is missing from the
On 2/12/25 4:38 PM, Roger Pau Monne wrote:
Xen currently prevents dom0 from creating CPU or IOMMU page-table mappings
into the interrupt address range [0xfee0, 0xfeef]. This range has
two different purposes. For accesses from the CPU is contains the default
position of local APIC page
This work has been presented at Xen Summit 2024 during the
IOMMU paravirtualization and Xen IOMMU subsystem rework
design session.
Operating systems may want to have access to a IOMMU in order to do DMA
protection or implement certain features (e.g VFIO on Linux).
VFIO support is mandatory for
Preparatory work for IOMMU redesign.
Introduce a new structure (arch_)iommu_context that will hold all
per-IOMMU context related informations for the IOMMU drivers.
Signed-off-by: Teddy Astie
---
xen/arch/arm/include/asm/iommu.h| 4 +
xen/arch/ppc/include/asm/iommu.h|
On 16/02/2025 11:09 pm, Greg A. Woods wrote:
> I had been testing 4.20-rc (at git:19730dbb3f) relatively successfully
> on a older Dell PE-2950 server.
>
> Today I tried upgrading to git:414dde38b0 and I encountered the
> following highly repeatable crash on first boot. (note the git commit
> show
On 16.02.2025 11:23, Juergen Gross wrote:
> The list_for_each_entry*() iterators are testing for having reached the
> end of the list in a way which relies on undefined behavior: the
> iterator (being a pointer to the struct of a list element) is advanced
> and only then tested to have reached not
Introduce a new facility that reserves a fixed amount of contiguous
pages and provide a way to allocate them.
It is used to ensure that the guest cannot cause the hypervisor to
OOM with unconstrained allocations by abusing the PV-IOMMU interface.
Signed-off-by: Teddy Astie
---
xen/arch/x86/incl
When Xen is built without HAS_PASSTHROUGH, there are some parts
in arm and x86 where iommu_* functions are called in the codebase,
but their implementation is under xen/drivers/passthrough that is
not built.
So provide some stub for these functions in order to build Xen
when !HAS_PASSTHROUGH, whic
Hi all,
in order to build Xen for Arm64 with MPU support, there are few changes to
support the compilation of Arm code without HAS_PASSTHROUGH and some refactoring
around the start_xen for Arm.
Luca Fancellu (2):
xen/passthrough: Provide stub functions when !HAS_PASSTHROUGH
xen/arm: Restrict
On 17.02.2025 11:20, Roger Pau Monné wrote:
> On Mon, Feb 17, 2025 at 09:44:28AM +0100, Jan Beulich wrote:
>> On 17.02.2025 09:25, Roger Pau Monné wrote:
>>> On Fri, Feb 14, 2025 at 02:07:05PM +0100, Jan Beulich wrote:
On 14.02.2025 13:38, Roger Pau Monné wrote:
> On Fri, Feb 14, 2025 at 1
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible consequ
On 17.02.2025 11:17, Penny, Zheng wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, February 11, 2025 8:09 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andryuk, Jason
>> ; Andrew Cooper ;
>> Anthony PER
On 16.02.2025 22:19, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is actually what the caller acquire_resource() expects on any kind
> of error (the comment on top of resource_max_frames() also suggests that).
> Otherwise, the caller will treat -errno as a valid value and pro
On 14.02.2025 21:05, dm...@proton.me wrote:
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -210,9 +210,28 @@ void __init xen_build_init(void)
> }
> }
> #endif /* CONFIG_X86 */
> -if ( !rc )
> -printk(XENLOG_INFO "build-id: %*phN\n", build_id_len, build_id_
On 17.02.2025 11:51, Roger Pau Monné wrote:
> On Mon, Feb 17, 2025 at 11:27:52AM +0100, Jan Beulich wrote:
>> On 17.02.2025 11:20, Roger Pau Monné wrote:
>>> On Mon, Feb 17, 2025 at 09:44:28AM +0100, Jan Beulich wrote:
On 17.02.2025 09:25, Roger Pau Monné wrote:
> On Fri, Feb 14, 2025 at 0
On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is actually what the caller acquire_resource() expects on any kind
> of error (the comment on top of resource_max_frames() also suggests that).
:(
So it broke somewhere between v3 and v8 of the original pat
On 17.02.25 10:47, Jan Beulich wrote:
On 16.02.2025 11:23, Juergen Gross wrote:
The list_for_each_entry*() iterators are testing for having reached the
end of the list in a way which relies on undefined behavior: the
iterator (being a pointer to the struct of a list element) is advanced
and only
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
> 1. Const string arrays reformatting
> In case the length of items change we might need to introduce a bigger
> change wrt new formatting of unaffected lines
> ==
>
> --
On 16.02.2025 11:23, Juergen Gross wrote:
> Patch 1 is a fix for an undefined behavior reported by Andrew. I think
> this patch should be considered for 4.20.
>
> Patch 2 is fixing wrong comments in list.h I stumbled over when doing
> patch 1. As it is absolutely no risk involved with this patch,
On 17.02.2025 12:16, Juergen Gross wrote:
> On 17.02.25 10:47, Jan Beulich wrote:
>> On 16.02.2025 11:23, Juergen Gross wrote:
>>> @@ -556,11 +590,11 @@ static inline void list_splice_init(struct list_head
>>> *list,
>>>* @head: the head for your list.
>>>* @member: the name of the list_
On 16.02.2025 11:23, Juergen Gross wrote:
> There are several places in list.h where "list_struct" is used instead
> of "struct list_head". Fix that.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On 17.02.2025 10:47, Roger Pau Monné wrote:
> On Mon, Feb 17, 2025 at 09:49:18AM +0100, Jan Beulich wrote:
>> On 14.02.2025 14:57, Roger Pau Monné wrote:
>>> On Fri, Feb 14, 2025 at 02:01:09PM +0100, Jan Beulich wrote:
On 12.02.2025 16:38, Roger Pau Monne wrote:
> There's also the followin
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, February 11, 2025 8:09 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Roger Pau Monné
>
Introduce the changes proposed in docs/designs/iommu-context.md.
Signed-off-by: Teddy Astie
---
This patch is still quite large but I am not sure how to split it further.
---
xen/arch/x86/include/asm/iommu.h|8 +-
xen/arch/x86/mm/p2m-ept.c |2 +-
xen/arch/x8
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection.
This patch introduce a proposal for IOMMU paravirtualization for Dom0.
Signed-off-by: Teddy Astie
---
docs/designs/pv-iommu.md | 116 +++
1 file changed, 116 i
Simplify the hardware DID management by allocating a DID
per IOMMU context (currently Xen domain) instead of trying
to reuse Xen domain DID (which may not be possible depending
on hardware constraints like did limits).
Signed-off-by: Teddy Astie
---
xen/arch/x86/include/asm/iommu.h | 5
Current quarantine code is very hard to change and is very
complicated, remove most bits of it and replace it with direct
reassignement to dom_io domain instead.
Signed-off-by: Teddy Astie
---
A idea would be to rework this feature using the new reworked
IOMMU subsystem.
---
xen/arch/x86/include
This logic is almost never called as the only possible failures are
- no memory to allocate the pagetable (if it isn't already allocated)
this is fixed in this patch serie by ensuring that the pagetable is allocated
when entering this function
- EILSEQ when there is a race condtion with hardwar
Introduce the PV-IOMMU subsystem as defined in docs/designs/pv-iommu.md.
Signed-off-by: Teddy Astie
---
xen/arch/x86/include/asm/iommu.h| 3 +
xen/common/Makefile | 1 +
xen/common/pv-iommu.c | 536
xen/drivers/pa
For the IOMMU redesign, the iommu context pagetable is defined once during
initialization. When reusing P2M pagetable, we want to ensure that this
pagetable is properly initialized.
Signed-off-by: Teddy Astie
---
xen/arch/x86/domain.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
This feature exposed through `dom0-iommu=no-dma` prevents the devices
of default context to have access to domain's memory.
This basically enforces DMA protection by default. The domain will
need to prepare a specific IOMMU context to do DMA.
This feature needs the guest to provide a PV-IOMMU driv
Current IOMMU subsystem has some limitations that make PV-IOMMU practically
impossible.
One of them is the assumtion that each domain is bound to a single "IOMMU
domain", which
also causes complications with quarantine implementation.
Moreover, current IOMMU subsystem is not entirely well-define
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -14,7 +14,7 @@
> * abstracted.
> */
> #if defined(CONFIG_HAS_PCI) && defined(CONFIG_X86)
> -# define NS16550_PCI
> +#define NS16550_PCI
> #endif
Hmm. Either form oug
On Mon, Feb 17, 2025 at 09:44:28AM +0100, Jan Beulich wrote:
> On 17.02.2025 09:25, Roger Pau Monné wrote:
> > On Fri, Feb 14, 2025 at 02:07:05PM +0100, Jan Beulich wrote:
> >> On 14.02.2025 13:38, Roger Pau Monné wrote:
> >>> On Fri, Feb 14, 2025 at 12:53:01PM +0100, Jan Beulich wrote:
> On 1
On Fri, Feb 14, 2025 at 02:07:05PM +0100, Jan Beulich wrote:
> On 14.02.2025 13:38, Roger Pau Monné wrote:
> > On Fri, Feb 14, 2025 at 12:53:01PM +0100, Jan Beulich wrote:
> >> On 14.02.2025 10:29, Roger Pau Monne wrote:
> >>> +{
> >>> +unsigned long gfn = paddr_to_pfn(addr);
> >>> +struct
On 17.02.2025 00:09, Greg A. Woods wrote:
> I had been testing 4.20-rc (at git:19730dbb3f) relatively successfully
> on a older Dell PE-2950 server.
>
> Today I tried upgrading to git:414dde38b0 and I encountered the
> following highly repeatable crash on first boot. (note the git commit
> shown
On 2025-02-17 08:54, Jan Beulich wrote:
On 15.02.2025 00:04, Stefano Stabellini wrote:
On Fri, 14 Feb 2025, Nicola Vetrini wrote:
Rule 8.2 states: "Function types shall be in prototype form with
named parameters".
The parameter name is missing from the function pointer type
that constitutes th
LLC coloring can be used only on MMU system, move the code
that selects it from ARM_64 to MMU and add the ARM_64
dependency.
While there, add a clarification comment in the startup
code related to the LLC coloring, because boot_fdt_info()
is required to be called before llc_coloring_init(), becaus
On Mon, Feb 17, 2025 at 11:27:52AM +0100, Jan Beulich wrote:
> On 17.02.2025 11:20, Roger Pau Monné wrote:
> > On Mon, Feb 17, 2025 at 09:44:28AM +0100, Jan Beulich wrote:
> >> On 17.02.2025 09:25, Roger Pau Monné wrote:
> >>> On Fri, Feb 14, 2025 at 02:07:05PM +0100, Jan Beulich wrote:
> On 1
On 17.02.2025 11:27, Luca Fancellu wrote:
> When Xen is built without HAS_PASSTHROUGH, there are some parts
> in arm and x86 where iommu_* functions are called in the codebase,
> but their implementation is under xen/drivers/passthrough that is
> not built.
Why the mention of x86, where HAS_PASSTH
On Mon, Feb 17, 2025 at 09:49:18AM +0100, Jan Beulich wrote:
> On 14.02.2025 14:57, Roger Pau Monné wrote:
> > On Fri, Feb 14, 2025 at 02:01:09PM +0100, Jan Beulich wrote:
> >> On 12.02.2025 16:38, Roger Pau Monne wrote:
> >>> There's also the following restriction noted in Intel VT-d:
> >>>
>
On 16/02/2025 10:23 am, Juergen Gross wrote:
> The list_for_each_entry*() iterators are testing for having reached the
> end of the list in a way which relies on undefined behavior: the
> iterator (being a pointer to the struct of a list element) is advanced
> and only then tested to have reached n
On 17.02.2025 03:49, Volodymyr Babchuk wrote:> --- /dev/null
> +++ b/xen/include/xen/stack-protector.h
> @@ -0,0 +1,43 @@
> +#ifndef __XEN_STACK_PROTECTOR_H__
> +#define __XEN_STACK_PROTECTOR_H__
> +
> +#ifdef CONFIG_STACK_PROTECTOR
> +
> +extern unsigned long __stack_chk_guard;
> +
> +/*
> + * Thi
On 15.02.2025 03:16, Stefano Stabellini wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3797,22 +3797,14 @@ uint64_t hvm_get_reg(struct vcpu *v, unsigned int reg)
> {
> ASSERT(v == current || !vcpu_runnable(v));
>
> -switch ( reg )
> -{
> -default:
> -
On 17.02.25 11:18, Jan Beulich wrote:
Hello Jan
On 16.02.2025 22:19, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the ca
Hi Jan,
thanks for your review,
> On 17 Feb 2025, at 10:50, Jan Beulich wrote:
>
> On 17.02.2025 11:27, Luca Fancellu wrote:
>> When Xen is built without HAS_PASSTHROUGH, there are some parts
>> in arm and x86 where iommu_* functions are called in the codebase,
>> but their implementation is un
On 17.02.25 12:39, Jan Beulich wrote:
On 17.02.2025 12:16, Juergen Gross wrote:
On 17.02.25 10:47, Jan Beulich wrote:
On 16.02.2025 11:23, Juergen Gross wrote:
@@ -556,11 +590,11 @@ static inline void list_splice_init(struct list_head
*list,
* @head: the head for your list.
* @membe
>>> +static inline int iommu_domain_init(struct domain *d, unsigned int opts)
>>> +{
>>> +return 0;
>>
>> Shouldn't this fail when is_iommu_enabled(d) is true? (The use of the
>> predicate here as well as in the real function is slightly strange, but
>> that's the way it is.)
>
> Right, prob
On 17.02.2025 12:55, Luca Fancellu wrote:
>> On 17 Feb 2025, at 10:50, Jan Beulich wrote:
>> On 17.02.2025 11:27, Luca Fancellu wrote:
>>> When Xen is built without HAS_PASSTHROUGH, there are some parts
>>> in arm and x86 where iommu_* functions are called in the codebase,
>>> but their implementa
On 17.02.2025 12:58, Jürgen Groß wrote:
> On 17.02.25 12:39, Jan Beulich wrote:
>> On 17.02.2025 12:16, Juergen Gross wrote:
>>> On 17.02.25 10:47, Jan Beulich wrote:
On 16.02.2025 11:23, Juergen Gross wrote:
> @@ -556,11 +590,11 @@ static inline void list_splice_init(struct
> list_he
A lot of systems automatically add microcode to the initramfs so it can
be useful as a vendor policy to always scan for microcode. Add a Kconfig
option to allow setting the default behaviour.
The default behaviour is unchanged since the new option defaults to
"no".
Signed-off-by: Ross Lagerwall
On 2/16/25 11:23 AM, Juergen Gross wrote:
Patch 1 is a fix for an undefined behavior reported by Andrew. I think
this patch should be considered for 4.20.
Patch 2 is fixing wrong comments in list.h I stumbled over when doing
patch 1. As it is absolutely no risk involved with this patch, I think
On 17/02/2025 4:51 pm, Jan Beulich wrote:
> On 17.02.2025 17:12, Andrew Cooper wrote:
>> There is a corner case in the VMRUN instruction where its INTR_SHADOW state
>> leaks into guest state if a VMExit occurs before the VMRUN is complete. An
>> example of this could be taking #NPF due to event in
Hi Michal,
> On 17 Feb 2025, at 12:55, Orzel, Michal wrote:
>
>
>
> On 17/02/2025 11:27, Luca Fancellu wrote:
>>
>>
>> LLC coloring can be used only on MMU system, move the code
>> that selects it from ARM_64 to MMU and add the ARM_64
>> dependency.
>>
>> While there, add a clarification co
The current code in arch_iommu_hwdom_init() kind of open-codes the same
MMIO permission ranges that are added to the hardware domain ->iomem_caps.
Avoid this duplication and use ->iomem_caps in arch_iommu_hwdom_init() to
filter which memory regions should be added to the dom0 IOMMU page-tables.
Th
Xen currently prevents dom0 from creating CPU or IOMMU page-table mappings
into the interrupt address range [0xfee0, 0xfeef]. This range has
two different purposes. For accesses from the CPU is contains the default
position of local APIC page at 0xfee0. For accesses from devices
it's
On 29/01/2025 08:33, Bertrand Marquis wrote:
Hi Ayan,
Hi Bertrand,
Apologies for the delay in response. I am working on v2 , but need some
clarifications.
On 14 Jan 2025, at 20:50, Ayan Kumar Halder wrote:
We have written the requirements for some of the commands of the XEN_VERSION
h
On 17/02/2025 14:15, Luca Fancellu wrote:
>
>
> Hi Michal,
>
>> On 17 Feb 2025, at 12:55, Orzel, Michal wrote:
>>
>>
>>
>> On 17/02/2025 11:27, Luca Fancellu wrote:
>>>
>>>
>>> LLC coloring can be used only on MMU system, move the code
>>> that selects it from ARM_64 to MMU and add the ARM_6
On 17/02/2025 11:27, Luca Fancellu wrote:
>
>
> LLC coloring can be used only on MMU system, move the code
> that selects it from ARM_64 to MMU and add the ARM_64
> dependency.
>
> While there, add a clarification comment in the startup
> code related to the LLC coloring, because boot_fdt_inf
On 17/02/2025 1:11 pm, Oleksandr Tyshchenko wrote:
>
>
> On 17.02.25 13:09, Andrew Cooper wrote:
>
>
> Hello Andrew
>
>
>> On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> This is actually what the caller acquire_resource() expects on any kind
>>> of error
A lot of systems automatically add microcode to the initrd so it can be
useful as a vendor policy to always scan for microcode. Add a Kconfig
option to allow setting the default behaviour.
The default behaviour is unchanged since the new option defaults to
"no".
Signed-off-by: Ross Lagerwall
---
Hello,
First patch is a preparatory change to reduce the changes required in
patch 2. I would have wanted those to go in 4.20 to fix the issues on
Lenovo Thinkpads, but it's too late now.
Thanks, Roger.
Roger Pau Monne (2):
x86/iommu: account for IOMEM caps when populating dom0 IOMMU
page
On 17.02.25 13:16, Jan Beulich wrote:
On 17.02.2025 12:58, Jürgen Groß wrote:
On 17.02.25 12:39, Jan Beulich wrote:
On 17.02.2025 12:16, Juergen Gross wrote:
On 17.02.25 10:47, Jan Beulich wrote:
On 16.02.2025 11:23, Juergen Gross wrote:
@@ -556,11 +590,11 @@ static inline void list_splice_i
On 17/02/2025 1:55 pm, Frediano Ziglio wrote:
> ping
Ping what?
You have no maintainer ack, an outstanding bug raised against this
version, and a suggestion on how to address it.
I'd really like to see this in 4.20 too, but this needs a v6 before it's
going to progress any further.
~Andrew
On 17.02.2025 17:12, Andrew Cooper wrote:
> There is a corner case in the VMRUN instruction where its INTR_SHADOW state
> leaks into guest state if a VMExit occurs before the VMRUN is complete. An
> example of this could be taking #NPF due to event injection.
Ouch.
> --- a/xen/arch/x86/hvm/svm/e
On 17/02/2025 4:08 pm, Ross Lagerwall wrote:
> A lot of systems automatically add microcode to the initrd so it can be
> useful as a vendor policy to always scan for microcode. Add a Kconfig
> option to allow setting the default behaviour.
>
> The default behaviour is unchanged since the new option
On 17/02/2025 4:31 pm, Jan Beulich wrote:
> On 17.02.2025 17:26, Frediano Ziglio wrote:
>> --- a/xen/common/efi/efi-common.mk
>> +++ b/xen/common/efi/efi-common.mk
>> @@ -2,6 +2,7 @@ EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o
>> EFIOBJ-$(CONFIG_COMPAT) += compat.o
>>
>> CFLAGS-y +=
On Mon, Feb 17, 2025 at 4:41 PM Andrew Cooper wrote:
>
> On 17/02/2025 4:31 pm, Jan Beulich wrote:
> > On 17.02.2025 17:26, Frediano Ziglio wrote:
> >> --- a/xen/common/efi/efi-common.mk
> >> +++ b/xen/common/efi/efi-common.mk
> >> @@ -2,6 +2,7 @@ EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runti
On 17.02.2025 17:08, Ross Lagerwall wrote:
> A lot of systems automatically add microcode to the initrd so it can be
> useful as a vendor policy to always scan for microcode. Add a Kconfig
> option to allow setting the default behaviour.
>
> The default behaviour is unchanged since the new option
On 17.02.2025 17:52, Frediano Ziglio wrote:
> On Mon, Feb 17, 2025 at 4:41 PM Andrew Cooper
> wrote:
>>
>> On 17/02/2025 4:31 pm, Jan Beulich wrote:
>>> On 17.02.2025 17:26, Frediano Ziglio wrote:
--- a/xen/common/efi/efi-common.mk
+++ b/xen/common/efi/efi-common.mk
@@ -2,6 +2,7 @@
On Mon, Feb 17, 2025 at 4:44 PM Andrew Cooper wrote:
>
> On 17/02/2025 4:08 pm, Ross Lagerwall wrote:
> > A lot of systems automatically add microcode to the initrd so it can be
> > useful as a vendor policy to always scan for microcode. Add a Kconfig
> > option to allow setting the default behavi
Hello Frediano,
On 2/17/25 3:45 PM, Andrew Cooper wrote:
On 17/02/2025 1:55 pm, Frediano Ziglio wrote:
ping
Ping what?
You have no maintainer ack, an outstanding bug raised against this
version, and a suggestion on how to address it.
I'd really like to see this in 4.20 too, but this needs a
On 26/1/25 22:16, Richard Henderson wrote:
On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
CPU_INTERRUPT_EXIT was removed in commit 3098dba01c7
("Use a dedicated function to request exit from execution
loop"), tlb_flush() and tb_flush() are related to TCG
accelerator.
Signed-off-by: Philippe Ma
On 15/02/2025 01:17, Stefano Stabellini wrote:
>
>
> Add vcpu affinity to the dom0less bindings. Example:
>
> dom1 {
> ...
> cpus = <4>;
> vcpu0 {
>
On 17.02.25 13:09, Andrew Cooper wrote:
Hello Andrew
On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
:(
So
ping
On Wed, Feb 5, 2025 at 11:40 AM Frediano Ziglio
wrote:
>
> On Wed, Feb 5, 2025 at 10:24 AM Oleksii Kurochko
> wrote:
> >
> >
> > On 2/4/25 2:07 PM, Jan Beulich wrote:
> >
> > On 22.01.2025 11:14, Frediano Ziglio wrote:
> >
> > Although code is compiled with -fpic option data is not position
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c1f2d1b89d43..91fa579e73e5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -328,6 +328,7 @@ void asmlinkage __init start_xen(unsigned long
fdt_paddr)
(padd
There is a corner case in the VMRUN instruction where its INTR_SHADOW state
leaks into guest state if a VMExit occurs before the VMRUN is complete. An
example of this could be taking #NPF due to event injection.
Xen can safely execute STI anywhere between CLGI and VMRUN, as CLGI blocks
external i
>
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -110,6 +110,8 @@ extern int8_t iommu_hwdom_reserved;
extern unsigned int iommu_dev_iotlb_timeout;
+#ifdef CONFIG_HAS_PASSTHROUGH
+
int iommu_setup(void);
int iommu_hardware_setup(vo
On 17/02/2025 4:18 pm, Jan Beulich wrote:
> On 17.02.2025 17:08, Ross Lagerwall wrote:
>> A lot of systems automatically add microcode to the initrd so it can be
>> useful as a vendor policy to always scan for microcode. Add a Kconfig
>> option to allow setting the default behaviour.
>>
>> The defa
Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.
Code tested adding
PrintErrMesg(L"Test message", EFI_BUFFE
On 29/01/2025 08:27, Bertrand Marquis wrote:
Hi Ayan,
Hi Bertrand,
I need some clarifications.
On 14 Jan 2025, at 20:50, Ayan Kumar Halder wrote:
In the current patch, we have defined the requirements which are common for
all the commands.
Signed-off-by: Ayan Kumar Halder
---
.../fus
On 17.02.2025 17:14, Luca Fancellu wrote:
>>
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -110,6 +110,8 @@ extern int8_t iommu_hwdom_reserved;
>
> extern unsigned int iommu_dev_iotlb_timeout;
>
> +#ifdef CONFIG_HAS_PASSTHROUGH
> +
> int io
On 17.02.2025 17:26, Frediano Ziglio wrote:
> --- a/xen/common/efi/efi-common.mk
> +++ b/xen/common/efi/efi-common.mk
> @@ -2,6 +2,7 @@ EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o
> EFIOBJ-$(CONFIG_COMPAT) += compat.o
>
> CFLAGS-y += -fshort-wchar
> +CFLAGS-y += -fno-jump-tables
> C
On Mon, 17 Feb 2025, Jan Beulich wrote:
> On 15.02.2025 09:59, Nicola Vetrini wrote:
> > On 2025-02-15 00:04, Stefano Stabellini wrote:
> >> On Fri, 14 Feb 2025, Jan Beulich wrote:
> Would deviating macros "COOKIE2MCTE" and "MCTE2COOKIE" work?
> >>>
> >>> If it did, COOKIE2ID and ID2COOKIE wou
On Mon, 17 Feb 2025, Jan Beulich wrote:
> On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
> > 1. Const string arrays reformatting
> > In case the length of items change we might need to introduce a bigger
> > change wrt new formatting of unaffected lines
> >
On Mon, Jan 27, 2025 at 10:44:33AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 24, 2025 at 01:26:23PM -0800, Elliott Mitchell wrote:
> > On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monné wrote:
> > >
> > > I think I've figured out the cause for those faults, and posted a fix
> > > here:
>
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Monday, February 17, 2025 3:39 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Roger Pau Monné ; Anthony PERARD
> ; Orzel, Michal ; Julien
> Grall
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, February 11, 2025 9:57 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Roger Pau Monné ; xen-devel@lists.xenproject.org
> Subject: Re: [PA
[AMD Official Use Only - AMD Internal Distribution Only]
Hi
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, February 12, 2025 12:46 AM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Roger Pau Monné ; xen-devel@lists.xenproject.org
> Subject: Re: [
On Mon, 16 Feb 2025, Stefano Stabellini wrote:
> On Mon, 17 Feb 2025, Jan Beulich wrote:
> > On 15.02.2025 09:59, Nicola Vetrini wrote:
> > > On 2025-02-15 00:04, Stefano Stabellini wrote:
> > >> On Fri, 14 Feb 2025, Jan Beulich wrote:
> > Would deviating macros "COOKIE2MCTE" and "MCTE2COOKIE"
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Monday, February 17, 2025 6:34 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Roger Pau Monné
>
On 2/17/25 09:19, Philippe Mathieu-Daudé wrote:
On 26/1/25 22:16, Richard Henderson wrote:
On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
CPU_INTERRUPT_EXIT was removed in commit 3098dba01c7
("Use a dedicated function to request exit from execution
loop"), tlb_flush() and tb_flush() are relate
Add Xen version printout to 'h' keyhandler output.
That is useful for debugging systems that have been left intact for a long
time.
Signed-off-by: Denis Mukhin
Reviewed-by: Jan Beulich
---
Changes since v4:
- switched to checking build_id_len instead of build_id_p in print_build_id()
---
xen/c
On 17/02/2025 10:10 pm, Andrew Cooper wrote:
> On 17/02/2025 10:02 pm, Greg A. Woods wrote:
>> Note again my local patches do not change any actual code in the xen subdir.
>>
>> The "has no endbr64" messages are possibly due to the fact that I'm still
>> using GCC-9.x on NetBSD, and as I understand
On 17/02/2025 8:48 pm, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The sign of the presence of a corresponding bugfix is an error
> returned on querying the size of an unknown for Xen resource type.
>
> Signed-off-by: Oleksandr Tyshchenko
> ---
> Refer https://patchew.org/Xen/202
On Mon, 17 Feb 2025, Jan Beulich wrote:
> On 15.02.2025 03:16, Stefano Stabellini wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -3797,22 +3797,14 @@ uint64_t hvm_get_reg(struct vcpu *v, unsigned int
> > reg)
> > {
> > ASSERT(v == current || !vcpu_runnable(v)
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible consequ
1 - 100 of 111 matches
Mail list logo
