[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: [
[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: 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: 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 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:
>
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"
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, 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
On 17/02/2025 10:34 pm, Oleksandr Tyshchenko wrote:
> diff --git a/tools/tests/resource/test-resource.c
> b/tools/tests/resource/test-resource.c
> index 1b10be16a6..521c1fc51a 100644
> --- a/tools/tests/resource/test-resource.c
> +++ b/tools/tests/resource/test-resource.c
> @@ -123,6 +123,16 @@ st
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 10:02 pm, Greg A. Woods wrote:
> A quick reply, maybe more later...
>
> I thought I had done a fresh clean build as I ran "gmake clean" in the top
> level directory, however then when reading your's and Andrew's replies I
> realized I have been doing the Xen kernel build in a separate
On 17.02.25 23:09, Andrew Cooper wrote:
Hello.
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 Tyshchen
A quick reply, maybe more later...
I thought I had done a fresh clean build as I ran "gmake clean" in the top
level directory, however then when reading your's and Andrew's replies I
realized I have been doing the Xen kernel build in a separate build directory,
which the top-level makefile won't k
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 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
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/20250217102741.4122367-1-olekst...@gmail.com/
Current patch should g
On 17.02.25 15:52, Andrew Cooper wrote:
Hello
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()
Hello everyone,
for few months I'm struggling with a very weird memory corruption issue in
Xen PV Dom0 and storage backed by BOSS-S1 RAID-1 card. I noticed it when I
tried
to copy huge ISO file on Dom0 file system and use it for DomU installation.
Everything was fine while its contents were cac
For ABIs which pass parameters by register (all cases that we compile Xen
for), inserting new arguments on the left hand side involves shuffling all
other parameters along by one register whereas appending a new argument
doesn't involve shuffling of existing registers.
Reorder vprintk_common()'s p
Now that Xen has a real vprintk(), there's no need to opencode it locally with
vsnprintf(). Redirect the debug routines to the real {v,}printk() and drop
the local acpi_os_{v,}printf() implementations.
Amongst other things, this removes one arbitrary limit on message size, as
well as removing a 5
This taken from a security series (hence partially reviewed already), and
thought it only applied to a forthcoming selftest, but then Ayan posted a
truncated example to Matrix.
Patch 1 should be considered for 4.20 at this point. Patches 2 and 3 can
definitely wait until 4.21 opens.
Andrew Coope
The panic() function uses a static buffer to format its arguments into, simply
to emit the result via printk("%s", buf). This buffer is not large enough for
some existing users in Xen. e.g.:
(XEN)
(XEN) Panic on CPU 0:
(XEN) Invalid device tree blob
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
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 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
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 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
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 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
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: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 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 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 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
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 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 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 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
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
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
---
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 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
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
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
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
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
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
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
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
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 15/02/2025 01:17, Stefano Stabellini wrote:
>
>
> Add vcpu affinity to the dom0less bindings. Example:
>
> dom1 {
> ...
> cpus = <4>;
> vcpu0 {
>
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
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
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
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
>>> +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.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
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.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 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 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.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 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
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 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 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 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
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
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
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 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
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|
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
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 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 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
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
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
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
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 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
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
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
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
[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é
>
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
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.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
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.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 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
1 - 100 of 111 matches
Mail list logo
