> On 20 Dec 2022, at 09:51, Jan Beulich wrote:
>
> On 20.12.2022 09:50, Luca Fancellu wrote:
>> Cppcheck has found a violation of rule 20.7 for the macro XEN_ERRNO,
>> while the macro parameter is never used as an expression, it doesn't
>> harm the code or the readability to add parenthesis, s
> On 20 Dec 2022, at 09:55, Jan Beulich wrote:
>
> On 20.12.2022 09:50, Luca Fancellu wrote:
>> In this serie there are some fixes for the rule 20.7, mainly violation found
>> by
>> cppcheck, most of them are false positive but some of them can be fixed.
>>
>> The analysed build is arm64, to
On 21.12.2022 09:46, Luca Fancellu wrote:
>> On 20 Dec 2022, at 09:51, Jan Beulich wrote:
>> On 20.12.2022 09:50, Luca Fancellu wrote:
>>> Cppcheck has found a violation of rule 20.7 for the macro XEN_ERRNO,
>>> while the macro parameter is never used as an expression, it doesn't
>>> harm the code
flight 175424 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken
test-amd64-amd64-xl-qemuu-win7-amd64
> On 20 Dec 2022, at 09:48, Jan Beulich wrote:
>
> On 20.12.2022 09:50, Luca Fancellu wrote:
>> Cppcheck has found a violation of rule 20.7 for the macro
>> __config_enabled but the preprocessor branch where this macro is
>> defined should not be analysed by cppcheck when CPPCHECK macro is
>>
In this serie there are some fixes for the rule 20.7.
The analysed build is arm64, to reproduce the reports here the command:
./xen/scripts/xen-analysis.py --cppcheck-misra --run-cppcheck --
CROSS_COMPILE="aarch64-linux-gnu-" XEN_TARGET_ARCH="arm64"
O=/path/to/artifacts_folder
Luca Fancellu (
Cppcheck has found a violation of rule 20.7 for the macro XEN_ERRNO,
while the macro parameter is never used as an expression, it doesn't
harm the code or the readability to add parenthesis, so add them.
This finding is reported also by eclair and coverity.
Signed-off-by: Luca Fancellu
Acked-by:
Cppcheck has found a violation of rule 20.7 for the macro
XENMEM_SHARING_OP_FIELD_MAKE_GREF, the argument "val" is used in an
expression, hence add parenthesis to the argument "val" to fix the
violation.
Signed-off-by: Luca Fancellu
Acked-by: Jan Beulich
---
xen/include/public/memory.h | 2 +-
On 19.12.2022 07:34, 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_VTD
> and CONFIG_AMD_IOMMU, respectively.
>
>
On 19.12.2022 07:34, Xenia Ragiadakou wrote:
> @@ -774,6 +779,16 @@ static inline void hvm_set_nonreg_state(struct vcpu *v,
> alternative_vcall(hvm_funcs.set_nonreg_state, v, nrs);
> }
>
> +static inline int hvm_pi_update_irte(const struct vcpu *v,
> +
Hi Jan,
On 20/12/2022 15:08, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
From: Wei Liu
After the direct map removal, pages from the boot allocator are not
mapped at all in the direct map. Although we have map_domain_page, they
Nit: "will not be mapped" or "are not going to b
On 19.12.2022 07:34, 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.
>
> Remove the now empty xen/drivers/passthrough/vtd/x86/hvm.c.
>
> Since
flight 175426 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175426/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatchbroken
test-amd64-i386-
On 21.12.2022 11:18, Julien Grall wrote:
> On 20/12/2022 15:08, Jan Beulich wrote:
>> On 16.12.2022 12:48, Julien Grall wrote:
>>> --- a/xen/common/vmap.c
>>> +++ b/xen/common/vmap.c
>>> @@ -34,9 +34,20 @@ void __init vm_init_type(enum vmap_region type, void
>>> *start, void *end)
>>>
>>>
Hi Jan,
On 20/12/2022 15:15, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -244,6 +244,11 @@ void *vmap(const mfn_t *mfn, unsigned int nr)
return __vmap(mfn, 1, nr, 1, PAGE_HYPERVISOR, VMAP_DEFAULT);
}
+void *vmap_conti
On 12/21/22 09:51, Jan Beulich wrote:
On 19.12.2022 07:34, Xenia Ragiadakou wrote:
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -37,6 +37,22 @@ config IPMMU_VMSA
endif
+config AMD_IOMMU
+ bool "AMD IOMMU"
+ depends on X86
+ default y
flight 175438 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 175202
test-amd64-amd64-xl-qemuu
On 12/21/22 12:13, Jan Beulich wrote:
On 19.12.2022 07:34, Xenia Ragiadakou wrote:
@@ -774,6 +779,16 @@ static inline void hvm_set_nonreg_state(struct vcpu *v,
alternative_vcall(hvm_funcs.set_nonreg_state, v, nrs);
}
+static inline int hvm_pi_update_irte(const struct vcpu *v,
+
On 12/21/22 12:19, Jan Beulich wrote:
On 19.12.2022 07:34, 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.
Remove the now empty xen/drivers/pass
On 21.12.2022 12:09, Xenia Ragiadakou wrote:
>
> On 12/21/22 12:13, Jan Beulich wrote:
>> On 19.12.2022 07:34, Xenia Ragiadakou wrote:
>>> @@ -774,6 +779,16 @@ static inline void hvm_set_nonreg_state(struct vcpu *v,
>>> alternative_vcall(hvm_funcs.set_nonreg_state, v, nrs);
>>> }
>>>
On 21.12.2022 12:13, Xenia Ragiadakou wrote:
>
> On 12/21/22 12:19, Jan Beulich wrote:
>> On 19.12.2022 07:34, 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/p
flight 175427 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken
test-amd64-i386-xl-qemut-s
flight 175430 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm broken
test-amd64-amd64-xl-qemuu-ovmf-amd64
Various tidying changes accumulated during that effort. They're all
functionally independent afaict, but there may be contextual
interactions between some of them.
1: paging: fold HAP and shadow memory alloc related fields
2: paging: fold most HAP and shadow final teardown
3: paging: move update_p
Especially with struct shadow_domain and struct hap_domain not living in
a union inside struct paging_domain, let's avoid the duplication: The
fields are named and used in identical ways, and only one of HAP or
shadow can be in use for a domain. This then also renders involved
expressions slightly
HAP does a few things beyond what's common, which are left there at
least for now. Common operations, however, are moved to
paging_final_teardown(), allowing shadow_final_teardown() to go away.
While moving (and hence generalizing) the respective SHADOW_PRINTK()
drop the logging of total_pages fro
The hook isn't mode dependent, hence it's misplaced in struct
paging_mode. (Or alternatively I see no reason why the alloc_page() and
free_page() hooks don't also live there.) Move it to struct
paging_domain.
While there rename the hook and HAP's as well as shadow's hook functions
to use singular;
The hook isn't mode dependent, hence it's misplaced in struct
paging_mode. (Or alternatively I see no reason why the alloc_page() and
free_page() hooks don't also live there.) Move it to struct
paging_domain.
The hook also is used for HVM guests only, so make respective pieces
conditional upon CON
Drop the SH_type_none entry - there are no allocation attempts with
this type, and there also shouldn't be any. Adjust the shadow_size()
alternative path to match that change. Also generalize two related
assertions.
While there move the entire table and the respective part of the comment
there to
Let's use the library-like function that we have.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -455,7 +455,6 @@ static void _sh_resync(struct vcpu *v, m
static void oos_hash_add(struct vcpu *v, mfn_t gmfn)
{
int i, idx, oidx, sw
There's no need for this as struct domain starts out zero-filled.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -64,12 +64,8 @@ int shadow_domain_init(struct domain *d)
d->arch.paging.update_paging_mode = shadow_update_paging_mod
The function won't ever be invoked, as paging_mode_enabled() always
returns false here due to the immediately preceding clearing of
d->arch.paging.mode. While compilers recognize this and eliminate the
call, make this explicit in the source (which likely 9a28170f2da2 ["pvh
dom0: construct_dom0 chan
On 21/12/2022 1:24 pm, Jan Beulich wrote:
> Especially with struct shadow_domain and struct hap_domain not living in
> a union inside struct paging_domain, let's avoid the duplication: The
> fields are named and used in identical ways, and only one of HAP or
> shadow can be in use for a domain. Thi
On 21.12.2022 14:49, Andrew Cooper wrote:
> On 21/12/2022 1:24 pm, Jan Beulich wrote:
>> Especially with struct shadow_domain and struct hap_domain not living in
>> a union inside struct paging_domain, let's avoid the duplication: The
>> fields are named and used in identical ways, and only one of
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 addresses the issue under CONFIG_INTEL_VTD.
No functional chan
flight 175441 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175441/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0b633b14944903c32aa061befaf38bd8d994cf13
baseline version:
ovmf d103840cfb559c28831c2
On 21/12/2022 1:25 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -842,10 +842,46 @@ int paging_teardown(struct domain *d)
> /* Call once all of the references to the domain have gone away */
> void paging_final_teardown(struct domain *d)
> {
> -
On 21/12/2022 1:25 pm, Jan Beulich wrote:
> The hook isn't mode dependent, hence it's misplaced in struct
> paging_mode. (Or alternatively I see no reason why the alloc_page() and
> free_page() hooks don't also live there.) Move it to struct
> paging_domain.
>
> While there rename the hook and HAP'
On 21/12/2022 1:26 pm, Jan Beulich wrote:
> The hook isn't mode dependent, hence it's misplaced in struct
> paging_mode. (Or alternatively I see no reason why the alloc_page() and
> free_page() hooks don't also live there.) Move it to struct
> paging_domain.
How you flush the TLBs has absolutely n
On 21/12/2022 1:27 pm, Jan Beulich wrote:
> The function won't ever be invoked, as paging_mode_enabled() always
> returns false here due to the immediately preceding clearing of
> d->arch.paging.mode. While compilers recognize this and eliminate the
> call, make this explicit in the source (which l
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
On 21/12/2022 1:27 pm, Jan Beulich wrote:
> Drop the SH_type_none entry - there are no allocation attempts with
> this type, and there also shouldn't be any. Adjust the shadow_size()
> alternative path to match that change. Also generalize two related
> assertions.
>
> While there move the entire t
On 21/12/2022 1:27 pm, Jan Beulich wrote:
> Let's use the library-like function that we have.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 21/12/2022 1:28 pm, Jan Beulich wrote:
> There's no need for this as struct domain starts out zero-filled.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
flight 175433 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175433/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair broken
test-amd64-amd64-xl-qem
flight 175434 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair broken
test-amd64-i386-migrupgrade
flight 175444 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175444/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 62031335bdbacc68253d43481477b9a468e0644e
baseline version:
ovmf 0b633b14944903c32aa06
flight 175436 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175436/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175306
test-armhf-armhf-libvirt-raw 15 saveresto
flight 175437 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatchbroken
test-amd64-i386-xl-qemuu-debianhvm-i3
On Tue, 20 Dec 2022, Smith, Jackson wrote:
> > Hi Stefano,
> >
> > On 16/12/2022 01:46, Stefano Stabellini wrote:
> > > On Thu, 15 Dec 2022, Julien Grall wrote:
> > On 13/12/2022 19:48, Smith, Jackson wrote:
> > >>> Yes, we are familiar with the "secret-free hypervisor" work. As
> you
> > >>>
On Tue, 20 Dec 2022, Demi Marie Obenour wrote:
> On Tue, Dec 20, 2022 at 10:17:24PM +, Smith, Jackson wrote:
> > > Hi Stefano,
> > >
> > > On 16/12/2022 01:46, Stefano Stabellini wrote:
> > > > On Thu, 15 Dec 2022, Julien Grall wrote:
> > > On 13/12/2022 19:48, Smith, Jackson wrote:
> > >
On Mon, 19 Dec 2022, Michal Orzel wrote:
> At the moment, for dom0less domUs, we do not have a way to specify
> per domain grant table related limits (unlike when using xl), namely
> max version, max number of grant frames, max number of maptrack frames.
> This means that such domains always use th
On Tue, 20 Dec 2022, Xenia Ragiadakou wrote:
> > We need to decide whether it is sensible to allow users to turn off
> > IOMMU support. It probably is, because you could trivially do this by
> > selecting CONFIG_INTEL only, and booting the result on an AMD system.
> >
>
> I cannot understand. I
On Tue, 20 Dec 2022, Julien Grall wrote:
> Hi Luca,
>
> On 20/12/2022 08:50, Luca Fancellu wrote:
> > Cppcheck reports violations of rule 20.7 in two macros of
> > alternative.h.
> >
> > The first one is in the __ALT_PTR macro where cppcheck wants to have
> > parentheses on the second operand of
On Wed, Dec 21, 2022 at 04:53:46PM -0800, Stefano Stabellini wrote:
> On Tue, 20 Dec 2022, Demi Marie Obenour wrote:
> > On Tue, Dec 20, 2022 at 10:17:24PM +, Smith, Jackson wrote:
> > > > Hi Stefano,
> > > >
> > > > On 16/12/2022 01:46, Stefano Stabellini wrote:
> > > > > On Thu, 15 Dec 2022,
flight 175449 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175449/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 175439 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken
test-amd64-amd64-xl-qemuu-win7-amd64
flight 175448 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175448/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 129404f6e4395008ac0045e7e627edbba2a1e064
baseline version:
ovmf 62031335bdbacc68253d4
flight 175440 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175440/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatchbroken in 175426
test-
On 21.12.2022 18:16, Andrew Cooper wrote:
> On 21/12/2022 1:25 pm, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/paging.c
>> +++ b/xen/arch/x86/mm/paging.c
>> @@ -842,10 +842,46 @@ int paging_teardown(struct domain *d)
>> /* Call once all of the references to the domain have gone away */
>> void pa
60 matches
Mail list logo
