flight 173103 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173103/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6
On 09.09.22 22:25, Stefano Stabellini wrote:
On Fri, 9 Sep 2022, Juergen Gross wrote:
On 09.09.22 04:11, Stefano Stabellini wrote:
Adding more people in CC
On Thu, 8 Sep 2022, Stefano Stabellini wrote:
Hi Juergen,
A colleague is seeing a failure on x86 in Linux Dom0. The failure is
flight 173105 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173105/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173093 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173093/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1
flight 173100 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173091 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
flight 173096 xen-unstable-smoke real [real]
flight 173099 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173096/
http://logs.test-lab.xenproject.org/osstest/logs/173099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 173088 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173088/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-armhf-armhf-xl-arndale
flight 173098 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173098/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Fri, 9 Sep 2022, Jan Beulich wrote:
> While I was suspicious of the compiler issuing a diagnostic about an
> unused linking-only option when not doing any linking, I did check this
> with a couple of gcc versions only, but not with Clang. (Oddly enough at
> least older Clang versions complain
On Fri, 9 Sep 2022, Luca Fancellu wrote:
> > On 9 Sep 2022, at 10:40, Bertrand Marquis wrote:
> >
> > Hi Julien,
> >
> >> On 9 Sep 2022, at 10:27, Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 09/09/2022 08:45, Bertrand Marquis wrote:
>
> It should be:
>
> /*
> *
On Fri, 9 Sep 2022, Henry Wang wrote:
> In order to keep consistency in the device tree binding, there is
> no need for static memory allocation feature to define a specific
> set of address and size cells for "xen,static-mem" property.
>
> Therefore, this commit reuses the regular
On Fri, 9 Sep 2022, Rahul Singh wrote:
> is_memory_hole was implemented for x86 and not for ARM when introduced.
> Replace is_memory_hole call to pci_check_bar as function should check
> if device BAR is in defined memory range. Also, add an implementation
> for ARM which is required for PCI
On Fri, 9 Sep 2022, Juergen Gross wrote:
> On 09.09.22 04:11, Stefano Stabellini wrote:
> > Adding more people in CC
> >
> > On Thu, 8 Sep 2022, Stefano Stabellini wrote:
> > > Hi Juergen,
> > >
> > > A colleague is seeing a failure on x86 in Linux Dom0. The failure is
> > > pin_user_pages_fast
flight 173083 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 173095 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173095/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173080 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 broken
build-i386-libvirt6
flight 173090 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173090/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6
On Thu, Sep 8, 2022 at 9:26 PM Daniel P. Smith
wrote:
>
> The current flow for initial SID assignment is that the function
> flask_domain_alloc_security() allocates the security context and assigns an
> initial SID based on the limited state information it can access. Specifically
> the initial
On 9/9/22 08:10, Jan Beulich wrote:
> On 09.09.2022 13:34, Daniel P. Smith wrote:
>> On 9/9/22 06:04, Jan Beulich wrote:
>>> On 09.09.2022 11:50, Daniel P. Smith wrote:
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -566,14 +566,14 @@ void avc_audit(u32 ssid, u32 tsid, u16
Hi Jan,
> On 9 Sep 2022, at 15:26, Jan Beulich wrote:
>
> On 09.09.2022 15:50, Bertrand Marquis wrote:
>>> On 9 Sep 2022, at 14:41, Jan Beulich wrote:
>>>
>>> It has been bothering me for a while that I made a bad suggestion during
>>
>> This is not a sentence for a commit message.
>
> How
On Fri, Sep 09, 2022 at 08:59:09AM -0400, Jason Andryuk wrote:
> On Fri, Sep 9, 2022 at 6:19 AM Anthony PERARD
> wrote:
> >
> > On Thu, Sep 08, 2022 at 03:51:12PM -0400, Jason Andryuk wrote:
> > > hvm_xs_strings.h specifies xenstore entries which can be used to set or
> > > override smbios
On Fri, Sep 09, 2022 at 08:13:28PM +0530, Viresh Kumar wrote:
> The iommu node will be required for other virtio device types too, not
> just disk device.
>
> Move the call to make_xen_iommu_node(), out of the disk device specific
> block and rename "iommu_created" variable to "iommu_needed", and
The iommu node will be required for other virtio device types too, not
just disk device.
Move the call to make_xen_iommu_node(), out of the disk device specific
block and rename "iommu_created" variable to "iommu_needed", and set it
to true for virtio disk device.
Signed-off-by: Viresh Kumar
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
core_parking_cpunum[i] = core_parking_cpunum[i + 1];
complaining that the right hand side array access is past the bounds of
1. Clearly the compiler can't know that cur_idle_nums can only ever be
zero in
On 09.09.2022 15:50, Bertrand Marquis wrote:
>> On 9 Sep 2022, at 14:41, Jan Beulich wrote:
>>
>> It has been bothering me for a while that I made a bad suggestion during
>
> This is not a sentence for a commit message.
How else should I express the motivation for the change?
>> review: Having
On 09.09.2022 14:27, Julien Grall wrote:
> Hi,
>
> On 09/09/2022 13:14, Jan Beulich wrote:
>> On 09.09.2022 13:00, Julien Grall wrote:
>>> On 09/09/2022 11:18, Jan Beulich wrote:
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
On Fri, Sep 09, 2022 at 01:50:38PM +, Bertrand Marquis wrote:
> > On 9 Sep 2022, at 14:41, Jan Beulich wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -746,11 +746,9 @@ cppcheck-version:
> > # documentation file. Also generate a json file with the right arguments for
> > #
flight 173092 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173092/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi Jan,
> On 9 Sep 2022, at 14:41, Jan Beulich wrote:
>
> It has been bothering me for a while that I made a bad suggestion during
This is not a sentence for a commit message.
> review: Having cppcheck-misra.json depend on cppcheck-misra.txt does not
> properly address the multiple targets
On Thu, Sep 08, 2022 at 02:23:01PM +0530, Viresh Kumar wrote:
> The iommu node will be required for other virtio device types too, not
> just disk device.
>
> Move the call to make_xen_iommu_node(), out of the disk device specific
> block and rename "iommu_created" variable to "iommu_needed", and
It has been bothering me for a while that I made a bad suggestion during
review: Having cppcheck-misra.json depend on cppcheck-misra.txt does not
properly address the multiple targets problem. If cppcheck-misra.json
is deleted from the build tree but cppcheck-misra.txt is still there,
nothing will
Hi Luca,
On 09/09/2022 14:35, Luca Fancellu wrote:
>
>> On 9 Sep 2022, at 10:40, Bertrand Marquis wrote:
>>
>> Hi Julien,
>>
>>> On 9 Sep 2022, at 10:27, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 09/09/2022 08:45, Bertrand Marquis wrote:
>
> It should be:
>
> /*
> * TODO:
On Thu, Sep 08, 2022 at 02:23:00PM +0530, Viresh Kumar wrote:
> make_virtio_mmio_node() creates the DT node for simple MMIO devices
> currently, i.e. the ones that don't require any additional properties.
>
> In order to allow using it for other complex device types, split the
> functionality
On Thu, Sep 08, 2022 at 02:22:59PM +0530, Viresh Kumar wrote:
> In order to prepare for adding support for more device types, create a
> separate routine to allocate base and irq for a device as the same code
> will be required for other device types too.
>
> Also move updates to virtio_irq and
On 09.09.22 15:12, Andrew Cooper wrote:
On 09/09/2022 13:53, Juergen Gross wrote:
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddrs can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This
On 09/09/2022 13:53, Juergen Gross wrote:
> Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
> warning") was wrong, as vaddrs can legitimately be NULL in case
> XENMEM_resource_grant_table_id_status was specified for a grant table
> v1. This would result in crashes in debug
On Fri, Sep 9, 2022 at 6:19 AM Anthony PERARD wrote:
>
> On Thu, Sep 08, 2022 at 03:51:12PM -0400, Jason Andryuk wrote:
> > hvm_xs_strings.h specifies xenstore entries which can be used to set or
> > override smbios strings. hvmloader has support for reading them, but
> > xl/libxl support is not
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddrs can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This would result in crashes in debug builds due to
ASSERT_UNREACHABLE() triggering.
Hi Daniel,
> -Original Message-
> From: Daniel P. Smith
> > This should also be fine to merge in 4.17, but following the discussion with
> > Julien and Jan I think providing a Release ack would lead to confusion...
>
> I was hoping it would go in, but understand if it is kept out. I
> On 9 Sep 2022, at 10:40, Bertrand Marquis wrote:
>
> Hi Julien,
>
>> On 9 Sep 2022, at 10:27, Julien Grall wrote:
>>
>> Hi,
>>
>> On 09/09/2022 08:45, Bertrand Marquis wrote:
It should be:
/*
* TODO:
*
I think this is good to go. The two minor
Hi,
On 09/09/2022 13:14, Jan Beulich wrote:
On 09.09.2022 13:00, Julien Grall wrote:
On 09/09/2022 11:18, Jan Beulich wrote:
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
core_parking_cpunum[i] = core_parking_cpunum[i + 1];
complaining that
On 09.09.2022 13:00, Julien Grall wrote:
> On 09/09/2022 11:18, Jan Beulich wrote:
>> Gcc12 takes issue with core_parking_remove()'s
>>
>> for ( ; i < cur_idle_nums; ++i )
>> core_parking_cpunum[i] = core_parking_cpunum[i + 1];
>>
>> complaining that the right hand side array access
On 09.09.2022 13:34, Daniel P. Smith wrote:
> On 9/9/22 06:04, Jan Beulich wrote:
>> On 09.09.2022 11:50, Daniel P. Smith wrote:
>>> --- a/xen/xsm/flask/avc.c
>>> +++ b/xen/xsm/flask/avc.c
>>> @@ -566,14 +566,14 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32
>>> requested,
>>> if ( a
flight 173073 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173073/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1
flight 173089 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173089/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 9/9/22 05:56, Henry Wang wrote:
Hi Daniel,
-Original Message-
Subject: [PATCH] xsm/flask: adjust print messages to use %pd
Print messages from flask use an inconsistent format when printing the
domain
id. The %pd conversion specifier provides a consistent way to format for the
On 9/9/22 06:04, Jan Beulich wrote:
On 09.09.2022 11:50, Daniel P. Smith wrote:
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -566,14 +566,14 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32
requested,
if ( a && (a->sdom || a->tdom) )
{
if ( a->sdom &&
Hi Jan,
On 09/09/2022 11:18, Jan Beulich wrote:
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
core_parking_cpunum[i] = core_parking_cpunum[i + 1];
complaining that the right hand side array access is past the bounds of
1. Clearly the compiler
flight 173075 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
On 09/09/2022 11:24, Juergen Gross wrote:
> Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
> warning") was wrong, as vaddrs can legitimately be NULL in case
> XENMEM_resource_grant_table_id_status was specified for a grant table
> v1. This would result in crashes in debug
On Thu, Sep 08, 2022 at 03:51:13PM -0400, Jason Andryuk wrote:
> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> index c3125ed310..0b01e09632 100644
> --- a/tools/libs/light/libxl_dom.c
> +++ b/tools/libs/light/libxl_dom.c
> @@ -773,8 +774,18 @@ static int
On 09.09.2022 12:24, Juergen Gross wrote:
> Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
> warning") was wrong, as vaddrs can legitimately be NULL in case
> XENMEM_resource_grant_table_id_status was specified for a grant table
> v1. This would result in crashes in debug
On 09.09.2022 12:24, SHARMA, JYOTIRMOY wrote:
> [AMD Official Use Only - General]
>
> Adding xen devel
Please don't cross-post.
> Regards,
> Jyotirmoy
>
> From: SHARMA, JYOTIRMOY
> Sent: Friday, September 9, 2022 3:52 PM
> To: 'xen-us...@lists.xenproject.org'
> Subject: libxl source code
>
>
Hi,
On 09.09.22 12:24, SHARMA, JYOTIRMOY wrote:
[AMD Official Use Only - General]
Adding xen devel
Removing xen-users.
Regards,
Jyotirmoy
*From:* SHARMA, JYOTIRMOY
*Sent:* Friday, September 9, 2022 3:52 PM
*To:* 'xen-us...@lists.xenproject.org'
*Subject:* libxl source code
[AMD
[AMD Official Use Only - General]
Adding xen devel
Regards,
Jyotirmoy
From: SHARMA, JYOTIRMOY
Sent: Friday, September 9, 2022 3:52 PM
To: 'xen-us...@lists.xenproject.org'
Subject: libxl source code
[AMD Official Use Only - General]
Hello,
I am looking for the libxl source code to
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddrs can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This would result in crashes in debug builds due to
ASSERT_UNREACHABLE() triggering.
On Thu, Sep 08, 2022 at 03:51:12PM -0400, Jason Andryuk wrote:
> hvm_xs_strings.h specifies xenstore entries which can be used to set or
> override smbios strings. hvmloader has support for reading them, but
> xl/libxl support is not wired up.
>
> Allow specifying the strings with the new xl.cfg
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
core_parking_cpunum[i] = core_parking_cpunum[i + 1];
complaining that the right hand side array access is past the bounds of
1. Clearly the compiler can't know that cur_idle_nums can only ever be
zero in
On 09.09.2022 11:50, Daniel P. Smith wrote:
> --- a/xen/xsm/flask/avc.c
> +++ b/xen/xsm/flask/avc.c
> @@ -566,14 +566,14 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32
> requested,
> if ( a && (a->sdom || a->tdom) )
> {
> if ( a->sdom && a->tdom && a->sdom != a->tdom )
>
Hi Jan,
> -Original Message-
> On 09.09.2022 11:28, Henry Wang wrote:
> >
> >
> > Kind regards,
> > Henry
>
> Hmm, did you mean to actually add some text in your message?
I am really sorry, my outlook just got frozen and I must mis-send an
empty email somehow. No nothing from my side.
On 09.09.2022 11:28, Henry Wang wrote:
>
>
> Kind regards,
> Henry
Hmm, did you mean to actually add some text in your message?
Jan
Hi Daniel,
> -Original Message-
> Subject: [PATCH] xsm/flask: adjust print messages to use %pd
>
> Print messages from flask use an inconsistent format when printing the
> domain
> id. The %pd conversion specifier provides a consistent way to format for the
> domain id and aligns with
Print messages from flask use an inconsistent format when printing the domain
id. The %pd conversion specifier provides a consistent way to format for the
domain id and aligns with the rest of the hypervisor code.
Signed-off-by: Daniel P. Smith
---
xen/xsm/flask/avc.c | 8
Hi Jan,
On 09/09/2022 10:08, Juergen Gross wrote:
On 09.09.22 10:56, Julien Grall wrote:
Hi Juergen,
On 09/09/2022 09:09, Juergen Gross wrote:
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
Hi Julien,
> On 9 Sep 2022, at 10:27, Julien Grall wrote:
>
> Hi,
>
> On 09/09/2022 08:45, Bertrand Marquis wrote:
>>>
>>> It should be:
>>>
>>> /*
>>> * TODO:
>>> *
>>>
>>> I think this is good to go. The two minor style issues could be fixed on
>>> commit. I haven't committed to give
flight 173086 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
is_memory_hole was implemented for x86 and not for ARM when introduced.
Replace is_memory_hole call to pci_check_bar as function should check
if device BAR is in defined memory range. Also, add an implementation
for ARM which is required for PCI passthrough.
On x86, pci_check_bar will call
Modify pci_find_host_bridge_node argument to const pdev to avoid
converting the dev to pdev in pci_find_host_bridge_node and also
constify the return.
Signed-off-by: Rahul Singh
Acked-by: Stefano Stabellini
Reviewed-by: Oleksandr Tyshchenko
---
Changes in v6:
- no changes
Changes in v5:
- no
This patch series is to implement something like is_memory_hole function for
ARM.
Rahul Singh (2):
xen/arm: pci: modify pci_find_host_bridge_node argument to const pdev
xen/pci: replace call to is_memory_hole to pci_check_bar
xen/arch/arm/include/asm/pci.h | 5 ++-
On 08/09/2022 14:05, Julien Grall wrote:
Hi Henry,
On 08/09/2022 13:07, Henry Wang wrote:
The static-heap dt-binding should be placed after the last feature,
namely static-evtchn.
Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory")
Signed-off-by: Henry Wang
Thanks for
On 09/09/2022 10:25, Juergen Gross wrote:
On 09.09.22 11:15, Jan Beulich wrote:
On 09.09.2022 10:09, Juergen Gross wrote:
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
Kind regards,
Henry
> -Original Message-
> From: Juergen Gross
> Sent: Friday, September 9, 2022 5:26 PM
> To: Jan Beulich
> Cc: Henry Wang ; Andrew Cooper
> ; George Dunlap ;
> Julien Grall ; Stefano Stabellini ;
> Wei Liu ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH]
Hi,
On 09/09/2022 08:45, Bertrand Marquis wrote:
It should be:
/*
* TODO:
*
I think this is good to go. The two minor style issues could be fixed on
commit. I haven't committed to give Julien & Bertrand another chance to
have a look.
I think that it is ok to fix those on commit and I am ok
On 09.09.22 11:15, Jan Beulich wrote:
On 09.09.2022 10:09, Juergen Gross wrote:
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This
On 09.09.2022 10:09, Juergen Gross wrote:
> Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
> warning") was wrong, as vaddr can legitimately be NULL in case
> XENMEM_resource_grant_table_id_status was specified for a grant table
> v1. This would result in crashes in debug
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH] xen/gnttab: fix gnttab_acquire_resource()
>
> Hi Henry,
>
> On 09/09/2022 09:47, Henry Wang wrote:
> >> -Original Message-
> >> From: Juergen Gross
> >> Subject: [PATCH] xen/gnttab: fix
Hi Jan,
On 09/09/2022 10:10, Jan Beulich wrote:
On 09.09.2022 11:04, Julien Grall wrote:
Unrelated to this patch, but as this is your first Released-acked-by
tag, I wanted to check the policy going forward.
From now, will any new patch need your approval before been merged?
It was my
On 09.09.2022 11:04, Julien Grall wrote:
> Unrelated to this patch, but as this is your first Released-acked-by
> tag, I wanted to check the policy going forward.
>
> From now, will any new patch need your approval before been merged?
It was my understanding (from past releases) that bug fixes
On 09.09.22 10:56, Julien Grall wrote:
Hi Juergen,
On 09/09/2022 09:09, Juergen Gross wrote:
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant
Hi Henry,
On 09/09/2022 09:47, Henry Wang wrote:
-Original Message-
From: Juergen Gross
Subject: [PATCH] xen/gnttab: fix gnttab_acquire_resource()
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
Hi Juergen,
On 09/09/2022 09:09, Juergen Gross wrote:
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This would result in crashes in
flight 173074 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173074/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
Hi Juergen,
> -Original Message-
> From: Juergen Gross
> Subject: [PATCH] xen/gnttab: fix gnttab_acquire_resource()
>
> Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
> warning") was wrong, as vaddr can legitimately be NULL in case
>
Commit 9dc46386d89d ("gnttab: work around "may be used uninitialized"
warning") was wrong, as vaddr can legitimately be NULL in case
XENMEM_resource_grant_table_id_status was specified for a grant table
v1. This would result in crashes in debug builds due to
ASSERT_UNREACHABLE() triggering.
Hi Henry,
> On 9 Sep 2022, at 06:23, Henry Wang wrote:
>
> In order to keep consistency in the device tree binding, there is
> no need for static memory allocation feature to define a specific
> set of address and size cells for "xen,static-mem" property.
>
> Therefore, this commit reuses the
Hi,
> On 8 Sep 2022, at 22:41, Julien Grall wrote:
>
> Hi Stefano,
>
> On 08/09/2022 21:59, Stefano Stabellini wrote:
>>> +/*
>>> + * TODO: BAR addresses and Root Complex window addresses are not guaranteed
>>> + * to be page aligned. We should check for alignment but this is not the
>>> + *
Hi,
> On 8 Sep 2022, at 22:05, Stefano Stabellini wrote:
>
> On Thu, 8 Sep 2022, Penny Zheng wrote:
>> We expose the shared memory to the domU using the "xen,shared-memory-v1"
>> reserved-memory binding. See
>> Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
>> in Linux
Commit 68f5aac012b9 ("build: suppress future GNU ld warning about RWX
load segments") didn't quite cover all the cases: I missed ones in the
building of the test code blobs. Clone the workaround to the helper
Makefile in question, kind of open-coding the hypervisor build system's
ld-option macro.
While I was suspicious of the compiler issuing a diagnostic about an
unused linking-only option when not doing any linking, I did check this
with a couple of gcc versions only, but not with Clang. (Oddly enough at
least older Clang versions complain about the use of '-nopie' now that
we actually
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年9月9日 0:02
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 5/6] xen/x86: move NUMA scan
flight 173081 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 09/09/2022 07:23, Henry Wang wrote:
>
> In order to keep consistency in the device tree binding, there is
> no need for static memory allocation feature to define a specific
> set of address and size cells for "xen,static-mem" property.
>
> Therefore, this commit reuses the regular
On 09.09.22 04:11, Stefano Stabellini wrote:
Adding more people in CC
On Thu, 8 Sep 2022, Stefano Stabellini wrote:
Hi Juergen,
A colleague is seeing a failure on x86 in Linux Dom0. The failure is
pin_user_pages_fast with addresses that correspond to foreign memory
pages:
- QEMU maps a domU
On 09.09.2022 01:34, Stefano Stabellini wrote:
> This patch breaks the gitlab-ci pipeline, specifically it breaks the
> hvmloader build with clang:
>
>
> https://gitlab.com/xen-project/xen/-/pipelines/634274727
> https://gitlab.com/xen-project/xen/-/jobs/2996114313
>
> make[7]: Entering
On 09.09.2022 03:25, Daniel P. Smith wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -38,6 +38,12 @@
> #include
> #include "private.h"
>
> +#ifdef CONFIG_X86
> +#include
> +#else
> +#define pv_shim false
> +#endif
Hmm, yet another instance of such. We have already
96 matches
Mail list logo
