On 17.05.2021 15:22, Jan Beulich wrote:
> L3 entry updates aren't specified to take immediate effect in PAE mode:
> On bare metal, only the next CR3 load actually loads the PDPTEs, and a
> 32-bit Xen also wouldn't immediately propagate new entries into the
> PDPTEs. Them taking immediate effect (le
flight 163654 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 13.07.2021 18:33, Julien Grall wrote:
> Hi,
>
> On 13/07/2021 17:27, Jan Beulich wrote:
>> On 13.07.2021 18:15, Julien Grall wrote:
>>> On 13/07/2021 16:52, Jan Beulich wrote:
On 13.07.2021 16:33, Julien Grall wrote:
> On 13/07/2021 15:23, Jan Beulich wrote:
>> On 13.07.2021 16:19,
flight 163647 xen-unstable real [real]
flight 163667 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163647/
http://logs.test-lab.xenproject.org/osstest/logs/163667/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 163658 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163658/
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. 162359
test-amd64-amd64-xl-qemuu
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
Hello,
this is v4 of the final patch set for my effort to make struct
bus_type::remove return void.
The first four patches contain cleanups that make some of these
callbacks (more obviously) always return 0. They are acked by the
respective maintainers. Bjorn Helgaas explicitly asked to include t
On Tue, 22 Jun 2021, Roman Skakun wrote:
> This commit is dedicated to fix incorrect conversion from
> cpu_addr to page address in cases when we get virtual
> address which allocated in the vmalloc range.
> As the result, virt_to_page() cannot convert this address
> properly and return incorrect pa
On Mon, 5 Jul 2021, Jan Beulich wrote:
> On 03.07.2021 19:11, Julien Grall wrote:
> > From: Julien Grall
> >
> > At the moment, Arm is providing a dummy implementation for the M2P
> > helpers used in common code. However, they are quite isolated and could
> > be used by other architecture in the
On Tue, 6 Jul 2021, Michal Orzel wrote:
> On 03.07.2021 19:11, Julien Grall wrote:
> > From: Julien Grall
> >
> > The current implementation of mfn_to_gfn() is completely bogus and
> > there are no plan to implement an M2P on Arm. As there are no more
> > users, drop the helper.
> >
> s/plan/pla
Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu container. The minimal test simply boots Xen
(built from previous build stages) and Dom0. The test is fetching the
Dom0 kernel and initrd from Debian Jessie: they work just fine and this
way we don't hav
Add qemu-system-arm to the existing test-artifacts qemu container (which
doesn't get build for every iteration but only updated once in a while.)
With qemu-system-arm available, we'll be able to run ARM32 tests.
This patch also bumps the QEMU version to v6.0.0 for both arm32 and
arm64 (the test-a
Hi all,
This short series adds a minimal ARM32 test based on QEMU. It just runs
Xen and Dom0 up to a Busybox prompt.
Cheers,
Stefano
Stefano Stabellini (2):
Add qemu-system-arm to the existing tests-artifacts container
Add an ARM32 qemu-based smoke test
automation/gitlab-ci/build
Ops, I realized this series never made it entirely to xen-devel. Let me
resend it.
On Tue, 13 Jul 2021, Stefano Stabellini wrote:
> Ping?
>
>
> On Fri, 25 Jun 2021, Stefano Stabellini wrote:
> > Hi all,
> >
> > This short series adds a minimal ARM32 test based on QEMU. It just runs
> > Xen and
Ping?
On Fri, 25 Jun 2021, Stefano Stabellini wrote:
> Hi all,
>
> This short series adds a minimal ARM32 test based on QEMU. It just runs
> Xen and Dom0 up to a Busybox prompt.
>
> Cheers,
>
> Stefano
>
>
> Stefano Stabellini (2):
> Add qemu-system-arm to the existing tests-artifacts
Add Dom0less to SUPPORT.md to clarify its support status. The feature is
mature enough and small enough to make it security supported.
Signed-off-by: Stefano Stabellini
diff --git a/SUPPORT.md b/SUPPORT.md
index 317392d8f3..c777f3da72 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -832,6 +832,12 @@
On Tue, Jun 22, 2021 at 04:34:14PM +0300, Roman Skakun wrote:
> This commit is dedicated to fix incorrect conversion from
> cpu_addr to page address in cases when we get virtual
> address which allocated in the vmalloc range.
> As the result, virt_to_page() cannot convert this address
> properly an
..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
flight 163642 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163642/
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. 163321
test-amd64-amd64
flight 163656 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163656/
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
On Sat, 3 Jul 2021, Julien Grall wrote:
> Hi Stefano,
>
> Sorry for the late answer.
>
> On 13/05/2021 23:44, Stefano Stabellini wrote:
> > On Wed, 12 May 2021, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 12/05/2021 22:30, Stefano Stabellini wrote:
> > > > On Wed, 12 May 2021, Julien Gr
flight 163646 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163646/
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. 162359
test-amd64-amd64-xl-qemuu
flight 163645 xen-unstable-smoke real [real]
flight 163651 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163645/
http://logs.test-lab.xenproject.org/osstest/logs/163651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 20 ++-
tools/libs/guest/xg_sr_restore.c | 69
tools/libs/guest/xg_sr_restore_x86_hvm.c | 9
tools/libs/guest/xg_sr_restore_x86_pv.c | 7 +++
4 files changed, 34 insertions(+), 7
During creating of a HVM domU meminit_hvm() tries to map superpages.
After save/restore or migration this mapping is lost, everything is
allocated in single pages. This causes a performance degradation after
migration.
Add neccessary code to preallocate a superpage for an incoming chunk of
pfns. I
The decision to stop+move a domU to the new host must be based on two factors:
- the available network bandwidth for the migration stream
- the maximum time a workload within a domU can be savely suspended
Both values define how many dirty pages a workload may produce prior the
final stop+move.
T
Since the incoming migration stream lacks info about what the highest pfn
will be, some data structures can not be allocated upfront.
Add an API for expandable bitmaps, loosely based on pfn_set_populated.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.c | 39 +++
t
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in an incoming batch.
Allocate the space once.
Use some prefix to avoid conflict with an array used in handle_page_data.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h
Read incoming migration stream directly into the guest memory.
This avoids the memory allocation and copying, and the resulting
performance penalty.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 3 +
tools/libs/guest/xg_sr_restore.c | 155 ++-
2
This duplicates simple_precopy_policy. To recap its purpose:
- do up to 5 iterations of copying dirty domU memory to target,
including the initial copying of all domU memory, excluding
the final copying while the domU is suspended
- do fewer iterations in case the domU dirtied less than 50 page
Migrating a large, and potentially busy, domU will take more
time than neccessary due to excessive number of copying iterations.
Allow to host admin to control the number of iterations which
copy cumulated domU dirty pages to the target host.
The default remains 5, which means one initial iterati
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in an incoming batch.
Allocate the space once.
Use some prefix to avoid conflict with an array used in handle_page_data.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h
flight 163640 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Upcoming changes will pass more knobs down to xc_domain_save.
Adjust the libxl_domain_suspend API to allow easy adding of additional knobs.
No change in behavior intented.
Signed-off-by: Olaf Hering
Acked-by: Christian Lindig
---
tools/include/libxl.h| 26 ++
Provide a knob to the host admin to abort the live migration of a
running domU if the downtime during final transit will be too long
for the workload within domU.
Adjust error reporting. Add ERROR_MIGRATION_ABORTED to allow callers of
libxl_domain_suspend to distinguish between errors and the requ
handle_page_data must be able to read directly into mapped guest memory.
This will avoid unneccesary memcpy calls for data that can be consumed verbatim.
Split the various steps of record processing:
- move processing to handle_buffered_page_data
- adjust xenforeignmemory_map to set errno in case
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in an incoming batch.
Allocate the space once.
Adjust the verification for page count. It must be at least one page,
but not more than MAX_BATCH_SIZE.
Signed-off-by: Olaf Hering
---
too
This is required by upcoming API changes.
Signed-off-by: Olaf Hering
---
tools/include/libxl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index ae7fe27c1f..29931626a2 100644
--- a/tools/include/libxl.h
+++ b/tools/include/l
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in an incoming batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 22 +++---
2 fil
handle_page_data must be able to read directly into mapped guest memory.
This will avoid unneccesary memcpy calls for data which can be consumed
verbatim.
Rearrange the code to allow decisions based on the incoming record.
This change is preparation for future changes in handle_page_data,
no cha
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch.
Allocate the space once.
Because this was allocated with calloc:
Adjust the loop to clear unused entries as needed.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_com
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in an incoming batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 22 +++---
2 fil
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_save.c | 34 -
2 file
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in an incoming batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_restore.c | 16
2 files cha
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_save.c | 28 +++-
2 files cha
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch.
Allocate the space once.
Adjust the code to use the unmodified src page in case of HVM.
In case of PV the page may need to be normalised, use a private memory
area for this pur
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_save.c | 28 +---
2 files cha
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_save.c | 20 ++--
2 files changed, 11
xl migrate --debug used to track every pfn in every batch of pages.
But these times are gone. The code in xc_domain_save is the consumer
of this knob, now may enable verification mode.
Signed-off-by: Olaf Hering
---
v03:
- adjust to describe what --debug would do when the code which
consumes th
Remove repeated allocation from migration loop. There will never be
more than MAX_BATCH_SIZE pages to process in a batch, see add_to_batch.
Allocate the space once.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 1 +
tools/libs/guest/xg_sr_save.c | 25 +--
Read a batch of iovec's.
Short reads are the common case, finish the trailing iov with read_exact.
Signed-off-by: Olaf Hering
---
v2:
- add comment to short-read handling
---
tools/libs/ctrl/xc_private.c | 57 +++-
tools/libs/ctrl/xc_private.h | 1 +
2 files cha
Show how fast domU pages are transferred in each iteration.
The relevant data is how fast the pfns travel, not so much how much
protocol overhead exists. So the reported MiB/sec is just for pfns.
Signed-off-by: Olaf Hering
---
v02:
- rearrange MiB_sec calculation (jgross)
---
tools/libs/guest/x
A hard to trigger race with another unrelated systemd service and
xenstored.service unveiled a bug in the way how xenstored is launched
with systemd.
launch-xenstore may start either a daemon or a domain. In case a domain
is used, systemd-notify was called. If another service triggered a
restart o
Various unreviewed changes, rebase to 3a98c1a4ce.
Olaf Hering (31):
tools: fix make rpmball
hotplug/Linux: fix starting of xenstored with restarting systemd
tools: add API to work with sevaral bits at once
xl: fix description of migrate --debug
tools: add readv_exact to libxenctrl
tool
Commit 438c5ffa44e99cceb574c0f9946aacacdedd2952 ("rpmball: Adjust to
new rpm, do not require --force") attempted to handle stricter
directory permissions in newer distributions.
This introduced a few issues:
- /boot used to be a constant prior commit
6475d700055fa952f7671cee982a23de2f5e4a7c ("us
Introduce new API to test if a fixed number of bits is clear or set,
and clear or set them all at once.
The caller has to make sure the input bitnumber is a multiple of BITS_PER_LONG.
This API avoids the loop over each bit in a known range just to see
if all of them are either clear or set.
Sign
Am Mon, 5 Jul 2021 14:01:07 +0100
schrieb Andrew Cooper :
> > Unfortunately, I'm not able to prove the reported gain with the systems I
> > have today.
> > I'm waiting for preparation of different hardware, right now I have only a
> > pair of CoyotePass and WilsonCity.
> >
> > I'm sure there wer
Hi,
On 13/07/2021 17:27, Jan Beulich wrote:
On 13.07.2021 18:15, Julien Grall wrote:
On 13/07/2021 16:52, Jan Beulich wrote:
On 13.07.2021 16:33, Julien Grall wrote:
On 13/07/2021 15:23, Jan Beulich wrote:
On 13.07.2021 16:19, Julien Grall wrote:
On 13/07/2021 15:14, Jan Beulich wrote:
And
On 13.07.2021 18:15, Julien Grall wrote:
> On 13/07/2021 16:52, Jan Beulich wrote:
>> On 13.07.2021 16:33, Julien Grall wrote:
>>> On 13/07/2021 15:23, Jan Beulich wrote:
On 13.07.2021 16:19, Julien Grall wrote:
> On 13/07/2021 15:14, Jan Beulich wrote:
>>> And I don't think it should
Hi Jan,
On 13/07/2021 16:52, Jan Beulich wrote:
On 13.07.2021 16:33, Julien Grall wrote:
On 13/07/2021 15:23, Jan Beulich wrote:
On 13.07.2021 16:19, Julien Grall wrote:
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that
On 13.07.2021 16:33, Julien Grall wrote:
> On 13/07/2021 15:23, Jan Beulich wrote:
>> On 13.07.2021 16:19, Julien Grall wrote:
>>> On 13/07/2021 15:14, Jan Beulich wrote:
> And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at le
On 13.07.2021 16:58, Anthony PERARD wrote:
> On Tue, Jul 13, 2021 at 09:51:45AM +0200, Jan Beulich wrote:
>> On 12.07.2021 18:32, Anthony PERARD wrote:
>>> On Wed, Jul 07, 2021 at 05:48:57PM +0200, Jan Beulich wrote:
On 01.07.2021 16:09, Anthony PERARD wrote:
> --- a/xen/common/Makefile
>>
On 13.07.21 17:15, Julien Grall wrote:
Hi Juergen,
On 13/07/2021 16:09, Juergen Gross wrote:
On 13.07.21 16:38, Julien Grall wrote:
Hi Juergen,
On 13/07/2021 15:23, Juergen Gross wrote:
On 13.07.21 16:19, Julien Grall wrote:
Hi Jan,
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think
Hi Juergen,
On 13/07/2021 16:09, Juergen Gross wrote:
On 13.07.21 16:38, Julien Grall wrote:
Hi Juergen,
On 13/07/2021 15:23, Juergen Gross wrote:
On 13.07.21 16:19, Julien Grall wrote:
Hi Jan,
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rathe
On 13.07.21 16:38, Julien Grall wrote:
Hi Juergen,
On 13/07/2021 15:23, Juergen Gross wrote:
On 13.07.21 16:19, Julien Grall wrote:
Hi Jan,
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at
On Tue, Jul 13, 2021 at 09:51:45AM +0200, Jan Beulich wrote:
> On 12.07.2021 18:32, Anthony PERARD wrote:
> > On Wed, Jul 07, 2021 at 05:48:57PM +0200, Jan Beulich wrote:
> >> On 01.07.2021 16:09, Anthony PERARD wrote:
> >>> --- a/xen/common/Makefile
> >>> +++ b/xen/common/Makefile
> >>> @@ -80,8 +
Hi Juergen,
On 13/07/2021 15:23, Juergen Gross wrote:
On 13.07.21 16:19, Julien Grall wrote:
Hi Jan,
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at least in principle. There
shouldn't
be
flight 163632 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163632/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 16 xen-boot/l1 fail REGR. vs. 163458
Tests which are fa
On Tue, Jul 13, 2021 at 09:41:03AM +0200, Jan Beulich wrote:
> On 12.07.2021 17:22, Anthony PERARD wrote:
> > On Wed, Jul 07, 2021 at 05:26:13PM +0200, Jan Beulich wrote:
> >> On 01.07.2021 16:09, Anthony PERARD wrote:
> >>> --- a/xen/test/Makefile
> >>> +++ b/xen/test/Makefile
> >>> @@ -4,15 +4,10
On 13/07/2021 15:23, Jan Beulich wrote:
On 13.07.2021 16:19, Julien Grall wrote:
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at least in principle. There shouldn't
be a build time setting
On 13.07.21 16:28, Jan Beulich wrote:
On 13.07.2021 16:23, Juergen Gross wrote:
On 13.07.21 16:19, Julien Grall wrote:
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at least in principle. The
On 13.07.2021 16:23, Juergen Gross wrote:
> On 13.07.21 16:19, Julien Grall wrote:
>> On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
>>>
>>> Even that doesn't seem right to me, at least in principle. There
>>> shouldn't
>>> be a
On 13.07.21 16:19, Julien Grall wrote:
Hi Jan,
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at least in principle. There
shouldn't
be a build time setting when it may vary at runtime. IOW o
On 13.07.2021 16:19, Julien Grall wrote:
> On 13/07/2021 15:14, Jan Beulich wrote:
>>> And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
>>
>> Even that doesn't seem right to me, at least in principle. There shouldn't
>> be a build time setting when it may vary at runtime. IOW
Hi Jan,
On 13/07/2021 15:14, Jan Beulich wrote:
And I don't think it should be named XC_PAGE_*, but rather XEN_PAGE_*.
Even that doesn't seem right to me, at least in principle. There shouldn't
be a build time setting when it may vary at runtime. IOW on Arm I think a
runtime query to the hyper
On 13.07.2021 16:00, Juergen Gross wrote:
> On 13.07.21 15:46, Costin Lupu wrote:
>> Hi guys,
>>
>> On 7/13/21 4:00 PM, Julien Grall wrote:
>>>
>>>
>>> On 13/07/2021 13:39, Andrew Cooper wrote:
On 13/07/2021 12:53, Julien Grall wrote:
> Hi Andrew,
>
> On 13/07/2021 12:23, Andrew Co
On 13.07.21 15:46, Costin Lupu wrote:
Hi guys,
On 7/13/21 4:00 PM, Julien Grall wrote:
On 13/07/2021 13:39, Andrew Cooper wrote:
On 13/07/2021 12:53, Julien Grall wrote:
Hi Andrew,
On 13/07/2021 12:23, Andrew Cooper wrote:
On 13/07/2021 12:21, Julien Grall wrote:
Hi Andrew,
On 13/07/202
flight 163638 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163638/
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. 162359
test-amd64-amd64-xl-qemuu
Hi guys,
On 7/13/21 4:00 PM, Julien Grall wrote:
>
>
> On 13/07/2021 13:39, Andrew Cooper wrote:
>> On 13/07/2021 12:53, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 13/07/2021 12:23, Andrew Cooper wrote:
On 13/07/2021 12:21, Julien Grall wrote:
> Hi Andrew,
>
> On 13/07/2021 1
flight 163641 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163474
Tests which
On 13/07/2021 13:39, Andrew Cooper wrote:
On 13/07/2021 12:53, Julien Grall wrote:
Hi Andrew,
On 13/07/2021 12:23, Andrew Cooper wrote:
On 13/07/2021 12:21, Julien Grall wrote:
Hi Andrew,
On 13/07/2021 10:35, Andrew Cooper wrote:
On 13/07/2021 10:27, Juergen Gross wrote:
On 13.07.21 11:
On 13/07/2021 12:53, Julien Grall wrote:
> Hi Andrew,
>
> On 13/07/2021 12:23, Andrew Cooper wrote:
>> On 13/07/2021 12:21, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 13/07/2021 10:35, Andrew Cooper wrote:
On 13/07/2021 10:27, Juergen Gross wrote:
> On 13.07.21 11:20, Julien Grall wrote
Hi Andrew,
On 13/07/2021 12:23, Andrew Cooper wrote:
On 13/07/2021 12:21, Julien Grall wrote:
Hi Andrew,
On 13/07/2021 10:35, Andrew Cooper wrote:
On 13/07/2021 10:27, Juergen Gross wrote:
On 13.07.21 11:20, Julien Grall wrote:
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of x
Hi Jan,
First of all sorry for breaking the stubdom build. Please see inline.
On 7/13/21 9:47 AM, Jan Beulich wrote:
> On 08.06.2021 14:35, Costin Lupu wrote:
>> --- a/tools/libs/foreignmemory/private.h
>> +++ b/tools/libs/foreignmemory/private.h
>> @@ -1,6 +1,7 @@
>> #ifndef XENFOREIGNMEMORY_PR
On 13/07/2021 12:21, Julien Grall wrote:
> Hi Andrew,
>
> On 13/07/2021 10:35, Andrew Cooper wrote:
>> On 13/07/2021 10:27, Juergen Gross wrote:
>>> On 13.07.21 11:20, Julien Grall wrote:
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
w
Hi Andrew,
On 13/07/2021 10:35, Andrew Cooper wrote:
On 13/07/2021 10:27, Juergen Gross wrote:
On 13.07.21 11:20, Julien Grall wrote:
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
wreck the build in an interesting way:
In file included from xen/stu
flight 163621 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321
test-amd64-amd64-
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年7月13日 18:21
> To: Julien Grall ; Wei Chen
> Cc: Penny Zheng ; Bertrand Marquis
> ; xen-de...@lists.xen.org; Roger Pau Monné
> ; Stefano Stabellini ;
> Andrew Cooper
> Subject: Re: DMA restriction and NUMA node number
>
> On 1
On 13.07.21 11:31, Julien Grall wrote:
On 13/07/2021 10:27, Juergen Gross wrote:
On 13.07.21 11:20, Julien Grall wrote:
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
wreck the build in an interesting way:
In file included from xen/stubdom/include/
On 13.07.2021 11:26, Julien Grall wrote:
> On 13/07/2021 04:19, Wei Chen wrote:
>> I am doing some NUMA testing on Xen. And I find the DMA restriction is
>> based on NUMA node number [1].
>> if ( !dma_bitsize && (num_online_nodes() > 1) )
>> dma_bitsize = arch_get_dma_bitsize();
>>
>>
flight 163620 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 13/07/2021 10:27, Juergen Gross wrote:
> On 13.07.21 11:20, Julien Grall wrote:
>> From: Julien Grall
>>
>> Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
>> wreck the build in an interesting way:
>>
>> In file included from xen/stubdom/include/xen/domctl.h:39:0,
>>
On 13/07/2021 10:27, Juergen Gross wrote:
On 13.07.21 11:20, Julien Grall wrote:
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
wreck the build in an interesting way:
In file included from xen/stubdom/include/xen/domctl.h:39:0,
fr
On 13.07.21 11:20, Julien Grall wrote:
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
wreck the build in an interesting way:
In file included from xen/stubdom/include/xen/domctl.h:39:0,
from xen/tools/include/xenctrl.h:36,
(+Andrew, Jan, Roger)
On 13/07/2021 04:19, Wei Chen wrote:
Hi,
I am doing some NUMA testing on Xen. And I find the DMA restriction is
based on NUMA node number [1].
if ( !dma_bitsize && (num_online_nodes() > 1) )
dma_bitsize = arch_get_dma_bitsize();
On Arm64, we will set dma_bit
flight 163634 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163474
Tests which
On 13/07/2021 10:20, Julien Grall wrote:
> From: Julien Grall
>
> Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
> wreck the build in an interesting way:
>
> In file included from xen/stubdom/include/xen/domctl.h:39:0,
> from xen/tools/include/xenctrl.h:36,
From: Julien Grall
Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
wreck the build in an interesting way:
In file included from xen/stubdom/include/xen/domctl.h:39:0,
from xen/tools/include/xenctrl.h:36,
from private.h:4,
f
On 13.07.2021 10:36, Andrew Cooper wrote:
> On 13/07/2021 07:28, Jan Beulich wrote:
>> On 13.07.2021 01:48, Andrew Cooper wrote:
>>> On 12/07/2021 21:32, Daniel P. Smith wrote:
diff --git a/xen/include/xen/alternative-call.h
b/xen/include/xen/alternative-call.h
new file mode 100644
flight 163630 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163630/
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
1 - 100 of 113 matches
Mail list logo
