flight 165976 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165976/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165965
test-armhf-armhf-libvirt 16
flight 165975 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/include/asm/xen/hypercall.h
between commits:
f4afb713e5c3 ("x86/xen: Make get_debugreg() noinstr")
7361fac0465b ("x86/xen: Make set_debugreg() noinstr")
from Linus' tree and commit:
321d124f13fd ("xen:
flight 165973 xen-unstable real [real]
flight 165977 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165973/
http://logs.test-lab.xenproject.org/osstest/logs/165977/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Mon, Nov 01, 2021 at 10:47:26AM +, Andrew Cooper wrote:
> Hello,
>
> On ARM, the GIC is a hard prerequisite for VMs.
>
> I can't remember what the state of RISCV is, but IIRC there is still
> some debate over how interrupts are expected to work under virt.
>
Yes sir, that addition to
On Fri, 29 Oct 2021, Juergen Gross wrote:
> On 28.10.21 18:41, Stefano Stabellini wrote:
> > On Thu, 28 Oct 2021, Juergen Gross wrote:
> > > On 28.10.21 01:24, Stefano Stabellini wrote:
> > > > On Wed, 27 Oct 2021, Stefano Stabellini wrote:
> > > > > On Wed, 27 Oct 2021, Juergen Gross wrote:
> > >
From: Peter Xu
They're actually more commonly used than the helper without _under_bus, because
most callers do have the pci bus on hand. After exporting we can switch a lot
of the call sites to use these two helpers.
Reviewed-by: David Hildenbrand
Reviewed-by: Eric Auger
Signed-off-by: Peter
flight 165974 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 165965
build-i386-pvops
From: David Hildenbrand
Let's use QEMU_ALIGN_DOWN() and friends to make the code a bit easier to
read.
Reviewed-by: Peter Xu
Signed-off-by: David Hildenbrand
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
migration/migration.c| 6 +++---
From: Hyman Huang(黄勇)
introduce dirty-bitmap mode as the third method of calc-dirty-rate.
implement dirty-bitmap dirtyrate calculation, which can be used
to measuring dirtyrate in the absence of dirty-ring.
introduce "dirty_bitmap:-b" option in hmp calc_dirty_rate to
indicate dirty bitmap
From: David Hildenbrand
Let's factor out prefaulting/populating to make further changes easier to
review and add a comment what we are actually expecting to happen. While at
it, use the actual page size of the ramblock, which defaults to
qemu_real_host_page_size for anonymous memory. Further,
From: David Hildenbrand
We don't want to migrate memory that corresponds to discarded ranges as
managed by a RamDiscardManager responsible for the mapped memory region of
the RAMBlock. The content of these pages is essentially stale and
without any guarantees for the VM ("logically unplugged").
From: David Hildenbrand
We already don't ever migrate memory that corresponds to discarded ranges
as managed by a RamDiscardManager responsible for the mapped memory region
of the RAMBlock.
virtio-mem uses this mechanism to logically unplug parts of a RAMBlock.
Right now, we still populate
From: David Hildenbrand
Implement it similar to the replay_populated callback.
Acked-by: Peter Xu
Signed-off-by: David Hildenbrand
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
hw/virtio/virtio-mem.c | 58 ++
1 file changed, 58
From: Peter Xu
Both dump-guest-memory and live migration caches vm state at the beginning.
Either of them entering the other one will cause race on the vm state, and even
more severe on that (please refer to the crash report in the bug link).
Let's block live migration in dump-guest-memory, and
From: Hyman Huang(黄勇)
introduce global var total_dirty_pages to stat dirty pages
along with memory_global_dirty_log_sync.
Signed-off-by: Hyman Huang(黄勇)
Reviewed-by: Peter Xu
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
include/exec/ram_addr.h | 9 +
From: Peter Xu
An internal version that removes -only-migratable implications. It can be used
for temporary migration blockers like dump-guest-memory.
Reviewed-by: Marc-André Lureau
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
Signed-off-by: Juan Quintela
---
From: Hyman Huang(黄勇)
use dirty ring feature to implement dirtyrate calculation.
introduce mode option in qmp calc_dirty_rate to specify what
method should be used when calculating dirtyrate, either
page-sampling or dirty-ring should be passed.
introduce "dirty_ring:-r" option in hmp
From: Hyman Huang(黄勇)
since main thread may "query dirty rate" at any time, it's better
to move init step into main thead so that synchronization overhead
between "main" and "get_dirtyrate" can be reduced.
Signed-off-by: Hyman Huang(黄勇)
Message-Id:
From: Hyman Huang(黄勇)
registering get_dirtyrate thread in advance so that both
page-sampling and dirty-ring mode can be covered.
Signed-off-by: Hyman Huang(黄勇)
Message-Id:
Reviewed-by: Peter Xu
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
migration/dirtyrate.c | 5
From: David Hildenbrand
Currently, when someone (i.e., the VM) accesses discarded parts inside a
RAMBlock with a RamDiscardManager managing the corresponding mapped memory
region, postcopy will request migration of the corresponding page from the
source. The source, however, will never answer,
From: David Hildenbrand
Migration code now properly handles RAMBlocks which are indirectly managed
by a RamDiscardManager. No need for manual handling via the free page
optimization interface, let's get rid of it.
Acked-by: Michael S. Tsirkin
Acked-by: Peter Xu
Signed-off-by: David
From: Hyman Huang(黄勇)
introduce "DirtyRateMeasureMode" to specify what method should be
used to calculate dirty rate, introduce "DirtyRateVcpu" to store
dirty rate for each vcpu.
use union to store stat data of specific mode
Signed-off-by: Hyman Huang(黄勇)
Message-Id:
From: David Hildenbrand
Introduce replay_discarded callback similar to our existing
replay_populated callback, to be used my migration code to never migrate
discarded memory.
Acked-by: Peter Xu
Signed-off-by: David Hildenbrand
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
From: Hyman Huang(黄勇)
since dirty ring has been introduced, there are two methods
to track dirty pages of vm. it seems that "logging" has
a hint on the method, so rename the global_dirty_log to
global_dirty_tracking would make description more accurate.
dirty rate measurement may start or
From: Peter Xu
save_snapshot() checks migration blocker, which looks sane. At the meantime we
should also teach the blocker add helper to fail if during a snapshot, just
like for migrations.
Reviewed-by: Marc-André Lureau
Signed-off-by: Peter Xu
Reviewed-by: Juan Quintela
Signed-off-by:
From: Hyman Huang(黄勇)
dirty_pages is used to calculate dirtyrate via dirty ring, when
enabled, kvm-reaper will increase the dirty pages after gfns
being dirtied.
kvm_dirty_ring_enabled shows if kvm-reaper is working. dirtyrate
thread could use it to check if measurement can base on dirty
The following changes since commit af531756d25541a1b3b3d9a14e72e7fedd941a2e:
Merge remote-tracking branch 'remotes/philmd/tags/renesas-20211030' into
staging (2021-10-30 11:31:41 -0700)
are available in the Git repository at:
https://github.com/juanquintela/qemu.git
From: Li Zhijian
destination:
../qemu/build/qemu-system-x86_64 -enable-kvm -netdev
tap,id=hn0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device
e1000,netdev=hn0,mac=50:52:54:00:11:22 -boot c -drive
if=none,file=./Fedora-rdma-server-migration.qcow2,id=drive-virtio-disk0 -device
On Mon, 1 Nov 2021, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO
> handlers"):
> > On 28/10/2021 16:54, Ian Jackson wrote:
> > > There are a number of patches that I'm getting CC'd on related to ARM
> > > and vpci (according to the Subject).
On Mon, 1 Nov 2021, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu
> master list with a lock"):
> > In regards to this specific patch and also the conversation about 4.16
> > or 4.17: I think it would be fine to take this patch in 4.16 in its
> >
+Bertrand
On Mon, 1 Nov 2021, Andrew Cooper wrote:
> Hello,
>
> On ARM, the GIC is a hard prerequisite for VMs.
>
> I can't remember what the state of RISCV is, but IIRC there is still
> some debate over how interrupts are expected to work under virt.
>
> On x86, the story is very different.
flight 165972 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 165682
build-i386
On 10/28/21 4:12 AM, Juergen Gross wrote:
Some cleanups, mostly related to no longer supporting 32-bit PV mode.
Juergen Gross (4):
x86/xen: remove 32-bit pv leftovers
xen: allow pv-only hypercalls only with CONFIG_XEN_PV
xen: remove highmem remnants
x86/xen: remove 32-bit
On 10/27/21 9:25 PM, Dongli Zhang wrote:
The sched_clock() can be used very early since
commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
with commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock time from
0"), kdump kernel in Xen HVM guest may panic at very
On 01/11/2021 12:13, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] x86/kexec: Fix crash on transition to a
> 32bit kernel on AMD hardware"):
>> This path is only taken for a 32bit crash kernel. It is not taken for
>> 64bit crash kernels, or they wouldn't work on AMD either, and this is
flight 165971 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165971/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi everyone,
Our next meeting is tomorrow at 1500 UTC.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/fsdoZMp0ZKERXS-2-VwTPzJ0/. Please add
or edit any items to this agenda. Alternatively, please feel free to email
me directly with agenda items.
Please put your name beside any
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This is beneficial to performance and avoids speculation issues.
With calling the handlers using the correct number of parameters now
it is possible to do the parameter register clobbering
Today the *_op_compat hypercalls call the modern handler functions by
using the entries from the hypercall table. This is resulting in a
not needed indirect function call which can be avoided by using the
correct handler function directly. This is basically a revert of
commit 1252e282311734
The HVM hypercall handler is missing incrementing the per hypercall
counters. Add that.
The counters for PV are handled wrong, as they are not using
perf_incra() with the number of the hypercall as index, but are
incrementing the first hypercall entry (set_trap_table) for each
hypercall. Fix
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This makes the calls of the handlers type safe.
For deprecated hypercalls define stub functions.
Signed-off-by: Juergen Gross
---
V2:
- make hypercall_args[] const (Jan Beulich)
---
The hypercall names need some update.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
tools/misc/xenperf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/misc/xenperf.c b/tools/misc/xenperf.c
index a5fbdaa45f..2ad737e661 100644
--- a/tools/misc/xenperf.c
+++
Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions from that rule,
however.
Get rid of the exceptions by letting compat handlers always return int
and others always return long.
For the compat hvm case use eax instead of rax
Instead of listing each single file with .s or .i suffixes in
.gitignore use pattern based entries. Restrict those to the xen
directory as we have e.g. tools/libs/stat/bindings/swig/xenstat.i in
our tree.
Below xen the pattern based entries are fine, as we have pattern rules
for creating *.s and
The calls_to_multicall performance counter is basically redundant to
the multicall hypercall counter. The only difference is the counting
of continuation calls, which isn't really that interesting.
Drop the calls_to_multicall performance counter.
Suggested-by: Jan Beulich
Signed-off-by: Juergen
Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.
This prepares for generating the handlers' prototypes at build time.
Add a guard in asm/hypercall.h to catch direct inclusion.
Signed-off-by:
When running as pv-shim the hypercall is modified today in order to
replace the functions for __HYPERVISOR_event_channel_op and
__HYPERVISOR_grant_table_op hypercalls.
Change this to call the related functions from the normal handlers
instead when running as shim. The performance implications are
Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.
Some handlers having been static before need to be made globally
visible.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/hypercall.c| 6 +-
Today Arm is using another entry point for the vcpu_op hypercall as
x86, as some of the common sub-ops are not supported on Arm. The Arm
specific handler filetrs out the not supported sub-ops and then calls
the common handler. This leads to the weird call hierarchy:
do_arm_vcpu_op()
hvm_memory_op() should take an unsigned long as cmd, like
do_memory_op().
As hvm_memory_op() is basically just calling do_memory_op() (or
compat_memory_op()) passing through the parameters the cmd parameter
should have no smaller size than that of the called functions.
Signed-off-by: Juergen
In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall handler calls via the function array
by automatically generated call macros.
Another by-product of generating the call macros is
Instead of repeating similar data multiple times use a single source
file and a generator script for producing prototypes and call sequences
of the hypercalls.
As the script already knows the number of parameters used add generating
a macro for populating an array with the number of parameters
Today there is no hypercall with more than 5 parameters, while the ABI
allows up to 6 parameters. Especially for the X86 32-bit case using
6 parameters would require to run without frame pointer, which isn't
very fortunate. Note that for Arm the limit is 5 parameters already.
So limit the maximum
flight 165970 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 165682
build-i386
On Thu, Oct 21, 2021 at 03:44:27PM +0200, Roger Pau Monné wrote:
> On Mon, Oct 18, 2021 at 10:21:28AM +0200, Jan Beulich wrote:
> > On 24.08.2021 23:11, Andrew Cooper wrote:
> > > On 18/08/2021 13:44, Andrew Cooper wrote:
> > >> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
> > >>>
On Thu, Oct 28, 2021 at 12:16:41AM +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
Ian Jackson writes ("Xen 4.16 RC1"):
> Xen 4.16 RC1 is now available.
>
> It is available from git:
> git clone https://xenbits.xenproject.org/git-http/xen.git -b 4.16.0-rc1
>
> For your convenience a tarball is available:
>
>
flight 165966 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165966/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 165953
Xen 4.16 RC1 is now available.
It is available from git:
git clone https://xenbits.xenproject.org/git-http/xen.git -b 4.16.0-rc1
For your convenience a tarball is available:
https://downloads.xenproject.org/release/xen/4.16.0-rc1/xen-4.16.0-rc1.tar.gz
Andrew Cooper writes ("Re: [PATCH] x86/kexec: Fix crash on transition to a
32bit kernel on AMD hardware"):
> This path is only taken for a 32bit crash kernel. It is not taken for
> 64bit crash kernels, or they wouldn't work on AMD either, and this is
> something we test routinely in XenServer.
>
On 01/11/2021 10:53, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] x86/kexec: Fix crash on transition to a 32bit
> kernel on AMD hardware"):
>> The `ljmp *mem` instruction is (famously?) not binary compatible between
>> Intel
>> and AMD CPUS. The AMD-compatible version would require .long
Andrew Cooper writes ("[PATCH] x86/kexec: Fix crash on transition to a 32bit
kernel on AMD hardware"):
> The `ljmp *mem` instruction is (famously?) not binary compatible between Intel
> and AMD CPUS. The AMD-compatible version would require .long to be .quad in
> the second hunk.
>
> Switch to
Hello,
On ARM, the GIC is a hard prerequisite for VMs.
I can't remember what the state of RISCV is, but IIRC there is still
some debate over how interrupts are expected to work under virt.
On x86, the story is very different. PV have no hardware assistance,
while HVM hardware assistance
Roger Pau Monné writes ("Re: [PATCH for-4.16 v4] gnttab: allow setting max
version per-domain"):
> [...]
Roger Pau Monné writes ("Re: [PATCH for-4.16 2/2] xen: Report grant table v1/v2
capabilities to the toolstack"):
> [...]
FTAOD I think these patches are related and I see discussion is
Andrew Cooper writes ("[PATCH for-4.16 1/2] tools/golang: Regenerate bindings"):
> This was missed previously.
>
> Fixes: 1e6706b0d123 ("xen/arm: Introduce gpaddr_bits field to struct
> xen_domctl_getdomaininfo")
> Signed-off-by: Andrew Cooper
Thanks.
Release-Acked-by: Ian Jackson
(but note
Tree status
===
We are now in code freeze.
All patches which have not yet been committed, but which still need to
go into 4.16, need a release ack.
I will be cutting RC1 shortly. Please do not commit anything, even
release-acked patches, until I let you know.
The current planned
Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master
list with a lock"):
> In regards to this specific patch and also the conversation about 4.16
> or 4.17: I think it would be fine to take this patch in 4.16 in its
> current form. Although it is not required because
flight 165969 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165969/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 939c2355daaf94cd7eb2018d15928b9bc471d680
baseline version:
ovmf
Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO
handlers"):
> On 28/10/2021 16:54, Ian Jackson wrote:
> > There are a number of patches that I'm getting CC'd on related to ARM
> > and vpci (according to the Subject). Are these targeted for 4.16 ?
> > Most of them
flight 165968 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165968/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 29 Oct 2021, at 18:38, Andrew Cooper
mailto:andrew.coop...@citrix.com>> wrote:
In order to let the toolstack be able to set the gnttab version on a
per-domain basis, it needs to know which ABIs Xen supports. Introduce
XEN_SYSCTL_PHYSCAP_gnttab_v{1,2} for the purpose, and plumb in down into
>> +if ( rc )
>> +gdprintk(XENLOG_ERR,
>> + "%pp: failed to add BAR handlers for dom%pd: %d\n",
>> + >sbdf, d, rc);
>> +return rc;
>> +}
>> +
>> +int vpci_bar_remove_handlers(const struct domain *d, const struct pci_dev
>> *pdev)
>> +{
>> +/*
flight 165967 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 165682
build-i386
On 30.10.21 01:44, Boris Ostrovsky wrote:
On 10/29/21 6:18 PM, Marek Marczykowski-Górecki wrote:
On Fri, Oct 29, 2021 at 05:46:18PM -0400, Boris Ostrovsky wrote:
On 10/29/21 10:20 AM, Juergen Gross wrote:
--- a/Documentation/ABI/stable/sysfs-devices-system-xen_memory
+++
On 29.10.21 23:46, Boris Ostrovsky wrote:
On 10/29/21 10:20 AM, Juergen Gross wrote:
--- a/Documentation/ABI/stable/sysfs-devices-system-xen_memory
+++ b/Documentation/ABI/stable/sysfs-devices-system-xen_memory
@@ -84,3 +84,13 @@ Description:
Control scrubbing pages before returning
flight 165965 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165965/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165963
test-armhf-armhf-libvirt 16
On 29.10.21 10:33, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote:
>>
>> On 28.10.21 19:03, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 02:23:34PM +, Oleksandr Andrushchenko wrote:
On 28.10.21 16:36, Roger Pau Monné wrote:
>
78 matches
Mail list logo
