flight 165439 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165439/
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
flight 165429 qemu-mainline real [real]
flight 165440 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165429/
http://logs.test-lab.xenproject.org/osstest/logs/165440/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 165437 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165437/
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
On Fri, 8 Oct 2021, Michal Orzel wrote:
> Introduce flag XEN_SYSCTL_PHYSCAP_vpmu which
> indicates whether the platform supports vPMU
> functionality. Modify Xen and tools accordingly.
>
> Take the opportunity and fix XEN_SYSCTL_PHYSCAP_vmtrace
> definition in sysctl.h which wrongly use (1<<6)
>
On Fri, 8 Oct 2021, Michal Orzel wrote:
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps(currently only for ARM).
>
> The current status is that the PMU registers are not
> virtualized and the physical registers are
On Fri, Oct 08, 2021 at 10:19:33AM +0200, Michal Orzel wrote:
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps(currently only for ARM).
>
> The current status is that the PMU registers are not
> virtualized and the
On Fri, Oct 08, 2021 at 10:19:31AM +0200, Michal Orzel wrote:
> Introduce flag XEN_SYSCTL_PHYSCAP_vpmu which
> indicates whether the platform supports vPMU
> functionality. Modify Xen and tools accordingly.
>
> Take the opportunity and fix XEN_SYSCTL_PHYSCAP_vmtrace
> definition in sysctl.h which
Hi tools and libxl Maintainers,
I am writing this email as a summary of the outstanding ARM series
targeting 4.16 that we are aiming to complete by Oct 15.
There has been a lot of traffic on the mailing list and in a few
occasions there has been 1 or 2 tools patches embedded in larger ARM
flight 165428 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165428/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 165408
Tests which did not
On Fri, 8 Oct 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> PCI host bridges are special devices in terms of implementing PCI
> passthrough. According to [1] the current implementation depends on
> Domain-0 to perform the initialization of the relevant PCI host
>
Hi Oleksandr,
I committed patches #1-#5
On Fri, 8 Oct 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hi, all!
>
> This is an assorted series of patches which aim is to make some further
> basis for PCI passthrough on Arm support. The series continues the work
>
On Fri, 8 Oct 2021, Oleksandr wrote:
> On 08.10.21 15:36, Jan Beulich wrote:
> > On 08.10.2021 12:25, Oleksandr wrote:
> > > Just a quick question. What do you think can XEN_DOMCTL_getdomaininfo be
> > > reused to retrieve gpaddr_bits? I don't see why not at the moment, but
> > > maybe there are
On Fri, 8 Oct 2021, Julien Grall wrote:
> On 07/10/2021 23:14, Stefano Stabellini wrote:
> > On Thu, 7 Oct 2021, Volodymyr Babchuk wrote:
> > > Hi Stefano,
> > >
> > > Stefano Stabellini writes:
> > >
> > > > On Wed, 6 Oct 2021, Oleksandr wrote:
> > > > > Hello all
> > > > >
> > > > > Gentle
On Fri, 8 Oct 2021, Julien Grall wrote:
> Hi Andrew,
>
> On Fri, 8 Oct 2021, 20:07 Andrew Cooper, wrote:
> On 06/10/2021 18:40, Rahul Singh wrote:
> > Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
> > Reject the use of this new flag for x86 as VPCI is not
flight 165436 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165436/
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
Hi Andrew,
On Fri, 8 Oct 2021, 20:07 Andrew Cooper, wrote:
> On 06/10/2021 18:40, Rahul Singh wrote:
> > Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
> > Reject the use of this new flag for x86 as VPCI is not supported for
> > DOMU guests for x86.
> >
> > Signed-off-by:
The pull request you sent on Fri, 8 Oct 2021 16:19:11 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.15b-rc5-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3946b46cab8b4714a9274af91772b9ad17a10e12
Thank you!
--
Deet-doot-dot,
On 06/10/2021 18:40, Rahul Singh wrote:
> Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
> Reject the use of this new flag for x86 as VPCI is not supported for
> DOMU guests for x86.
>
> Signed-off-by: Rahul Singh
> Reviewed-by: Stefano Stabellini
> Acked-by: Christian Lindig
On 08/10/2021 11:47, Jan Beulich wrote:
> The conversion of the original code failed to recognize that the 32-bit
> compat variant of this (sorry, two different meanings of "compat" here)
> needs to continue to invoke the compat handler, not the native one.
> Arrange for this and also remove the
flight 165422 linux-linus real [real]
flight 165432 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165422/
http://logs.test-lab.xenproject.org/osstest/logs/165432/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 08/10/2021 14:06, Jan Beulich wrote:
> Like for PV, 32-bit guests need to invoke the compat handler, not the
> native one.
>
> Fixes: db984809d61b ("hvm: wire up domctl and xsm hypercalls")
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
flight 165425 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165425/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5ece2ad36caa7ddc62d4954559b2cdd0d8a40a14
baseline version:
ovmf
flight 165414 linux-5.4 real [real]
flight 165430 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165414/
http://logs.test-lab.xenproject.org/osstest/logs/165430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On 08.10.21 09:44, YueHaibing wrote:
Return NULL instead of passing to ERR_PTR while err is zero,
this fix smatch warnings:
drivers/xen/xen-pciback/conf_space_capability.c:163
pm_ctrl_init() warn: passing zero to 'ERR_PTR'
Fixes: a92336a1176b ("xen/pciback: Drop two backends, squash and
flight 165424 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165424/
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-armhf-libvirt
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.15b-rc5-tag
xen: branch for v5.15-rc5
It contains the following patches:
- a small series to fix two minor issues in the Xen privcmd driver plus
a cleanup patch for that driver
On 08.10.2021 15:38, Luca Fancellu wrote:
>> On 7 Oct 2021, at 08:15, Jan Beulich wrote:
>> On 01.10.2021 17:13, Luca Fancellu wrote:
On 1 Oct 2021, at 15:22, Jan Beulich wrote:
On 01.10.2021 15:55, Luca Fancellu wrote:
>> On 1 Oct 2021, at 12:02, Jan Beulich wrote:
>> On
> On 7 Oct 2021, at 08:15, Jan Beulich wrote:
>
> On 01.10.2021 17:13, Luca Fancellu wrote:
>>
>>
>>> On 1 Oct 2021, at 15:22, Jan Beulich wrote:
>>>
>>> On 01.10.2021 15:55, Luca Fancellu wrote:
> On 1 Oct 2021, at 12:02, Jan Beulich wrote:
> On 30.09.2021 16:28, Luca Fancellu
On 08.10.21 15:36, Jan Beulich wrote:
Hi Jan
On 08.10.2021 12:25, Oleksandr wrote:
Just a quick question. What do you think can XEN_DOMCTL_getdomaininfo be
reused to retrieve gpaddr_bits? I don't see why not at the moment, but
maybe there are some implications/concerns which are invisible
Like for PV, 32-bit guests need to invoke the compat handler, not the
native one.
Fixes: db984809d61b ("hvm: wire up domctl and xsm hypercalls")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -138,7 +138,7 @@ static const struct {
On 08.10.2021 12:25, Oleksandr wrote:
> Just a quick question. What do you think can XEN_DOMCTL_getdomaininfo be
> reused to retrieve gpaddr_bits? I don't see why not at the moment, but
> maybe there are some implications/concerns which are invisible to me.
>
> I see that arch_get_domain_info()
On 08.10.2021 13:09, Anthony PERARD wrote:
> On Tue, Sep 21, 2021 at 05:43:38PM +0200, Jan Beulich wrote:
>> The xen-syms and xen.efi linking steps are serialized only when the
>> intermediate note.o file is necessary. Otherwise both may run in
>> parallel. This in turn means that the compiler /
flight 165409 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165409/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164950
test-amd64-amd64-qemuu-nested-amd
On Tue, Sep 21, 2021 at 05:43:38PM +0200, Jan Beulich wrote:
> The xen-syms and xen.efi linking steps are serialized only when the
> intermediate note.o file is necessary. Otherwise both may run in
> parallel. This in turn means that the compiler / linker invocations to
> create efi/check.o /
The conversion of the original code failed to recognize that the 32-bit
compat variant of this (sorry, two different meanings of "compat" here)
needs to continue to invoke the compat handler, not the native one.
Arrange for this and also remove the one #define that hasn't been
necessary anymore as
On 08.10.21 11:13, Jan Beulich wrote:
Hi Jan
On 07.10.2021 22:23, Stefano Stabellini wrote:
On Thu, 7 Oct 2021, Jan Beulich wrote:
On 07.10.2021 15:12, Oleksandr wrote:
On 07.10.21 15:43, Jan Beulich wrote:
Hi Jan.
On 07.10.2021 14:30, Oleksandr wrote:
On 07.10.21 10:42, Jan Beulich
flight 165408 xen-unstable real [real]
flight 165427 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165408/
http://logs.test-lab.xenproject.org/osstest/logs/165427/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Thanks for pointing this fix Jan. It helped me a lot.
Best!
On Fri, Oct 8, 2021, 10:30 Jan Beulich wrote:
> On 07.10.2021 17:10, Charles Gonçalves wrote:
> > During some experiments in my PhD I've tried to reused a code from
> > Jann Horn (
>
On 07.10.2021 17:10, Charles Gonçalves wrote:
> During some experiments in my PhD I've tried to reused a code from
> Jann Horn (https://bugs.chromium.org/p/project-zero/issues/detail?id=1184
> ) that used the mapping in
>
> ```
> 0x8040 - 0x807f [256GB, 2^38 bytes,
Hi Jan,
On 08.10.2021 10:33, Jan Beulich wrote:
> On 08.10.2021 10:19, Michal Orzel wrote:
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
>> @@ -100,10 +100,12 @@ struct xen_sysctl_tbuf_op {
>> #define _XEN_SYSCTL_PHYSCAP_iommu_hap_pt_share 5
>> #define
On 08.10.2021 10:19, Michal Orzel wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -100,10 +100,12 @@ struct xen_sysctl_tbuf_op {
> #define _XEN_SYSCTL_PHYSCAP_iommu_hap_pt_share 5
> #define XEN_SYSCTL_PHYSCAP_iommu_hap_pt_share \
> (1u <<
Hi Michal,
> On 8 Oct 2021, at 09:19, Michal Orzel wrote:
>
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps(currently only for ARM).
>
> The current status is that the PMU registers are not
> virtualized and the
Hi Michal,
> On 8 Oct 2021, at 09:19, Michal Orzel wrote:
>
> ID_AA64DFR0_EL1/ID_DFR0_EL1 registers provide
> information about PMU support. Replace structure
> dbg64/dbg32 with a union and fill in all the
> register fields according to document:
> ARM Architecture Registers(DDI 0595, 2021-06).
Hi Michal
> On 8 Oct 2021, at 09:19, Michal Orzel wrote:
>
> Introduce flag XEN_SYSCTL_PHYSCAP_vpmu which
> indicates whether the platform supports vPMU
> functionality. Modify Xen and tools accordingly.
>
> Take the opportunity and fix XEN_SYSCTL_PHYSCAP_vmtrace
> definition in sysctl.h which
Add parameter vpmu to xl domain configuration syntax
to enable the access to PMU registers by disabling
the PMU traps(currently only for ARM).
The current status is that the PMU registers are not
virtualized and the physical registers are directly
accessible when this parameter is enabled. There
ID_AA64DFR0_EL1/ID_DFR0_EL1 registers provide
information about PMU support. Replace structure
dbg64/dbg32 with a union and fill in all the
register fields according to document:
ARM Architecture Registers(DDI 0595, 2021-06).
Add macros boot_dbg_feature64/boot_dbg_feature32
to check for a debug
Introduce flag XEN_SYSCTL_PHYSCAP_vpmu which
indicates whether the platform supports vPMU
functionality. Modify Xen and tools accordingly.
Take the opportunity and fix XEN_SYSCTL_PHYSCAP_vmtrace
definition in sysctl.h which wrongly use (1<<6)
instead of (1u<<6).
Signed-off-by: Michal Orzel
---
This patch series is a rework of an already pushed patch
exposing PMU to the guests. Since the second version the vpmu
parameter is common and prework in the form of reporting
availability of vPMU on the hardware is added.
The third version of the patch series removes the redundant check
from x86
On 07.10.2021 22:23, Stefano Stabellini wrote:
> On Thu, 7 Oct 2021, Jan Beulich wrote:
>> On 07.10.2021 15:12, Oleksandr wrote:
>>>
>>> On 07.10.21 15:43, Jan Beulich wrote:
>>>
>>> Hi Jan.
>>>
On 07.10.2021 14:30, Oleksandr wrote:
> On 07.10.21 10:42, Jan Beulich wrote:
>> On
Hi Christopher,
Reviewed-by: Bertrand Marquis
Just one small NIT that could be fixed during commit.
> On 8 Oct 2021, at 05:12, Christopher Clark
> wrote:
>
> Add a section to the Argo design document to supply guidance on how to
> enable Argo in Xen and where to obtain source code and
On 08.10.2021 06:12, Christopher Clark wrote:
> Add a section to the Argo design document to supply guidance on how to
> enable Argo in Xen and where to obtain source code and documentation
> for Argo device drivers for guest OSes, primarily from OpenXT.
>
> Signed-off-by: Christopher Clark
Return NULL instead of passing to ERR_PTR while err is zero,
this fix smatch warnings:
drivers/xen/xen-pciback/conf_space_capability.c:163
pm_ctrl_init() warn: passing zero to 'ERR_PTR'
Fixes: a92336a1176b ("xen/pciback: Drop two backends, squash and cleanup some
code.")
Signed-off-by:
Hi Stefano,
On 07/10/2021 23:14, Stefano Stabellini wrote:
On Thu, 7 Oct 2021, Volodymyr Babchuk wrote:
Hi Stefano,
Stefano Stabellini writes:
On Wed, 6 Oct 2021, Oleksandr wrote:
Hello all
Gentle reminder.
Many thanks for the ping, this patch fell off my radar.
On 23.09.21
53 matches
Mail list logo
