Hi Julien,
On 21.02.2022 16:58, Julien Grall wrote:
> Hi Michal,
>
> On 21/02/2022 10:59, Michal Orzel wrote:
>> Following a discussion [1] it seems like that renaming work has
>> been forgotten.
>
> This is in my todo list of clean-up I need to do for Xen. But I haven't yet
> had a chance to
flight 168187 linux-linus real [real]
flight 168190 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168187/
http://logs.test-lab.xenproject.org/osstest/logs/168190/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 168188 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168188/
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
flight 168186 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168186/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168180
test-armhf-armhf-libvirt 16 sav
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-running the network script even if it was already called (in case of
the frontent re-connecting).
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on the
watch being fired the first time - to check if maybe 'hotplug-status' is
already set to 'conne
On Mon, Feb 21, 2022 at 07:27:32AM +0100, Juergen Gross wrote:
> I checked some of the call paths leading to xennet_close(), and all of
> those contained an ASSERT_RTNL(), so it seems the rtnl_lock is already
> taken here. Could you test with adding an ASSERT_RTNL() in
> xennet_destroy_queues()?
T
Hi Julien,
On 21/02/2022 19:13, Julien Grall wrote:
On 21/02/2022 19:05, Ayan Kumar Halder wrote:
If we (ie Xen) didn't decode the instruction manually, then
check_p2m() has not been invoked yet. This is because of the
following (info.dabt.valid == True) :-
if ( !is_data || !info
On 17/02/2022 10:20, Jan Beulich wrote:
> On 16.02.2022 23:17, Andrew Cooper wrote:
>> On 14/02/2022 13:56, Jan Beulich wrote:
>>> On 14.02.2022 14:50, Andrew Cooper wrote:
On 14/02/2022 13:33, Jan Beulich wrote:
> On 14.02.2022 13:50, Andrew Cooper wrote:
>> From: Juergen Gross
>
On 21/02/2022 19:05, Ayan Kumar Halder wrote:
If we (ie Xen) didn't decode the instruction manually, then check_p2m()
has not been invoked yet. This is because of the following
(info.dabt.valid == True) :-
if ( !is_data || !info.dabt.valid )
{
...
On 21/02/2022 17:57, Julien Grall wrote:
On 21/02/2022 17:05, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
Hi Julien,
On 13/02/2022 12:19, Julien Grall wrote:
}
void register_mmio_handler(struct domain *d,
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 308650b400..3c0
Hi Julien,
On Fri, Feb 18, 2022 at 10:17:33AM +, Julien Grall wrote:
>
>
> On 18/02/2022 09:16, Oleksii Moisieiev wrote:
> > Hi Julien,
>
> Hi Oleksii,
>
> > On Thu, Feb 17, 2022 at 03:20:36PM +, Julien Grall wrote:
> > > >xlu_cfg_get_defbool(config, "xend_suspend_evtchn_compat
Most IOMMU hooks are already altcall for performance reasons. Convert the
rest of them so we can harden all the hooks in Control Flow Integrity
configurations. This necessitates the use of iommu_{v,}call() in debug builds
too.
Move the root iommu_ops from __read_mostly to __ro_after_init now tha
On 21/02/2022 17:05, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
On 13/02/2022 12:19, Julien Grall wrote:
}
void register_mmio_handler(struct domain *d,
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 308650b400..3c0a935ccf 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch
flight 168185 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168185/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b24306f15daa2ff8510b06702114724b33895d3c
baseline version:
ovmf 8a576733162bb72afb4d1
Hi Julien,
Apprecciate your continuous help on this. Most of your comments make
sense, but I need few clarifications as below :-
On 13/02/2022 12:19, Julien Grall wrote:
Hi,
On 12/02/2022 23:34, Ayan Kumar Halder wrote:
xen/arch/arm/arm32/traps.c | 7 +++
xen/arch/arm/arm64/trap
Hi Michal,
On 21/02/2022 10:59, Michal Orzel wrote:
Following a discussion [1] it seems like that renaming work has
been forgotten.
This is in my todo list of clean-up I need to do for Xen. But I haven't
yet had a chance to look at it. Thank you for taking a look!
Perform renaming of psr_
On 21.02.22 16:31, Jan Beulich wrote:
On 21.02.2022 16:05, Juergen Gross wrote:
On 21.02.22 15:31, Jan Beulich wrote:
On 21.02.2022 15:27, Juergen Gross wrote:
On 21.02.22 15:18, Jan Beulich wrote:
On 21.02.2022 13:42, Juergen Gross wrote:
Providing a macro for an invalid grant reference wou
On Mon, Jan 31, 2022 at 02:37:13AM +0300, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the
On 21.02.2022 16:05, Juergen Gross wrote:
> On 21.02.22 15:31, Jan Beulich wrote:
>> On 21.02.2022 15:27, Juergen Gross wrote:
>>> On 21.02.22 15:18, Jan Beulich wrote:
On 21.02.2022 13:42, Juergen Gross wrote:
> Providing a macro for an invalid grant reference would be beneficial
> fo
On 21.02.22 15:31, Jan Beulich wrote:
On 21.02.2022 15:27, Juergen Gross wrote:
On 21.02.22 15:18, Jan Beulich wrote:
On 21.02.2022 13:42, Juergen Gross wrote:
Providing a macro for an invalid grant reference would be beneficial
for users, especially as some are using the wrong value "0" for t
On 21.02.2022 15:27, Juergen Gross wrote:
> On 21.02.22 15:18, Jan Beulich wrote:
>> On 21.02.2022 13:42, Juergen Gross wrote:
>>> Providing a macro for an invalid grant reference would be beneficial
>>> for users, especially as some are using the wrong value "0" for that
>>> purpose.
>>>
>>> Signe
On 21.02.22 15:18, Jan Beulich wrote:
On 21.02.2022 13:42, Juergen Gross wrote:
Providing a macro for an invalid grant reference would be beneficial
for users, especially as some are using the wrong value "0" for that
purpose.
Signed-off-by: Juergen Gross
Over the years I've been considering
On 21/02/2022 12:23, Roger Pau Monne wrote:
> On Mon, Feb 21, 2022 at 11:28:39AM +, Andrew Cooper wrote:
>> On 21/02/2022 11:21, Roger Pau Monné wrote:
>>> On Mon, Feb 21, 2022 at 10:02:53AM +, Andrew Cooper wrote:
Coverity reports that there is a memory leak in
ioreq_server_alloc
On 21.02.2022 13:42, Juergen Gross wrote:
> Providing a macro for an invalid grant reference would be beneficial
> for users, especially as some are using the wrong value "0" for that
> purpose.
>
> Signed-off-by: Juergen Gross
Over the years I've been considering to add such to the public
inter
On 21.02.2022 11:02, Andrew Cooper wrote:
> Coverity reports that there is a memory leak in
> ioreq_server_alloc_rangesets(). This would be true if Xen's implementation of
> asprintf() had glibc's return semantics, but it doesn't.
>
> Rename to xasprintf() to reduce confusion for Coverity and oth
Providing a macro for an invalid grant reference would be beneficial
for users, especially as some are using the wrong value "0" for that
purpose.
Signed-off-by: Juergen Gross
---
xen/include/public/grant_table.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/public/grant_tabl
On Mon, Feb 21, 2022 at 11:28:39AM +, Andrew Cooper wrote:
> On 21/02/2022 11:21, Roger Pau Monné wrote:
> > On Mon, Feb 21, 2022 at 10:02:53AM +, Andrew Cooper wrote:
> >> Coverity reports that there is a memory leak in
> >> ioreq_server_alloc_rangesets(). This would be true if Xen's
> >
flight 168183 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168183/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168179
test-armhf-armhf-libvirt 16 saver
flight 168184 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 21/02/2022 11:22, Roger Pau Monné wrote:
> On Mon, Feb 21, 2022 at 11:14:54AM +, Andrew Cooper wrote:
>> * Use workflow_dispatch to allow manual creation of the job.
> I guess such manual creation requires some kind of superpower
> credentials on the github repo?
I'd expect its open to pro
On 21/02/2022 11:21, Roger Pau Monné wrote:
> On Mon, Feb 21, 2022 at 10:02:53AM +, Andrew Cooper wrote:
>> Coverity reports that there is a memory leak in
>> ioreq_server_alloc_rangesets(). This would be true if Xen's implementation
>> of
>> asprintf() had glibc's return semantics, but it do
On Mon, Feb 21, 2022 at 11:14:54AM +, Andrew Cooper wrote:
> * Use workflow_dispatch to allow manual creation of the job.
I guess such manual creation requires some kind of superpower
credentials on the github repo?
> * Use parallel builds; the workers have two vCPUs. Also, use the build-*
On Mon, Feb 21, 2022 at 10:02:53AM +, Andrew Cooper wrote:
> Coverity reports that there is a memory leak in
> ioreq_server_alloc_rangesets(). This would be true if Xen's implementation of
> asprintf() had glibc's return semantics, but it doesn't.
>
> Rename to xasprintf() to reduce confusion
On 21/02/2022 09:48, Roger Pau Monne wrote:
> We are currently doing the Coverity Scans using a github workflow.
>
> Signed-off-by: Roger Pau Monné
FWIW, Acked-by: Andrew Cooper
* Use workflow_dispatch to allow manual creation of the job.
* Use parallel builds; the workers have two vCPUs. Also, use the build-*
targets rather than the ones which expand to dist-*.
* Shrink the dependency list further. build-essential covers make and gcc,
while bridge-utils and ipr
Following a discussion [1] it seems like that renaming work has
been forgotten. Perform renaming of psr_mode_is_32bit to
regs_mode_is_32bit as the function no longer takes psr parameter.
[1] https://marc.info/?l=xen-devel&m=156457538423787&w=2
Signed-off-by: Michal Orzel
---
xen/arch/arm/includ
On 21/02/2022 10:37, Roger Pau Monné wrote:
> On Mon, Feb 21, 2022 at 10:02:54AM +, Andrew Cooper wrote:
>> * Use workflow_dispatch to allow manual creation of the job.
>> * Use parallel builds. The workers have two vCPUs.
>> * Shrink the dependency list further. build-essential covers mak
From: Wei Liu
The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We
pre-populate all the relevant page tables before the system is fully
set up.
We will need it on Arm in order to rework the arm64 version of
xenheap_setup_mappings() as we may need to use pages allocated from
the boot
From: Julien Grall
The current implementation of setup_xenheap_mappings() is using 1GB
mappings. This can lead to unexpected result because the mapping
may alias a non-cachable region (such as device or reserved regions).
For more details see B2.8 in ARM DDI 0487H.a.
map_pages_to_xen() was recen
From: Julien Grall
Currently, memory is added to the boot allocator after the xenheap
mappings are done. This will break if the first mapping is more than
512GB of RAM.
In addition to that, a follow-up patch will rework setup_xenheap_mappings()
to use smaller mappings (e.g. 2MB, 4KB). So it will
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
This has the advantage to remove the differences between 32-bit and
64-bit code.
Lastly remove create_mappings() as there is no more ca
From: Julien Grall
During early boot, it is not possible to use xen_{,un}map_table()
if the page tables are not residing the Xen binary.
This is a blocker to switch some of the helpers to use xen_pt_update()
as we may need to allocate extra page tables and access them before
the domheap has been
From: Julien Grall
xen_{un,}map_table() already uses the helper to map/unmap pages
on-demand (note this is currently a NOP on arm64). So switching to
domheap don't have any disavantage.
But this as the benefit:
- to keep the page tables unmapped if an arch decided to do so
- reduce xenhe
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
Signed-off-by: Julien Grall
---
Changes in v3:
- Fix build when CONFIG_DEBUG=y
Changes in v2:
- New patch
From: Julien Grall
To use properly the fixmap definitions, their user would need
also new to include . This is not very great when
the user itself is not meant to directly use ACPI definitions.
Including in is not option because
the latter header is included by everyone. So move out the fixmap
From: Julien Grall
The numbers of includes in mm.c has been growing quite a lot. However
some of them (e.g. xen/device_tree.h, xen/softirq.h) doesn't look
to be directly used by the file or other will be included by
larger headers (e.g asm/flushtlb.h will be included by xen/mm.h).
So trim down t
From: Julien Grall
At the moment, page-table can only be allocated from domheap. This means
it is not possible to create mapping in the page-tables via
map_pages_to_xen() if page-table needs to be allocated.
In order to avoid open-coding page-tables update in early boot, we need
to be able to al
On Mon, Feb 21, 2022 at 10:02:52AM +, Andrew Cooper wrote:
> It the 'addr' input to mmap(), and currently consuming stack rubble.
>
> Coverity-ID: 1500115
> Fixes: c7a7f14b9299 ("tests/resource: Extend to check that the grant frames
> are mapped correctly")
> Signed-off-by: Andrew Cooper
Re
On Mon, Feb 21, 2022 at 10:02:54AM +, Andrew Cooper wrote:
> * Use workflow_dispatch to allow manual creation of the job.
> * Use parallel builds. The workers have two vCPUs.
> * Shrink the dependency list further. build-essential covers make and gcc,
>while bridge-utils and iproute2 a
flight 168182 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168182/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-seattle 8 xen-boot fail in 168175 pass in 168182
test-amd64-amd64-xl-qemut-debian
From: Julien Grall
Currently, Xen PT helpers are only working with 4KB page granularity
and open-code the generic helpers. To allow more flexibility, we can
re-use the generic helpers and pass Xen's page granularity
(PAGE_SHIFT).
As Xen PT helpers are used in both C and assembly, we need to move
From: Julien Grall
Only the first 2GB of the virtual address space is shared between all
the page-tables on Arm32.
There is a long outstanding TODO in xen_pt_update() stating that the
function can only work with shared mapping. Nobody has ever called
the function with private mapping, however as
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() calls by map_pages_to_xen() calls.
The mapping can also be marked read-only has Xen as no business to
modify the host Device Tree.
Signed-off-by: Julien Grall
Signed-o
From: Julien Grall
Now that xen_pt_update_entry() is able to deal with different mapping
size, we can replace the open-coding of the page-tables update by a call
to modify_xen_mappings().
As the function is not meant to fail, a BUG_ON() is added to check the
return.
Signed-off-by: Julien Grall
From: Julien Grall
Currently, the function xen_pt_update() will flush the TLBs even when
the mappings are inserted. This is a bit wasteful because we don't
allow mapping replacement. Even if we were, the flush would need to
happen earlier because mapping replacement should use Break-Before-Make
w
From: Julien Grall
In follow-up patches, we will use xen_pt_update() (or its callers)
to handle large mappings (e.g. frametable, xenheap). They are also
not going to be modified once created.
The page-table entries have an hint to indicate that whether an
entry is contiguous to another 16 entrie
From: Julien Grall
At the moment, xen_pt_update_entry() only supports mapping at level 3
(i.e 4KB mapping). While this is fine for most of the runtime helper,
the boot code will require to use superpage mapping.
We don't want to allow superpage mapping by default as some of the
callers may expec
From: Julien Grall
The array level_orders and level_masks can be replaced with the
recently introduced macros LEVEL_ORDER and LEVEL_MASK.
Signed-off-by: Julien Grall
---
Changes in v3:
- Fix clashes after prefixing the PT macros with XEN_PT_
Changes in v2:
- New patch
From: Julien Grall
Hi all,
This series was originally sent as "xen/arm: mm: Add limited support
for superpages" [1] and finally has grown enough to remove most of
the open-coding mappings in the boot code.
This will help to:
1) Get better compliance with the Arm memory model
2) Pave the
From: Julien Grall
Commit 05031fa87357 "xen/arm: guest_walk: Only generate necessary
offsets/masks" introduced LPAE_ENTRIES_MASK_GS. In a follow-up patch,
we will use it for to define LPAE_ENTRY_MASK.
This will lead to inconsistent naming. As LPAE_ENTRY_MASK is used in
many places, it is better
Coverity reports that there is a memory leak in
ioreq_server_alloc_rangesets(). This would be true if Xen's implementation of
asprintf() had glibc's return semantics, but it doesn't.
Rename to xasprintf() to reduce confusion for Coverity and other developers.
While at it, fix style issues. Rear
It the 'addr' input to mmap(), and currently consuming stack rubble.
Coverity-ID: 1500115
Fixes: c7a7f14b9299 ("tests/resource: Extend to check that the grant frames are
mapped correctly")
Signed-off-by: Andrew Cooper
---
CC: Roger Pau Monné
---
tools/tests/resource/test-resource.c | 2 +-
1 f
* Use workflow_dispatch to allow manual creation of the job.
* Use parallel builds. The workers have two vCPUs.
* Shrink the dependency list further. build-essential covers make and gcc,
while bridge-utils and iproute2 are runtime dependencies not build
dependencies. Alter bzip2 to libb
Andrew Cooper (3):
tests/resource: Initialise gnttab before
xenforeignmemory_map_resource()
xen: Rename asprintf() to xasprintf()
CI: Coverity tweaks
.github/workflows/coverity.yml | 14 --
tools/tests/resource/test-resource.c | 2 +-
xen/common/ioreq.c
We are currently doing the Coverity Scans using a github workflow.
Signed-off-by: Roger Pau Monné
---
crontab | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crontab b/crontab
index 8d9b31f1..f43e8bc5 100755
--- a/crontab
+++ b/crontab
@@ -12,7 +12,7 @@ MAILTO=osstest-ad...@x
On Sat, Feb 19, 2022 at 11:24:25AM -, David Woodhouse wrote:
>
>
> > /*
> > * With interrupt format set to 0 (non-remappable) bits 55:49 from the
> > * IO-APIC RTE and bits 11:5 from the MSI address can be used to store
> > * high bits for the Destination ID. This expands the Destination I
67 matches
Mail list logo
