flight 168168 xen-unstable real [real]
flight 168172 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168168/
http://logs.test-lab.xenproject.org/osstest/logs/168172/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 168166 linux-linus real [real]
flight 168169 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168166/
http://logs.test-lab.xenproject.org/osstest/logs/168169/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
On 18/02/2022 23:30, Stefano Stabellini wrote:
> When Xen is configured with --with-systemd currently both the systemd
> init scripts as well as the traditional init.d scripts (e.g. xencommons)
> are installed.
>
> This causes issues to distros where old style init scripts are still
> supported eve
When Xen is configured with --with-systemd currently both the systemd
init scripts as well as the traditional init.d scripts (e.g. xencommons)
are installed.
This causes issues to distros where old style init scripts are still
supported even when systemd is enabled, e.g. Yocto. The consequence is
flight 168167 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168167/
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 Mon, Feb 14, 2022 at 10:21:01AM +0100, Roger Pau Monn?? wrote:
Good afternoon, I hope the week has gone well for everyone.
> On Mon, Feb 14, 2022 at 12:00:11AM -0600, Dr. Greg wrote:
> >
> > [ Material removed ]
> >
> > It appears to be a problem with mapping interrupts back to dom0 given
> >
flight 168161 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168161/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
168157 pass in 168161
test-amd64-am
flight 168165 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168165/
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
Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
and x2apic, on x86 hardware.
No such features are currently implemented on AMD hardware.
For that purpose, also add an arch-specific "capabilities" parameter
to struct xen_sysctl_phys
Introduce a new per-domain creation x86 specific flag to
select whether hardware assisted virtualization should be used for
x{2}APIC.
A per-domain option is added to xl in order to select the usage of
x{2}APIC hardware assisted vitualization, as well as a global
configuration option.
Having all A
Jane Malalane (2):
xen+tools: Report Interrupt Controller Virtualization capabilities on
x86
x86/xen: Allow per-domain usage of hardware virtualized APIC
docs/man/xl.cfg.5.pod.in | 19 +
docs/man/xl.conf.5.pod.in | 12 +++
tools/golang/xenl
On 18/02/2022 16:28, Stefano Stabellini wrote:
> On Fri, 18 Feb 2022, Anthony PERARD wrote:
>> On Fri, Feb 18, 2022 at 01:17:40PM +, Andrew Cooper wrote:
>>> A forthcoming change is going to want more support than busybox's grep can
>>> provide.
>>>
>>> Signed-off-by: Andrew Cooper
>>> ---
>>>
On Fri, 18 Feb 2022, Anthony PERARD wrote:
> On Fri, Feb 18, 2022 at 01:17:40PM +, Andrew Cooper wrote:
> > A forthcoming change is going to want more support than busybox's grep can
> > provide.
> >
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Doug Goldstein
> > CC: Wei Liu
> > CC: Ant
On 18/02/2022 14:34, Roger Pau Monne wrote:
> Hello,
>
> The following series adds retpoline support for clang builds, and also
> allows the user to select whether to enable retpoline support at build
> time via a new Kconfig option.
>
> I've tried adding a suitable description to the Kconfig optio
On 18/02/2022 14:46, Anthony PERARD wrote:
> On Fri, Feb 18, 2022 at 01:18:11PM +, Andrew Cooper wrote:
>> * `apk --no-cache` is the preferred way of setting up containers, and it
>> does
>>shrink the image by a few MB.
>> * Neither container needs curl-dev.
>> * Flex and bison are need
On Fri, Feb 18, 2022 at 01:18:11PM +, Andrew Cooper wrote:
> * `apk --no-cache` is the preferred way of setting up containers, and it does
>shrink the image by a few MB.
> * Neither container needs curl-dev.
> * Flex and bison are needed for Xen, so move to the Xen block.
>
> Signed-off
On Fri, Feb 18, 2022 at 01:17:40PM +, Andrew Cooper wrote:
> A forthcoming change is going to want more support than busybox's grep can
> provide.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Doug Goldstein
> CC: Wei Liu
> CC: Anthony PERARD
> CC: Roger Pau Monné
> CC: Stefano Stabellini
Add a new Kconfig option under the "Speculative hardening" section
that allows selecting whether to enable retpoline. This depends on the
underlying compiler having retpoline support.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Place first in the section.
Detect whether the compiler supports clang retpoline option and enable
by default if available, just like it's done for gcc.
Note clang already disables jump tables when retpoline is enabled, so
there's no need to also pass the fno-jump-tables parameter. Also clang
already passes the return addres
Hello,
The following series adds retpoline support for clang builds, and also
allows the user to select whether to enable retpoline support at build
time via a new Kconfig option.
I've tried adding a suitable description to the Kconfig option, but I'm
sure there's room for improvement.
Thanks, R
Keep the previous option as a way to signal generic retpoline support
regardless of the underlying compiler, while introducing a new
CC_INDIRECT_THUNK that signals whether the underlying compiler
supports retpoline.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since
On Fri, Feb 18, 2022 at 01:58:31PM +, Andrew Cooper wrote:
> On 16/02/2022 16:21, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series adds retpoline support for clang builds, and also
> > allows the user to select whether to enable retpoline support at build
> > time via a new Kconfi
On 18/02/2022 13:36, Roger Pau Monne wrote:
> On Fri, Feb 18, 2022 at 12:23:47PM +, Andrew Cooper wrote:
>> On 18/02/2022 12:21, Andrew Cooper wrote:
>>> On 18/02/2022 12:00, Roger Pau Monne wrote:
Add a workflow that performs a build like it's done by osstest
Coverity flight and uplo
On 18/02/2022 13:38, Brian Olson wrote:
> Can someone please tell me how to remove my email account from this
> list? Thank you.
Use https://lists.xenproject.org/mailman/listinfo/xen-devel to unsubscribe.
~Andrew
On 16/02/2022 16:21, Roger Pau Monne wrote:
> Hello,
>
> The following series adds retpoline support for clang builds, and also
> allows the user to select whether to enable retpoline support at build
> time via a new Kconfig option.
>
> I've tried adding a suitable description to the Kconfig optio
flight 168159 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168159/
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
Can someone please tell me how to remove my email account from this
list? Thank you.
On 2/18/22 07:36, Roger Pau Monné wrote:
On Fri, Feb 18, 2022 at 12:23:47PM +, Andrew Cooper wrote:
On 18/02/2022 12:21, Andrew Cooper wrote:
On 18/02/2022 12:00, Roger Pau Monne wrote:
Add a workflow th
On Fri, Feb 18, 2022 at 12:23:47PM +, Andrew Cooper wrote:
> On 18/02/2022 12:21, Andrew Cooper wrote:
> > On 18/02/2022 12:00, Roger Pau Monne wrote:
> >> Add a workflow that performs a build like it's done by osstest
> >> Coverity flight and uploads the result to Coverity for analysis. The
>
On 27/05/2021 13:34, Jan Beulich wrote:
> There's no point in keeping the VA space occupied when no further output
> will occur.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 27/05/2021 13:35, Jan Beulich wrote:
> If we get mode dimensions wrong, having the remapping size controllable
> via command line option isn't going to help much. Drop the option.
>
> While adjusting this also
> - add __initdata to the variable,
> - use ROUNDUP() instead of open-coding it.
>
> R
On 27/05/2021 13:34, Jan Beulich wrote:
> The source file requests page alignment - avoid a padding hole by
> placing it right after .text.entry. On average this yields a .text size
> reduction of 2k.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
I'll
On 18/02/2022 08:39, Jan Beulich wrote:
> On 12.01.2022 10:28, Jan Beulich wrote:
>> On 12.01.2022 10:22, Andrew Cooper wrote:
>>> On 12/01/2022 09:00, Jan Beulich wrote:
When the macro's "return value" is not used, the macro use can be
replaced by a simply division, avoiding some obfusca
* `apk --no-cache` is the preferred way of setting up containers, and it does
shrink the image by a few MB.
* Neither container needs curl-dev.
* Flex and bison are needed for Xen, so move to the Xen block.
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: Wei Liu
CC: Anthony PERARD
A forthcoming change is going to want more support than busybox's grep can
provide.
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: Wei Liu
CC: Anthony PERARD
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Jan Beulich
I've already rebuilt the containers and confirmed that the build
On 18/02/2022 12:27, Roger Pau Monne wrote:
> On Fri, Feb 18, 2022 at 12:21:34PM +, Andrew Cooper wrote:
>> On 18/02/2022 12:00, Roger Pau Monne wrote:
>>> Add a workflow that performs a build like it's done by osstest
>>> Coverity flight and uploads the result to Coverity for analysis. The
>>>
flight 168158 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168158/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168156
test-amd64-amd64-qemuu-nested-amd 20
flight 168160 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168160/
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 Fri, Feb 18, 2022 at 12:21:34PM +, Andrew Cooper wrote:
> On 18/02/2022 12:00, Roger Pau Monne wrote:
> > Add a workflow that performs a build like it's done by osstest
> > Coverity flight and uploads the result to Coverity for analysis. The
> > build process is exactly the same as the one c
On 18/02/2022 12:21, Andrew Cooper wrote:
> On 18/02/2022 12:00, Roger Pau Monne wrote:
>> Add a workflow that performs a build like it's done by osstest
>> Coverity flight and uploads the result to Coverity for analysis. The
>> build process is exactly the same as the one currently used in
>> osst
On 18/02/2022 12:00, Roger Pau Monne wrote:
> Such external projects should have their own Coverity runs, and
> there's not much point in also making them part of our scan (apart
> from greatly increasing the amount of code scanned).
>
> Trim the dependencies now that QEMU is not built.
>
> Signed-
On 18/02/2022 12:00, Roger Pau Monne wrote:
> Add a workflow that performs a build like it's done by osstest
> Coverity flight and uploads the result to Coverity for analysis. The
> build process is exactly the same as the one currently used in
> osstest, and it's also run at the same time (bi-week
Add a workflow that performs a build like it's done by osstest
Coverity flight and uploads the result to Coverity for analysis. The
build process is exactly the same as the one currently used in
osstest, and it's also run at the same time (bi-weekly).
This has one big benefit over using osstest: w
Hello,
Following series introduces a github workflow to trigger a Coverity
Scan. First patch attempts to move the logic currently in osstest into a
github action mostly as-is (same build targets).
Second patch removes the build of QEMU, SeaBIOS and OVMF from the
Coverity Scan.
Thanks, Roger.
Ro
Such external projects should have their own Coverity runs, and
there's not much point in also making them part of our scan (apart
from greatly increasing the amount of code scanned).
Trim the dependencies now that QEMU is not built.
Signed-off-by: Roger Pau Monné
---
.github/workflows/coverity
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",
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 093bb4403f..f1f19bf711 100644
--
flight 168157 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168157/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168145
test-amd64-amd64-qemuu-nested-amd 20
On 18.02.2022 10:09, Roger Pau Monné wrote:
> On Thu, Feb 17, 2022 at 04:57:41PM +0100, Jan Beulich wrote:
>> On 17.02.2022 16:50, Roger Pau Monné wrote:
>>> On Thu, Feb 17, 2022 at 04:02:39PM +0100, Jan Beulich wrote:
On 17.02.2022 15:47, Roger Pau Monné wrote:
> On Thu, Feb 17, 2022 at 1
Hi Julien,
On Thu, Feb 17, 2022 at 03:20:36PM +, Julien Grall wrote:
> Hi,
>
> On 08/02/2022 18:00, Oleksii Moisieiev wrote:
> > If set, Xen is allowed to assign the devices even if they are not under
> > IOMMU.
>
> I think you mean "not protected by an IOMMU".
Yes. Thanks.
>
> > Can be co
On Thu, Feb 17, 2022 at 04:57:41PM +0100, Jan Beulich wrote:
> On 17.02.2022 16:50, Roger Pau Monné wrote:
> > On Thu, Feb 17, 2022 at 04:02:39PM +0100, Jan Beulich wrote:
> >> On 17.02.2022 15:47, Roger Pau Monné wrote:
> >>> On Thu, Feb 17, 2022 at 12:01:08PM +0100, Jan Beulich wrote:
> ---
On 05.01.2022 14:56, Jan Beulich wrote:
> Addressing some observations made while reviewing other patches.
>
> 1: VMX: sync VM-exit perf counters with known VM-exit reasons
> 2: SVM: sync VM-exit perf counters with known VM-exit reasons
> 3: x86/perfc: fold HVM's VM-exit counter arrays
Patch 1 ha
On 12.01.2022 10:28, Jan Beulich wrote:
> On 12.01.2022 10:22, Andrew Cooper wrote:
>> On 12/01/2022 09:00, Jan Beulich wrote:
>>> When the macro's "return value" is not used, the macro use can be
>>> replaced by a simply division, avoiding some obfuscation.
>>>
>>> According to my observations, no
The initial observation is that unlike the original ACPI idle driver we
have a 2nd cpu_is_haltable() in here. By making the actual state entry
conditional, the emitted trace records as well as the subsequent stats
update are at least misleading in case the state wasn't actually entered.
Hence they
On 18.02.2022 06:20, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Tuesday, January 11, 2022 12:36 AM
>>
>> When a page table ends up with no present entries left, it can be
>> replaced by a non-present entry at the next higher level. The page table
>> itself can then be scheduled for freeing.
> From: Jan Beulich
> Sent: Friday, February 18, 2022 4:25 PM
>
> On 18.02.2022 06:01, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Tuesday, January 11, 2022 12:35 AM
> >>
> >> Page tables are used for two purposes after allocation: They either
> >> start out all empty, or they get fille
On 18.02.2022 06:01, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Tuesday, January 11, 2022 12:35 AM
>>
>> Page tables are used for two purposes after allocation: They either
>> start out all empty, or they get filled to replace a superpage.
>> Subsequently, to replace all empty or fully conti
Hi Anthony,
On Thu, Feb 17, 2022 at 02:52:44PM +, Anthony PERARD wrote:
> On Tue, Feb 08, 2022 at 06:00:12PM +, Oleksii Moisieiev wrote:
> > If set, Xen is allowed to assign the devices even if they are not under
> > IOMMU.
> > Can be confugired from dom.cfg in the following format:
> > fo
On 16.02.2022 11:30, Roger Pau Monne wrote:
> Expose the feature if available for the domain.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
On 17.02.2022 15:09, Roger Pau Monne wrote:
> Prevent libxl from creating guests that attempts to use PoD together
> with an IOMMU, even if no devices are actually assigned.
>
> While the hypervisor could support using PoD together with an IOMMU as
> long as no devices are assigned, such usage see
58 matches
Mail list logo
