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.
> 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 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
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,
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
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.
>
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 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
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 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:
> 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
> 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
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
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.
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
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
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
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.
>>
>>
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));
>> }
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):
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
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"
> > |
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,
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
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 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 {
>>>
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 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
101 - 128 of 128 matches
Mail list logo
