This is a design doc for GICv4.0 vLPI support.
Signed-off-by: Penny Zheng
---
docs/designs/gicv4_vlpi.md | 333 +
1 file changed, 333 insertions(+)
create mode 100644 docs/designs/gicv4_vlpi.md
diff --git a/docs/designs/gicv4_vlpi.md b/docs/designs/gicv4_vlp
flight 181580 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
Tests which are fai
flight 181577 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-build fail in 181563 REGR. vs. 181363
Tests which are faili
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first. However, Qubes OS's GUI protocol is subject to the constraints
of the X Window
flight 181575 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181575/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-migrupgrade 11 xen-install/dst_host fail pass in 181565
test-amd64-i386-xl-qemut-debianh
We want all accelerators to share the same opaque pointer in
CPUState.
Rename the 'hvf_vcpu_state' structure as 'AccelCPUState'.
Use the generic 'accel' field of CPUState instead of 'hvf'.
Replace g_malloc0() by g_new0() for readability.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richa
g_new0() can not fail. Remove the unreachable error path.
https://developer-old.gnome.org/glib/stable/glib-Memory-Allocation.html#glib-Memory-Allocation.description
Reported-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/whpx/whpx-al
g_malloc0() can not fail. Remove the unreachable error path.
https://developer-old.gnome.org/glib/stable/glib-Memory-Allocation.html#glib-Memory-Allocation.description
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/nvmm/nvmm-all.c | 4
1 file changed,
No need for this helper to access the CPUState::accel field.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/whpx/whpx-all.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/target/i386/whpx/whpx-all.c b/tar
hThread variable is only used by the HAX accelerator,
so move it to the accelerator specific context.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
include/hw/core/cpu.h | 1 -
target/i386/hax/hax-i386.h | 3 +++
target/i386/hax/hax-accel-ops.c | 2 +-
We want all accelerators to share the same opaque pointer in
CPUState. Rename WHPX 'whpx_vcpu' as 'AccelCPUState'; use
the typedef.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/whpx/whpx-all.c | 30 +++---
1 file changed, 15 insert
No need for this helper to access the CPUState::accel field.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/nvmm/nvmm-all.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/target/i386/nvmm/nvmm-all.c b/targ
We want all accelerators to share the same opaque pointer in
CPUState. Rename NVMM 'qemu_vcpu' as 'AccelCPUState'; directly
use the typedef, remove unnecessary casts.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/nvmm/nvmm-all.c | 32 --
Most of the codebase uses 'CPUState *cpu' or 'CPUState *cs'.
While 'cpu_state' is kind of explicit, it makes the code
harder to review. Simply rename as 'cs'.
Acked-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/hvf/x86hvf.h | 18 +-
target/i386/hvf/x86hvf.c | 372
We want all accelerators to share the same opaque pointer in
CPUState. Start with the HAX context, renaming its forward
declarated structure 'hax_vcpu_state' as 'AccelCPUState'.
Document the CPUState field. Directly use the typedef.
Remove the amusing but now unnecessary casts in NVMM / WHPX.
Sig
All accelerators will share a single opaque context
in CPUState. Start by renaming 'hax_vcpu' as 'accel'.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 2 +-
target/i386/hax/hax-accel-ops.c | 2 +-
target/i386/hax/hax-all.c |
When the vCPU thread finished its processing, destroy
it and signal its destruction to generic vCPU management
layer.
Add a sanity check for the vCPU accelerator context.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/hax/hax-accel-ops.c | 3 +++
target/i3
hThread is only used on the error path in hax_kick_vcpu_thread().
Fixes: b0cb0a66d6 ("Plumb the HAXM-based hardware acceleration support")
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/hax/hax-all.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ta
On Windows hosts, cpu->hThread is assigned but never accessed:
remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/tcg/tcg-accel-ops-mttcg.c | 4
accel/tcg/tcg-accel-ops-rr.c | 3 ---
target/i386/whpx/whpx-accel-ops.c | 3 ---
3 files changed, 1
These headers are meant to be include by any file to check
the availability of accelerators, thus are not accelerator
specific.
Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Richard Henderson
---
include/sysemu/hax.h | 2 ++
include/sysemu/kvm.h | 2 ++
include/sysemu/nvmm.h | 2 ++
include
r.bolsha...@yadro.com is bouncing: Update Roman's email address
using one found somewhere on the Internet; this way he can Ack-by.
(Reorder Taylor's line to keep the section sorted alphabetically).
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 4 ++--
.mailmap| 3 ++-
2 files chan
This series is part of the single binary effort.
All accelerator will share their per-vCPU context in
an opaque 'accel' pointer within the CPUState.
First handle HAX/NVMM/WHPX/HVF. KVM and TCG will follow
as two different (bigger) follow-up series.
Except HVF/intel, all has been (cross-)build te
On 22/6/23 19:46, Richard Henderson wrote:
On 6/22/23 18:08, Philippe Mathieu-Daudé wrote:
|+ struct AccelvCPUState *accel;|
...
+typedef struct AccelCPUState {
hax_fd fd;
int vcpu_id;
struct hax_tunnel *tunnel;
unsigned char *iobuf;
-};
+} hax_vcpu_state;
Discussed face
flight 181573 linux-linus real [real]
flight 181579 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181573/
http://logs.test-lab.xenproject.org/osstest/logs/181579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On Thu, Jun 22, 2023, at 10:20 AM, Juergen Gross wrote:
> On 22.06.23 18:39, Andy Lutomirski wrote:
>> On Thu, Jun 22, 2023, at 3:33 AM, Juergen Gross wrote:
>>> On 22.06.23 10:26, Peter Zijlstra wrote:
On Thu, Jun 22, 2023 at 07:22:53AM +0200, Juergen Gross wrote:
> The hypercalls we
Hello Julien,
Thank you very much for your reply. Can you teach me how to find the
relationship between MBI-gen and devices?
I am not sure how to find out the mbi-gen backed devices..
Best Regards,
Jiatong Shen
On Sat, Jun 24, 2023 at 4:24 PM Julien Grall wrote:
> Hi,
>
> On 20/06/2023 08:0
Hi Yann,
Adding Juergen.
On 31/05/2023 11:35, Yann Dirson wrote:
Signed-off-by: Yann Dirson
Reviewed-by: Julien Grall
Cheers,
---
docs/misc/xenstore-paths.pandoc | 29 +
1 file changed, 29 insertions(+)
diff --git a/docs/misc/xenstore-paths.pandoc b/docs/m
Hi Jan,
On 17/05/2023 15:19, Jan Beulich wrote:
We still don't use it (in the tool stack), and its values (plural) also
aren't fetched correctly, but it is odd to continue to see the
hypervisor log "ELF: note: unknown (0xd)" when loading a Linux Dom0.
Signed-off-by: Jan Beulich
Acked-by: Jul
Stefano: 2min summary: gitlab as CI infrastucture, not as code hosting, tickets
etc;
we have several improvements for gitlab CI, including tests on hw
there are a bunch of build jobs, and also some run tests, most on qemu, but
some on hw
I'd like to give commiters and other notable communit
Hi,
Here is what I managed to capture, unfortunately some parts slipped by
me.
Julien: remove directmap, avoid speculative reading it
series sent 6 months ago - enough to remove directmap, but not perfect
resolving virtual adresses requires mapping/unmapping page tables -
significant perf h
flight 181571 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt broken
build-amd64 6 xen-build
Hi,
On 20/06/2023 08:09, Jiatong Shen wrote:
Hello Julien,
Sorry for the delay.. I obtained the full xen log and attached it in the
mail. Please take a look when you are available. Thank you very much
Thanks for sharing the logs. The following lines are interesting:
[1.081905] Hisili
Hi,
On 21/06/2023 11:13, Michal Orzel wrote:
On 21/06/2023 12:02, Julien Grall wrote:
Hi,
On 21/06/2023 10:33, Michal Orzel wrote:
On 19/06/2023 19:01, Julien Grall wrote:
From: Julien Grall
On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
the following paragrap
On 24.06.2023 09:11, Julien Grall wrote:
> On 23/06/2023 18:16, Jan Beulich wrote:
>> I'm not happy to, with the continued use of the
>> two U suffixes. It may seem minor, but to me it feels like setting a
>> bad precedent.
>
> I wasn't able to find the reasoning behind your objections in the
> a
Hi,
First, one remark about the title. We don't usually add full stop in the
title. I am happy to fix it on commit.
On 23/06/2023 18:16, Jan Beulich wrote:
I'm not happy to, with the continued use of the
two U suffixes. It may seem minor, but to me it feels like setting a
bad precedent.
I w
Hi,
On 23/06/2023 22:26, Julien Grall wrote:
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -322,7 +322,7 @@ cpu_init:
PRINT("- Setting up control registers -\r\n")
mov r5, lr /* r5 := return address */
-
+#ifndef CONFIG_ARM_NO_PRO
flight 181565 xen-unstable real [real]
flight 181574 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181565/
http://logs.test-lab.xenproject.org/osstest/logs/181574/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
37 matches
Mail list logo
