On 11.03.2021 19:34, Bob Eshleman wrote:
> We would like to start a working group for secure boot support in Xen
> to coordinate the various interested parties and set out a plan for
> the feature and its implications for the whole Xen system.
>
> The end goal is a full implementation that restric
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.12b-rc3-tag
xen: branch for v5.12-rc3
It contains two patch series and a single patch:
- a small cleanup patch to remove unneeded symbol exports
- a series to cleanup Xen grant han
On 11.03.2021 16:29, Roger Pau Monné wrote:
> On Thu, Mar 11, 2021 at 03:40:05PM +0100, Jan Beulich wrote:
>> The first thing the "xen-dir" rule does is delete the entire xen/
>> subtree. Obviously this includes deleting xen/lib/x86/*autogen.h. As a
>> result there's no original version for $(move-
On Fri, Mar 12, 2021 at 08:54:46AM +0100, Jan Beulich wrote:
> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
> handler early enough to cover for example the rdmsrl_safe() of
> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
> of MSR_K7_HWCR later in the
On Fri, Mar 12, 2021 at 09:45:35AM +0100, Jan Beulich wrote:
> On 11.03.2021 16:29, Roger Pau Monné wrote:
> > On Thu, Mar 11, 2021 at 03:40:05PM +0100, Jan Beulich wrote:
> >> The first thing the "xen-dir" rule does is delete the entire xen/
> >> subtree. Obviously this includes deleting xen/lib/x
On 12.03.2021 10:17, Roger Pau Monné wrote:
> On Fri, Mar 12, 2021 at 09:45:35AM +0100, Jan Beulich wrote:
>> On 11.03.2021 16:29, Roger Pau Monné wrote:
>>> On Thu, Mar 11, 2021 at 03:40:05PM +0100, Jan Beulich wrote:
The first thing the "xen-dir" rule does is delete the entire xen/
subt
On 12.03.2021 10:08, Roger Pau Monné wrote:
> On Fri, Mar 12, 2021 at 08:54:46AM +0100, Jan Beulich wrote:
>> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
>> handler early enough to cover for example the rdmsrl_safe() of
>> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of
Hi all,
> On 8 Mar 2021, at 14:12, Julien Grall wrote:
>
> Hi Luca,
>
> On 08/03/2021 11:56, Luca Fancellu wrote:
>> This patch prevents the dom0 to be loaded skipping its
>> building and going forward to build domUs when the dom0
>> kernel is not found and at least one domU is present.
>
> As
Julien Grall writes ("Re: [PATCH][4.15] gnttab: work around "may be used
uninitialized" warning"):
> This is pretty much what we are already doing slowly by initializing
> values to shut up older compilers. I agree this is more limited, but we
> also waive off diagnostics from every single compi
On 12.03.2021 11:04, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH][4.15] gnttab: work around "may be used
> uninitialized" warning"):
>> This is pretty much what we are already doing slowly by initializing
>> values to shut up older compilers. I agree this is more limited, but we
>> als
Jan Beulich writes ("[PATCH v2 1/2][4.15] tools/x86: don't rebuild
cpuid-autogen.h every time"):
> Ian did suggest to pass -0r to xargs (and -print0 to find), but I
> couldn't convince myself that these are standard compliant options. We
> don't use any special characters in file names, so -print0
Jan Beulich writes ("[PATCH v2 2/2] tools/x86: move arch-specific include/xen/
population into arch-specific rule"):
> There's no need for the common "xen-dir" rule to have an arch-specific
> part when there already is a arch-specific rule where this can be taken
> care of (arguably instead of all
ping
Patchew page:
https://patchew.org/QEMU/20210303095910.78277-1-lekir...@yandex-team.ru
03.03.2021, 13:01, "Alexey Kirillov" :
> This patch series introduces a new QMP command "query-netdev" to get
> information about currently attached backend network devices (netdevs).
>
> Also, since the "
Jan Beulich writes ("Re: [PATCH][4.15] gnttab: work around "may be used
uninitialized" warning"):
> On 12.03.2021 11:04, Ian Jackson wrote:
> > Julien Grall writes ("Re: [PATCH][4.15] gnttab: work around "may be used
> > uninitialized" warning"):
> >> This is pretty much what we are already doing
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (11):
block: rsxx: core: Remove superfluous const qualifier
block: drbd: drbd_interval: Demote some kernel-doc abuses and fix
anot
Fixes the following W=1 kernel build warning(s):
drivers/block/xen-blkfront.c:1960: warning: Function parameter or member 'dev'
not described in 'blkfront_probe'
drivers/block/xen-blkfront.c:1960: warning: Function parameter or member 'id'
not described in 'blkfront_probe'
drivers/block/xen-b
flight 159947 qemu-mainline real [real]
flight 159995 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159947/
http://logs.test-lab.xenproject.org/osstest/logs/159995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Largely to re-base patch 1.
1: PV: conditionally avoid raising #GP for early guest MSR reads
2: AMD: expose HWCR.TscFreqSel to guests
Jan
Prior to 4.15 Linux, when running in PV mode, did not install a #GP
handler early enough to cover for example the rdmsrl_safe() of
MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
of MSR_K7_HWCR later in the same function). The respective change
(42b3a4cb5609 "x86/xen: Support
Linux has been warning ("firmware bug") about this bit being clear for a
long time. While writable in older hardware it has been readonly on more
than just most recent hardware. For simplicitly report it always set (if
anything we may want to log the issue ourselves if it turns out to be
clear on o
On 12.03.2021 11:29, Ian Jackson wrote:
> I am sympathetic to Julien's desire to try to limit the set of
> supported compilers.
Yes, and I agree we're long overdue with raising the baseline. It's
just that it's not straightforward to establish a good new one.
Jan
flight 159991 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159991/
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 12/03/2021 07:54, Jan Beulich wrote:
> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
> handler early enough to cover for example the rdmsrl_safe() of
> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
> of MSR_K7_HWCR later in the same function). The r
I don’t think I wrote this up anywhere yet, but I used TLA+ to verify the fixes
for XSA-299 several years ago. I’d always intended to post them once the
embargo was up, but never got around to it. TLA came up in an online
discussion board recently, so I spent a bit of time to clean things up
Hi Luca,
On 12/03/2021 09:38, Luca Fancellu wrote:
+
size_t __read_mostly dcache_line_bytes;
/* C entry point for boot CPU */
@@ -804,7 +833,7 @@ void __init start_xen(unsigned long boot_phys_offset,
int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
-
On 10/03/2021 10:13, Jan Beulich wrote:
> Sadly I was wrong to suggest dropping vaddrs' initializer during review
> of v2 of the patch introducing this code. gcc 4.3 can't cope.
>
> Fixes: 52531c734ea1 ("xen/gnttab: Rework resource acquisition")
> Signed-off-by: Jan Beulich
>
> --- a/xen/common/gr
flight 159950 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 12.03.2021 12:32, Andrew Cooper wrote:
> On 10/03/2021 10:13, Jan Beulich wrote:
>> Sadly I was wrong to suggest dropping vaddrs' initializer during review
>> of v2 of the patch introducing this code. gcc 4.3 can't cope.
>>
>> Fixes: 52531c734ea1 ("xen/gnttab: Rework resource acquisition")
>> Si
On 12.03.2021 14:08, Jan Beulich wrote:
> On 12.03.2021 12:32, Andrew Cooper wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -4059,6 +4059,16 @@ int gnttab_acquire_resource(
>> if ( rc )
>> goto out;
>>
>> + /*
>> + * Some older toolchains can
On 12/03/2021 13:18, Jan Beulich wrote:
> On 12.03.2021 14:08, Jan Beulich wrote:
>> On 12.03.2021 12:32, Andrew Cooper wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -4059,6 +4059,16 @@ int gnttab_acquire_resource(
>>> if ( rc )
>>> goto out;
>>>
On 12/03/2021 13:08, Jan Beulich wrote:
> On 12.03.2021 12:32, Andrew Cooper wrote:
>> On 10/03/2021 10:13, Jan Beulich wrote:
>>> Sadly I was wrong to suggest dropping vaddrs' initializer during review
>>> of v2 of the patch introducing this code. gcc 4.3 can't cope.
>>>
>>> Fixes: 52531c734ea1 ("
Sadly I was wrong to suggest dropping vaddrs' initializer during review
of v2 of the patch introducing this code. gcc 4.3 can't cope.
Fixes: 52531c734ea1 ("xen/gnttab: Rework resource acquisition")
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v2: Re-insert the other half of what Andrew
On 12.03.2021 14:25, Andrew Cooper wrote:
> On 12/03/2021 13:08, Jan Beulich wrote:
>> On 12.03.2021 12:32, Andrew Cooper wrote:
>>> On 10/03/2021 10:13, Jan Beulich wrote:
Sadly I was wrong to suggest dropping vaddrs' initializer during review
of v2 of the patch introducing this code. gc
On 12.03.2021 12:19, Andrew Cooper wrote:
> On 12/03/2021 07:54, Jan Beulich wrote:
>> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
>> handler early enough to cover for example the rdmsrl_safe() of
>> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
>> o
Jan Beulich writes ("[PATCH v4 0/2][4.15] x86: guest MSR access handling
tweaks"):
> Largely to re-base patch 1.
>
> 1: PV: conditionally avoid raising #GP for early guest MSR reads
> 2: AMD: expose HWCR.TscFreqSel to guests
Jan, thanks for the v4. Roger, thanks for your reviews and for your
ma
Dario Faggioli writes ("[PATCH] xen: fix for_each_cpu when NR_CPUS=1"):
> When running an hypervisor build with NR_CPUS=1 for_each_cpu does not
> take into account whether the bit of the CPU is set or not in the
> provided mask.
>
> This means that whatever we have in the bodies of these loops is
Andrew Cooper writes ("Re: [PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__
header guard from public API"):
> On 11/03/2021 14:18, Roger Pau Monné wrote:
> > I think using __XEN_UNSTABLE_ABI__ would be way clearer than
> > __XEN_TOOLS__, or even placing those in a separate directory as you
> > me
Igor Druzhinin writes ("[PATCH for-4.15] vtd: make sure QI/IR are disabled
before initialisation"):
> BIOS might pass control to Xen leaving QI and/or IR in enabled and/or
> partially configured state. In case of x2APIC code path where EIM is
> enabled early in boot - those are correctly disabled
> On Feb 16, 2021, at 3:29 PM, Jan Beulich wrote:
>
> On 16.02.2021 11:28, George Dunlap wrote:
>> --- /dev/null
>> +++ b/docs/hypervisor-guide/memory-allocation-functions.rst
>> @@ -0,0 +1,118 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Xenheap memory allocation functions
>> +===
On Thu, Mar 11, 2021 at 10:59:44PM +, ChiaHao Hsu wrote:
> In order to support live migration of guests between kernels
> that do and do not support 'feature-ctrl-ring', we add a
> module parameter that allows the feature to be disabled
> at run time, instead of using hardcode value.
> The defa
On 11/03/2021 18:34, Bob Eshleman wrote:
> Hey all,
>
> We would like to start a working group for secure boot support in Xen
> to coordinate the various interested parties and set out a plan for
> the feature and its implications for the whole Xen system.
>
> The end goal is a full implementation
Andrew Lunn 於 2021/3/12 15:52 寫道:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On Thu, Mar 11, 2021 at 10:59:44PM +, ChiaHao Hsu wrote:
In order to support live m
> On Mar 12, 2021, at 2:32 PM, George Dunlap wrote:
>
>
>
>> On Feb 16, 2021, at 3:29 PM, Jan Beulich wrote:
>>
>> On 16.02.2021 11:28, George Dunlap wrote:
>>> --- /dev/null
>>> +++ b/docs/hypervisor-guide/memory-allocation-functions.rst
>>> @@ -0,0 +1,118 @@
>>> +.. SPDX-License-Identifie
On Thu, Mar 11, 2021 at 10:34:02AM -0800, Bob Eshleman wrote:
> Hey all,
>
> We would like to start a working group for secure boot support in Xen
> to coordinate the various interested parties and set out a plan for
> the feature and its implications for the whole Xen system.
>
> The end goal is
flight 159969 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159969/
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
On 3/11/21 1:34 PM, Bob Eshleman wrote:
> Hey all,
>
> We would like to start a working group for secure boot support in Xen
> to coordinate the various interested parties and set out a plan for
> the feature and its implications for the whole Xen system.
>
> The end goal is a full implementation
On 12.03.2021 15:03, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH] xen: fix for_each_cpu when NR_CPUS=1"):
>> -#if NR_CPUS > 1
>> #define for_each_cpu(cpu, mask) \
>> for ((cpu) = cpumask_first(mask); \
>
> Just a thought: does cpumask_first work on an empty
On 12.03.2021 11:04, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH][4.15] gnttab: work around "may be used
> uninitialized" warning"):
>> This is pretty much what we are already doing slowly by initializing
>> values to shut up older compilers. I agree this is more limited, but we
>> als
On Fri, Feb 12, 2021 at 05:38:13PM -0800, Stefano Stabellini wrote:
> Add a debian build container with cross-gcc for arm32 installed.
> Add build jobs to cross-compile Xen-only for arm32.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
Cc Ian.
The risk is small: Gitlab CI doesn't gat
On 12.03.2021 15:32, George Dunlap wrote:
>> On Feb 16, 2021, at 3:29 PM, Jan Beulich wrote:
>> On 16.02.2021 11:28, George Dunlap wrote:
>>> --- /dev/null
>>> +++ b/docs/hypervisor-guide/memory-allocation-functions.rst
>>> @@ -0,0 +1,118 @@
>>> +.. SPDX-License-Identifier: CC-BY-4.0
>>> +
>>> +Xe
On Fri, Mar 12, 2021 at 04:24:53PM +0100, Marek Marczykowski-G??recki wrote:
> On Thu, Mar 11, 2021 at 10:34:02AM -0800, Bob Eshleman wrote:
> > We would like to start a working group for secure boot support in Xen
> > to coordinate the various interested parties and set out a plan for
> > the feat
Jan Beulich writes ("Re: [PATCH][4.15] gnttab: work around "may be used
uninitialized" warning"):
> On 12.03.2021 11:04, Ian Jackson wrote:
> > But this is outside my usual area so I won't nack it either.
>
> But would you be willing to release-ack v2?
Good question. I don't think my code quali
The first thing the "xen-dir" rule does is delete the entire xen/
subtree. Obviously this includes deleting xen/lib/x86/*autogen.h. As a
result there's no original version for $(move-if-changed ...) to compare
against, and hence the file and all its consumers would get rebuilt
every time. Instead o
Jan Beulich writes ("[PATCH v3][4.15] tools/x86: don't rebuild cpuid-autogen.h
every time"):
> The first thing the "xen-dir" rule does is delete the entire xen/
> subtree. Obviously this includes deleting xen/lib/x86/*autogen.h. As a
> result there's no original version for $(move-if-changed ...)
On 25.02.2021 16:24, Connor Davis wrote:
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
Btw - changes like this one would better be split off, so
they would come with a justification / description. A file
On 11/03/2021 18:34, Bob Eshleman wrote:
> Hey all,
>
> We would like to start a working group for secure boot support in Xen
> to coordinate the various interested parties and set out a plan for
> the feature and its implications for the whole Xen system.
>
> The end goal is a full implementation
On 25.02.2021 16:24, Connor Davis wrote:
> --- /dev/null
> +++ b/xen/include/public/arch-riscv.h
> @@ -0,0 +1,183 @@
> +/**
> + * arch-riscv.h
> + *
> + * Guest OS interface to RISC-V Xen.
> + * Initially based on the ARM i
On Wed, Mar 10, 2021 at 09:54:57AM +0100, Jan Beulich wrote:
> On 09.03.2021 22:27, Andrew Cooper wrote:
> >
> > I wonder why our header checks don't pick this up.?? Do we need to throw
> > a -pedantic around?
>
> That's a long-standing issue with the checking: For issues to be
> found in macros,
Awesome, it's great to see this interest.
I'll wait until early next week to give more
people a chance to pitch in, then start
bugging everybody about availability to
schedule a meeting. I'll put together a
small agenda then to get the ball rolling.
Thanks all.
flight 160031 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160031/
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
The pull request you sent on Fri, 12 Mar 2021 09:34:00 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.12b-rc3-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6bf8819fede1fef9805e1d803261c0d3bb62f239
Thank you!
--
Deet-doot-dot,
flight 159953 xen-unstable real [real]
flight 160042 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159953/
http://logs.test-lab.xenproject.org/osstest/logs/160042/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Fri, Mar 12, 2021 at 04:18:02PM +0100, Hsu, Chiahao wrote:
>
> Andrew Lunn 於 2021/3/12 15:52 寫道:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe.
> >
> >
> >
>
Would love to participate! What are the next steps?
Thanks,
Roman.
On Fri, Mar 12, 2021 at 11:06 AM Bob Eshleman wrote:
>
> Awesome, it's great to see this interest.
>
> I'll wait until early next week to give more
> people a chance to pitch in, then start
> bugging everybody about availability
Hi all,
During the last 6 months we have been working on improving the Xen
Project gitlab-ci and patchew infrastructure.
You can see the results from gitlab-ci tests on the staging branch here:
https://gitlab.com/xen-project/xen/-/pipelines
https://gitlab.com/xen-project/xen/-/pipelines/26967867
Now that the Alpine Linux build jobs complete successfully on staging we
can remove the "allow_failure: true" tag.
Signed-off-by: Stefano Stabellini
---
automation/gitlab-ci/build.yaml | 4
1 file changed, 4 deletions(-)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/b
Hi Jürgen,
just wanted to give you (and everyone who may be keeping an eye on
this) an update.
Somehow, after applying your kernel patch -- the VM is now running 10
days+ without a problem.
I'll keep experimenting (A/B-testing style) but at this point I'm
actually pretty perplexed as to why this
flight 160044 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160044/
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
Introduce two feature flags to tell the domain whether it is
direct-mapped or not. It allows the guest kernel to make informed
decisions on things such as swiotlb-xen enablement.
The introduction of both flags (XENFEAT_direct_mapped and
XENFEAT_not_direct_mapped) allows the guest kernel to avoid a
flight 160002 qemu-mainline real [real]
flight 160047 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160002/
http://logs.test-lab.xenproject.org/osstest/logs/160047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 160010 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160010/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 160048 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 152631
build-amd64-xsm
flight 160050 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 152631
build-amd64-xsm
flight 160053 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160053/
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
flight 160057 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160057/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 152631
build-amd64-xsm
On 12.03.21 22:33, Roman Shaposhnik wrote:
Hi Jürgen,
just wanted to give you (and everyone who may be keeping an eye on
this) an update.
Somehow, after applying your kernel patch -- the VM is now running 10
days+ without a problem.
Can you check the kernel console messages, please? There are
flight 160045 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160045/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159953
test-amd64-amd64-xl-qemuu-ws16-amd64
77 matches
Mail list logo
