flight 175435 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175435/
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 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
> + ---help---
> + Ena
On 20.12.2022 21:56, Andrew Cooper wrote:
> On 20/12/2022 1:51 pm, Jan Beulich wrote:
>> On 16.12.2022 21:17, Andrew Cooper wrote:
>>> +"mov%[cr4], %%cr4\n\t" /* CR4.PGE = 1 */
>>> +: [cr4] "=&a" (tmp) /* Could be "r", but "a" makes better asm */
>>> +: [cr3] "r" (__
On 20.12.2022 18:45, Demi Marie Obenour wrote:
> On Tue, Dec 20, 2022 at 05:13:04PM +0100, Jan Beulich wrote:
>> --- a/tools/firmware/hvmloader/cacheattr.c
>> +++ b/tools/firmware/hvmloader/cacheattr.c
>> @@ -22,6 +22,8 @@
>> #include "util.h"
>> #include "config.h"
>>
>> +#include
>> +
>> #d
flight 175425 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-pvops 4 host-
flight 175432 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175432/
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
flight 175419 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175419/
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-libvirt-pair 7 host-install/ds
flight 175421 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175421/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade broken
test-amd64-i386-xl-pvshim
flight 175418 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64broken
test-amd64-i386-xl-qemuu-debianhv
flight 175431 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175431/
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 175429 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175429/
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 Tue, Dec 20, 2022 at 10:17:24PM +, Smith, Jackson wrote:
> -Original Message-
> > From: Julien Grall
> > Sent: Friday, December 16, 2022 3:39 AM
> >
> > Hi Stefano,
> >
> > On 16/12/2022 01:46, Stefano Stabellini wrote:
> > > On Thu, 15 Dec 2022, Julien Grall wrote:
> > On 13/1
-Original Message-
> From: Julien Grall
> Sent: Friday, December 16, 2022 3:39 AM
>
> 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-fr
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -115,47 +117,32 @@ hashtable_expand(struct hashtable *h)
if (h->primeindex == (prime_table_length - 1)) return 0;
newsize = primes[++(h->primeindex)];
-newtable = (struct entry **)calloc(newsize, sizeof(struct entry*));
On 12/20/22 23:00, Andrew Cooper wrote:
On 20/12/2022 8:57 pm, Xenia Ragiadakou wrote:
On 12/20/22 19:01, Jan Beulich wrote:
On 19.12.2022 07:34, Xenia Ragiadakou wrote:
Currently, for x86 platforms, Xen does not provide to the users any
configuration control over the IOMMU support and can
On 12/20/22 19:04, Jan Beulich wrote:
On 19.12.2022 07:34, 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.
Please further take the opportunity and u
On 20/12/2022 8:57 pm, Xenia Ragiadakou wrote:
>
> On 12/20/22 19:01, Jan Beulich wrote:
>> On 19.12.2022 07:34, Xenia Ragiadakou wrote:
>>> Currently, for x86 platforms, Xen does not provide to the users any
>>> configuration control over the IOMMU support and can only be built with
>>> both AMD a
On 12/20/22 19:01, Jan Beulich wrote:
On 19.12.2022 07:34, Xenia Ragiadakou wrote:
Currently, for x86 platforms, Xen does not provide to the users any
configuration control over the IOMMU support and can only be built with
both AMD and Intel IOMMU drivers enabled.
However, there are use cases,
On 20/12/2022 1:51 pm, Jan Beulich wrote:
> On 16.12.2022 21:17, Andrew Cooper wrote:
>> Partly for clarity because there is a lot of subtle magic at work here.
>> Expand the commentary of what's going on.
>>
>> Also, because there is no need to double copy the stack (32kB) to retrieve
>> local val
On 12/20/22 12:31, Andrew Cooper wrote:
On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 5e2a720d29..1a02fdc453 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -58,7 +58,6 @
On 12/20/22 12:26, Andrew Cooper wrote:
On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 479d7de57a..82465aa627 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -37,6 +37,22
On 12/20/22 12:09, Jan Beulich wrote:
On 19.12.2022 19:28, Andrew Cooper wrote:
IOMMUs are more tricky still. They are (for most intents and purposes)
mandatory on systems with >254 CPUs. We could in principle start
supporting asymmetric IRQ routing on large systems, but Xen doesn't
currentl
Hi,
On 12/19/22 20:28, Andrew Cooper wrote:
On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
This series aims to provide a means to render the iommu driver support for x86
configurable. Currently, irrespectively of the target platform, both AMD and
Intel iommu drivers are built. This is the case
flight 175428 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175428/
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
Hi,
On 13/12/2022 16:00, Juergen Gross wrote:
The accounting for the number of nodes of a domain in an active
transaction is not working correctly, as it allows to create arbitrary
number of nodes. The transaction will finally fail due to exceeding
the number of nodes quota, but before closing t
Hi,
On 13/12/2022 16:00, Juergen Gross wrote:
Rework the interface and the internals of the per-domain node
accounting:
- rename the functions to domain_nbentry_*() in order to better match
the related counter name
- switch from node pointer to domid as interface, as all nodes have the
o
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
Move all code related to struct changed_domain from
xenstored_transaction.c to xenstored_domain.c.
This will be needed later in order to simplify the accounting data
updates in cases of errors during a request.
Split the code to have a more
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -313,19 +302,19 @@ const char *dump_state_watches(FILE *fp, struct
connection *conn,
unsigned int conn_id)
{
const char *ret = NULL;
+ const char *watch_path;
struct watch *watch;
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
Instead of special casing the permission handling and watch event
firing for the special watch paths "@introduceDomain" and
"@releaseDomain", use static dummy nodes added to the data base when
starting Xenstore.
The node accounting needs to
On 20/12/2022 3:18 pm, Jan Beulich wrote:
> On 20.12.2022 15:50, Andrew Cooper wrote:
>> On 19/12/2022 2:45 pm, Sergey Dyasli wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 6bb5bc7c84..2d7c815e0a 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>>
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
Today finding a struct domain by its domain id requires to scan the
list of domains until finding the correct domid.
Add a hashlist for being able to speed this up. This allows to remove
the linking of struct domain in a list. Note that the
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
When a domain has been released by Xen tools, remove all its
registered watches. This avoids sending watch events to the dead domain
when all the nodes related to it are being removed by the Xen tools.
AFAICT, the only user of the command i
On Tue, Dec 20, 2022 at 05:13:04PM +0100, Jan Beulich wrote:
> Now that we have them available in a header which is okay to use from
> hvmloader sources, do away with respective literal numbers and silent
> assumptions.
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/firmware/hvmloader/cacheattr.
Hi Julien,
I need a clarification.
On 20/12/2022 12:51, Ayan Kumar Halder wrote:
On 20/12/2022 12:14, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+ /*
+ * Currently, we support uImage headers for uncompressed
images only.
+ * Thus, i
On 19.12.2022 07:34, 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.
Please further take the opportunity and use ...
> --- a/xen/drivers/passthro
On 19.12.2022 07:34, Xenia Ragiadakou wrote:
> Currently, for x86 platforms, Xen does not provide to the users any
> configuration control over the IOMMU support and can only be built with
> both AMD and Intel IOMMU drivers enabled.
> However, there are use cases, e.g in safety-critical systems, th
On 20.12.2022 17:36, Andrew Cooper wrote:
> On 20/12/2022 4:13 pm, Jan Beulich wrote:
>> --- a/tools/firmware/hvmloader/cacheattr.c
>> +++ b/tools/firmware/hvmloader/cacheattr.c
>> @@ -22,6 +22,8 @@
>> #include "util.h"
>> #include "config.h"
>>
>> +#include
>> +
>> #define MSR_MTRRphysBase(r
flight 175417 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
test-amd64-amd64-xl-qemuu-debian
On 20/12/2022 4:13 pm, Jan Beulich wrote:
> Now that we have them available in a header which is okay to use from
> hvmloader sources, do away with respective literal numbers and silent
> assumptions.
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/firmware/hvmloader/cacheattr.c
> +++ b/tools/firmw
Hi,
On 20/12/2022 15:24, Ayan Kumar Halder wrote:
On 16/12/2022 10:23, Julien Grall wrote:
Each adaptations are distinct, so I would prefer if they are in in
separate patch.
This will also make clear which components you touched because I would
be surprised if this is really the only place w
Now that we have them available in a header which is okay to use from
hvmloader sources, do away with respective literal numbers and silent
assumptions.
Signed-off-by: Jan Beulich
--- a/tools/firmware/hvmloader/cacheattr.c
+++ b/tools/firmware/hvmloader/cacheattr.c
@@ -22,6 +22,8 @@
#include "u
flight 175423 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175423/
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
flight 175414 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175414/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel broken
test-amd
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-by: Julien Grall
Reviewed-by: Jan Beulich
However, ...
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> This avoids the assumption that there is a direct map and boot pages
> fall inside the direct map.
>
> Clean up the variables so that mfn actually stores a type-safe mfn.
>
> Signed-off-by: Hongyan Xia
> Signed-off-by: Julien Gra
On 16/12/2022 10:23, Julien Grall wrote:
Hi,
Hi Julien,
Each adaptations are distinct, so I would prefer if they are in in
separate patch.
This will also make clear which components you touched because I would
be surprised if this is really the only place where we need
adaptation. Maybe
On 20.12.2022 15:50, Andrew Cooper wrote:
> On 19/12/2022 2:45 pm, Sergey Dyasli wrote:
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index 6bb5bc7c84..2d7c815e0a 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> relocated = true;
>> @@ -1762,11 +1768,9
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_contig_pages(mfn_t mfn, unsigned int nr_pages)
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 be mapped", or else this
sounds like there's a
On 19/12/2022 2:45 pm, Sergey Dyasli wrote:
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 6bb5bc7c84..2d7c815e0a 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> relocated = true;
> @@ -1762,11 +1768,9 @@ void __init noreturn __start_xen(unsigned long
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 foreign access for this buffer, but doesn't free allocated pages.
Call free_active_ring t
On 15.12.2022 18:09, Jennifer Herbert wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -1009,6 +1009,13 @@ void hvmloader_acpi_build_tables(struct acpi_config
> *config,
> config->table_flags |= ACPI_HAS_TPM;
> config->tis_hdr = (uint16_
On 15.12.2022 18:09, Jennifer Herbert wrote:
> --- a/docs/misc/xenstore-paths.pandoc
> +++ b/docs/misc/xenstore-paths.pandoc
> @@ -269,6 +269,14 @@ at the guest physical address in
> HVM_PARAM_VM_GENERATION_ID_ADDR.
> See Microsoft's "Virtual Machine Generation ID" specification for the
> circum
On 19.12.2022 15:45, Sergey Dyasli wrote:
> Call early_microcode_init() straight after multiboot modules become
> accessible. Modify it to load the ucode directly from the blob bypassing
> populating microcode_cache because xmalloc is still not available at
> that point during Xen boot.
>
> Introd
On 19.12.2022 15:45, Sergey Dyasli wrote:
> This is a preparatory step in order to do earlier microcode loading on
> the boot CPU when the domain heap has not been initialized yet and
> xmalloc still unavailable.
>
> Add make_copy argument which will allow to load microcode directly from
> the blo
On 19.12.2022 15:45, Sergey Dyasli wrote:
> This allows to use them for forward declaration in other headers.
>
> Signed-off-by: Sergey Dyasli
Acked-by: Jan Beulich
with ...
> --- a/xen/include/xen/multiboot.h
> +++ b/xen/include/xen/multiboot.h
> @@ -46,23 +46,25 @@
> #ifndef __ASSEMBLY__
>
On 16.12.2022 21:17, Andrew Cooper wrote:
> Partly for clarity because there is a lot of subtle magic at work here.
> Expand the commentary of what's going on.
>
> Also, because there is no need to double copy the stack (32kB) to retrieve
> local values spilled to the stack under the old alias, wh
flight 175412 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175412/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 broken in 175402
test-
flight 175422 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175422/
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 175411 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175411/
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/12/2022 12:14, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+ /*
+ * Currently, we support uImage headers for uncompressed
images only.
+ * Thus, it is valid for the load address and start address
to be the
+ * same. This is
Hi Ayan,
On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+ /*
+ * Currently, we support uImage headers for uncompressed images
only.
+ * Thus, it is valid for the load address and start address to
be the
+ * same. This is consistent with the uboot behavior (Refer
+ * "case
I've been working on getting qemu to support Xen HVM guests 'natively'
under KVM:
https://lore.kernel.org/qemu-devel/20221216004117.862106-1-dw...@infradead.org/T/
The basic platform is mostly working and I can start XTF tests with
'qemu -kernel'. Now it really needs a xenstore.
I'm thinking of i
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 change intended.
>
> Signed-off-by: Xeni
Hi Julien/Michal,
On 20/12/2022 10:05, Julien Grall wrote:
On 20/12/2022 09:44, Michal Orzel wrote:
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not set info->zimage.start. As a
result, it contains the default value (ie 0). This causes,
kernel_z
Hello,
How to solve the pixman error:
$ sudo ./configure
checking build system type... x86_64-pc-solaris2.11
checking host system type... x86_64-pc-solaris2.11
Will build the following subsystems:
xen
tools
stubdom
docs
configure: creating ./config.status
config.status: creating config/To
On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 5e2a720d29..1a02fdc453 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -58,7 +58,6 @@ bool __read_mostly iommu_hap_pt_s
On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index 479d7de57a..82465aa627 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -37,6 +37,22 @@ config IPMMU_VMSA
>
> endif
>
flight 175420 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175420/
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 19.12.2022 19:28, Andrew Cooper wrote:
> IOMMUs are more tricky still. They are (for most intents and purposes)
> mandatory on systems with >254 CPUs. We could in principle start
> supporting asymmetric IRQ routing on large systems, but Xen doesn't
> currently and it would be a lot work that's
On 20/12/2022 09:44, Michal Orzel wrote:
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not set info->zimage.start. As a
result, it contains the default value (ie 0). This causes,
kernel_zimage_place() to treat the binary (contained within uImage) a
On 20/12/2022 09:59, Jan Beulich wrote:
On 20.12.2022 09:48, Julien Grall wrote:
Hi Jan,
On 20/12/2022 08:45, Jan Beulich wrote:
On 20.12.2022 09:40, Julien Grall wrote:
On 19/12/2022 12:48, Jan Beulich wrote:
On 16.12.2022 13:26, Julien Grall wrote:
On 19/10/2022 08:41, Jan Beulich wrot
On 20.12.2022 09:48, Julien Grall wrote:
> Hi Jan,
>
> On 20/12/2022 08:45, Jan Beulich wrote:
>> On 20.12.2022 09:40, Julien Grall wrote:
>>> On 19/12/2022 12:48, Jan Beulich wrote:
On 16.12.2022 13:26, Julien Grall wrote:
> On 19/10/2022 08:41, Jan Beulich wrote:
>> RFC: HVM guests
Hi Jan,
On 20/12/2022 09:38, Jan Beulich wrote:
On 20.12.2022 10:12, Julien Grall wrote:
On 20/12/2022 08:50, Luca Fancellu wrote:
Cppcheck has found a violation of rule 20.7 for the macro memset
about missing parenthesis for the "n" argument, while the parenthesis
are not mandatory because th
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 reproduce the reports here the command:
>
> ./xen/scripts/x
On 20.12.2022 09:51, Luca Fancellu wrote:
> 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:
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, so add them.
>
> This finding is reported also by eclair an
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
> defined, hence this is a false positive of the tool and we c
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
> Currently, kernel_uimage_probe() does not set info->zimage.start. As a
> result, it contains the default value (ie 0). This causes,
> kernel_zimage_place() to treat the binary (contained within uImage) as
> position independent executable. T
On 20.12.2022 09:50, Luca Fancellu wrote:
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -15,6 +15,7 @@
> #define __initconstrel__section(".init.rodata.rel")
> #define __exitdata__used_section(".exit.data")
> #define __initsetup __used_section(".init.setup")
On 20.12.2022 10:12, Julien Grall wrote:
> On 20/12/2022 08:50, Luca Fancellu wrote:
>> Cppcheck has found a violation of rule 20.7 for the macro memset
>> about missing parenthesis for the "n" argument, while the parenthesis
>> are not mandatory because the argument is never used in an
>> expressi
Hi,
On 15/12/2022 21:26, Stewart Hildebrand wrote:
When building with clang 12 and CONFIG_ARM_SMMU_V3=y, we observe the
following build error:
drivers/passthrough/arm/smmu-v3.c:1408:20: error: unused function
'arm_smmu_disable_pasid' [-Werror,-Wunused-function]
static inline void arm_smmu_disa
Hi Daniel,
On 12/12/2022 11:31, Daniel P. Smith wrote:
On 12/12/22 04:36, Julien Grall wrote:
From: Julien Grall
The array initial_sid_to_string is storing pointer to literal strings
and is not meant to be modified. So change the type of the variable
to "const char * const ...[]".
Signed-off
On 20.12.2022 10:07, Julien Grall wrote:
> On 20/12/2022 08:50, Luca Fancellu wrote:
>> --- a/docs/misra/false-positive-cppcheck.json
>> +++ b/docs/misra/false-positive-cppcheck.json
>> @@ -3,6 +3,20 @@
>> "content": [
>> {
>> "id": "SAF-0-false-positive-cppcheck",
>>
Hi,
On 20/12/2022 08:50, Luca Fancellu wrote:
Cppcheck has found a violation of rule 20.7 for the macro memset
about missing parenthesis for the "n" argument, while the parenthesis
are not mandatory because the argument is never used in an
expression, adding them will not harm code and readabili
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 a member access operator, which
is not allowed from the c languag
Cppcheck has found violations of rule 20.7 for the macros
___DEFINE_XEN_GUEST_HANDLE and set_xen_guest_handle_raw.
For the first one, the macro parameters are never used as an
expression, so it is safe to suppress the finding.
For the second one, while the argument "val" is never used
in an express
Cppcheck has found violations of rule 20.7 for the macros
__DECL_REG_LOHI, __DECL_REG_LO8 and __DECL_REG_LO16, but the macro
parameters are used as variable identifiers, so it is safe to
suppress the findings.
Eclair and coverity does not report these findings.
Signed-off-by: Luca Fancellu
---
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
---
xen/include/public/memory.h | 2 +-
1 file changed, 1 inser
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
---
xen/
Hi Jan,
On 19/12/2022 15:01, Jan Beulich wrote:
On 17.12.2022 16:53, Julien Grall wrote:
On 19/10/2022 08:45, Jan Beulich wrote:
Switch to using map_guest_area(). Noteworthy differences from
map_vcpu_info():
- remote vCPU-s are paused rather than checked for being down (which in
principle
Cppcheck has found violations of rule 20.7 for the macros
___DEFINE_XEN_GUEST_HANDLE, set_xen_guest_handle_raw, __DECL_REG_LO8
and __DECL_REG_LO16.
For set_xen_guest_handle_raw, while the "val" argument is never used
in an expression, it doesn't harm the code or the readability to add
parenthesis,
Cppcheck has found a violation of rule 20.7 for the macro
XEN_HVM_VIOAPIC, but the first macro argument is never used
as an expression, cppcheck is not taking into account the context of
use for it, so we can suppress the finding.
Eclair and coverity does not report this finding.
Signed-off-by: L
Cppcheck has found a violation of rule 20.7 for the macro
DECLARE_BITMAP, but the macro parameter is used as variable
identifier, so it is safe to suppress the finding and don't put
parenthesis.
Eclair and coverity does not report this finding.
Signed-off-by: Luca Fancellu
---
xen/include/xen/t
Cppcheck has found violations of rule 20.7 for the macros xmalloc,
xzalloc, xmalloc_array, xzalloc_array, xzalloc_flex_struct and
xmalloc_flex_struct.
In all the cases the macro parameters are never used as an expression,
so it is safe to suppress the findings.
Eclair and coverity does not report
Cppcheck has found a violation of rule 20.7 for the macro
WRITE_SYSREG64, the macro parameter "v" is never used in an
expression, but adding parenthesis to it doesn't harm the code
or the readability, so add parenthesis to it.
Eclair and coverity does not report this finding.
Signed-off-by: Luca
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
defined, hence this is a false positive of the tool and we can
safely suppress the finding.
Eclair and coveri
Cppcheck has found a violation of rule 20.7 for the macro
sizeof_field, but the parenthesis cannot be applied on the second
operand of a member access operator, hence we can suppress the
finding.
Eclair and coverity does not report this finding.
Signed-off-by: Luca Fancellu
---
xen/include/xen/
Cppcheck has found violations of rule 20.7 for the macros
__init_call, presmp_initcall, __initcall and __exitcall.
For the first one, the macro parameter is never used as an expression,
it is used for text substitution but cppcheck is not taking into
account the context of use of the argument, so w
Cppcheck has found violations of rule 20.7 for the macros
___DEFINE_XEN_GUEST_HANDLE, set_xen_guest_handle_raw and __DECL_REG.
For the first and third finding, the macro parameters are never
used in an expression, cppcheck is not taking into account the
context where the arguments are used, so we c
1 - 100 of 111 matches
Mail list logo
