On 05.11.2020 02:14, Stefano Stabellini wrote:
> On Wed, 4 Nov 2020, Bertrand Marquis wrote:
>>> On 4 Nov 2020, at 07:34, Jan Beulich wrote:
>>> On 03.11.2020 20:37, Stefano Stabellini wrote:
On Tue, 3 Nov 2020, Jan Beulich wrote:
> On 02.11.2020 22:41, Stefano Stabellini wrote:
>> On
On 04.11.2020 18:19, Elliott Mitchell wrote:
> On Wed, Nov 04, 2020 at 03:57:49PM +0100, Jan Beulich wrote:
>> --- a/tools/python/Makefile
>> +++ b/tools/python/Makefile
>> @@ -8,19 +8,21 @@ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
>> PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
>> INSTALL_LOG
Le jeu. 5 nov. 2020 05:28, Stefano Stabellini a
écrit :
> On Wed, 4 Nov 2020, Thomas Huth wrote:
> > On 04/11/2020 03.27, Stefano Stabellini wrote:
> > [...]
> > > Actually I care about Xen and 9pfs support, it is one of the few
> > > combinations that I use regularly and it is even enabled in th
flight 156400 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156400/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8d5708833509ece6ac63084dc07c8ac53c4d4c1a
baseline version:
ovmf 375683654d46380e4e557
Overall I like this, just an inline question:
On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
(...)
> +/**
> + * dma_buf_map_memcpy_to - Memcpy i
On 20.10.20 15:33, Jan Beulich wrote:
On 16.10.2020 10:53, Juergen Gross wrote:
Actions in NMI context are rather limited as e.g. locking is rather
fragile.
Add a generic framework to continue processing in normal interrupt
context after leaving NMI processing.
This is done by a high priority
Hi
Am 05.11.20 um 11:07 schrieb Linus Walleij:
> Overall I like this, just an inline question:
>
> On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
>
>> To do framebuffer updates, one needs memcpy from system memory and a
>> pointer-increment function. Add both interfaces with documenta
flight 156403 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156403/
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 156406 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 156358
build-amd64
On 05/11/20 03:48, Stefano Stabellini wrote:
I repeated all the steps to make sure. The first time I was using
Samurai because Alpine Linux comes with it and not Ninja. Then, I
removed Samurai and built and installed Ninja by hand from
https://github.com/ninja-build/ninja and that actually works.
flight 156399 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156399/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 156317
test-amd64-i386-xl-qemuu-win7-am
On 05.11.2020 11:22, Jürgen Groß wrote:
> On 20.10.20 15:33, Jan Beulich wrote:
>> On 16.10.2020 10:53, Juergen Gross wrote:
>>> Actions in NMI context are rather limited as e.g. locking is rather
>>> fragile.
>>>
>>> Add a generic framework to continue processing in normal interrupt
>>> context af
On 04.11.2020 16:53, Jürgen Groß wrote:
> On 04.11.20 16:29, Jan Beulich wrote:
>>> @@ -738,7 +725,8 @@ int evtchn_send(struct domain *ld, unsigned int lport)
>>>
>>> lchn = evtchn_from_port(ld, lport);
>>>
>>> -spin_lock_irqsave(&lchn->lock, flags);
>>> +if ( !evtchn_read_trylo
On 27.10.2020 12:40, Jan Beulich wrote:
> $(DSDT_FILES-y) depends on the recursive make to have run in libacpi/
> such that the file(s) itself/themselves were generated before
> compilation gets attempted. The same, however, is also necessary for
> generated headers, before source files including t
On 11/4/20 6:54 PM, Greg Kurz wrote:
> On Wed, 04 Nov 2020 13:18:09 +0100
> Christian Schoenebeck wrote:
>
>> On Mittwoch, 4. November 2020 12:57:04 CET Philippe Mathieu-Daudé wrote:
>>> Commit b2c00bce54c ("meson: convert hw/9pfs, cleanup") introduced
>>> CONFIG_9PFS (probably a wrong conflict r
On Thu, 5 Nov 2020 13:15:59 +0100
Philippe Mathieu-Daudé wrote:
> On 11/4/20 6:54 PM, Greg Kurz wrote:
> > On Wed, 04 Nov 2020 13:18:09 +0100
> > Christian Schoenebeck wrote:
> >
> >> On Mittwoch, 4. November 2020 12:57:04 CET Philippe Mathieu-Daudé wrote:
> >>> Commit b2c00bce54c ("meson: conv
flight 156409 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 156358
build-amd64
On Donnerstag, 5. November 2020 13:23:46 CET Greg Kurz wrote:
> On Thu, 5 Nov 2020 13:15:59 +0100
>
> Philippe Mathieu-Daudé wrote:
> > On 11/4/20 6:54 PM, Greg Kurz wrote:
> > > On Wed, 04 Nov 2020 13:18:09 +0100
> > >
> > > Christian Schoenebeck wrote:
> > >> On Mittwoch, 4. November 2020 12:
On Thu, Nov 05, 2020 at 11:37:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 11:07 schrieb Linus Walleij:
> > Overall I like this, just an inline question:
> >
> > On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann
> > wrote:
> >
> >> To do framebuffer updates, one needs memcpy fr
On Thu, Nov 05, 2020 at 12:56:46PM +0100, Jan Beulich wrote:
> On 27.10.2020 12:40, Jan Beulich wrote:
> > $(DSDT_FILES-y) depends on the recursive make to have run in libacpi/
> > such that the file(s) itself/themselves were generated before
> > compilation gets attempted. The same, however, is al
We think we have all the pieces now for a bunch of long-awaited
hardware work in the Massachusetts colo.
There will be several days of complete stoppage. If anyone has
opinions about good or bad times, please let me know.
Ian.
On Donnerstag, 5. November 2020 13:28:31 CET Christian Schoenebeck wrote:
> On Donnerstag, 5. November 2020 13:23:46 CET Greg Kurz wrote:
> > On Thu, 5 Nov 2020 13:15:59 +0100
> >
> > Philippe Mathieu-Daudé wrote:
> > > On 11/4/20 6:54 PM, Greg Kurz wrote:
> > > > On Wed, 04 Nov 2020 13:18:09 +01
flight 156401 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156401/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 156389
test-amd64-amd64-xl-qemuu-win7-amd64
On Fri, Oct 30, 2020 at 10:46:37AM -0700, Stefano Stabellini wrote:
> On Fri, 30 Oct 2020, Takahiro Akashi wrote:
> > === after "xl console -t vuart" ===
> > U-Boot 2020.10-00777-g10cf956a26ba (Oct 29 2020 - 19:31:29 +0900) xenguest
> >
> > Xen virtual CPU
> > Model: XENVM-4.15
> > DRAM: 128 MiB
On Wed, Nov 04, 2020 at 09:37:09PM +0800, Xinhao Zhang wrote:
> Fix code style. Don't use '#' flag of printf format ('%#') in
> format strings, use '0x' prefix instead
>
> Signed-off-by: Xinhao Zhang
> Signed-off-by: Kai Deng
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway. Do so indirectly
though, by making grant_to_status_frames() return zero in this case.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
Using max undermines the separation between default and max. For example,
turning off AVX512F on an MPX-capable system silently turns on MPX,
despite this not being part of the default policy anymore. Since the
information is used only for determining what to convert 'x' to (but not
to e.g. validat
On 30.10.2020 15:47, George Dunlap wrote:
> Hi all,
>
> The proposed agenda is in
> https://cryptpad.fr/pad/#/2/pad/edit/k-0Aj+Sxb5SliLWrFRBwx49V/ and you can
> edit to add items. Alternatively, you can reply to this mail directly.
>
> Agenda items appreciated a few days before the call: pleas
On 05/11/2020 15:41, Anthony PERARD wrote:
On Fri, Oct 30, 2020 at 10:46:37AM -0700, Stefano Stabellini wrote:
On Fri, 30 Oct 2020, Takahiro Akashi wrote:
=== after "xl console -t vuart" ===
U-Boot 2020.10-00777-g10cf956a26ba (Oct 29 2020 - 19:31:29 +0900) xenguest
Xen virtual CPU
Model: XE
On Thu, 5 Nov 2020, Anthony PERARD wrote:
> On Fri, Oct 30, 2020 at 10:46:37AM -0700, Stefano Stabellini wrote:
> > On Fri, 30 Oct 2020, Takahiro Akashi wrote:
> > > === after "xl console -t vuart" ===
> > > U-Boot 2020.10-00777-g10cf956a26ba (Oct 29 2020 - 19:31:29 +0900) xenguest
> > >
> > > Xen
> On Nov 5, 2020, at 11:01, Jan Beulich wrote:
> On 30.10.2020 15:47, George Dunlap wrote:
>> Hi all,
>>
>> The proposed agenda is in
>> https://cryptpad.fr/pad/#/2/pad/edit/k-0Aj+Sxb5SliLWrFRBwx49V/ and you can
>> edit to add items. Alternatively, you can reply to this mail directly.
>>
>>
We should never build something that calls this without having it.
Signed-off-by: Alex Bennée
---
stubs/xen-hw-stub.c | 4
1 file changed, 4 deletions(-)
diff --git a/stubs/xen-hw-stub.c b/stubs/xen-hw-stub.c
index 2ea8190921..15f3921a76 100644
--- a/stubs/xen-hw-stub.c
+++ b/stubs/xen-hw-
When running on non-x86 systems there is no point building HVM support
because we will never see such things. To achieve this we need to
shuffle a little bit of the inline and other stubs about.
Signed-off-by: Alex Bennée
---
include/sysemu/xen-mapcache.h | 2 +-
include/sysemu/xen.h |
flight 156405 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
On Thu, Nov 05, 2020 at 08:29:20AM -0800, Stefano Stabellini wrote:
> On Thu, 5 Nov 2020, Anthony PERARD wrote:
> > On Fri, Oct 30, 2020 at 10:46:37AM -0700, Stefano Stabellini wrote:
> > > On Fri, 30 Oct 2020, Takahiro Akashi wrote:
> > > > === after "xl console -t vuart" ===
> > > > U-Boot 2020.1
Chardev is already a typedef'ed struct.
Signed-off-by: Alex Bennée
---
include/hw/xen/xen.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 1406648ca5..0f9962b1c1 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@
flight 156444 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156444/
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 156404 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156404/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 10 host-ping-check-xen fail REGR. vs. 156394
build-i386
[this is my personal account, opinions expressed are entirely my own]
Hi,
I'm starting this new series thread to discuss how Linux's LL/SC and LSE
atomics helpers may best be ported to Xen, as per the discussion at [1].
Arguments in favour of doing this
=
-
The current Arm boot_cpu_feature64() and boot_cpu_feature32() macros
are hardcoded to only detect features in ID_AA64PFR{0,1}_EL1 and
ID_PFR{0,1} respectively.
This patch replaces these macros with a new macro, boot_cpu_feature(),
which takes an explicit ID register name as an argument.
While we'
This patch introduces the ARM64_HAS_LSE_ATOMICS hwcap.
While doing this, CONFIG_ARM64_LSE_ATOMICS is added to control whether
the hwcap is actually detected and set at runtime. Without this Kconfig
being set we will always fallback on LL/SC atomics using Armv8.0 exlusive
accesses.
Note this patch
This patch ports Linux's arm32 LL/SC atomics helpers to Xen.
The opening comment of each header file details the changes made to
that file while porting it to Xen.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm32/atomic.h | 261 ++
xen/include/asm-arm/arm32/cmpxchg.h |
Now that we have explicit implementations of LL/SC and LSE atomics
helpers after porting Linux's versions to Xen, we can drop the reference
to gcc's builtin __sync_fetch_and_add().
This requires some fudging using container_of() because the users of
__sync_fetch_and_add(), namely xen/spinlock.c, e
Use the new infrastructure for detecting CPU features in other ID
registers to detect the presence of Armv8.1-LSE atomic instructions,
as reported by ID_AA64ISAR0_EL1.Atomic.
While we're here, print detection of these instructions in setup.c's
processor_id().
Signed-off-by: Ash Wilding
---
xen/
This patch ports Linux's arm64 LL/SC and LSE atomics helpers to Xen,
using Linux 5.10-rc2 (last commit 3cea11cd5) as a basis.
The opening comment of each header file details the changes made to
that file while porting it to Xen.
!! NB: This patch breaks arm32 builds until the next patch in th
flight 156402 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156402/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl 12 debian-install fail REGR. vs. 152332
test-arm64-arm64-ex
flight 156407 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 156400
version targeted for testi
On 11/5/20 6:51 PM, Alex Bennée wrote:
> Chardev is already a typedef'ed struct.
>
> Signed-off-by: Alex Bennée
> ---
> include/hw/xen/xen.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé
On 11/5/20 6:51 PM, Alex Bennée wrote:
> We should never build something that calls this without having it.
"because ..."?
Reviewed-by: Philippe Mathieu-Daudé
>
> Signed-off-by: Alex Bennée
> ---
> stubs/xen-hw-stub.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/stubs/xen-hw-
On Wed, 4 Nov 2020, Jan Beulich wrote:
> On 04.11.2020 16:43, Jan Beulich wrote:
> > On 03.11.2020 16:59, Rahul Singh wrote:
> >> --- a/xen/drivers/pci/Kconfig
> >> +++ b/xen/drivers/pci/Kconfig
> >> @@ -1,3 +1,12 @@
> >>
> >> config HAS_PCI
> >>bool
> >> +
> >> +config PCI_ATS
> >> + bool
On Tue, 3 Nov 2020, Rahul Singh wrote:
> passthrough/pci.c file is common for all architecture, but there is x86
> sepcific code in this file.
^ specific
Aside from that:
Reviewed-by: Stefano Stabellini
> Move x86 specific code to the x86 directory to avoid compilation error
> for other arc
On Thu, 5 Nov 2020, Anthony PERARD wrote:
> On Thu, Nov 05, 2020 at 08:29:20AM -0800, Stefano Stabellini wrote:
> > On Thu, 5 Nov 2020, Anthony PERARD wrote:
> > > On Fri, Oct 30, 2020 at 10:46:37AM -0700, Stefano Stabellini wrote:
> > > > On Fri, 30 Oct 2020, Takahiro Akashi wrote:
> > > > > === a
libxl: set vuart_gfn in libxl__build_hvm
Setting vuart_gfn was missed when switching ARM guests to the PVH build.
Like libxl__build_pv, libxl__build_hvm should set state->vuart_gfn to
dom->vuart_gfn.
Without this change, xl console cannot connect to the vuart console (-t
vuart), see https://marc.
This is a note to let you know that I've just added the patch titled
linkage: Introduce new macros for assembler symbols
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
lin
From: Julien Grall
Even if debug trap are only meant for debugging purpose, it is quite
harsh to crash Xen if one of the trap sent by the guest is not handled.
So switch from a panic() to a printk().
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c | 2 +-
1 file changed, 1 insertion(+),
On Thu, Nov 05, 2020 at 10:31:06PM +, Julien Grall wrote:
> Even if debug trap are only meant for debugging purpose, it is quite
> harsh to crash Xen if one of the trap sent by the guest is not handled.
>
> So switch from a panic() to a printk().
Might this qualify as security due to potentia
On 05/11/2020 23:10, Elliott Mitchell wrote:
On Thu, Nov 05, 2020 at 10:31:06PM +, Julien Grall wrote:
Even if debug trap are only meant for debugging purpose, it is quite
harsh to crash Xen if one of the trap sent by the guest is not handled.
So switch from a panic() to a printk().
Mi
flight 156412 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156412/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 156345
Tests which did not succeed, b
On Wed, 4 Nov 2020, Jan Beulich wrote:
> All,
>
> the release is due in a couple of weeks time. Please point out
> backports you find missing from the respective staging branch,
> but which you consider relevant. (Ian: Please double check
> there are indeed no tools side backports needed here.)
>
On Thu, 5 Nov 2020, Julien Grall wrote:
> From: Julien Grall
>
> Even if debug trap are only meant for debugging purpose, it is quite
> harsh to crash Xen if one of the trap sent by the guest is not handled.
>
> So switch from a panic() to a printk().
>
> Signed-off-by: Julien Grall
Reviewed-
flight 156423 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156423/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruckbroken in 156398
Tests
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/0x60
...
Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
...
On Thu, Nov 05, 2020 at 07:35:29PM -0500, Brian Masney wrote:
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 799f4eba0a62..4a052459a08e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -93,9 +93,24 @@ void xen_init_lock_cpu(int cpu)
>
> void x
flight 156502 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156502/
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
While these may seem somewhat unrelated, the connection between them
is the middle of the patches
1: mm: introduce xvmalloc() et al and use for grant table allocations
2: x86/xstate: use xvzalloc() for save area allocation
3: x86/xstate: re-size save area when CPUID policy changes
Jan
All of the array allocations in grant_table_init() can exceed a page's
worth of memory, which xmalloc()-based interfaces aren't really suitable
for after boot. Introduce interfaces dynamically switching between
xmalloc() et al and vmalloc() et al, based on requested size, and use
them instead.
All
This is in preparation for the area size exceeding a page's worth of
space, as will happen with AMX as well as Architectural LBR.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
vCPU-s get maximum size areas allocated initially. Hidden (and in
particular default-off) features may allow for a smaller size area to
suffice.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
Seeing that both vcpu_init_fpu() and cpuid_policy_updated() get called
from arch_vcpu_create
On 06.11.2020 08:13, Jan Beulich wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -541,6 +541,41 @@ int xstate_alloc_save_area(struct vcpu *
>
> return 0;
> }
> +
> +int xstate_update_save_area(struct vcpu *v)
> +{
> +unsigned int i, size, old;
> +struct xsave
On 06.11.2020 02:58, Stefano Stabellini wrote:
> On Wed, 4 Nov 2020, Jan Beulich wrote:
>> the release is due in a couple of weeks time. Please point out
>> backports you find missing from the respective staging branch,
>> but which you consider relevant. (Ian: Please double check
>> there are inde
Hi Julien,
> On 5 Nov 2020, at 22:31, Julien Grall wrote:
>
> From: Julien Grall
>
> Even if debug trap are only meant for debugging purpose, it is quite
> harsh to crash Xen if one of the trap sent by the guest is not handled.
>
> So switch from a panic() to a printk().
Very smart idea :-)
71 matches
Mail list logo
