On 13.01.23 03:57, Marek Marczykowski-Górecki wrote:
Hi,
6.1.3 as PV dom0 crashes when attempting to suspend. 6.1.1 works. The
crash:
[ 348.284004] PM: suspend entry (deep)
[ 348.289532] Filesystems sync: 0.005 seconds
[ 348.291545] Freezing user space processes ... (elapsed 0
On 1/12/23 17:53, Jan Beulich wrote:
On 12.01.2023 16:43, Xenia Ragiadakou wrote:
On 1/12/23 13:49, Xenia Ragiadakou wrote:
On 1/12/23 13:31, Jan Beulich wrote:
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -74,9 +74,13 @@ extern
On 12.01.23 15:31, Peter Zijlstra wrote:
Since Xen PV doesn't use restore_processor_state(), and we're going to
have to avoid CALL/RET until at least GS is restored, de-paravirt the
easy bits.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Juergen Gross
with one remark: save_processor_s
On 13.01.2023 09:10, Xenia Ragiadakou wrote:
>
> On 1/12/23 17:53, Jan Beulich wrote:
>> On 12.01.2023 16:43, Xenia Ragiadakou wrote:
>>> On 1/12/23 13:49, Xenia Ragiadakou wrote:
On 1/12/23 13:31, Jan Beulich wrote:
> On 04.01.2023 09:44, Xenia Ragiadakou wrote:
>> --- a/xen/include/
On 12.01.2023 19:24, Andrew Cooper wrote:
> On 12/01/2023 3:43 pm, Xenia Ragiadakou wrote:
>>
>> On 1/12/23 13:49, Xenia Ragiadakou wrote:
>>>
>>> On 1/12/23 13:31, Jan Beulich wrote:
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/
Hi Luca,
On 12/01/2023 11:58, Luca Fancellu wrote:
On 11 Jan 2023, at 16:59, Julien Grall wrote:
On 11/01/2023 14:38, Luca Fancellu wrote:
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to im
While reviewing Xenia's change to iommu_snoop placement, I've
spotted a shortcoming in _sh_propagate(), fixing of which made
me notice (again) a 2nd kind of issue.
1: sanitize iommu_snoop usage
2: further correct MMIO handling in _sh_propagate()
Jan
First of all the variable is meaningful only when an IOMMU is in use for
a guest. Qualify the check accordingly, like done elsewhere. Furthermore
the controlling command line option is supposed to take effect on VT-d
only. Since command line parsing happens before we know whether we're
going to use
While c61a6f74f80e ("x86: enforce consistent cachability of MMIO
mappings") correctly converted one !mfn_valid() check there, two others
were wrongly left untouched: Both cachability control and log-dirty
tracking ought to be uniformly handled/excluded for all (non-)MMIO
ranges, not just ones quali
Hi Luca,
On 12/01/2023 10:46, Luca Fancellu wrote:
On 11 Jan 2023, at 17:16, Julien Grall wrote:
Hi Luca,
As this is an RFC, I will be mostly making general comments.
Hi Julien,
Thank you.
On 11/01/2023 14:38, Luca Fancellu wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/do
On 13.01.2023 06:28, Penny Zheng wrote:
> xen/arch/x86/Kconfig |1 +
> xen/common/Kconfig|6 +
> xen/common/Makefile |2 +-
> xen/include/xen/vmap.h| 93 +-
I would like to take a look at these non
On 12.01.2023 18:07, Andrew Cooper wrote:
> On 12/01/2023 12:47 pm, Jan Beulich wrote:
>> On 10.01.2023 18:18, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -936,6 +936,9 @@ void cpu_init(void)
>>> write_debugreg(6, X86_DR6_DEFAULT);
>>>
Hi Luca,
On 12/01/2023 10:54, Luca Fancellu wrote:
On 11 Jan 2023, at 17:27, Julien Grall wrote:
Hi Luca,
On 11/01/2023 14:38, Luca Fancellu wrote:
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and t
On 13.01.2023 08:30, Xenia Ragiadakou wrote:
> On 1/12/23 14:16, Jan Beulich wrote:
>> On 04.01.2023 09:45, Xenia Ragiadakou wrote:
>>> @@ -250,6 +252,9 @@ struct hvm_function_table {
>>> /* Architecture function to setup TSC scaling ratio */
>>> void (*setup)(struct vcpu *v);
>
On 13.01.2023 08:44, Xenia Ragiadakou wrote:
>
> On 1/12/23 14:37, Jan Beulich wrote:
>> On 12.01.2023 13:16, Jan Beulich wrote:
>>> On 04.01.2023 09:45, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2143,6 +2143,14 @@ static bool cf_c
On 13.01.2023 00:15, Julien Grall wrote:
> Hi,
>
> On 04/01/2023 10:23, Jan Beulich wrote:
>> On 23.12.2022 12:31, Julien Grall wrote:
>>> On 20/12/2022 15:30, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> This avoids the assumption that boot
Hi,
On 13/01/2023 08:54, Jan Beulich wrote:
On 13.01.2023 06:28, Penny Zheng wrote:
xen/arch/x86/Kconfig |1 +
xen/common/Kconfig|6 +
xen/common/Makefile |2 +-
xen/include/xen/vmap.h| 93
On 13/01/2023 09:16, Jan Beulich wrote:
On 13.01.2023 00:15, Julien Grall wrote:
Hi,
On 04/01/2023 10:23, Jan Beulich wrote:
On 23.12.2022 12:31, Julien Grall wrote:
On 20/12/2022 15:30, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
From: Hongyan Xia
This avoids the assum
On Fri, Jan 13, 2023 at 07:39:38AM +, Joan Bruguera wrote:
> Hi Peter,
>
> I tried your patches on both QEMU and my two (real) computers where
> s2ram with `retbleed=stuff` was failing and they wake up fine now.
Yay \o/
> However, I think some minor reviews are needed:
>
> (1) I got a build
On 13.01.2023 00:20, Julien Grall wrote:
> On 04/01/2023 10:27, Jan Beulich wrote:
>> On 23.12.2022 13:22, Julien Grall wrote:
>>> On 22/12/2022 11:12, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
>>
On 13.01.2023 10:16, Julien Grall wrote:
> On 13/01/2023 08:54, Jan Beulich wrote:
>> On 13.01.2023 06:28, Penny Zheng wrote:
>>> xen/arch/x86/Kconfig |1 +
>>> xen/common/Kconfig|6 +
>>> xen/common/Makefile |2 +-
>
On Thu, 12 Jan 2023 23:14:26 -0500
Chuck Zmudzinski wrote:
> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:
> >> I think the change Michael suggests is very minimalistic: Move the if
> >> condition around xen_igd_reserve_slot(
On 1/13/23 10:47, Jan Beulich wrote:
First of all the variable is meaningful only when an IOMMU is in use for
a guest. Qualify the check accordingly, like done elsewhere. Furthermore
the controlling command line option is supposed to take effect on VT-d
only. Since command line parsing happens
On 13.01.2023 06:29, Penny Zheng wrote:
> VMAP in MMU system, is used to remap a range of normal memory
> or device memory to another virtual address with new attributes
> for specific purpose, like ALTERNATIVE feature. Since there is
> no virtual address translation support in MPU system, we can
>
On 13.01.2023 06:29, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -43,6 +43,9 @@ config HAS_EX_TABLE
> config HAS_FAST_MULTIPLY
> bool
>
> +config HAS_FIXMAP
> + bool
I think it'll end up misleading if this option is not selected by x86
as well. So imo
On 13.01.2023 06:29, Penny Zheng wrote:
> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -89,15 +89,27 @@ static inline void vfree(void *va)
> ASSERT_UNREACHABLE();
> }
>
> +#ifdef CONFIG_HAS_MPU
> +void __iomem *ioremap(paddr_t, size_t);
> +#else
> void __iomem *ioremap(
Hi Juergen,
On 12/01/2023 05:49, Juergen Gross wrote:
On 11.01.23 18:48, Julien Grall wrote:
Hi Juergen,
On 11/01/2023 08:59, Juergen Gross wrote:
... to make sure domain_nbentry_add() is not returning a negative
value. Then it would not work.
A good example imagine you have a transaction r
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
>
> On 1/13/23 10:47, Jan Beulich wrote:
>> First of all the variable is meaningful only when an IOMMU is in use for
>> a guest. Qualify the check accordingly, like done elsewhere. Furthermore
>> the controlling command line option is supposed to take e
On 13.01.23 10:53, Julien Grall wrote:
Hi Juergen,
On 12/01/2023 05:49, Juergen Gross wrote:
On 11.01.23 18:48, Julien Grall wrote:
Hi Juergen,
On 11/01/2023 08:59, Juergen Gross wrote:
... to make sure domain_nbentry_add() is not returning a negative value.
Then it would not work.
A good
Hi Michal,
On 06/01/2023 10:41, Michal Orzel wrote:
On 05/01/2023 13:15, Andrew Cooper wrote:
On 05/01/2023 11:19 am, Julien Grall wrote:
On 05/01/2023 09:59, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
I have a clarification.
On 05/01/2023 09:26, Julien Grall wrote:
CAUTION: This messa
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
These two variables are stale variables, they only have declarations
in config.h, they don't have any definition and no any code is using
these two variables. So in this patch, we remove them from config.h.
Signed-off-by: Wei Ch
On 13.01.2023 06:29, Penny Zheng wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -13,9 +13,10 @@ config ARM
> def_bool y
> select HAS_ALTERNATIVE if !ARM_V8R
> select HAS_DEVICE_TREE
> + select HAS_FIXMAP if !ARM_V8R
> select HAS_PASSTHROUGH
>
From: Julien Grall
Hi all,
Currently, Xen on Arm will switch TTBR whilst the MMU is on. This is
similar to replacing existing mappings with new ones. So we need to
follow a break-before-make sequence.
When switching the TTBR, we need to temporarily disable the MMU
before updating the TTBR. This
From: Julien Grall
Per G5-9224 in ARM DDI 0487I.a:
"A DSB NSH is sufficient to ensure completion of TLB maintenance
instructions that apply to a single PE. A DSB ISH is sufficient to
ensure completion of TLB maintenance instructions that apply to PEs
in the same Inner Shareable domain.
"
Thi
From: Julien Grall
Per D5-4929 in ARM DDI 0487H.a:
"A DSB NSH is sufficient to ensure completion of TLB maintenance
instructions that apply to a single PE. A DSB ISH is sufficient to
ensure completion of TLB maintenance instructions that apply to PEs
in the same Inner Shareable domain.
"
This
From: Julien Grall
At the moment, flush_xen_tlb_range_va{,_local}() are using system
wide memory barrier. This is quite expensive and unnecessary.
For the local version, a non-shareable barrier is sufficient.
For the SMP version, an inner-shareable barrier is sufficient.
Furthermore, the initia
From: Julien Grall
Looking at the Neoverse N1 errata document, it is not clear to me
why the TLBI repeat workaround is not applied for TLB flush by VA.
The TBL flush by VA helpers are used in flush_xen_tlb_range_va_local()
and flush_xen_tlb_range_va(). So if the range size if a fixed size smalle
From: Julien Grall
In a follow-up patch, the base address for the common mappings will
vary between arm32 and arm64. To avoid any duplication, define
every mapping in the common region from the previous one.
Take the opportunity to:
* add missing *_SIZE for FIXMAP_VIRT_* and XEN_VIRT_*
*
From: Julien Grall
At the moment, enable_mmu() will return to an address in the 1:1 mapping
and each path is responsible to switch to the runtime mapping.
In a follow-up patch, the behavior to switch to the runtime mapping
will become more complex. So to avoid more code/comment duplication,
move
From: Julien Grall
"ldr rX, =" is used to load a value from the literal pool. This
implies a memory access.
This can be avoided by using the macro mov_w which encode the value in
the immediate of two instructions.
So replace all "ldr rX, =" with "mov_w rX, ".
No functional changes intended.
S
From: Julien Grall
The sequence for flushing the TLBs is 4 instruction long and often
requires an explanation how it works.
So create a helper and use it in the boot code (switch_ttbr() is left
alone until we decide the semantic of the call).
Note that in secondary_switched, we were also flushi
From: Julien Grall
At the moment, bootloaders can load Xen anywhere in memory but the
region 2MB - 4MB. While I am not aware of any issue, we have no way
to tell the bootloader to avoid that region.
In addition to that, in the future, Xen may grow over 2MB if we
enable feature like UBSAN or GCOV
On 13/01/2023 8:48 am, Jan Beulich wrote:
> While c61a6f74f80e ("x86: enforce consistent cachability of MMIO
> mappings") correctly converted one !mfn_valid() check there, two others
> were wrongly left untouched: Both cachability control and log-dirty
> tracking ought to be uniformly handled/exclu
(missed to CC Paul on the original submission)
On 13.01.2023 09:47, Jan Beulich wrote:
> First of all the variable is meaningful only when an IOMMU is in use for
> a guest. Qualify the check accordingly, like done elsewhere. Furthermore
> the controlling command line option is supposed to take eff
From: Julien Grall
Switching TTBR while the MMU is on is not safe. Now that the identity
mapping will not clash with the rest of the memory layout, we can avoid
creating temporary page-tables every time a CPU is brought up.
The arm32 code will use a different approach. So this issue is for now
o
From: Julien Grall
At the moment, the temporary mapping is only used when the virtual
runtime region of Xen is clashing with the physical region.
In follow-up patches, we will rework how secondary CPU bring-up works
and it will be convenient to use the fixmap area for accessing
the root page-tab
From: Julien Grall
In follow-up patches we will need to have part of Xen identity mapped in
order to safely switch the TTBR.
On some platform, the identity mapping may have to start at 0. If we always
keep the identity region mapped, NULL pointer dereference would lead to
access to valid mapping
From: Julien Grall
Xen is currently not fully compliant with the Arm Arm because it will
switch the TTBR with the MMU on.
In order to be compliant, we need to disable the MMU before
switching the TTBR. The implication is the page-tables should
contain an identity mapping of the code switching th
From: Julien Grall
At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
still on.
Switching TTBR is like replacing existing mappings with new ones. So
we need to follow the break-before-make sequence.
In this case, it means the MMU needs to be switched off while the
TTBR is upda
> -Original Message-
> From: Julien Grall
> Sent: Friday, January 13, 2023 6:07 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Julien Grall
>
> Subject: Re: [PATCH v2 01/40] xen/arm: remove xen_phys_st
On 13/01/2023 11:11, Julien Grall wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> From: Julien Grall
>
> "ldr rX, =" is used to load a value from the literal pool. This
> implies a memory
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> The sequence for flushing the TLBs is 4 instruction long and often
> requires an explanation how it works.
>
> So create a helper and use it in the boot code (switch_ttbr() is left
> alone until we decide the semantic of
Hi,
On 13/01/2023 10:45, Michal Orzel wrote:
On 13/01/2023 11:11, Julien Grall wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
From: Julien Grall
"ldr rX, =" is used to load a value from the lite
flight 175750 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 175743
build-amd64-xsm
flight 175751 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 173462
build-amd64-xsm
On 13.01.2023 12:06, osstest service owner wrote:
> flight 175751 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/175751/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64 6 x
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 01/14] xen/arm64: flushtlb: Reduce scope of barrier for
> local TLB flush
>
> From: Julien Grall
>
> Per D5-4929 in ARM DDI 0487H.a:
> "A DSB NSH is sufficient to ensure completion of TLB maintenance
> instructions that apply to a si
On 13/01/2023 8:47 am, Jan Beulich wrote:
As far as the subject goes, I really wouldn't call this "sanitise". The
behaviour is crazy, and broken.
"Make shadow consistent with how HAP works" feels somewhat better.
> First of all the variable is meaningful only when an IOMMU is in use for
> a g
(CC Paul as well)
On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
On 1/13/23 10:47, Jan Beulich wrote:
First of all the variable is meaningful only when an IOMMU is in use for
a guest. Qualify the check accordingly, like done elsewhere. Furthermore
the contro
Currently it's impossible to get CPU's microcode revision after late
loading without looking into Xen logs which is not always convenient.
Add an option to xen-ucode tool to print the currently loaded ucode
version and also print it during usage info.
Add a new platform op in order to get the requ
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
> On 1/13/23 11:53, Jan Beulich wrote:
>> On 13.01.2023 10:34, Xenia Ragiadakou wrote:
>>> On 1/13/23 10:47, Jan Beulich wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -56,6 +56,13 @@ void __i
Currently, kernel_uimage_probe() does not read the load/entry point address
set in the uImge header. Thus, info->zimage.start is 0 (default value). This
causes, kernel_zimage_place() to treat the binary (contained within uImage)
as position independent executable. Thus, it loads it at an incorrect
Hi All,
On 10/01/2023 12:30, Dmytro Firsov wrote:
On 09.01.23 11:36, Oleksandr Tyshchenko wrote:
On 08.01.23 18:06, Julien Grall wrote:
Hello Julien, Ayan, all
Hi Ayan,
...
The changes look good to me (with a few of comments below). That
said, before acking the code, I would like an existin
> On 13 Jan 2023, at 08:53, Julien Grall wrote:
>
> Hi Luca,
>
> On 12/01/2023 10:46, Luca Fancellu wrote:
>>> On 11 Jan 2023, at 17:16, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> As this is an RFC, I will be mostly making general comments.
>> Hi Julien,
>> Thank you.
>>>
>>> On 11/01/20
Hello Julien,
>>>xentrace should work on upstream Xen. What did you version did you try?
While building my image using the BSP-linux of NXP, the version that was
downloaded is Xen 4.14.
>>>Can you also clarify the error you are seen?
The error I receive while tipping xentrace is: Command no
On Fri, Jan 13, 2023 at 10:17:46AM +0100, Peter Zijlstra wrote:
> > (2) Tracing with QEMU I still see two `sarq $5, %gs:0x1337B33F` before
> > `%gs` is restored. Those correspond to the calls from
> > `secondary_startup_64` in `arch/x86/kernel/head_64.S` to
> > `verify_cpu` and `sev_ve
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8ea3843ea8e8..27f38729302b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
>>
On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
On 1/13/23 10:47, Jan Beulich wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -56
* Peter Zijlstra wrote:
> Since we can't do CALL/RET until GS is restored and CR[04] pinning is
> of dubious value in this code path, simply write the stored values.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/power/cpu.c |4 ++--
> 1 file changed, 2 insertions(+), 2 delet
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 02/14] xen/arm64: flushtlb: Implement the TLBI repeat
> workaround for TLB flush by VA
>
> From: Julien Grall
>
> Looking at the Neoverse N1 errata document, it is not clear to me
> why the TLBI repeat workaround is not applied for TL
On 13.01.2023 14:07, Xenia Ragiadakou wrote:
>
> On 1/13/23 14:12, Jan Beulich wrote:
>> On 13.01.2023 12:55, Xenia Ragiadakou wrote:
>>> On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
> On 1/13/23 10:47, Jan Beulich wrote:
>> --- a/xen/drivers/passt
On Fri, Jan 13, 2023 at 09:08:35AM +0100, Juergen Gross wrote:
> On 13.01.23 03:57, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > 6.1.3 as PV dom0 crashes when attempting to suspend. 6.1.1 works. The
> > crash:
> >
> > [ 348.284004] PM: suspend entry (deep)
> > [ 348.289532] Files
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 03/14] xen/arm32: flushtlb: Reduce scope of barrier for
> local TLB flush
>
> From: Julien Grall
>
> Per G5-9224 in ARM DDI 0487I.a:
>
> "A DSB NSH is sufficient to ensure completion of TLB maintenance
> instructions that apply to a
On 1/13/23 15:24, Jan Beulich wrote:
On 13.01.2023 14:07, Xenia Ragiadakou wrote:
On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
On 1/13/23 10:47, Jan Beulich wrote:
--- a
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 04/14] xen/arm: flushtlb: Reduce scope of barrier for the
> TLB range flush
>
> From: Julien Grall
>
> At the moment, flush_xen_tlb_range_va{,_local}() are using system
> wide memory barrier. This is quite expensive and unnecessary.
>
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 05/14] xen/arm: Clean-up the memory layout
>
> From: Julien Grall
>
> In a follow-up patch, the base address for the common mappings will
> vary between arm32 and arm64. To avoid any duplication, define
> every mapping in the common r
Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:
[ 348.284004] PM: suspend entry (deep)
[ 348.289532] Filesystems sync: 0.005 seconds
On 13.01.23 14:44, Marek Marczykowski-Górecki wrote:
But, unrelated to this bug, it did get message like in
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg107609.html
(WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:523 switch_mm_irqs_off+0x230/0x4a0)
Hmm, is applying the attached
On 13.01.2023 14:53, Xenia Ragiadakou wrote:
> On 1/13/23 15:24, Jan Beulich wrote:
>> On 13.01.2023 14:07, Xenia Ragiadakou wrote:
>>> On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
> On 1/13/23 11:53, Jan Beulich wrote:
>> On 13.01.2023 10:34, Xenia
flight 175752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl 5 hos
On 1/13/23 16:22, Jan Beulich wrote:
On 13.01.2023 14:53, Xenia Ragiadakou wrote:
On 1/13/23 15:24, Jan Beulich wrote:
On 13.01.2023 14:07, Xenia Ragiadakou wrote:
On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
On 1/13/23 11:53, Jan Beulich wrote:
On 13.
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, bootloaders can load Xen anywhere in memory but the
> region 2MB - 4MB. While I am not aware of any issue, we have no way
> to tell the bootloader to avoid that region.
>
> In addition to that, in the f
flight 175749 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt-qcow2
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, the temporary mapping is only used when the virtual
> runtime region of Xen is clashing with the physical region.
>
> In follow-up patches, we will rework how secondary CPU bring-up works
> and it will
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> Xen is currently not fully compliant with the Arm Arm because it will
> switch the TTBR with the MMU on.
>
> In order to be compliant, we need to disable the MMU before
> switching the TTBR. The implication is the pag
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> In follow-up patches we will need to have part of Xen identity mapped in
> order to safely switch the TTBR.
>
> On some platform, the identity mapping may have to start at 0. If we always
> keep the identity region ma
On Fri, Jan 13, 2023 at 03:20:37PM +0100, Juergen Gross wrote:
> On 13.01.23 14:44, Marek Marczykowski-Górecki wrote:
> > But, unrelated to this bug, it did get message like in
> > https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg107609.html
> > (WARNING: CPU: 1 PID: 0 at arch/x86/mm
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
> still on.
>
> Switching TTBR is like replacing existing mappings with new ones. So
> we need to follow the break-before-make sequence.
>
> In thi
On Fri, Jan 13, 2023 at 02:16:44PM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > Since we can't do CALL/RET until GS is restored and CR[04] pinning is
> > of dubious value in this code path, simply write the stored values.
> >
> > Signed-off-by: Peter Zijlstra (Intel)
> > ---
> >
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> Switching TTBR while the MMU is on is not safe. Now that the identity
> mapping will not clash with the rest of the memory layout, we can avoid
> creating temporary page-tables every time a CPU is brought up.
>
> The
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> Looking at the Neoverse N1 errata document, it is not clear to me
> why the TLBI repeat workaround is not applied for TLB flush by VA.
>
> The TBL flush by VA helpers are used in flush_xen_tlb_range_va_local()
> and
On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
>
> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> Xen PV guest") missed one code path accessing real_mode_header, leading
> to dereferencing NULL when suspending the system under Xen:
>
> [ 348.284004] PM: suspen
On 1/13/23 4:33 AM, Igor Mammedov wrote:
> On Thu, 12 Jan 2023 23:14:26 -0500
> Chuck Zmudzinski wrote:
>
>> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
>> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:
>> >> I think the change Michael suggests is very minimalistic: Move
On Fri, Jan 13, 2023 at 08:40:15PM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
> >
> > Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> > Xen PV guest") missed one code path accessing real_mode_header, leading
> > to dereferencing
See patch 3 for details of the problem. Other patches fix other errors found
while investigating.
Some patches committed straight from v1. Several new patches with additional
cleanup.
Andrew Cooper (5):
xen/version: Drop bogus return values for XENVER_platform_parameters
xen/version: Calcul
The arch_get_xen_caps() infrastructure is horribly inefficient, for something
that is constant after features have been resolved on boot.
Every instance used snprintf() to format constants into a string (which gets
shorter when %d gets resolved!), which gets double buffered on the stack.
Switch t
A split in virtual address space is only applicable for x86 PV guests.
Furthermore, the information returned for x86 64bit PV guests is wrong.
Explain the problem in version.h, stating the other information that PV guests
need to know.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
---
xen/common/kernel.c | 11 +--
xen/common/version.c | 4 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/common/k
Recently in XenServer, we have encountered problems caused by both
XENVER_extraversion and XENVER_commandline having fixed bounds.
More than just the invariant size, the APIs/ABIs also broken by typedef-ing an
array, and using an unqualified 'char' which has implementation-specific
signed-ness
Pr
struct xen_build_id and struct xen_varbuf are identical from an ABI point of
view, so XENVER_build_id can reuse xenver_varbuf_op() rather than having it's
own almost identical copy of the logic.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefan
1 - 100 of 105 matches
Mail list logo
