Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
Xen grant mappings") introduced a new requirement for using virtio
devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
feature.
This is an undue requirement for non-PV guests, as those can be operated
with
flight 171184 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171184/
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 171181 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171181/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 171174
build-i386
On Wed, 15 Jun 2022, Xenia Ragiadakou wrote:
> Add a new config parameter to configure a dom0less VM with static allocation.
> DOMU_STATIC_MEM[number]="baseaddr1 size1 ... baseaddrN sizeN"
> The parameter specifies the host physical address regions to be statically
> allocated to the VM. Each
On Wed, 15 Jun 2022, Julien Grall wrote:
> On 11/06/2022 01:41, Stefano Stabellini wrote:
> > > #endif /* __ASSEMBLY__ */
> > > /*
> > > diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> > > index 676740ef1520..6f90c08a6304 100644
> > > --- a/xen/arch/arm/vsmc.c
> > > +++
On Wed, 15 Jun 2022, Juergen Gross wrote:
> Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
> Xen grant mappings") introduced a new requirement for using virtio
> devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
> feature.
>
> This is an undue
flight 171180 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171180/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167674
Tests which did
On Wed, Jun 15, 2022 at 08:01:28PM +0100, Julien Grall wrote:
> Hi,
>
> On 15/06/2022 16:58, Jens Wiklander wrote:
> > On Fri, Jun 10, 2022 at 05:41:33PM -0700, Stefano Stabellini wrote:
> > > > #endif /* __ASSEMBLY__ */
> > > > /*
> > > > diff --git a/xen/arch/arm/vsmc.c
flight 171177 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw broken in 171168
test-arm64-arm64-examine
Hi Stefano,
On 11/06/2022 01:41, Stefano Stabellini wrote:
#endif /* __ASSEMBLY__ */
/*
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 676740ef1520..6f90c08a6304 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -93,7 +93,7 @@ static bool handle_arch(struct
Hi,
On 15/06/2022 16:58, Jens Wiklander wrote:
On Fri, Jun 10, 2022 at 05:41:33PM -0700, Stefano Stabellini wrote:
#endif /* __ASSEMBLY__ */
/*
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 676740ef1520..6f90c08a6304 100644
--- a/xen/arch/arm/vsmc.c
+++
Add a new config parameter to configure a dom0less VM with static allocation.
DOMU_STATIC_MEM[number]="baseaddr1 size1 ... baseaddrN sizeN"
The parameter specifies the host physical address regions to be statically
allocated to the VM. Each region is defined by its start address and size.
For
Hi Bertrand,
On 13/06/2022 13:53, Bertrand Marquis wrote:
This patch is adding sb instruction support when it is supported by a
CPU on arm64.
A new cpu feature capability system is introduced to enable alternative
code using sb instruction when it is supported by the processor. This is
decided
Hi,
On 14/06/2022 20:47, Volodymyr Babchuk wrote:
menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1d862351d111..dbf5e593a069 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -20,6 +20,7 @@ obj-y +=
On 15.06.22 03:45, Stefano Stabellini wrote:
Hello Stefano
On Tue, 14 Jun 2022, Oleksandr wrote:
On 11.06.22 03:12, Stefano Stabellini wrote:
On Wed, 8 Jun 2022, Oleksandr wrote:
2. Drop the "page_list" entirely and use "dma_pool" for all (contiguous
and
non-contiguous) allocations.
On 15.06.22 03:51, Stefano Stabellini wrote:
Hello Stefano
On Tue, 14 Jun 2022, Oleksandr wrote:
On 11.06.22 02:55, Stefano Stabellini wrote:
Hello Stefano
On Thu, 9 Jun 2022, Oleksandr wrote:
On 04.06.22 00:19, Stefano Stabellini wrote:
Hello Stefano
Thank you for having a look and
On 15.06.22 17:23, Anthony PERARD wrote:
Hello Anthony
On Mon, Jun 13, 2022 at 09:05:20PM +0300, Oleksandr Tyshchenko wrote:
diff --git a/tools/libs/light/libxl_disk.c b/tools/libs/light/libxl_disk.c
index a5ca778..673b0d6 100644
--- a/tools/libs/light/libxl_disk.c
+++
On Fri, Jun 10, 2022 at 05:41:33PM -0700, Stefano Stabellini wrote:
> On Thu, 9 Jun 2022, Jens Wiklander wrote:
> > SMCCC v1.2 AArch64 allows x0-x17 to be used as both parameter registers
> > and result registers for the SMC and HVC instructions.
> >
> > Arm Firmware Framework for Armv8-A
On 15.06.22 11:48, Juergen Gross wrote:
Hello Juergen
Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
Xen grant mappings") introduced a new requirement for using virtio
devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
feature.
This is an undue
On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> The ehci number was parsed but ignored.
Oops.
> Signed-off-by: Marek Marczykowski-Górecki
This could do with a Fixes: tag. Then
Reviewed-by: Jan Beulich
Jan
flight 171175 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171175/
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 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -721,10 +721,15 @@ Available alternatives, with their meaning, are:
>
> ### dbgp
> > `= ehci[ | @pci:. ]`
> +> `= xue[ | @pci:. ]`
>
> Specify
Perfect Petr, thanks for your feedback!
I'll be out for some weeks, but after that what I'm doing is to split
the series in 2 parts:
(a) The general fixes, which should be reviewed by subsystem maintainers
and even merged individually by them.
(b) The proper panic refactor, which includes the
On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> Reset ports, to force host system to re-enumerate devices. Otheriwse it
> will require the cable to be re-plugged, or will wait in the
> "configuring" state indefinitely.
>
> Trick and code copied from Linux:
>
flight 171174 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 171157 REGR. vs. 171174
Tests which are
On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> From: Connor Davis
>
> [Connor]
> Xue is a cross-platform USB 3 debugger that drives the Debug
> Capability (DbC) of xHCI-compliant host controllers. This patch
> implements the operations needed for xue to initialize the host
>
On Mon, Jun 13, 2022 at 09:05:20PM +0300, Oleksandr Tyshchenko wrote:
> diff --git a/tools/libs/light/libxl_disk.c b/tools/libs/light/libxl_disk.c
> index a5ca778..673b0d6 100644
> --- a/tools/libs/light/libxl_disk.c
> +++ b/tools/libs/light/libxl_disk.c
> @@ -575,6 +660,41 @@ cleanup:
>
flight 171173 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171173/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit2 18 guest-start/debian.repeatfail like 170846
test-armhf-armhf-xl-credit1 14
On 15.06.22 15:43, Christoph Hellwig wrote:
On Wed, Jun 15, 2022 at 02:53:54PM +0200, Juergen Gross wrote:
On 15.06.22 13:54, Christoph Hellwig wrote:
On Wed, Jun 15, 2022 at 01:39:01PM +0200, Juergen Gross wrote:
No, it doesn't. I'm working on a qemu patch series enabling the qemu
based
On Wed, Jun 15, 2022 at 02:53:54PM +0200, Juergen Gross wrote:
> On 15.06.22 13:54, Christoph Hellwig wrote:
> > On Wed, Jun 15, 2022 at 01:39:01PM +0200, Juergen Gross wrote:
> > > No, it doesn't. I'm working on a qemu patch series enabling the qemu
> > > based backends to support grants with
flight 171171 qemu-mainline real [real]
flight 171179 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171171/
http://logs.test-lab.xenproject.org/osstest/logs/171179/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 171178 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171178/
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 15.06.22 13:54, Christoph Hellwig wrote:
On Wed, Jun 15, 2022 at 01:39:01PM +0200, Juergen Gross wrote:
No, it doesn't. I'm working on a qemu patch series enabling the qemu
based backends to support grants with virtio. The code is working fine
on x86, too (apart from the fact that the
On 15.06.22 09:23, Viresh Kumar wrote:
Hi Oleksandr,
Hello Viresh
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
wrote:
The high level idea is to create new Xen’s grant table based DMA-mapping layer
for the guest Linux whose main
purpose is to provide a special 64-bit DMA
On Wed, Jun 15, 2022 at 01:39:01PM +0200, Juergen Gross wrote:
> No, it doesn't. I'm working on a qemu patch series enabling the qemu
> based backends to support grants with virtio. The code is working fine
> on x86, too (apart from the fact that the backends aren't ready yet).
The code right now
On 15.06.22 13:28, Christoph Hellwig wrote:
On Wed, Jun 15, 2022 at 01:26:27PM +0200, Juergen Gross wrote:
On 15.06.22 13:24, Christoph Hellwig wrote:
I don't think this command line mess is a good idea. Instead the
brand new grant devices need to be properly advertised in the device
tree,
On Wed, Jun 15, 2022 at 01:26:27PM +0200, Juergen Gross wrote:
> On 15.06.22 13:24, Christoph Hellwig wrote:
> > I don't think this command line mess is a good idea. Instead the
> > brand new grant devices need to be properly advertised in the device
> > tree, and any device that isn't a grant
On 15.06.22 13:24, Christoph Hellwig wrote:
I don't think this command line mess is a good idea. Instead the
brand new grant devices need to be properly advertised in the device
tree, and any device that isn't a grant device doesn't need
VIRTIO_F_ACCESS_PLATFORM. No need for a command line or
I don't think this command line mess is a good idea. Instead the
brand new grant devices need to be properly advertised in the device
tree, and any device that isn't a grant device doesn't need
VIRTIO_F_ACCESS_PLATFORM. No need for a command line or user
intervention.
On 15.06.2022 12:31, Anthony PERARD wrote:
> On Wed, Jun 15, 2022 at 08:37:42AM +0200, Jan Beulich wrote:
>> On 14.06.2022 18:22, Anthony PERARD wrote:
>>> diff --git a/xen/include/Makefile b/xen/include/Makefile
>>> index 6d9bcc19b0..49c75a78f9 100644
>>> --- a/xen/include/Makefile
>>> +++
Aspects to consider are that these have 32-bit element size (pairs of
FP16) and that there are restrictions on the registers valid to use.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -614,12 +614,18 @@ static const struct
While, as before, this leverages that the Map6 encoding space is a very
sparse clone of the "0f38" one, switch around the simd_size overriding
for opcode 2D. This way less separate overrides are needed.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年6月15日 17:47
> To: Wei Chen ; xen-devel@lists.xenproject.org
> Cc: nd ; Stefano Stabellini ; Bertrand
> Marquis ; Volodymyr Babchuk
>
> Subject: Re: [PATCH] xen/arm: avoid vtimer flip-flop transition in context
> switch
>
Naming of some of the builtins isn't fully consistent with that of
pre-existing ones, so there's a need for a new BR2() wrapper macro.
With the tests providing some proof of proper functioning of the
emulator code also enable use of the feature by guests, as there's no
other infrastructure
On Wed, Jun 15, 2022 at 08:37:42AM +0200, Jan Beulich wrote:
> On 14.06.2022 18:22, Anthony PERARD wrote:
> > diff --git a/xen/include/Makefile b/xen/include/Makefile
> > index 6d9bcc19b0..49c75a78f9 100644
> > --- a/xen/include/Makefile
> > +++ b/xen/include/Makefile
> > @@ -158,13 +158,22 @@
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -612,18 +612,36 @@ static const struct test avx512_fp16_all
INSN(cmpph, , 0f3a, c2,vl, fp16, vl),
INSN(cmpsh, f3, 0f3a, c2,el, fp16, el),
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -612,8 +612,16 @@ static const struct test avx512_fp16_all
INSN(cmpph, , 0f3a, c2,vl, fp16, vl),
INSN(cmpsh, f3, 0f3a, c2,el, fp16, el),
These are easiest in that they have same-size source and destination
vectors, yet they're different from other conversion insns in that they
use opcodes which have different meaning in the 0F encoding space
({,V}H{ADD,SUB}P{S,D}), hence requiring a little bit of overriding.
Signed-off-by: Jan
The Map6 encoding space is a very sparse clone of the "0f38" one. Once
again re-use that table, as the entries corresponding to invalid opcodes
in Map6 are simply benign with simd_size forced to other than simd_none
(preventing undue memory reads in SrcMem handling early in
x86_emulate()).
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -622,6 +622,8 @@ static const struct test avx512_fp16_all
INSN(maxsh, f3, map5, 5f,el, fp16, el),
INSN(minph, , map5, 5d,vl, fp16, vl),
This encoding space is a very sparse clone of the "twobyte" one. Re-use
that table, as the entries corresponding to invalid opcodes in Map5 are
simply benign with simd_size forced to other than simd_none (preventing
undue memory reads in SrcMem handling early in x86_emulate()).
Signed-off-by: Jan
In order to re-use (also in subsequent patches) existing code and tables
as much as possible, simply introduce a new boolean field in emulator
state indicating whether an insn is one with a half-precision source.
Everything else then follows "naturally".
Signed-off-by: Jan Beulich
---
SDE: -spr
Signed-off-by: Jan Beulich
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -221,6 +221,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"serialize",0x0007, 0, CPUID_REG_EDX, 14, 1},
{"tsxldtrk", 0x0007, 0, CPUID_REG_EDX, 16, 1},
While I (quite obviously) don't have any suitable hardware, Intel's
SDE allows testing the implementation. And since there's no new
state (registers) associated with this ISA extension, this should
suffice for integration.
01: CPUID: AVX512-FP16 definitions
02: handle AVX512-FP16 insns encoded in
Hello everyone,
The Xen Project Design and Developer Summit 2022 is officially announced in
Cambridge, UK, for 19-2 September:
https://events.linuxfoundation.org/xen-summit/
The Call for Papers is open as well; please submit talks here:
The function is already non-trivial and is expected to further grow.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be phased out anyway).
Signed-off-by: Jan Beulich
---
v2: Re-base.
---
On 10.06.2022 11:13, Bertrand Marquis wrote:
> cppcheck MISRA addon can be used to check for non compliance to some of
> the MISRA standard rules.
>
> Add a CPPCHECK_MISRA variable that can be set to "y" using make command
> line to generate a cppcheck report including cppcheck misra checks.
>
>
Emulator code is large and involving it in guest operations cannot be
expected to be fast anyway. Help binary size as well as, for release
builds at least, compile time by building all involved code with size
optimization, independent of the build being a debug or a release one.
The size savings
Many are needed by the hypervisor only - have one file for this purpose.
Some are also needed by the harness (but not the fuzzer) - have another
file for these.
Code moved gets slightly adjusted in a few places, e.g. replacing
"state" by "s" (like was done for other that has been split off).
This is a fair chunk of code and data and can easily live separate from
the main emulation function.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be phased out anyway).
Signed-off-by: Jan
Some of the helper functions/macros are needed only for this, and the
code is otherwise relatively independent of other parts of the emulator.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be
There's a fair amount of sub-cases (with some yet to be implemented), so
a separate function seems warranted.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be phased out anyway).
Signed-off-by:
There's a fair amount of sub-cases (with some yet to be implemented), so
a separate function seems warranted.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be phased out anyway).
Signed-off-by:
There's a fair amount of sub-cases (with some yet to be implemented), so
a separate function seems warranted.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be phased out anyway).
Signed-off-by:
... of the huge monolithic source file. The series is largely code
movement and hence has the intention of not incurring any functional
change.
It has now been almost a year since the v1 submission, without having
had any feedback. Some re-basing was necessary in the meantime, and a
new patch
Hi Wei,
Title: I don't quite understand what you mean by "flip-flop transition".
On 15/06/2022 02:39, Wei Chen wrote:
virt_vtimer_save is calculating the new time for the vtimer and
has a potential risk of timer flip in:
"v->arch.virt_timer.cval + v->domain->arch.virt_timer_base.offset
-
On 15.06.22 11:25, Viresh Kumar wrote:
On 15-06-22, 10:48, Juergen Gross wrote:
Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
Xen grant mappings") introduced a new requirement for using virtio
devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
On 15-06-22, 10:48, Juergen Gross wrote:
> Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
> Xen grant mappings") introduced a new requirement for using virtio
> devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
> feature.
>
> This is an undue
Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
Xen grant mappings") introduced a new requirement for using virtio
devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
feature.
This is an undue requirement for non-PV guests, as those can be operated
with
flight 171168 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171168/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw broken
test-arm64-arm64-libvirt-raw 5
Add a new config parameter to configure a dom0less VM with static allocation.
DOMU_STATIC_MEM[number]="baseaddr1 size1 ... baseaddrN sizeN"
The parameter specifies the host physical address regions to be statically
allocated to the VM. Each region is defined by its start address and size.
For
On 14.06.2022 18:22, Anthony PERARD wrote:
> The command line generated for headers++.chk by make is quite long,
> and in some environment it is too long. This issue have been seen in
> Yocto build environment.
>
> Error messages:
> make[9]: execvp: /bin/sh: Argument list too long
>
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping
> layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using
> the grant reference (for a
On 14.06.2022 18:22, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -22,6 +22,7 @@ PYTHON_INTERPRETER := $(word 1,$(shell which python3
> python python2 2>/dev/null)
> export PYTHON?= $(PYTHON_INTERPRETER)
>
> export CHECKPOLICY ?= checkpolicy
>
On Tue, 14 Jun 2022 17:24:48 +0100,
Mark Rutland wrote:
>
> On Wed, Jun 08, 2022 at 04:27:46PM +0200, Peter Zijlstra wrote:
> > Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as
> > normal interrupts") this function is called in regular IRQ context.
> >
> > Signed-off-by:
75 matches
Mail list logo
