Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.11-rc8-tag
xen: branch for v5.11-rc8
It contains a single fix for an issue introduced in 5.11: when running
as a Xen guest on Arm systems the kernel will hang during boot.
Thanks.
flight 159280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159280/
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
flight 159239 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159239/
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 159273 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159273/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 159204 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 broken in 159042
test-amd64-i386-xl-qemuu-o
flight 159266 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159266/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 159202 xen-unstable real [real]
flight 159264 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159202/
http://logs.test-lab.xenproject.org/osstest/logs/159264/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
branch xen-unstable
xenbranch xen-unstable
job test-arm64-arm64-xl-credit2
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tr
On Thu, 11 Feb 2021, Julien Grall wrote:
> On 11/02/2021 13:20, Rahul Singh wrote:
> > > On 10 Feb 2021, at 7:52 pm, Julien Grall wrote:
> > > On 10/02/2021 18:08, Rahul Singh wrote:
> > > > Hello Julien,
> > > > > On 10 Feb 2021, at 5:34 pm, Julien Grall wrote:
> > > > > On 10/02/2021 15:06, Rah
flight 159258 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159258/
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 2/9/21 3:21 PM, Jan Beulich wrote:
> On 09.02.2021 14:56, Norbert Manthey wrote:
>> On 2/9/21 2:45 PM, Jan Beulich wrote:
>>> On 09.02.2021 14:41, Norbert Manthey wrote:
On 2/9/21 10:40 AM, Jan Beulich wrote:
> On 08.02.2021 20:47, Norbert Manthey wrote:
>> On 2/8/21 3:21 PM, Jan Be
On Thu, 11 Feb 2021 at 17:19, Alex Bennée wrote:
>
> The use of FDT's is quite common across our various platforms. To
> allow the generic loader to tweak it we need to make it available in
> the generic state. This creates the field and migrates the initial
> user to use the generic field. Other
flight 159199 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159199/
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-
These tests make sure we can boot the Xen hypervisor with a Dom0
kernel using the guest-loader. We currently have to use a kernel I
built myself because there are issues using the Debian kernel images.
Signed-off-by: Alex Bennée
---
MAINTAINERS | 1 +
tests/acceptance/boot_xen
We might as well surface this useful information in the manual so
users can find it easily. It is a fairly simple conversion to rst with
the only textual fixes being QemuOps to QemuOpts.
Signed-off-by: Alex Bennée
Message-Id: <20201105175153.30489-6-alex.ben...@linaro.org>
---
v2
- fix whitesp
Signed-off-by: Alex Bennée
Message-Id: <20201105175153.30489-7-alex.ben...@linaro.org>
---
v2
- add docs and MAINTAINERS
---
docs/system/guest-loader.rst | 54
docs/system/index.rst| 1 +
MAINTAINERS | 1 +
3 files changed, 56 ins
A string array in device tree is simply a series of \0 terminated
strings next to each other. As libfdt doesn't support that directly
we need to build it ourselves.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Message-Id: <20201105175153.30489-4-alex.ben...@linaro.org>
---
v2
- ch
This is a mechanical change to make the fdt available through
MachineState.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201021170842.25762-3-alex.ben...@linaro.org>
Message-Id: <20201105175153.30489-3-alex.ben...@linaro.org>
Signed
The use of FDT's is quite common across our various platforms. To
allow the generic loader to tweak it we need to make it available in
the generic state. This creates the field and migrates the initial
user to use the generic field. Other boards will be updated in later
patches.
Signed-off-by: Ale
Hypervisors, especially type-1 ones, need the firmware/bootcode to put
their initial guest somewhere in memory and pass the information to it
via platform data. The guest-loader is modelled after the generic
loader for exactly this sort of purpose:
$QEMU $ARGS -kernel ~/xen.git/xen/xen \
-a
Hi,
These patches have been sitting around as part of a larger series to
improve the support of Xen on AArch64. The second part of the work is
currently awaiting other re-factoring and build work to go in to make
the building of a pure-Xen capable QEMU easier. As that might take
some time and thes
On Thu, Feb 11, 2021 at 03:57:06PM +, Andrew Cooper wrote:
> On 11/02/2021 15:50, Andrew Cooper wrote:
> > Logical continuation of c/s eb52442d7f "automation: Add Ubuntu:focal
> > container".
> >
> > No further changes required. Everything builds fine.
> >
> > Signed-off-by: Andrew Cooper
> >
On Wed, Feb 10, 2021 at 01:53:35PM +, Andrew Cooper wrote:
> Matches the comment in the xl-network-configuration manpage.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
Hello Julien,
> On 11 Feb 2021, at 1:52 pm, Julien Grall wrote:
>
>
>
> On 11/02/2021 13:20, Rahul Singh wrote:
>> Hello Julien,
>
> Hi Rahul,
>
>>> On 10 Feb 2021, at 7:52 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 10/02/2021 18:08, Rahul Singh wrote:
Hello Julien,
> On 10 Feb
On 11/02/2021 15:50, Andrew Cooper wrote:
> Logical continuation of c/s eb52442d7f "automation: Add Ubuntu:focal
> container".
>
> No further changes required. Everything builds fine.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Doug Goldstein
> CC: George Dunlap
> CC: Ian Jackson
> CC: Jan Be
Logical continuation of c/s eb52442d7f "automation: Add Ubuntu:focal
container".
No further changes required. Everything builds fine.
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
On 23.11.2020 15:33, Jan Beulich wrote:
> Zapping leaf data for out of range leaves is just one half of it: To
> avoid guests (bogusly or worse) inferring information from mere leaf
> presence, also shrink maximum indicators such that the respective
> trailing entry is not all blank (unless of cour
On 23.11.2020 15:32, Jan Beulich wrote:
> A maximum extended leaf input value with the high half different from
> 0x8000 should not be considered valid - all leaves should be cleared in
> this case.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Integrate into series.
While most other parts of this
On Thu, Feb 11, 2021 at 11:16:12AM +0100, Juergen Gross wrote:
> In case of a common event for rx and tx queue the event should be
> regarded to be spurious if no rx and no tx requests are pending.
>
> Unfortunately the condition for testing that is wrong causing to
> decide a event being spurious
Andrew Cooper writes ("Stable library ABI compatibility checking"):
> What I propose is tweaking the library build to write out
> lib$FOO.so.$X.$Y-$(ARCH).abi.dump files.
+1
> A pristine set of these should be put somewhere on xenbits, and a
> task put on the release technicians checklist for f
Hello everyone!
Submissions are now open for The XenProject Design and Developer Summit, to be
held virtually, May 25-28.
CFP closes 11:59pm PST on Friday, April 2, and notifications will be made on 19
April.
As always, a significant chunk of time will be dedicated to attendee-submitted
desig
> -Original Message-
> From: Juergen Gross
> Sent: 11 February 2021 10:16
> To: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org;
> linux-ker...@vger.kernel.org;
> net...@vger.kernel.org; linux-s...@vger.kernel.org
> Cc: Juergen Gross ; Konrad Rzeszutek Wilk
> ; Roger Pau Monn
> -Original Message-
> From: Juergen Gross
> Sent: 11 February 2021 10:16
> To: xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross ; Wei Liu ; Paul
> Durrant ; David
> S. Miller ; Jakub Kicinski
> Subject: [PATCH v2 4/8] xen/netbac
On 09/02/2021 19:53, Stefano Stabellini wrote:
PCI buses differ from default buses in a few important ways, so it is
important to detect them properly. Normally, PCI buses are expected to
have the following property:
device_type = "pci"
In reality, it is not always the case. To handle P
On 11/02/2021 10:36, Jan Beulich wrote:
> On 11.02.2021 09:45, Roger Pau Monné wrote:
>> On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
>>> I did further consider not allocating any real page at all, but just
>>> using the address of some unpopulated space (which would require
>>> ann
On 11/02/2021 13:20, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 10 Feb 2021, at 7:52 pm, Julien Grall wrote:
On 10/02/2021 18:08, Rahul Singh wrote:
Hello Julien,
On 10 Feb 2021, at 5:34 pm, Julien Grall wrote:
Hi,
On 10/02/2021 15:06, Rahul Singh wrote:
On 9 Feb 2021, at 8:36
Hello Julien,
> On 10 Feb 2021, at 7:52 pm, Julien Grall wrote:
>
>
>
> On 10/02/2021 18:08, Rahul Singh wrote:
>> Hello Julien,
>>> On 10 Feb 2021, at 5:34 pm, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 10/02/2021 15:06, Rahul Singh wrote:
> On 9 Feb 2021, at 8:36 pm, Stefano Stabellin
On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote:
> On 11.02.2021 12:16, Roger Pau Monné wrote:
> > On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote:
> >> On 11.02.2021 09:45, Roger Pau Monné wrote:
> >>> On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
> ---
On 11/02/2021 11:53, Jan Beulich wrote:
> On 11.02.2021 12:30, Andrew Cooper wrote:
>> On 11/02/2021 11:05, Jan Beulich wrote:
>>> On 11.02.2021 02:08, Andrew Cooper wrote:
Hello,
Last things first, some examples:
http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.
Hello Stefano,
> On 10 Feb 2021, at 9:13 pm, Stefano Stabellini wrote:
>
> On Wed, 10 Feb 2021, Rahul Singh wrote:
>>> On 9 Feb 2021, at 8:36 pm, Stefano Stabellini
>>> wrote:
>>> On Tue, 9 Feb 2021, Rahul Singh wrote:
> On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
> wrote:
>
>
On 11.02.2021 12:30, Andrew Cooper wrote:
> On 11/02/2021 11:05, Jan Beulich wrote:
>> On 11.02.2021 02:08, Andrew Cooper wrote:
>>> Hello,
>>>
>>> Last things first, some examples:
>>>
>>> http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.1_to_1.2.html
>>> http://xenbits.xen.org/people/a
flight 159203 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159203/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 broken
test-amd64-amd64-libvirt-vhd 19 g
On 11/02/2021 11:05, Jan Beulich wrote:
> On 11.02.2021 02:08, Andrew Cooper wrote:
>> Hello,
>>
>> Last things first, some examples:
>>
>> http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.1_to_1.2.html
>> http://xenbits.xen.org/people/andrewcoop/abi/libxenforeignmemory-1.3_to_1.4.html
>
On 11.02.2021 09:11, Roger Pau Monné wrote:
> On Wed, Feb 10, 2021 at 05:55:52PM +0100, Jan Beulich wrote:
>> On 09.02.2021 17:26, Roger Pau Monné wrote:
>>> On Thu, Jan 14, 2021 at 04:04:57PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -1
On 11.02.2021 12:16, Roger Pau Monné wrote:
> On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote:
>> On 11.02.2021 09:45, Roger Pau Monné wrote:
>>> On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@
On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote:
> On 11.02.2021 09:45, Roger Pau Monné wrote:
> > On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
> >> I did further consider not allocating any real page at all, but just
> >> using the address of some unpopulated space (whi
On 11.02.2021 02:08, Andrew Cooper wrote:
> Hello,
>
> Last things first, some examples:
>
> http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.1_to_1.2.html
> http://xenbits.xen.org/people/andrewcoop/abi/libxenforeignmemory-1.3_to_1.4.html
>
> These are an ABI compatibility report betw
On 11.02.2021 11:16, Juergen Gross wrote:
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -162,13 +162,15 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> {
> struct xenvif_queue *queue = dev_id;
> int old;
> + bool has_rx, has_t
On 11.02.2021 09:45, Roger Pau Monné wrote:
> On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
>> I did further consider not allocating any real page at all, but just
>> using the address of some unpopulated space (which would require
>> announcing this page as reserved to Dom0, so it w
flight 159198 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159198/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 124f1dd1ee1140b441151043aacbe5d33bb5ab79
baseline version:
ovmf 472276f59bba2b22bb882
In order to support the possibility of per-device event channel
settings (e.g. lateeoi spurious event thresholds) add a xenbus device
pointer to struct irq_info() and modify the related event channel
binding interfaces to take the pointer to the xenbus device as a
parameter instead of the domain id
Add syfs nodes for each xenbus device showing event statistics (number
of events and spurious events, number of associated event channels)
and for setting a spurious event threshold in case a frontend is
sending too many events without being rogue on purpose.
Signed-off-by: Juergen Gross
---
V2:
The ring buffer for user events is local to the given kernel instance,
so smp barriers are fine for ensuring consistency.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
drivers/xen/evtchn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
In case of a common event for rx and tx queue the event should be
regarded to be spurious if no rx and no tx requests are pending.
Unfortunately the condition for testing that is wrong causing to
decide a event being spurious if no rx OR no tx requests are
pending.
Fix that plus using local varia
For avoiding read- and write-tearing by the compiler use READ_ONCE()
and WRITE_ONCE() for accessing the ring indices in evtchn.c.
Signed-off-by: Juergen Gross
---
V2:
- modify all accesses (Julien Grall)
---
drivers/xen/evtchn.c | 25 -
1 file changed, 16 insertions(+), 9
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port. So when tearing an event
channel down reset all affinity bits.
The same applies to the affinity when onlining a vcpu:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Reported-b
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to be able to distinguish "normal" masking/unmasking from eoi related
masking/unmasking an
The first four patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Patches 5 and 6 are some additions to event handling in order to add
some per pv-device statistics to sysfs and the ability to have a per
backend device spurious event delay control
branch xen-unstable
xenbranch xen-unstable
job test-arm64-arm64-xl-xsm
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree:
On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote:
> I did further consider not allocating any real page at all, but just
> using the address of some unpopulated space (which would require
> announcing this page as reserved to Dom0, so it wouldn't put any PCI
> MMIO BARs there). But I tho
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and adopt the drivers. Same for the rsp
simple-pipe helper.
Compile-tested with x86-64, aarch64 and arm. The patch is fairly
On Wed, Feb 10, 2021 at 05:55:52PM +0100, Jan Beulich wrote:
> On 09.02.2021 17:26, Roger Pau Monné wrote:
> > On Thu, Jan 14, 2021 at 04:04:57PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/usercopy.c
> >> +++ b/xen/arch/x86/usercopy.c
> >> @@ -10,12 +10,19 @@
> >> #include
> >> #include
63 matches
Mail list logo
