flight 146923 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
test-amd64-i386-xl
flight 146994 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146994/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
flight 146986 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
flight 146915 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146915/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 139698
test-amd64-amd64-qemu
flight 146910 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146910/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 142947
test-amd64-amd64-qemu
flight 146919 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146919/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
version targeted for test
flight 146980 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
libvirt.git commit 2621d48f00 removed the last traces of gnulib, which
also removed the '--no-git' option from autogen.sh. Unknown options are
now passed to the configure script, which quickly fails with
configure: error: unrecognized option: `--no-git'
Remove the gnulib handling from ts-libvir
flight 146905 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
142849
test-armhf-a
flight 146976 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146976/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
On Wed, Feb 12, 2020 at 05:49:47PM +0100, Roger Pau Monne wrote:
> Unify the two adjacent header includes that are both gated with ifndef
> __ASSEMBLY__.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
___
On Wed, Feb 12, 2020 at 06:09:24PM +0100, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 04:09:17PM +, Wei Liu wrote:
> > Implement a basic hook for L0 assisted TLB flush. The hook needs to
> > check if prerequisites are met. If they are not met, it returns an error
> > number to fall back to
Save/restore xen_sched_clock_offset in syscore suspend/resume during PM
hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface
for xen")' fixes xen guest time handling during migration. A similar issue
is seen during PM hibernation when system runs CPU intensive workload.
Post
From: Aleksei Besogonov
The SNAPSHOT_SET_SWAP_AREA is supposed to be used to set the hibernation
offset on a running kernel to enable hibernating to a swap file.
However, it doesn't actually update the swsusp_resume_block variable. As
a result, the hibernation fails at the last step (after all th
From: Munehisa Kamata
Currently, steal time accounting code in scheduler expects steal clock
callback to provide monotonically increasing value. If the accounting
code receives a smaller value than previous one, it uses a negative
value to calculate steal time and results in incorrectly updated i
Introduce wrappers for save/restore xen_sched_clock_offset to be
used by PM hibernation code to avoid system instability during resume.
Signed-off-by: Anchal Agarwal
---
Changes since V2:
* Dropped marking tsc unstable during hibernation patch
* Fixed issue with xen_sched_clock_offset during sus
There are no pm handlers for the legacy devices, so during tear down
stale event channel <> IRQ mapping may still remain in the image and
resume may fail. To avoid adding much code by implementing handlers for
legacy devices, add a new irq_chip flag IRQCHIP_SHUTDOWN_ON_SUSPEND which
when enabled on
From: Munehisa Kamata
Save steal clock values of all present CPUs in the system core ops
suspend callbacks. Also, restore a boot CPU's steal clock in the system
core resume callback. For non-boot CPUs, restore after they're brought
up, because runstate info for non-boot CPUs are not active until
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
events, need to implement these xenbus_driver callbacks.
The freeze handler stops a block-layer queue and disconnect the
frontend f
Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.
Signed-off-by: Anchal
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. The freeze handler simply disconnects the frotnend from the
backend and frees resources associated with queues after disabling the
net_device from the system. The restore handler just changes the
From: Munehisa Kamata
Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
From: Munehisa Kamata
Guest hibernation is different from xen suspend/resume/live migration.
Xen save/restore does not use pm_ops as is needed by guest hibernation.
Hibernation in guest follows ACPI path and is guest inititated , the
hibernation image is saved within guest as compared to later mo
Hello,
I am sending out a v3 version of series of patches that implements guest
PM hibernation.
These guests are running on xen hypervisor. The patches had been tested
against mainstream kernel. EC2 instance hibernation feature is provided
to the AWS EC2 customers. PM hibernation uses swap space ca
flight 146921 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146921/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
flight 146922 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146922/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 12/02/2020 22:36, Stefano Stabellini wrote:
On Wed, 12 Feb 2020, Andrei Cherechesu wrote:
(XEN) DOM1: [ 3.883482] sdhci: Secure Digital Host Controller Interface
driver
(XEN) DOM1: [ 3.891021] sdhci: Copyright(c) Pierre Ossman
(XEN) DOM1: [ 3.896389] sdhci-pltfm: SDHCI platform an
flight 146973 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146973/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
On Wed, 12 Feb 2020, Andrei Cherechesu wrote:
> Hello,
>
>
> I applied your direct-map patch, Stefano, on top of RELEASE-4.13.0
> Xen.
FYI I am working on a direct-map patch series but it is still
work-in-progress:
http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git
d
On 12/02/2020 17:49, Roger Pau Monne wrote:
Hello,
Hi Roger,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible
There is a more subtle problem introduced by this patch. I thought I
would mention it here just in case this affect
flight 146968 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146968/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
flight 146904 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146904/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 133580
test-amd64-amd64-xl
flight 146963 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
On Wed, Feb 12, 2020 at 04:09:18PM +, Wei Liu wrote:
> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> of several hypercalls:
>
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> * HVCALL_FLUSH_VI
On 12/02/2020 18:01, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote:
>> On 12/02/2020 17:49, Roger Pau Monne wrote:
>>> Hello,
>>>
>>> Commit:
>>>
>>> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
>>> x86/smp: use APIC ALLBUT destination shorthand when possib
On Wed, Feb 12, 2020 at 04:09:17PM +, Wei Liu wrote:
> Implement a basic hook for L0 assisted TLB flush. The hook needs to
> check if prerequisites are met. If they are not met, it returns an error
> number to fall back to native flushes.
>
> Introduce a new variable to indicate if hypercall p
On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote:
> On 12/02/2020 17:49, Roger Pau Monne wrote:
> > Hello,
> >
> > Commit:
> >
> > 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
> > x86/smp: use APIC ALLBUT destination shorthand when possible
> >
> > Introduced a bogus usage of the s
On Wed, Feb 12, 2020 at 04:09:16PM +, Wei Liu wrote:
> Hyper-V's L0 assisted flush has fine-grained control over what gets
> flushed. We need all the flags available to make the best decisions
> possible.
>
> No functional change because Xen's implementation doesn't care about
> what is passed
On 12/02/2020 17:49, Roger Pau Monne wrote:
> Hello,
>
> Commit:
>
> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
> x86/smp: use APIC ALLBUT destination shorthand when possible
>
> Introduced a bogus usage of the scratch cpumask: it was used in a
> function that could be called from interrupt contex
On Wed, Feb 12, 2020 at 04:09:15PM +, Wei Liu wrote:
> Change hv_vp_index to use uint32_t because that is what is defined in TLFS.
>
> Add "_addr" suffix to hv_do_rep_hypercall's parameters.
Being of type paddr_t I'm unsure the _addr suffix adds any value to
the name.
>
> Signed-off-by: Wei
Using scratch_cpumask in send_IPI_mak is not safe because it can be
called from interrupt context, and hence Xen would have to make sure
all the users of the scratch cpumask disable interrupts while using
it.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while
Unify the two adjacent header includes that are both gated with ifndef
__ASSEMBLY__.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/include/asm-x86/smp.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x8
Hello,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible
Introduced a bogus usage of the scratch cpumask: it was used in a
function that could be called from interrupt context, and hence using
the scratch cpumask there is not safe. Patc
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced:
Change hv_vp_index to use uint32_t because that is what is defined in TLFS.
Add "_addr" suffix to hv_do_rep_hypercall's parameters.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 2 +-
xen/arch/x86/guest/hyperv/private.h | 2 +-
xen/include/asm-x86/guest/hyperv-hcall
Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.
Introduce a new variable to indicate if hypercall page is ready.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hype
Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
of several hypercalls:
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
Pick the most efficient hypercalls available.
Hi all
This seris is based on Roger's L0 assisted flush series.
I have done some testing against a Linux on Hyper-V in a 32-vcpu VM.
All builds were done with -j32.
Building Xen on Linux:
real0m45.376s
user2m28.156s
sys 0m51.672s
Building Xen on Linux on Xen on Hyper-V, no assiste
Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.
No functional change because Xen's implementation doesn't care about
what is passed to it.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hypervisor.c
On 12/02/2020 09:32, Jan Beulich wrote:
> On 11.02.2020 14:42, Sergey Dyasli wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -228,6 +228,14 @@ choice
>> bool "SILO" if XSM_SILO
>> endchoice
>>
>> +config XSM_DENIED_STRING
>> +string "xen_version hypercall deni
flight 146950 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
Am Wed, 12 Feb 2020 11:53:25 +0100
schrieb Olaf Hering :
> Is there a formula to calculate that amount of extra memory, is this behavior
> documented somewhere?
With the script below, the formula may look like this:
- each vcpu needs 1MB extra memory
- each GB of a HVM domU memory needs 8MB ext
[[ Sorry. Needed to send another mail because I forgot to add xen-devel lists
to CC. ]]
Hello,
I applied your direct-map patch, Stefano, on top of RELEASE-4.13.0
Xen.
I also took your advice and used the Imagebuilder tool to setup my
u-boot environment. I modified the tool to allow SDCard booti
flight 146935 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
We want to actually resize ram blocks (make everything between
used_length and max_length inaccessible) - however, not all ram block
notifiers will support that. Let's teach the notifier that ram blocks
are indeed resizable, but keep using max_size in the existing notifiers.
Supply the max_size wh
flight 146901 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail REGR. vs. 142932
Tests which did not
On 12.02.20 12:21, Sergey Dyasli wrote:
Hi Juergen,
Recently our testing has found a host crash which is reproducible.
Do you have any idea what might be going on here?
Oh, nice catch!
The problem is that get_cpu_idle_time() is calling vcpu_runstate_get()
for an idle vcpu. This is fragile as
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu
flight 146896 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146896/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 146796
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Juergen,
Recently our testing has found a host crash which is reproducible.
Do you have any idea what might be going on here?
(XEN) [175654.165126] Assertion 'lock ==
get_sched_res(i->res->master_cpu)->schedule_lock' failed at
...ild/BUILD/xen-4.13.1/xen/include/xen/sched-if.h:269
(XEN) [175
flight 146928 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
I was made aware of the fact that Xen apparently loses memory as soon as domUs
are started. In my testing HVM domUs occupy much more memory than what was
configured for them. The expected memory footprint for a PV domU seems to match
the value in the domU config file.
My test host has 128GB and
flight 146931 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146931/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
baseline version:
xen f7fb
Hello,
I am trying to debug an issue in QubesOS where a domain created by
libvirt often does not have information stored about the console TTY path.
The relevant part of libvirt creates a domain using
libxl_domain_create_new() and registers a callback (aop_console_how)
that is supposed to fire wh
On 11.02.2020 10:31, Juergen Gross wrote:
> One of the main design goals of core scheduling is to avoid actions
> which are not directly related to the domain currently running on a
> given cpu or core. Live patching is one of those actions which are
> allowed taking place on a cpu only when the id
On 11.02.2020 15:55, Andrew Cooper wrote:
> These were introduced in 262bb227a4 in 2012, and have never had any users.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenp
On 11.02.2020 15:08, Andrew Cooper wrote:
> The printf() in init_hypercalls() only ends up in the hypervisor console log,
> so extraversion really isn't interesting.
>
> The SMBios table doesn't need extraversion, and removing it reduces the
> ability for a guest to fingerprint the exact hyperviso
On 11.02.2020 14:56, Andrew Cooper wrote:
> On 11/02/2020 13:42, Sergey Dyasli wrote:
>> Add Kconfig option to make it possible to configure the string returned
>> to non-privileged guests instead of the default "" which could
>> propagate to UI / logs after the subsequent patch that hides detailed
On 11.02.2020 14:42, Sergey Dyasli wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -228,6 +228,14 @@ choice
> bool "SILO" if XSM_SILO
> endchoice
>
> +config XSM_DENIED_STRING
> + string "xen_version hypercall denied information replacement string"
> + def
On 11.02.2020 12:27, Andrew Cooper wrote:
> Conform to style, drop unnecessary local variables, and avoid opencoding
> clear_domain_page().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproje
On Wed, Feb 12, 2020 at 09:46:22AM +0100, Sander Eikelenboom wrote:
> On 11/02/2020 15:00, Roger Pau Monné wrote:
> > Thanks, I have another patch for you to try, which will likely make
> > your system crash. Could you give it a try and paste the log output?
> >
> > Thanks, Roger.
>
> Applied the
On 11/02/2020 15:00, Roger Pau Monné wrote:
> On Mon, Feb 10, 2020 at 09:49:30PM +0100, Sander Eikelenboom wrote:
>> On 03/02/2020 14:21, Roger Pau Monné wrote:
>>> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
On 03/02/2020 13:41, Roger Pau Monné wrote:
> On Mon, Feb
On 11.02.2020 18:16, Andrew Cooper wrote:
> On 11/02/2020 16:59, Jan Beulich wrote:
>> On 11.02.2020 17:31, Roger Pau Monné wrote:
>>> On Tue, Feb 11, 2020 at 03:51:54PM +, Andrew Cooper wrote:
Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
configured with
flight 146925 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
75 matches
Mail list logo
