On 19.02.2025 19:04, Andrew Cooper wrote:
> Oleksii has asked for RC5, and we're overdue. I'm intending to commit:
>
> diff --git a/xen/Makefile b/xen/Makefile
> index 65b460e2b480..4e37fff92514 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(
On 19.02.2025 17:34, Frediano Ziglio wrote:
> On Mon, Feb 17, 2025 at 4:56 PM Jan Beulich wrote:
>> 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 w
On Wed, 19 Feb 2025, Marek Marczykowski-Górecki wrote:
> Debugging sometimes involves running specific jobs on different
> versions. It's useful to easily avoid running all of the not interesting
> ones (for given case) to save both time and CI resources. Doing so used
> to require changing the yam
On Wed, 19 Feb 2025, Marek Marczykowski-Górecki wrote:
> Include info how to get access/enable hardware runners and how to select
> individual jobs.
>
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> new in v3
> Definitely there can be more content here, but lets start somewhere.
> ---
> docs
On Wed, 19 Feb 2025, Michal Orzel wrote:
> At the moment the GIC node we create for hwdom has a name
> "interrupt-controller". Change it so that we use the same name as the
> GIC node from host device tree. This is done for at least 2 purposes:
> 1) The convention in DT spec is that a node name wit
On Wed, 19 Feb 2025, Julien Grall wrote:
> Hi Stefano,
>
> On 18/02/2025 20:29, Stefano Stabellini wrote:
> > Add vcpu affinity to the dom0less bindings. Example:
> >
> > dom1 {
> > ...
> > cpus = <4>;
> > vcpu0 {
> > compatible = "x
On Wed, 19 Feb 2025, Jan Beulich wrote:
> On 18.02.2025 22:42, Stefano Stabellini wrote:
> > On Tue, 18 Feb 2025, Jan Beulich wrote:
> >> On 18.02.2025 00:12, Stefano Stabellini wrote:
> >>> On Mon, 17 Feb 2025, Jan Beulich wrote:
> On 15.02.2025 03:16, Stefano Stabellini wrote:
> > --- a/
On Wed, 19 Feb 2025, Andrew Cooper wrote:
> On 19/02/2025 10:00 am, Jan Beulich wrote:
> > struct mctelem_ent is opaque outside of mcetelem.c; the cookie
> > abstraction exists - afaict - just to achieve this opaqueness. Then it
> > is irrelevant though which kind of pointer mctelem_cookie_t resolv
On Wed, 19 Feb 2025, Andrew Cooper wrote:
> On 19/02/2025 2:18 pm, 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
On Wed, 19 Feb 2025, Oleksandr Andrushchenko wrote:
> Yes, I do agree. But only if we talk about having an automated
> code style check now (which is definitely the goal at some time).
> Before that we could still use the tool to take all that good that
> it does and manually prepare a set of patch
On Wed, 19 Feb 2025, Andrew Cooper wrote:
> On 13/02/2025 7:54 am, Jan Beulich wrote:
> > On 13.02.2025 01:51, Andrew Cooper wrote:
> >> On 12/02/2025 9:52 pm, Stefano Stabellini wrote:
> >>> On Wed, 12 Feb 2025, Oleksii Kurochko wrote:
> Hello everyone,
>
> During the installation o
On 2/19/25 07:13, Valentin Schneider wrote:
>> Maybe I missed part of the discussion though. Is VMEMMAP your only
>> concern? I would have guessed that the more generic vmalloc()
>> functionality would be harder to pin down.
> Urgh, that'll teach me to send emails that late - I did indeed mean the
On 2/19/25 09:08, Joel Fernandes wrote:
>> Pretty much so yeah. That is, *if* there such a vmalloc'd address access in
>> early entry code - testing says it's not the case, but I haven't found a
>> way to instrumentally verify this.
> Ok, thanks for confirming. Maybe there is an address sanitizer w
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.
No
Hello,
> So the issue doesn't happen on debug=y builds? That's unexpected. I would
> expect the opposite, that some code in Linux assumes that pfn + 1 == mfn +
> 1, and hence breaks when the relation is reversed.
It was also surprising for me but I think the key thing is that debug=y
causes whol
On Wed, Feb 19, 2025 at 6:23 PM Petr Beneš wrote:
>
> On Wed, Feb 19, 2025 at 5:53 PM Petr Beneš wrote:
> >
> > On Wed, Feb 19, 2025 at 5:04 PM Petr Beneš wrote:
> > >
> > > Hello,
> > >
> >
> > To add more information and observations:
>
> Even more observations.
Next observations:
The Dom ID
On 14/02/2025 7:15 am, Jan Beulich wrote:
> On 13.02.2025 20:09, Stefano Stabellini wrote:
>> On Thu, 13 Feb 2025, Jan Beulich wrote:
>>> On 13.02.2025 01:51, Andrew Cooper wrote:
On 12/02/2025 9:52 pm, Stefano Stabellini wrote:
> On Wed, 12 Feb 2025, Oleksii Kurochko wrote:
>> Hello e
On 13/02/2025 7:54 am, Jan Beulich wrote:
> On 13.02.2025 01:51, Andrew Cooper wrote:
>> On 12/02/2025 9:52 pm, Stefano Stabellini wrote:
>>> On Wed, 12 Feb 2025, Oleksii Kurochko wrote:
Hello everyone,
During the installation of Xen on an ARM server machine from the source
cod
On 2/18/25 6:03 PM, Jan Beulich wrote:
--- a/xen/arch/riscv/arch.mk
+++ b/xen/arch/riscv/arch.mk
@@ -6,8 +6,13 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32
riscv-abi-$(CONFIG_RISCV_64) := -mabi=lp64
-riscv-march-$(CONFIG_RISCV_IS
At the moment the GIC node we create for hwdom has a name
"interrupt-controller". Change it so that we use the same name as the
GIC node from host device tree. This is done for at least 2 purposes:
1) The convention in DT spec is that a node name with "reg" property
is formed "node-name@unit-addres
On Wed, Feb 19, 2025 at 5:53 PM Petr Beneš wrote:
>
> On Wed, Feb 19, 2025 at 5:04 PM Petr Beneš wrote:
> >
> > Hello,
> >
>
> To add more information and observations:
Even more observations. This is from a run where 4 vms (4 VCPUs each)
were being created in parallel:
```
Saving to /clones/wi
On 2/19/2025 11:18 AM, Valentin Schneider wrote:
> On 19/02/25 10:05, Joel Fernandes wrote:
>> On Fri, Jan 17, 2025 at 05:53:33PM +0100, Valentin Schneider wrote:
>>> On 17/01/25 16:52, Jann Horn wrote:
On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
wrote:
> On 14/01/25 19:16
On Wed, Feb 19, 2025 at 5:04 PM Petr Beneš wrote:
>
> Hello,
>
To add more information and observations:
I'm running Xen 4.20-rc on a MFF Dell Optiplex, CPU is i5-12500T (6
cores, 12 threads). I have allocated 8 cores for dom0. Now:
- xl saving 4 vms, each with 4 VCPUs tend to fail
- xl saving
Hello,
I have a script that's supposed to start a couple of (Windows 10) VMs
in parallel, wait until they boot and connect to the network, and then
create a live snapshot.
VMs are created by simple "xl create vm.cfg" and the live snapshot is
created by "xl save win10-18362-NNN path/to/state".
I
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
Hello,
First two patches are preparatory changes to reduce the changes required
in patch 3. 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 (3):
x86/dom0: correctly set the maximum ->iomem_caps bound for PVH
The logic in dom0_setup_permissions() sets the maximum bound in
->iomem_caps unconditionally using paddr_bits, which is not correct for HVM
based domains. Instead use domain_max_paddr_bits() to get the correct
maximum paddr bits for each possible domain type.
Switch to using PFN_DOWN() instead of
On Mon, Feb 17, 2025 at 4:56 PM Jan Beulich wrote:
>
> 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-co
On 19/02/25 10:05, Joel Fernandes wrote:
> On Fri, Jan 17, 2025 at 05:53:33PM +0100, Valentin Schneider wrote:
>> On 17/01/25 16:52, Jann Horn wrote:
>> > On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
>> > wrote:
>> >> On 14/01/25 19:16, Jann Horn wrote:
>> >> > On Tue, Jan 14, 2025 at 6:51
On 19.02.2025 16:40, Oleksandr Andrushchenko wrote:
> On 19.02.25 16:05, Jan Beulich wrote:
>> On 19.02.2025 14:52, Oleksandr Andrushchenko wrote:
>>> On 19.02.25 15:18, Jan Beulich wrote:
On 19.02.2025 13:39, Oleksandr Andrushchenko wrote:
> On 17.02.25 12:20, Jan Beulich wrote:
>> On
> On 19 Feb 2025, at 13:30, Jan Beulich wrote:
>
> On 19.02.2025 14:06, Luca Fancellu wrote:
>>> On 19 Feb 2025, at 12:45, Jan Beulich wrote:
>>> On 18.02.2025 10:51, Luca Fancellu wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -110,6 +110,8 @@ extern int8
On 19.02.2025 16:25, Luca Fancellu wrote:
>> On 19 Feb 2025, at 13:30, Jan Beulich wrote:
>> On 19.02.2025 14:06, Luca Fancellu wrote:
On 19 Feb 2025, at 12:45, Jan Beulich wrote:
As per the
respective revlog entry, this change looks to belong into whatever is
going to be done
On 19.02.2025 15:46, Oleksii Kurochko wrote:
> On 2/19/25 12:28 PM, Jan Beulich wrote:
>> On 12.02.2025 17:50, Oleksii Kurochko wrote:
>>> +else
>>> {
>>> -rc = pt_next_level(alloc_tbl, &table, offsets[level]);
>>> -if ( rc == XEN_TABLE_MAP_NOMEM )
>>> +pte_t *tabl
On 19.02.25 16:05, Jan Beulich wrote:
On 19.02.2025 14:52, Oleksandr Andrushchenko wrote:
On 19.02.25 15:18, Jan Beulich wrote:
On 19.02.2025 13:39, Oleksandr Andrushchenko wrote:
On 17.02.25 12:20, Jan Beulich wrote:
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
@@ -248,8 +249,9 @@
On 19/02/2025 2:18 pm, 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 no
On 18/02/25 16:39, Dave Hansen wrote:
> On 2/18/25 14:40, Valentin Schneider wrote:
>>> In practice, it's mostly limited like that.
>>>
>>> Architecturally, there are no promises from the CPU. It is within its
>>> rights to cache anything from the page tables at any time. If it's in
>>> the CR3 tre
On 2/19/25 12:05 PM, Jan Beulich wrote:
On 12.02.2025 17:50, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,502 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Originally taken for Linux kernel v6.12-rc3.
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Copyri
On 2/19/25 4:05 PM, Jan Beulich wrote:
On 19.02.2025 15:46, Oleksii Kurochko wrote:
On 2/19/25 12:28 PM, Jan Beulich wrote:
On 12.02.2025 17:50, Oleksii Kurochko wrote:
+else
{
-rc = pt_next_level(alloc_tbl, &table, offsets[level]);
-if ( rc == XEN_TABLE_MAP_NOMEM )
On Fri, Jan 17, 2025 at 05:53:33PM +0100, Valentin Schneider wrote:
> On 17/01/25 16:52, Jann Horn wrote:
> > On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
> > wrote:
> >> On 14/01/25 19:16, Jann Horn wrote:
> >> > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider
> >> > wrote:
> >> >> vu
On 19.02.2025 15:55, Oleksii Kurochko wrote:
> On 2/18/25 6:03 PM, Jan Beulich wrote:
>> On 12.02.2025 17:50, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/Kconfig
>>> +++ b/xen/arch/riscv/Kconfig
>>> @@ -28,16 +28,6 @@ choice
>>> help
>>> This selects the base ISA extensions that Xen
On 19.02.2025 15:23, Oleksandr Andrushchenko wrote:
> On 19.02.25 14:39, Oleksandr Andrushchenko wrote:
>> On 17.02.25 12:20, Jan Beulich wrote:
>>> 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 @@
On 2/18/25 6:03 PM, Jan Beulich wrote:
On 12.02.2025 17:50, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -28,16 +28,6 @@ choice
help
This selects the base ISA extensions that Xen will target.
-config RISCV_ISA_RV64G
- bool "RV6
On 2/19/25 12:28 PM, Jan Beulich wrote:
On 12.02.2025 17:50, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -249,12 +249,10 @@ pte_t pt_walk(vaddr_t va, unsigned int *pte_level)
/* Update an entry at the level @target. */
static int pt_update_entry(mfn_t
On 2/19/25 12:14 PM, Jan Beulich wrote:
On 12.02.2025 17:50, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -185,6 +185,68 @@ static int pt_next_level(bool alloc_tbl, pte_t **table,
unsigned int offset)
return XEN_TABLE_NORMAL;
}
+/*
+ * _pt_walk() p
Hello, Jan!
On 19.02.25 14:39, Oleksandr Andrushchenko wrote:
Hello, Jan!
On 17.02.25 12:20, Jan Beulich wrote:
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_H
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
it should be 4.20 material, too.
Changes in
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
Release-Acked-by: Oleksii Kurochko
---
xen/include/xen/list.h | 34 +-
1 file changed, 17 insertions(+), 17
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 the next element, but the list
head. This results
On 19.02.2025 14:52, Oleksandr Andrushchenko wrote:
> On 19.02.25 15:18, Jan Beulich wrote:
>> On 19.02.2025 13:39, Oleksandr Andrushchenko wrote:
>>> On 17.02.25 12:20, Jan Beulich wrote:
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
> @@ -248,8 +249,9 @@ static int cf_check ns16550
Hello Frediano,
Ok for typos fixes
Le 19/02/2025 à 13:02, Frediano Ziglio a écrit :
> On 17/02/2025 10:18, Teddy Astie wrote:
>> +Each IOMMU context within a Xen domain is identified using a domain-
>> specific
>> +context number that is used in the Xen IOMMU subsystem and the hypercall
>> +inter
On 18.02.2025 09:31, dm...@proton.me wrote:
> @@ -546,31 +555,23 @@ static void __serial_rx(char c)
> * getting stuck.
> */
> send_global_virq(VIRQ_CONSOLE);
> -break;
> -
> +}
> #ifdef CONFIG_SBSA_VUART_CONSOLE
> -default:
> -{
> -struct do
Hello, Jan!
On 19.02.25 15:18, Jan Beulich wrote:
On 19.02.2025 13:39, Oleksandr Andrushchenko wrote:
On 17.02.25 12:20, Jan Beulich wrote:
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
@@ -43,12 +43,12 @@
static struct ns16550 {
int baud, clock_hz, data_bits, parity, sto
On 19/02/2025 1:19 pm, Oleksandr Andrushchenko wrote:
>
>
> On 19.02.25 14:51, Oleksandr Andrushchenko wrote:
>> Hello, Andrew!
>>
>> On 19.02.25 14:49, Andrew Cooper wrote:
>>> On 16/02/2025 5:11 pm, Oleksandr Andrushchenko wrote:
Hello, Roger!
Please find the branch with all the co
On 17.02.2025 22:33, dm...@proton.me wrote:
> 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
Hmm, wait - there's yet another issue:
> --- a/xen
On 19.02.2025 14:06, Luca Fancellu wrote:
>> On 19 Feb 2025, at 12:45, Jan Beulich wrote:
>> On 18.02.2025 10:51, 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_d
On 19.02.25 14:51, Oleksandr Andrushchenko wrote:
Hello, Andrew!
On 19.02.25 14:49, Andrew Cooper wrote:
On 16/02/2025 5:11 pm, Oleksandr Andrushchenko wrote:
Hello, Roger!
Please find the branch with all the conversions [1].
Unfortunately I cannot provide a branch as seen with
diff --igno
On 19.02.2025 13:39, Oleksandr Andrushchenko wrote:
> On 17.02.25 12:20, Jan Beulich wrote:
>> On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
>>> @@ -43,12 +43,12 @@
>>>
>>> static struct ns16550 {
>>> int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, irq;
>>> -u64 io
> On 19 Feb 2025, at 12:45, Jan Beulich wrote:
>
> On 18.02.2025 10:51, 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
Hello, Jan!
On 19.02.25 14:49, Jan Beulich wrote:
On 19.02.2025 13:43, Oleksandr Andrushchenko wrote:
Hello, Jan, Stefano!
On 18.02.25 13:34, Jan Beulich wrote:
On 18.02.2025 03:36, Stefano Stabellini wrote:
On Mon, 17 Feb 2025, Jan Beulich wrote:
On 16.02.2025 11:21, Oleksandr Andrushchenk
Hello, Andrew!
On 19.02.25 14:49, Andrew Cooper wrote:
On 16/02/2025 5:11 pm, Oleksandr Andrushchenko wrote:
Hello, Roger!
Please find the branch with all the conversions [1].
Unfortunately I cannot provide a branch as seen with
diff --ignore-all-space as such a patch will not simply apply.
S
Hello, Grygorii!
On 18.02.25 11:56, Grygorii Strashko wrote:
On 16.02.25 12:21, Oleksandr Andrushchenko wrote:
Hello, everybody!
As agreed before [1] I am sending a series to show two samples of the
formatting done with clang-format. The clang-format configuration can be
found at [2]. It alr
On 19.02.2025 13:43, Oleksandr Andrushchenko wrote:
> Hello, Jan, Stefano!
>
> On 18.02.25 13:34, Jan Beulich wrote:
>> On 18.02.2025 03:36, Stefano Stabellini wrote:
>>> On Mon, 17 Feb 2025, Jan Beulich wrote:
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
> 1. Const string arrays r
On 16/02/2025 5:11 pm, Oleksandr Andrushchenko wrote:
> Hello, Roger!
>
> Please find the branch with all the conversions [1].
> Unfortunately I cannot provide a branch as seen with
> diff --ignore-all-space as such a patch will not simply apply.
>
> Stay safe,
> Oleksandr Andrushchenko
>
> On 16.0
On 18.02.2025 10:51, 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 iommu_setup(void);
> int iommu_har
Hello, Jan, Stefano!
On 18.02.25 13:34, Jan Beulich wrote:
On 18.02.2025 03:36, Stefano Stabellini wrote:
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 introdu
Hello, Jan!
On 17.02.25 12:20, Jan Beulich wrote:
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 NS
On 2/18/25 3:45 PM, Andrew Cooper wrote:
On 18/02/2025 2:42 pm, Jan Beulich wrote:
On 18.02.2025 15:37, 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 c
On 17/02/2025 10:18, Teddy Astie wrote:
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).
Minor: here and in the title, did sh
On 17/02/2025 10:18, Teddy Astie wrote:
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).
Minor: here and in the title, did sh
On 17/02/2025 10:18, Teddy Astie wrote:
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 +++
Hi Andrew,
On 14/02/2025 14:25, Andrew Cooper wrote:
On 14/02/2025 2:10 pm, Grygorii Strashko wrote:
For example, requested range:
00e614 - 00e6141004 should set e6140:e6141 nr=2, but will
configure
e6140 e6142 nr=3 instead.
I am not sure what 'nr' is referring to here.
Sorry, will
On 12.02.2025 17:50, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/pt.c
> +++ b/xen/arch/riscv/pt.c
> @@ -249,12 +249,10 @@ pte_t pt_walk(vaddr_t va, unsigned int *pte_level)
>
> /* Update an entry at the level @target. */
> static int pt_update_entry(mfn_t root, vaddr_t virt,
> -
Hi Grygorii,
On 18/02/2025 11:22, Grygorii Strashko wrote:
Now the following code in map_range_to_domain()
res = rangeset_add_range(mr_data->iomem_ranges,
paddr_to_pfn(addr),
paddr_to_pfn_aligned(addr + len - 1));
where
paddr_to_pfn_a
Hi Grygorii,
On 18/02/2025 11:22, Grygorii Strashko wrote:
Now the following code in map_range_to_domain()
res = iomem_permit_access(d, paddr_to_pfn(addr),
paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
calculates the iomem range end address by rounding it up to the next
On 12.02.2025 17:50, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -210,6 +210,13 @@ static inline pte_t pte_from_mfn(mfn_t mfn, unsigned int
> flags)
>
> pte_t pt_walk(vaddr_t va, unsigned int *pte_level);
>
> +static inline
On 12.02.2025 17:50, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/pt.c
> +++ b/xen/arch/riscv/pt.c
> @@ -185,6 +185,68 @@ static int pt_next_level(bool alloc_tbl, pte_t **table,
> unsigned int offset)
> return XEN_TABLE_NORMAL;
> }
>
> +/*
> + * _pt_walk() performs software page table wa
On 12.02.2025 17:50, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -0,0 +1,502 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Originally taken for Linux kernel v6.12-rc3.
> + *
> + * Copyright (C) 2015 ARM Ltd.
> + * Copyright (C) 2017 SiFive
> + *
On 2025-02-18 22:37, Stefano Stabellini wrote:
On Tue, 18 Feb 2025, Jan Beulich wrote:
On 18.02.2025 03:45, 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 202
On 2025-02-19 11:44, Andrew Cooper wrote:
On 19/02/2025 10:00 am, Jan Beulich wrote:
struct mctelem_ent is opaque outside of mcetelem.c; the cookie
abstraction exists - afaict - just to achieve this opaqueness. Then it
is irrelevant though which kind of pointer mctelem_cookie_t resolves
to.
IOW
On 19/02/2025 10:00 am, Jan Beulich wrote:
> struct mctelem_ent is opaque outside of mcetelem.c; the cookie
> abstraction exists - afaict - just to achieve this opaqueness. Then it
> is irrelevant though which kind of pointer mctelem_cookie_t resolves to.
> IOW we can as well use struct mctelem_ent
On 19.02.2025 11:44, Andrew Cooper wrote:
> On 19/02/2025 10:00 am, Jan Beulich wrote:
>> struct mctelem_ent is opaque outside of mcetelem.c; the cookie
>> abstraction exists - afaict - just to achieve this opaqueness. Then it
>> is irrelevant though which kind of pointer mctelem_cookie_t resolves
On 19/02/2025 10:34 am, Jan Beulich wrote:
> On 19.02.2025 11:29, Andrew Cooper wrote:
>> On 19/02/2025 10:02 am, Jan Beulich wrote:
>>> Avoid using the same literal number (8) in two distinct places.
>> You say two places but this is only one hunk. I presume you mean
>> SIF_PM_MASK as the other p
On 19/02/2025 10:01 am, Jan Beulich wrote:
> struct mc_telem_cpu_ctl's processing field is used solely in
> mctelem_process_deferred(), where the local variable can as well be used
> directly when retrieving the head of the list to process. This then also
> eliminates the field holding a dangling p
On 19.02.2025 11:29, Andrew Cooper wrote:
> On 19/02/2025 10:02 am, Jan Beulich wrote:
>> Avoid using the same literal number (8) in two distinct places.
>
> You say two places but this is only one hunk. I presume you mean
> SIF_PM_MASK as the other place.
Indeed. Somewhere there needs to be a l
Hi Stefano,
On 18/02/2025 20:29, Stefano Stabellini wrote:
Add vcpu affinity to the dom0less bindings. Example:
dom1 {
...
cpus = <4>;
vcpu0 {
compatible = "xen,vcpu-affinity";
I would prefer if the compatible is "xen,vcpu". This
On 19/02/2025 10:02 am, Jan Beulich wrote:
> Avoid using the same literal number (8) in two distinct places.
You say two places but this is only one hunk. I presume you mean
SIF_PM_MASK as the other place.
In which case I'd suggest that this would be clearer if phrased as "Use
MASK_INTR() to avo
Avoid using the same literal number (8) in two distinct places.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -886,7 +886,7 @@ static int __init dom0_construct(struct
si->flags= SIF_PRIVILEGED | SIF_INITDOMAIN;
if ( !vinitrd
struct mc_telem_cpu_ctl's processing field is used solely in
mctelem_process_deferred(), where the local variable can as well be used
directly when retrieving the head of the list to process. This then also
eliminates the field holding a dangling pointer once the processing of
the list finished, in
struct mctelem_ent is opaque outside of mcetelem.c; the cookie
abstraction exists - afaict - just to achieve this opaqueness. Then it
is irrelevant though which kind of pointer mctelem_cookie_t resolves to.
IOW we can as well use struct mctelem_ent there, allowing to remove the
casts from COOKIE2MC
Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both
MSI and MSI-X entries globally, regardless of the IRQ chip they are using.
Only Xen sets the pci_msi_ignore_mask when routing physical interrupts over
event channels, to prevent PCI code from attempting to toggle the maskbit
The current hypercall interface for doing PCI device operations always uses
a segment field that has a 16 bit width. However on Linux there are buses
like VMD that hook up devices into the PCI hierarchy at segment >= 0x1,
after the maximum possible segment enumerated in ACPI.
Attempting to re
MSI remapping bypass (directly configuring MSI entries for devices on the
VMD bus) won't work under Xen, as Xen is not aware of devices in such bus,
and hence cannot configure the entries using the pIRQ interface in the PV
case, and in the PVH case traps won't be setup for MSI entries for such
devi
Hello,
The following series should fix the usage of devices behind a VMD bridge
when running Linux as a Xen PV hardware domain (dom0). I've only been
able to test PV. I think PVH should also work but I don't have hardware
capable of testing it right now.
I don't expect the first two patches to b
On 19.02.2025 09:36, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, February 18, 2025 10:49 PM
>>
>> On 18.02.2025 07:05, Penny, Zheng wrote:
-Original Message-
From: Jan Beulich
Sent: Monday, February 17, 2025 3:39 PM
On
On 19.02.2025 08:32, Penny, Zheng wrote:
> I've written the following codes to let amd_log_freq() also adapt for 1a+
> ```
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -579,8 +579,7 @@ void amd_log_freq(const struct cpuinfo_x86 *c)
> unsigned int idx = 0, h;
>
On Tue, Feb 18, 2025 at 12:29:24PM -0800, Stefano Stabellini wrote:
> Add vcpu affinity to the dom0less bindings. Example:
>
> dom1 {
> ...
> cpus = <4>;
> vcpu0 {
>compatible = "xen,vcpu-affinity";
>id = <0>;
>
On 2/18/25 9:29 PM, Stefano Stabellini wrote:
Add vcpu affinity to the dom0less bindings. Example:
dom1 {
...
cpus = <4>;
vcpu0 {
compatible = "xen,vcpu-affinity";
id = <0>;
hard-affinity = "
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, February 18, 2025 10:49 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Roger Pau Monné ; Anthony PERARD
> ; Orzel, Michal ; Julien
> Gral
On 18.02.2025 22:42, Stefano Stabellini wrote:
> On Tue, 18 Feb 2025, Jan Beulich wrote:
>> On 18.02.2025 00:12, Stefano Stabellini wrote:
>>> 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/
On 2025-02-18 22:42, Stefano Stabellini wrote:
On Tue, 18 Feb 2025, Jan Beulich wrote:
On 18.02.2025 00:12, Stefano Stabellini wrote:
> 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
>>>
1 - 100 of 102 matches
Mail list logo
