On 11.01.2023 19:17, Anthony PERARD wrote:
> Some compat headers depends on other compat headers that may not have
> been generated due to config option.
>
> This would be a generic way to deal with deps, instead of
> headers-$(call or $(CONFIG_TRACEBUFFER),$(CONFIG_HVM)) += compat/trace.h
Bu
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 u8 nodeid_t;
>>> */
>>>
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/arm/include/asm/numa.h
>>> @@ -28,6 +28,20 @@ enum dt_numa_status {
>>> DT_N
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月12日 16:11
> 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 12.01.2023 08:46, Jan Beulich wrote:
> On 11.01.2023 23:29, Andrew Cooper wrote:
>> For posterity,
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is
>> the issue in question.
>>
>> In file included from arch/x86/hvm/hvm.c:82:
>> ./include/compat/hvm/hvm_op.h:6:10: fatal e
Public headers can include other public headers. Such interdependencies
are retained in their compat counterparts. Since some compat headers are
generated only in certain configurations, the referenced headers still
need to exist. The lack thereof was observed with hvm/hvm_op.h needing
trace.h, whe
On Thu, Jan 12, 2023 at 08:46:23AM +0100, Jan Beulich wrote:
> On 11.01.2023 23:29, Andrew Cooper wrote:
> > In file included from arch/x86/hvm/hvm.c:82:
> > ./include/compat/hvm/hvm_op.h:6:10: fatal error: ../trace.h: No such
> > file or directory
> > 6 | #include "../trace.h"
> > |
On 12.01.2023 01:02, Andrew Cooper wrote:
> On 11/01/2023 1:56 pm, Jan Beulich wrote:
>> The "n" input is a GFN/MFN value and hence bounded by the physical
>> address bits in use on a system. The hash quality won't improve by also
>> including the upper always-zero bits in the calculation. To keep
flight 175734 xen-unstable real [real]
flight 175738 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175734/
http://logs.test-lab.xenproject.org/osstest/logs/175738/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 12.01.2023 00:56, Andrew Cooper wrote:
> On 11/01/2023 1:57 pm, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/shadow/common.c
>> +++ b/xen/arch/x86/mm/shadow/common.c
>> @@ -2264,6 +2264,29 @@ void shadow_prepare_page_type_change(str
>> shadow_remove_all_shadows(d, page_to_mfn(page));
>> }
>
On 12.01.2023 00:15, Andrew Cooper wrote:
> On 11/01/2023 1:57 pm, Jan Beulich wrote:
>> Make HVM=y release build behavior prone against array overrun, by
>> (ab)using array_access_nospec(). This is in particular to guard against
>> e.g. SH_type_unused making it here unintentionally.
>>
>> Signed-o
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/arm/include/asm/numa.h
@@ -28,6 +28,20 @@ enum dt_numa
On 12.01.2023 10:27, Anthony PERARD wrote:
> On Thu, Jan 12, 2023 at 08:46:23AM +0100, Jan Beulich wrote:
>> On 11.01.2023 23:29, Andrew Cooper wrote:
>>> The real hvm_op.h legitimately includes the real trace.h, therefore the
>>> compat hvm_op.h legitimately includes the compat trace.h too. But
>
On Thu, Jan 12, 2023 at 10:17:47AM +0100, Jan Beulich wrote:
> Public headers can include other public headers. Such interdependencies
> are retained in their compat counterparts. Since some compat headers are
> generated only in certain configurations, the referenced headers still
> need to exist.
On 12/01/2023 9:47 am, Jan Beulich wrote:
> On 12.01.2023 00:15, Andrew Cooper wrote:
>> On 11/01/2023 1:57 pm, Jan Beulich wrote:
>>> Make HVM=y release build behavior prone against array overrun, by
>>> (ab)using array_access_nospec(). This is in particular to guard against
>>> e.g. SH_type_unuse
On 12.01.2023 11:31, Andrew Cooper wrote:
> On 12/01/2023 9:47 am, Jan Beulich wrote:
>> On 12.01.2023 00:15, Andrew Cooper wrote:
>>> On 11/01/2023 1:57 pm, Jan Beulich wrote:
Make HVM=y release build behavior prone against array overrun, by
(ab)using array_access_nospec(). This is in pa
> 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/domain.c
>> index 99577adb6c69..8ea3843ea8e
> 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 the number of SVE register bits tha
On 12/01/2023 7:46 am, Jan Beulich wrote:
> On 11.01.2023 23:29, Andrew Cooper wrote:
>> For posterity,
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is
>> the issue in question.
>>
>> In file included from arch/x86/hvm/hvm.c:82:
>> ./include/compat/hvm/hvm_op.h:6:10: fatal
On Tue, 10 Jan 2023 at 22:04, BALATON Zoltan wrote:
>
> On Tue, 10 Jan 2023, Philippe Mathieu-Daudé wrote:
> > The 'hwaddr' type is defined in "exec/hwaddr.h" as:
> >
> >hwaddr is the type of a physical address
> > (its size can be different from 'target_ulong').
> >
> > All definitions use
On 12.01.2023 12:02, Andrew Cooper wrote:
> On 12/01/2023 7:46 am, Jan Beulich wrote:
>> On 11.01.2023 23:29, Andrew Cooper wrote:
>>> For posterity,
>>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is
>>> the issue in question.
>>>
>>> In file included from arch/x86/hvm/hvm.
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -82,11 +82,13 @@ static int __init cf_check parse_iommu_param(const char
> *s)
> else if ( ss == s + 23 && !strncmp(s, "quarantine=scratch-page", 23)
> )
>
On 04.01.2023 09:44, 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.
>
flight 175736 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175736/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175718
test-amd64-amd64-libvirt-vhd 19 guest-sta
On 1/12/23 13:31, Jan Beulich wrote:
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -82,11 +82,13 @@ static int __init cf_check parse_iommu_param(const char *s)
else if ( ss == s + 23 && !strncmp(s, "quarant
On 21.12.2022 16:22, Xenia Ragiadakou wrote:
>
> On 12/20/22 13:09, Andrew Cooper wrote:
>> On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
>>> The variable untrusted_msi indicates whether the system is vulnerable to
>>> CVE-2011-1898. This vulnerablity is VT-d specific.
>>> Place the code that add
> On 11 Jan 2023, at 16:59, Julien Grall wrote:
>
> Hi Luca,
>
> 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 improve performances
>>
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
> The variable untrusted_msi indicates whether the system is vulnerable to
> CVE-2011-1898. This vulnerablity is VT-d specific.
As per the reply by Andrew to v1, this vulnerability is generic to intremap-
incapable or intremap-disabled configurations. Y
On 1/12/23 13:37, Jan Beulich wrote:
On 04.01.2023 09:44, 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
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_check vmx_test_pir(const struct vcpu
> *v, uint8_t vec)
> return pi_test_pir(vec, &v->arch.hvm.vmx.pi_desc);
> }
>
> +static int cf_che
On 04.01.2023 09:45, Xenia Ragiadakou wrote:
> The function hvm_dpci_isairq_eoi() has no dependencies on VT-d driver code
> and can be moved from xen/drivers/passthrough/vtd/x86/hvm.c to
> xen/drivers/passthrough/x86/hvm.c, along with the corresponding copyrights.
>
> Remove the now empty xen/driv
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_check vmx_test_pir(const struct vcpu
>> *v, uint8_t vec)
>> return pi_test_pir(vec, &v->arch.
On 04.01.2023 09:45, Xenia Ragiadakou wrote:
> Provide the user with configuration control over the IOMMU support by making
> AMD_IOMMU and INTEL_IOMMU options user selectable and able to be turned off.
>
> However, there are cases where the IOMMU support is required, for instance for
> a system w
On 12.01.2023 13:08, Xenia Ragiadakou wrote:
> On 1/12/23 13:37, Jan Beulich wrote:
>> On 04.01.2023 09:44, Xenia Ragiadakou wrote:
>>> --- a/xen/arch/x86/include/asm/acpi.h
>>> +++ b/xen/arch/x86/include/asm/acpi.h
>>> @@ -140,8 +140,22 @@ extern u32 pmtmr_ioport;
>>> extern unsigned int pmtmr_w
On 1/12/23 14:01, Jan Beulich wrote:
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
The variable untrusted_msi indicates whether the system is vulnerable to
CVE-2011-1898. This vulnerablity is VT-d specific.
As per the reply by Andrew to v1, this vulnerability is generic to intremap-
incapable
On 10.01.2023 18:18, Andrew Cooper wrote:
> While the reset value of the register is 0, it might not be after kexec/etc.
> If PKEY0.{WD,AD} have leaked in from an earlier context, construction of a PV
> dom0 will explode.
>
> Sequencing wise, this must come after setting CR4.PKE, and before we tou
On 10.01.2023 18:18, Andrew Cooper wrote:
> WRMSR Non-Serialising is an optimisation intended for cases where an MSR needs
> updating, but architectural serialising properties are not needed.
>
> In is anticipated that this will apply to most if not all MSRs modified on
> context switch paths.
>
On 10.01.2023 18:18, Andrew Cooper wrote:
> +static inline void wrpkrs(uint32_t pkrs)
> +{
> +uint32_t *this_pkrs = &this_cpu(pkrs);
> +
> +if ( *this_pkrs != pkrs )
> +{
> +*this_pkrs = pkrs;
> +
> +wrmsr_ns(MSR_PKRS, pkrs, 0);
> +}
> +}
> +
> +static inline void wr
On 10.01.2023 18:18, Andrew Cooper wrote:
> @@ -2471,6 +2477,9 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v,
> unsigned int reg)
> }
> return val;
>
> +case MSR_PKRS:
> +return (v == curr) ? rdpkrs() : msrs->pkrs;
Nothing here or ...
> @@ -2514,6 +2525,1
flight 175735 qemu-mainline real [real]
flight 175742 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175735/
http://logs.test-lab.xenproject.org/osstest/logs/175742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 12/01/2023 12:58 pm, Jan Beulich wrote:
> On 10.01.2023 18:18, Andrew Cooper wrote:
>> WRMSR Non-Serialising is an optimisation intended for cases where an MSR
>> needs
>> updating, but architectural serialising properties are not needed.
>>
>> In is anticipated that this will apply to most if
size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
on any ports Xen might gain. In particular I hope new ports can rely on
__SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.
Signed-off-by: Jan Beulich
---
This is just to start with some hopefully uncontr
flight 175741 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175741/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 12/01/2023 1:26 pm, Jan Beulich wrote:
> On 10.01.2023 18:18, Andrew Cooper wrote:
>> @@ -2471,6 +2477,9 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v,
>> unsigned int reg)
>> }
>> return val;
>>
>> +case MSR_PKRS:
>> +return (v == curr) ? rdpkrs() : msr
On 12/01/2023 2:01 pm, Jan Beulich wrote:
> size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
> on any ports Xen might gain. In particular I hope new ports can rely on
> __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.
>
> Signed-off-by: Jan Beulich
A
Hi,
I'm thinking these few patches should do the trick -- but I've only compiled
them and looked at the resulting asm output, I've not actually ran them.
Joan, could you kindly test?
The last (two) patches are optional fixes and should probably not go into
/urgent.
Disallow indirect branches to restore_processor_state().
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/suspend_64.h |4
arch/x86/power/cpu.c |2 +-
arch/x86/power/hibernate_asm_64.S |4
include/linux/suspend.h |4
4 files cha
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(+
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.
Signed-off-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20230109040531.7888-1-joanbrugue.
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 deletions(-)
--- a/arch/x86/power/cpu.c
+++ 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.
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)
---
arch/x86/power/cpu.c | 24
1 file changed, 12 insertions(+), 12 deletions(-
flight 175740 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175740/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e5ec3ba409b5baa9cf429cc25fdf3c8d1b8dcef0
baseline version:
ovmf fe405f08a09e9f2306c72
On 12.01.2023 15:22, Andrew Cooper wrote:
> On 12/01/2023 2:01 pm, Jan Beulich wrote:
>> size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
>> on any ports Xen might gain. In particular I hope new ports can rely on
>> __SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by t
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, and used by,
> -mbranches-within-32B-boundarie
On 12.01.2023 15:16, Andrew Cooper wrote:
> On 12/01/2023 1:26 pm, Jan Beulich wrote:
>> The other thing I'd like to understand (and having an answer to this
>> would have been better before re-applying my R-b to this re-based
>> logic) is towards the lack of feature checks here. hvm_get_reg()
>> c
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other cases
they are a NOP.
So merge them to a common callback .mmu.enter_mmap (in contrast to the
correspon
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/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -82,11 +82,13 @@ static int __init cf_check
parse_iommu_param(const char *s)
e
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 enum __packed iommu_
On 12/01/2023 1:10 pm, Jan Beulich wrote:
> On 10.01.2023 18:18, Andrew Cooper wrote:
>> +static inline void wrpkrs(uint32_t pkrs)
>> +{
>> +uint32_t *this_pkrs = &this_cpu(pkrs);
>> +
>> +if ( *this_pkrs != pkrs )
>> +{
>> +*this_pkrs = pkrs;
>> +
>> +wrmsr_ns(MSR_PKRS,
(re-sending with REST on Cc, as requested at the community call)
At present we use a mix of Makefile and Kconfig driven capability checks for
tool chain components involved in the building of the hypervisor. What approach
is used where is in some part a result of the relatively late introduction
On 12/01/2023 12:47 pm, Jan Beulich wrote:
> On 10.01.2023 18:18, Andrew Cooper wrote:
>> While the reset value of the register is 0, it might not be after kexec/etc.
>> If PKEY0.{WD,AD} have leaked in from an earlier context, construction of a PV
>> dom0 will explode.
>>
>> Sequencing wise, this m
Hi Jan,
On 12/01/2023 14:01, Jan Beulich wrote:
size_t, ssize_t, and ptrdiff_t are all expected to be uniformly defined
on any ports Xen might gain. In particular I hope new ports can rely on
__SIZE_TYPE__ and __PTRDIFF_TYPE__ being made available by the compiler.
Signed-off-by: Jan Beulich
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/xen/iommu.h
@@ -74,9 +74,13 @@ extern enum __pa
flight 175747 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175747/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb
baseline version:
ovmf e5ec3ba409b5baa9cf429
Am 11. Januar 2023 15:40:24 UTC schrieb Chuck Zmudzinski :
>On 1/10/23 3:16 AM, Michael S. Tsirkin wrote:
>> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
>>> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
>>> as noted in docs/igd-assign.txt in the Qemu
flight 175746 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175746/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 14/12/2022 14:24, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 12/12/2022 10:55, 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 an helper and use it in the boot code (switch_
On 1/12/23 10: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
are pinning the PGD of the new mm_struct, and for all other cases
they are a NOP.
So merge them to a common callback
On 1/12/23 2:18 PM, Bernhard Beschow wrote:
>
>
> Am 11. Januar 2023 15:40:24 UTC schrieb Chuck Zmudzinski :
>>On 1/10/23 3:16 AM, Michael S. Tsirkin wrote:
>>> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
Intel specifies that the Intel IGD must occupy slot 2 on the PCI
flight 175737 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-li
On Thu, Jan 12, 2023 at 03:31:43PM +0100, 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)
Reviewed-by: Kees Cook
--
Kees Cook
Hi,
On 13/12/2022 01:41, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index fdbf68aadcaa..e7a80fecec14 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -168,6 +168,17 @@ int map_range_to_domain(c
Am 12. Januar 2023 20:11:54 UTC schrieb Chuck Zmudzinski :
>On 1/12/23 2:18 PM, Bernhard Beschow wrote:
>>
>>
>> Am 11. Januar 2023 15:40:24 UTC schrieb Chuck Zmudzinski :
>>>On 1/10/23 3:16 AM, Michael S. Tsirkin wrote:
On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski 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() into the function itself and
> always call it there unconditionally -- basically turning three lines
> into one. Since
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 pages are in the direct map.
Signed-off-by: Hongyan Xia
Signed-off-b
Hi Jan,
On 04/01/2023 10:27, Jan Beulich wrote:
On 23.12.2022 13:22, Julien Grall wrote:
Hi,
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
@@ -165,7 +165,24 @@ restore_all_guest:
flight 175743 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175743/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail in 175735 pass in 175743
test-amd64-i386-pair 11 xen
The pull request you sent on Wed, 11 Jan 2023 13:25:01 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.2-rc4-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bad8c4a850eaf386df681d951e3afc06bf1c7cf8
Thank you!
--
Deet-doot-dot, I
flight 175748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175748/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-arm
flight 175739 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
test-armhf-armhf-xl-multivcpu 5 host-in
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.000 seconds)
done.
[ 348.292457] OOM killer disable
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() into the function itself and
>> always call it there unconditionally
From: Wei Chen
Currently, ARM_EFI will mandatorily selected by Arm64.
Even if the user knows for sure that their images will not
start in the EFI environment, they can't disable the EFI
support for Arm64. This means there will be about 3K lines
unused code in their images.
So in this patch, we m
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 Chen
Acked-by: Julien Grall
---
v1 -> v2:
1. Add Ab.
From: Wei Chen
>From Arm ARM Supplement of Armv8-R AArch64 (DDI 0600A) [1],
section D1.6.2 TLB maintenance instructions, we know that
Armv8-R AArch64 permits an implementation to cache stage 1
VMSAv8-64 and stage 2 PMSAv8-64 attributes as a common entry
for the Secure EL1&0 translation regime. Bu
The Armv8-R architecture profile was designed to support use cases
that have a high sensitivity to deterministic execution. (e.g.
Fuel Injection, Brake control, Drive trains, Motor control etc)
Arm announced Armv8-R in 2013, it is the latest generation Arm
architecture targeted at the Real-time pr
From: Wei Chen
On Armv8-A, Xen has a fixed virtual start address (link address
too) for all Armv8-A platforms. In an MMU based system, Xen can
map its loaded address to this virtual start address. So, on
Armv8-A platforms, the Xen start address does not need to be
configurable. But on Armv8-R pla
From: Wei Chen
We want to reuse head.S for MPU systems, but there are some
code implemented for MMU systems only. We will move such
code to another MMU specific file. But before that, we will
do some preparations in this patch to make them easier
for reviewing:
1. Fix the indentations of code com
From: Wei Chen
There are lots of MMU specific code in head.S. This code will not
be used in MPU systems. If we use #ifdef to gate them, the code
will become messy and hard to maintain. So we move MMU related
code to head_mmu.S, and keep common code still in head.S.
And some assembly macros that
From: Wei Chen
Only the first 4KB of Xen image will be mapped as identity
(PA == VA). At the moment, Xen guarantees this by having
everything that needs to be used in the identity mapping
in head.S before _end_boot and checking at link time if this
fits in 4KB.
In previous patch, we have moved t
From: Wei Chen
There is no VMSA support on Armv8-R AArch64, so we can not map early
UART to FIXMAP_CONSOLE. Instead, we use PA == VA to define
EARLY_UART_VIRTUAL_ADDRESS on Armv8-R AArch64.
Signed-off-by: Wei Chen
---
1. New patch
---
xen/arch/arm/include/asm/early_printk.h | 12
From: Wei Chen
copy_from_paddr will map a page to Xen's FIXMAP_MISC area for
temporary access. But for those systems do not support VMSA,
they can not implement set_fixmap/clear_fixmap, that means they
can't always use the same virtual address for source address.
In this case, we introduce to he
From: Penny Zheng
The start-of-day Xen MPU memory region layout shall be like as follows:
xen_mpumap[0] : Xen text
xen_mpumap[1] : Xen read-only data
xen_mpumap[2] : Xen read-only after init data
xen_mpumap[3] : Xen read-write data
xen_mpumap[4] : Xen BSS
..
xen_mpumap[max_xen_mpumap - 2]: X
Function setup_pagetables is responsible for boot-time pagetable setup
in MMU system.
But in MPU system, we have already built up start-of-day Xen MPU memory region
mapping at the very beginning in assembly.
So in order to keep only one codeflow in arm/setup.c, setup_mm_mappings
, with a more gene
As AArch64v8R only has one secure state, we have to use secure EL2 hypervisor
timer for Xen in secure EL2.
In this patch, we introduce a Kconfig option ARM_SECURE_STATE.
With this new Kconfig option, we can re-define the timer's
system register name in different secure state, but keep the
timer co
In MPU system, device tree binary can be packed with Xen
image through CONFIG_DTB_FILE, or provided by bootloader through x0.
In MPU system, each section in xen.lds.S is PAGE_SIZE aligned.
So in order to not overlap with the previous BSS section, dtb section
should be made page-aligned too.
We add
virt_to_maddr and maddr_to_virt are used widely in Xen code. So
even there is no VMSA in MPU system, we keep the interface name to
stay the same code flow.
We move the existing virt/maddr convertion from mm.h to mm_mmu.h.
And the MPU version of virt/maddr convertion is simple, returning
the input
Introduce a Kconfig option to enable Armv8-R64 architecture
support. STATIC_MEMORY and HAS_MPU will be selected by
ARM_V8R by default, because Armv8-R64 only has PMSAv8-64 on secure-EL2
and only supports statically configured system.
Signed-off-by: Wei Chen
---
xen/arch/arm/Kconfig | 13
From: Wei Chen
To make the code readable and maintainable, we move MMU-specific
memory management code from mm.c to mm_mmu.c and move MMU-specific
definitions from mm.h to mm_mmu.h.
Later we will create mm_mpu.h and mm_mpu.c for MPU-specific memory
management code.
This will avoid lots of #ifdef
1 - 100 of 128 matches
Mail list logo
