On 03.01.23 14:02, Per Bilse wrote:
/proc/xen is a legacy pseudo filesystem which predates Xen support
getting merged into Linux. It has largely been replaced with more
normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for
user devices). We want to compile xenfs support out of the
flight 175926 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175926/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-armhf
Hi Michal,
> -Original Message-
> Subject: [PATCH] xen/arm64: Fix incorrect DIRECTMAP_SIZE calculation
>
> The direct mapped area occupies L0 slots from 256 to 265 (i.e. 10 slots),
> resulting in 5TB (512GB * 10) of virtual address space. However, due to
> incorrect slot subtraction (we t
Hi Michal,
> -Original Message-
> Subject: [PATCH] xen/arm: Harden setup_frametable_mappings
>
> The amount of supported physical memory depends on the frametable size
> and the number of struct page_info entries that can fit into it. Define
> a macro PAGE_INFO_SIZE to store the current s
flight 175925 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-xsm
flight 175923 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-inst
On 16/01/2023 4:14 pm, Jan Beulich wrote:
> On 14.01.2023 00:08, Andrew Cooper wrote:
>> 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
On 16/01/2023 4:06 pm, Jan Beulich wrote:
> On 14.01.2023 00:08, Andrew Cooper wrote:
>> @@ -470,6 +471,59 @@ static int __init cf_check param_init(void)
>> __initcall(param_init);
>> #endif
>>
>> +static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>> +{
>> +struct xen_
flight 175924 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 hos
On 16/01/2023 3:53 pm, Jan Beulich wrote:
> On 14.01.2023 00:08, Andrew Cooper wrote:
>> 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 strin
On 1/16/23 2:49 AM, Juergen Gross wrote:
On 25.11.22 07:32, Juergen Gross wrote:
All play_dead() functions but xen_pv_play_dead() don't return to the
caller.
Adapt xen_pv_play_dead() to behave like the other play_dead() variants.
Juergen Gross (2):
x86/xen: don't let xen_pv_play_dead() re
flight 175922 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175922/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-ins
On 16/01/2023 8:56 am, Jan Beulich wrote:
> On 13.01.2023 12:55, Andrew Cooper wrote:
>> On 13/01/2023 8:47 am, Jan Beulich wrote:
>>> In _sh_propagate() I'm further puzzled: The iomem_access_permitted()
>>> certainly suggests very bad things could happen if it returned false
>>> (i.e. in the impli
David!
On Mon, Jan 16 2023 at 19:28, David Woodhouse wrote:
> On Mon, 2023-01-16 at 20:22 +0100, Thomas Gleixner wrote:
>> > Tested-by: David Woodhouse
>> >
>> > Albeit only under qemu with
>> > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
>> > and not under real Xen.
On Mon, 2023-01-16 at 20:22 +0100, Thomas Gleixner wrote:
> > Tested-by: David Woodhouse
> >
> > Albeit only under qemu with
> > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
> > and not under real Xen.
>
> Five levels of emulation. What could possibly go wrong?
It's
David!
On Mon, Jan 16 2023 at 18:58, David Woodhouse wrote:
> On Mon, 2023-01-16 at 19:11 +0100, Thomas Gleixner wrote:
>> + .flags = MSI_FLAG_FREE_MSI_DESCS |
>> MSI_FLAG_DEV_SYSFS,
>
> That doesn't apply on top of
> https://lore.kernel.org/all/4bffa69a949bfdc92c4a18e5a
On Mon, 2023-01-16 at 19:11 +0100, Thomas Gleixner wrote:
> + .flags = MSI_FLAG_FREE_MSI_DESCS |
> MSI_FLAG_DEV_SYSFS,
That doesn't apply on top of
https://lore.kernel.org/all/4bffa69a949bfdc92c4a18e5a1c3cbb3b94a0d32.ca...@infradead.org/
and doesn't include the | MSI_FLAG_
David!
On Mon, Jan 16 2023 at 17:35, Thomas Gleixner wrote:
> On Mon, Jan 16 2023 at 09:56, David Woodhouse wrote:
>
> This is just wrong. I need to taxi my grandson. Will have a look
> afterwards.
There are three 'tglx missed to fixup XEN' problems:
- b2bdda205c0c ("PCI/MSI: Let the MSI core f
The get-fields.sh which generate all the include/compat/.xlat/*.h
headers is quite slow. It takes for example nearly 3 seconds to
generate platform.h on a recent machine, or 2.3 seconds for memory.h.
Rewriting the mix of shell/sed/python into a single python script make
the generation of those fil
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-include-rework-v3
v3:
- Rewrite script into python instead of perl.
(last patch of the series)
v2:
- new patch [1/4] to fix issue with command line that can be way to
On 1/16/23 10:33, Igor Mammedov wrote:
> On Fri, 13 Jan 2023 16:31:26 -0500
> Chuck Zmudzinski wrote:
>
>> 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, J
On 1/16/23 18:49, Jan Beulich wrote:
On 16.01.2023 08:21, Xenia Ragiadakou wrote:
On 1/16/23 09:04, Xenia Ragiadakou wrote:
The variable untrusted_msi indicates whether the system is vulnerable to
CVE-2011-1898 due to the absence of interrupt remapping support.
AMD iommus with interrupt rema
This patch provides the option to compile in a preferred reboot method,
as an alternative to specifying it on the Xen command line. It uses the
same internals as the command line 'reboot' parameter, and will be
overridden by a choice on the command line.
I have referred to this as 'reboot method'
flight 175919 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175919/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-insta
Hi all,
As discussed during the last Community Call, here is a Doodle to choose the
apporiate time for the Xen backlog review meeting :
https://doodle.com/meeting/participate/id/e16WwpPa
Agenda:
- Review Epic Backlog and Status
- Feedback on the process (Project, Release & Bug Tracking)
Marc
On 16.01.2023 08:21, Xenia Ragiadakou wrote:
> On 1/16/23 09:04, Xenia Ragiadakou wrote:
>> The variable untrusted_msi indicates whether the system is vulnerable to
>> CVE-2011-1898 due to the absence of interrupt remapping support.
>> AMD iommus with interrupt remapping disabled are also exposed.
On 16.01.2023 08:04, Xenia Ragiadakou wrote:
> The functions acpi_dmar_init() and acpi_dmar_zap/reinstate() are
> VT-d specific while the function acpi_ivrs_init() is AMD-Vi specific.
> To eliminate dead code, they need to be guarded under CONFIG_INTEL_IOMMU
> and CONFIG_AMD_IOMMU, respectively.
>
On 16.01.2023 08:04, Xenia Ragiadakou wrote:
> The AMD-Vi driver forces coherent accesses by hardwiring the FC bit to 1.
> Therefore, given that iommu_snoop is used only when the iommu is enabled,
> when Xen is configured with only the AMD iommu enabled, iommu_snoop can be
> reduced to a #define to
On 16.01.2023 08:04, Xenia Ragiadakou wrote:
> Use CONFIG_INTEL_IOMMU to guard the usage of iommu_igfx and iommu_qinval
> in common code.
>
> No functional change intended.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Jan Beulich
On 16.01.2023 08:04, Xenia Ragiadakou wrote:
> Move its definition to the AMD-Vi driver and use CONFIG_AMD_IOMMU
> to guard its usage in common code.
>
> Take the opportunity to replace bool_t with bool and 1 with true.
>
> No functional change intended.
>
> Signed-off-by: Xenia Ragiadakou
Rev
David!
On Mon, Jan 16 2023 at 09:56, David Woodhouse wrote:
> On Fri, 2022-11-25 at 00:24 +0100, Thomas Gleixner wrote:
>> +
>> + if (ops->domain_free_irqs)
>> + ops->domain_free_irqs(domain, dev);
>
> Do you want a call to msi_free_dev_descs(dev) here? In the case where
> the
Hi,
On 16/01/2023 16:06, Jan Beulich wrote:
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -19,12 +19,20 @@
/* arg == NULL; returns major:minor (16:16). */
#define XENVER_version 0
-/* arg == xen_extraversion_t. */
+/*
+ * arg == xen_extraversion_t.
+ *
+ *
flight 175921 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175921/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 hos
On 14.01.2023 00:08, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 14.01.2023 00:08, Andrew Cooper wrote:
> 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 Co
On 1/15/23 10:43 PM, Juergen Gross wrote:
> On 16.01.23 05:27, Srivatsa S. Bhat wrote:
>>
>> Hi Juergen,
>>
>> On 1/12/23 7:21 AM, Juergen Gross wrote:
>>> The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
>>> sharing the same implementations in all cases: for Xen PV guests they
>>>
On 14.01.2023 00:08, Andrew Cooper wrote:
> @@ -470,6 +471,59 @@ static int __init cf_check param_init(void)
> __initcall(param_init);
> #endif
>
> +static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +struct xen_varbuf user_str;
> +const char *str = NULL;
Th
On 14.01.2023 00:08, Andrew Cooper wrote:
> 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!)
On 16/01/2023 3:04 pm, Jan Beulich wrote:
> On 16.01.2023 15:57, Andrew Cooper wrote:
>> On 16/01/2023 2:17 pm, Jan Beulich wrote:
>>> On 16.01.2023 14:00, Andrew Cooper wrote:
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -299,6 +299,13 @@ static int enter_state
On 14.01.2023 00:08, Andrew Cooper wrote:
> 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.
>
> Signe
On Fri, 13 Jan 2023 16:31:26 -0500
Chuck Zmudzinski wrote:
> 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 w
On 13.01.2023 12:56, Sergey Dyasli wrote:
> 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 inf
On 16.01.2023 15:57, Andrew Cooper wrote:
> On 16/01/2023 2:17 pm, Jan Beulich wrote:
>> On 16.01.2023 14:00, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -299,6 +299,13 @@ static int enter_state(u32 state)
>>>
>>> update_mcu_opt_ctrl();
On 16.01.2023 15:39, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V4:
> - Clean up types in and remain only necessary.
> The following types was removed as they are defined in :
> {__|}{u|s}{8|16|32|64}
For one you still typedef u32 and u64. And im
On 16/01/2023 2:17 pm, Jan Beulich wrote:
> On 16.01.2023 14:00, Andrew Cooper wrote:
>> On 12/01/2023 4:51 pm, Andrew Cooper wrote:
>>> On 12/01/2023 1:10 pm, Jan Beulich wrote:
On 10.01.2023 18:18, Andrew Cooper wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @
On Sun, 15 Jan 2023 22:01:34 -0800
"Srivatsa S. Bhat" wrote:
> From: "Srivatsa S. Bhat (VMware)"
>
> Under hypervisors that support mwait passthrough, a vCPU in mwait
> CPU-idle state remains in guest context (instead of yielding to the
> hypervisor via VMEXIT), which helps speed up wakeups fro
On 11.01.2023 15:23, Sergey Dyasli wrote:
> --- a/xen/arch/x86/cpu/microcode/amd.c
> +++ b/xen/arch/x86/cpu/microcode/amd.c
> @@ -176,8 +176,13 @@ static enum microcode_match_result compare_revisions(
> if ( new_rev > old_rev )
> return NEW_UCODE;
>
> -if ( opt_ucode_allow_same
The direct mapped area occupies L0 slots from 256 to 265 (i.e. 10 slots),
resulting in 5TB (512GB * 10) of virtual address space. However, due to
incorrect slot subtraction (we take 9 slots into account) we set
DIRECTMAP_SIZE to 4.5TB instead. Fix it.
Fixes: 5263507b1b4a ("xen: arm: Use a direct m
The amount of supported physical memory depends on the frametable size
and the number of struct page_info entries that can fit into it. Define
a macro PAGE_INFO_SIZE to store the current size of the struct page_info
(i.e. 56B for arm64 and 32B for arm32) and add a sanity check in
setup_frametable_m
Hi all,
Something went wrong with cover letter. I do not know if i have to
make new patch series but cover letter should be the following:
Subject: [PATCH v4 0/4] Basic early_printk and smoke test
implementation
The patch series introduces the following:
- the minimal set of headers and changes
Add check if there is a message 'Hello from C env' presents
in log file to be sure that stack is set and C part of early printk
is working.
Signed-off-by: Oleksii Kurochko
Acked-by: Stefano Stabellini
---
Changes in V4:
- Nothing changed
---
Changes in V3:
- Nothing changed
- All men
Because printk() relies on a serial driver (like the ns16550 driver)
and drivers require working virtual memory (ioremap()) there is not
print functionality early in Xen boot.
The patch introduces the basic stuff of early_printk functionality
which will be enough to print 'hello from C environment
From: Bobby Eshleman
Originally SBI implementation for Xen was introduced by
Bobby Eshleman but it was removed
all the stuff for simplicity except SBI call for putting
character to console.
The patch introduces sbi_putchar() SBI call which is necessary
to implement initial early_printk.
Signe
Signed-off-by: Oleksii Kurochko
---
Changes in V4:
- Clean up types in and remain only necessary.
The following types was removed as they are defined in :
{__|}{u|s}{8|16|32|64}
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Remove unneeded now types from
---
---
Changes in V4:
- Patches "xen/riscv: introduce dummy asm/init.h" and "xen/riscv: introduce
stack stuff" were removed from the patch series as they were merged
separately
into staging.
- Remove "depends on RISCV*" from Kconfig.debug as Kconfig.debug is located
in arch
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.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-b
Ensure no compiler instrumentation sneaks in while restoring the CPU
state. Specifically we can't handle CALL/RET until GS is restored.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/power/cpu.
Hi all,
Patches to address the various callthunk fails reported by Joan.
The first two patches are new (and I've temporarily dropped the
restore_processor_state sealing).
It is my understanding that AP bringup will always use the 16bit trampoline
path, if this is not the case, please holler.
Per the comment it is important to call sev_verify_cbit() before the
first RET instruction, this means we can delay calling this until more
of the CPU state is set up, specifically delay this until GS is
'sane' such that per-cpu variables work.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patchi
From: Joan Bruguera
When resuming from suspend we don't have coherent CPU state, trying to
do callthunks here isn't going to work. Specifically GS isn't set yet.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Signed-off-by: Joan Bruguera
Signed-off-by: Peter
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.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Inte
The boot trampolines from trampoline_64.S have code flow like:
16bit BIOSSEV-ES 64bit EFI
trampoline_start()sev_es_trampoline_start()
trampoline_start_64()
verify_cpu() | |
When resuming there must not be any code between swsusp_arch_suspend()
and restore_processor_state() since the CPU state is ill defined at
this point in time.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/power/hibernate.c | 30 +++---
1 file changed, 27 insertions(+
On 16.01.2023 14:00, Andrew Cooper wrote:
> On 12/01/2023 4:51 pm, Andrew Cooper wrote:
>> On 12/01/2023 1:10 pm, Jan Beulich wrote:
>>> On 10.01.2023 18:18, Andrew Cooper wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -54,6 +54,7 @@
#include
#include
>
From: Oleksii Moisieiev
[ Upstream commit f57034cedeb6e00256313a2a6ee67f974d709b0b ]
Data buffer for active map is allocated in alloc_active_ring and freed
in free_active_ring function, which is used only for the error
cleanup. pvcalls_front_release is calling pvcalls_front_free_map which
ends f
On 16.01.2023 13:02, Andrew Cooper wrote:
> Converting from PAT to PTE is trivial, and shorter to encode with bitwise
> logic than the space taken by a table counting from 0 to 7 in non-adjacent
> bits.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 16.01.2023 13:01, Wei Chen wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2023年1月16日 19:15
>>
>> On 16.01.2023 10:20, Wei Chen wrote:
>>> On 2023/1/12 16:08, Jan Beulich wrote:
On 12.01.2023 07:22, Wei Chen wrote:
>> -Original Message-
>> From: Jan Beuli
On 12/01/2023 4:51 pm, Andrew Cooper wrote:
> On 12/01/2023 1:10 pm, Jan Beulich wrote:
>> On 10.01.2023 18:18, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -54,6 +54,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>
flight 175917 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175917/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 175913 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175913/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On 12/01/2023 3:11 pm, Jan Beulich wrote:
> On 12.01.2023 14:58, Andrew Cooper wrote:
>> On 12/01/2023 12:58 pm, Jan Beulich wrote:
>>> Do you have any indications towards a CS prefix being the least risky
>>> one to use here (or in general)?
>> Yes.
>>
>> Remember it's the prefix recommended for,
Converting from PAT to PTE is trivial, and shorter to encode with bitwise
logic than the space taken by a table counting from 0 to 7 in non-adjacent
bits.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
Noticed while reviewing other shad
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月16日 19:15
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject:
On 16.01.2023 10:20, Wei Chen wrote:
> Hi Jan,
>
> On 2023/1/12 16:08, Jan Beulich wrote:
>> On 12.01.2023 07:22, Wei Chen wrote:
-Original Message-
From: Jan Beulich
Sent: 2023年1月11日 0:38
On 10.01.2023 09:49, Wei Chen wrote:
> --- a/xen/arch/arm/include/asm/n
Hi Julien,
On 16/01/2023 10:29, Julien Grall wrote:
>
>
> On 16/01/2023 08:46, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 13/01/2023 11:11, Julien Grall wrote:
>>>
>>>
>>> From: Julien Grall
>>>
>>> Xen is currently not fully compliant with the Arm Arm because it will
>>> switch
On Mon, 2023-01-16 at 09:56 +, David Woodhouse wrote:
>
> msi_for_each_desc(msidesc, &dev->dev, MSI_DESC_ASSOCIATED) {
> - for (i = 0; i < msidesc->nvec_used; i++)
> + for (i = 0; i < msidesc->nvec_used; i++) {
> xen_destroy_irq(msidesc->irq
On Fri, 2022-11-25 at 00:24 +0100, Thomas Gleixner wrote:
> Provide two sorts of interfaces to handle the different use cases:
>
> - msi_domain_free_irqs_range():
>
> Handles a caller defined precise range
>
> - msi_domain_free_irqs_all():
>
> Frees all interrupts associated
Hi Julien,
On 2023/1/12 17:47, Julien Grall wrote:
Hi,
On 12/01/2023 08:11, Jan Beulich wrote:
On 12.01.2023 07:31, Wei Chen wrote:
-Original Message-
From: Jan Beulich
Sent: 2023年1月11日 0:47
On 10.01.2023 09:49, Wei Chen wrote:
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/a
On 1/16/23 09:04, Xenia Ragiadakou wrote:
Posted interrupt support in Xen is currently implemented only for the
Intel platforms. Instead of calling directly pi_update_irte() from the
common hvm code, add a pi_update_irte callback to the hvm_function_table.
Then, create a wrapper function hvm_pi
On 16/01/2023 09:55, Julien Grall wrote:
>
>
> On 16/01/2023 08:14, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Luca,
>
>> On 13/01/2023 11:11, Julien Grall wrote:
>>> +/*
>>> + * Remove the temporary mapping of Xen starting at
>>> TEMPORARY_XEN_VIRT_START.
>>> + *
>>> + * Clobbers r0 - r1
>>>
On 16/01/2023 09:23, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 13/01/2023 11:11, Julien Grall wrote:
diff --git a/xen/arch/arm/arm64/mm.c b/xen/arch/arm/arm64/mm.c
index 798ae93ad73c..2ede4e75ae33 100644
--- a/xen/arch/arm/arm64/mm.c
+++ b/xen/arch/arm/arm64/mm.c
@@ -120,6 +120,36 @@ v
On 16/01/2023 08:46, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 13/01/2023 11: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 befor
Hi Julien,
On 13/01/2023 11: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.
>
> I
Hi Jan,
On 2023/1/12 16:08, Jan Beulich wrote:
On 12.01.2023 07:22, Wei Chen wrote:
-Original Message-
From: Jan Beulich
Sent: 2023年1月11日 0:38
On 10.01.2023 09:49, Wei Chen wrote:
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -22,6 +22,12 @@ typedef u
On Fri, Nov 25, 2022 at 07:32:46AM +0100, Juergen Gross wrote:
> All play_dead() functions but xen_pv_play_dead() don't return to the
> caller.
>
> Adapt xen_pv_play_dead() to behave like the other play_dead() variants.
>
> Juergen Gross (2):
> x86/xen: don't let xen_pv_play_dead() return
> x
Hi Julien,
>
> I’ve left the boards to test all night, so on Monday I will be 100% sure this
> serie
> Is not introducing any issue.
The serie passed the overnight tests on neoverse board, raspberry pi 4, Juno
board.
Cheers,
Luca
On 13.01.2023 12:55, Andrew Cooper wrote:
> On 13/01/2023 8:47 am, Jan Beulich wrote:
>> In _sh_propagate() I'm further puzzled: The iomem_access_permitted()
>> certainly suggests very bad things could happen if it returned false
>> (i.e. in the implicit "else" case). The assumption looks to be tha
On 16/01/2023 08:14, Michal Orzel wrote:
Hi Julien,
Hi Luca,
On 13/01/2023 11:11, Julien Grall wrote:
+/*
+ * Remove the temporary mapping of Xen starting at TEMPORARY_XEN_VIRT_START.
+ *
+ * Clobbers r0 - r1
+ */
+remove_temporary_mapping:
+/* r2:r3 := invalid page-table entry */
Hi Julien,
On 13/01/2023 11: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 regi
Hi Julien,
On 13/01/2023 11: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 th
flight 175918 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175918/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
Hi Luca,
On 13/01/2023 14:58, Luca Fancellu wrote:
+/*
+ * Remove the temporary mapping of Xen starting at TEMPORARY_XEN_VIRT_START.
+ *
+ * Clobbers r0 - r1
NIT: r0 - r3?
Yes. I have updated the version in my tree.
+ */
+remove_temporary_mapping:
+/* r2:r3 := invalid page-table
On 16.01.23 07:01, Srivatsa S. Bhat wrote:
From: "Srivatsa S. Bhat (VMware)"
Under hypervisors that support mwait passthrough, a vCPU in mwait
CPU-idle state remains in guest context (instead of yielding to the
hypervisor via VMEXIT), which helps speed up wakeups from idle.
However, this runs
Hi Luca,
On 13/01/2023 17:56, Luca Fancellu wrote:
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
Hi Julien,
On 13/01/2023 11: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
flight 175916 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175916/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-arm64-xsm
Hi Julien,
On 13/01/2023 11: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
On 13.01.2023 12:16, Jan Beulich wrote:
> 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 n
98 matches
Mail list logo
