Re: [PATCH v3 1/6] xen/riscv: introduce dummy asm/init.h
On 10.01.2023 20:16, Oleksii wrote: > Sorry for breaking into the conversation. That's perfectly fine; no need to be sorry. > On Tue, 2023-01-10 at 18:02 +0100, Jan Beulich wrote: >> Arm maintainers, >> >> On 10.01.2023 16:17, Oleksii Kurochko wrote: >>> --- /dev/null >>> +++ b/xen/arch/riscv/include/asm/init.h >>> @@ -0,0 +1,12 @@ >>> +#ifndef _XEN_ASM_INIT_H >>> +#define _XEN_ASM_INIT_H >>> + >>> +#endif /* _XEN_ASM_INIT_H */ >> >> instead of having RISC-V introduce an empty stub matching what x86 >> has, > Have you had a chance to look at the answer (Re: [PATCH v1 0/8] Basic > early_printk and smoke test implementation) of Andrew: > https://lore.kernel.org/xen-devel/299d913c-8095-ad90-ea3b-d46ef74d4...@citrix.com/#t > > I agree with his point regarding the usage of __has_include() to not > produce empty headers stubs for RISCV and for future architectures too. Sure, but as he said, that requires settling on a new toolchain baseline, which is something that we've failed to come to any results for, for a considerable number of years. Plus if we could get rid of this (then optional) arch header altogether, it would imo be even better. Jan
Re: [PATCH] bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plx
On 10/1/23 23:01, BALATON Zoltan wrote: On Tue, 10 Jan 2023, Philippe Mathieu-Daudé wrote: The 'hwaddr' type is defined in "exec/hwaddr.h" as: hwaddr is the type of a physical address (its size can be different from 'target_ulong'). All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx: $ fgrep define include/exec/hwaddr.h #define HWADDR_H #define HWADDR_BITS 64 #define HWADDR_MAX UINT64_MAX #define TARGET_FMT_plx "%016" PRIx64 ^^ #define HWADDR_PRId PRId64 #define HWADDR_PRIi PRIi64 #define HWADDR_PRIo PRIo64 #define HWADDR_PRIu PRIu64 #define HWADDR_PRIx PRIx64 Why are there both TARGET_FMT_plx and HWADDR_PRIx? Why not just use HWADDR_PRIx instead? Too lazy to specify the 0-digit alignment format I presume?
Re: [PATCH v2 08/19] tools/xenstore: replace watch->relative_path with a prefix length
On 20.12.22 20:42, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -313,19 +302,19 @@ const char *dump_state_watches(FILE *fp, struct
connection *conn,
unsigned int conn_id)
{
const char *ret = NULL;
+ const char *watch_path;
struct watch *watch;
struct xs_state_watch sw;
struct xs_state_record_header head;
- const char *path;
head.type = XS_STATE_TYPE_WATCH;
list_for_each_entry(watch, &conn->watches, list) {
head.length = sizeof(sw);
+ watch_path = get_watch_path(watch, watch->node);
It is not clear to me why you call get_watch_path() earlier and also rename the
variable.
I don't mind the new name, but it doesn't feel like it belongs to this patch as
the code in duymp_state_watches() would not be changed otherwise.
Both changes are the result of V1 of the series. Will undo them.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 07/19] tools/xenstore: introduce dummy nodes for special watch paths
On 20.12.22 20:39, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
Instead of special casing the permission handling and watch event
firing for the special watch paths "@introduceDomain" and
"@releaseDomain", use static dummy nodes added to the data base when
starting Xenstore.
The node accounting needs to reflect that change by adding the special
nodes in the domain_entry_fix() call in setup_structure().
Note that this requires to rework the calls of fire_watches() for the
special events in order to avoid leaking memory.
Move the check for a valid node name from get_node() to
get_node_canonicalized(), as it allows to use get_node() for the
special nodes, too.
In order to avoid read and write accesses to the special nodes use a
special variant for obtaining the current node data for the permission
handling.
This allows to simplify quite some code. In future sub-nodes of the
special nodes will be possible due to this change, allowing more fine
grained permission control of special events for specific domains.
Signed-off-by: Juergen Gross
---
V2:
- add get_spec_node()
- expand commit message (Julien Grall)
---
tools/xenstore/xenstored_control.c | 3 -
tools/xenstore/xenstored_core.c | 92 +---
tools/xenstore/xenstored_domain.c | 162 -
tools/xenstore/xenstored_domain.h | 6 --
tools/xenstore/xenstored_watch.c | 17 +--
5 files changed, 80 insertions(+), 200 deletions(-)
diff --git a/tools/xenstore/xenstored_control.c
b/tools/xenstore/xenstored_control.c
index d1aaa00bf4..41e6992591 100644
--- a/tools/xenstore/xenstored_control.c
+++ b/tools/xenstore/xenstored_control.c
@@ -676,9 +676,6 @@ static const char *lu_dump_state(const void *ctx, struct
connection *conn)
if (ret)
goto out;
ret = dump_state_connections(fp);
- if (ret)
- goto out;
- ret = dump_state_special_nodes(fp);
if (ret)
goto out;
ret = dump_state_nodes(fp, ctx);
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 1650821922..f96714e1b8 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -616,7 +616,8 @@ static void get_acc_data(TDB_DATA *key, struct
node_account_data *acc)
static unsigned int get_acc_domid(struct connection *conn, TDB_DATA *key,
unsigned int domid)
{
- return (!conn || key->dptr[0] == '/') ? domid : conn->id;
+ return (!conn || key->dptr[0] == '/' || key->dptr[0] == '@')
The comment on top of get_acc_domid() needs to be updated.
Oh, yes.
+ ? domid : conn->id;
}
[...]
+static void fire_special_watches(const char *name)
+{
+ void *ctx = talloc_new(NULL);
+ struct node *node;
+
+ if (!ctx)
+ return;
+
+ node = read_node(NULL, ctx, name);
+
+ if (node)
+ fire_watches(NULL, ctx, name, node, true, NULL);
NIT: I would consider to log an error (maybe only once) if 'node' is NULL. The
purpose is to help debugging Xenstored.
I think we can log it always, as this is really a bad problem.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 04/19] tools/xenstore: remove all watches when a domain has stopped
On 20.12.22 20:01, Julien Grall wrote: Hi Juergen, On 13/12/2022 16:00, Juergen Gross wrote: When a domain has been released by Xen tools, remove all its registered watches. This avoids sending watch events to the dead domain when all the nodes related to it are being removed by the Xen tools. AFAICT, the only user of the command in the tree is softreset. Would you be able to check this is still working as expected? Seems to work fine. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[qemu-mainline test] 175716: regressions - FAIL
flight 175716 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175716/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 175623 build-amd64 6 xen-buildfail REGR. vs. 175623 build-i3866 xen-buildfail REGR. vs. 175623 build-arm64-xsm 6 xen-buildfail REGR. vs. 175623 build-i386-xsm6 xen-buildfail REGR. vs. 175623 build-arm64 6 xen-buildfail REGR. vs. 175623 build-armhf 6 xen-buildfail REGR. vs. 175623 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1
[xtf test] 175715: all pass - PUSHED
flight 175715 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175715/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf c0f454c68329301447fd258e47824f7d402f19e9 baseline version: xtf d1b8b7c312d2cf0e501ed43e88e45bba2c6986b5 Last test of basis 175508 2022-12-27 20:12:16 Z 14 days Testing same since 175715 2023-01-11 01:41:46 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64-xtf pass build-amd64 pass build-amd64-pvopspass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xtf.git d1b8b7c..c0f454c c0f454c68329301447fd258e47824f7d402f19e9 -> xen-tested-master
[linux-linus test] 175706: regressions - FAIL
flight 175706 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175706/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 173462 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 173462 test-amd64-amd64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-pair12 xen-boot/src_hostfail REGR. vs. 173462 test-amd64-amd64-pair13 xen-boot/dst_hostfail REGR. vs. 173462 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-win7-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-win7-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-qemuu-nested-amd 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-xl-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-pvhv2-amd 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-freebsd11-amd64 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-pygrub 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-shadow8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-pvshim8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-debianhvm-amd64 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-ovmf-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-examine 8 reboot fail REGR. vs. 173462 test-amd64-coresched-amd64-xl 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-examine 8 reboot
[qemu-mainline test] 175709: regressions - FAIL
flight 175709 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 175623 build-amd64 6 xen-buildfail REGR. vs. 175623 build-i3866 xen-buildfail REGR. vs. 175623 build-arm64-xsm 6 xen-buildfail REGR. vs. 175623 build-i386-xsm6 xen-buildfail REGR. vs. 175623 build-arm64 6 xen-buildfail REGR. vs. 175623 build-armhf 6 xen-buildfail REGR. vs. 175623 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1
[xen-unstable-smoke test] 175712: tolerable all pass - PUSHED
flight 175712 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175712/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 4d975798e11579fdf405b348543061129e01b0fb baseline version: xen 692d04a9ca429ca574d859fa8f43578e03b9f8b3 Last test of basis 175653 2023-01-09 18:05:52 Z1 days Testing same since 175712 2023-01-10 22:00:26 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Julien Grall jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 692d04a9ca..4d975798e1 4d975798e11579fdf405b348543061129e01b0fb -> smoke
[ovmf test] 175711: tolerable FAIL - PUSHED
flight 175711 ovmf real [real] flight 175713 ovmf real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/175711/ http://logs.test-lab.xenproject.org/osstest/logs/175713/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail pass in 175713-retest version targeted for testing: ovmf fe405f08a09e9f2306c72aa23d8edfbcfaa23bff baseline version: ovmf ec54ce1f1ab41b92782b37ae59e752fff0ef9c41 Last test of basis 175707 2023-01-10 17:40:54 Z0 days Testing same since 175711 2023-01-10 21:40:39 Z0 days1 attempts People who touched revisions under test: Michael D Kinney Zachary Clark-Williams Zachary Clark-Williams jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git ec54ce1f1a..fe405f08a0 fe405f08a09e9f2306c72aa23d8edfbcfaa23bff -> xen-tested-master
[qemu-mainline bisection] complete build-armhf
branch xen-unstable xenbranch xen-unstable job build-armhf testid xen-build Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 3d83b78285d6e96636130f7d449fd02e2d4deee0 Bug not present: 528d9f33cad5245c1099d77084c78bb2244d5143 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/175708/ commit 3d83b78285d6e96636130f7d449fd02e2d4deee0 Merge: 528d9f33ca fb418b51b7 Author: Peter Maydell Date: Sun Jan 8 14:27:40 2023 + Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging * Atomic memslot updates for KVM (Emanuele, David) * Always send errors to logfile when daemonized (Greg) * Add support for IDE CompactFlash card (Lubomir) * First round of build system cleanups (myself) * First round of feature removals (myself) * Reduce "qemu/accel.h" inclusion (Philippe) # gpg: Signature made Thu 05 Jan 2023 23:51:09 GMT # gpg:using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg:issuer "pbonz...@redhat.com" # gpg: Good signature from "Paolo Bonzini " [full] # gpg: aka "Paolo Bonzini " [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (24 commits) i386: SGX: remove deprecated member of SGXInfo target/i386: Add SGX aex-notify and EDECCSSA support util: remove support -chardev tty and -chardev parport util: remove support for hex numbers with a scaling suffix KVM: remove support for kernel-irqchip=off docs: do not talk about past removal as happening in the future meson: accept relative symlinks in "meson introspect --installed" data meson: cleanup compiler detection meson: support meson 0.64 -Doptimization=plain configure: test all warnings tests/qapi-schema: remove Meson workaround meson: cleanup dummy-cpus.c rules meson: tweak hardening options for Windows configure: remove backwards-compatibility and obsolete options configure: preserve qemu-ga variables configure: cleanup $cpu tests configure: remove dead function configure: remove useless write_c_skeleton ide: Add "ide-cf" driver, a CompactFlash card ide: Add 8-bit data mode ... Signed-off-by: Peter Maydell commit fb418b51b7b43c34873f4b9af3da7031b7452115 Author: Paolo Bonzini Date: Fri Dec 16 11:02:48 2022 +0100 i386: SGX: remove deprecated member of SGXInfo Signed-off-by: Paolo Bonzini commit d45f24fe7525d8a8aaa4ca6d9d214dc41819caa5 Author: Kai Huang Date: Wed Nov 9 15:48:34 2022 +1300 target/i386: Add SGX aex-notify and EDECCSSA support The new SGX Asynchronous Exit (AEX) notification mechanism (AEX-notify) allows one enclave to receive a notification in the ERESUME after the enclave exit due to an AEX. EDECCSSA is a new SGX user leaf function (ENCLU[EDECCSSA]) to facilitate the AEX notification handling. Whether the hardware supports to create enclave with AEX-notify support is enumerated via CPUID.(EAX=0x12,ECX=0x1):EAX[10]. The new EDECCSSA user leaf function is enumerated via CPUID.(EAX=0x12,ECX=0x0):EAX[11]. Add support to allow to expose the new SGX AEX-notify feature and the new EDECCSSA user leaf function to KVM guest. Link: https://lore.kernel.org/lkml/166760360549.4906.809756297092548496.tip-bot2@tip-bot2/ Link: https://lore.kernel.org/lkml/166760360934.4906.2427175408052308969.tip-bot2@tip-bot2/ Reviewed-by: Yang Zhong Signed-off-by: Kai Huang Message-Id: <20221109024834.172705-1-kai.hu...@intel.com> Signed-off-by: Paolo Bonzini commit 6f9f630836df355b9ca3f4641e6b7be71f6af076 Author: Paolo Bonzini Date: Fri Dec 16 10:56:53 2022 +0100 util: remove support -chardev tty and -chardev parport These were deprecated in 6.0 and can now be removed. Signed-off-by: Paolo Bonzini commit 8b902e3d2309595567e4957b96e971c4f3ca455e Author: Paolo Bonzini Date: Fri Dec 16 10:50:05 2022 +0100 util: remove support for hex numbers with a scaling suffix This was deprecated in 6.0 and can now be removed. Signed-off-by: Paolo Bonzini commit eaaaf8abdc9a9f3493f2cb6a751660dff3f9db57 Author: Paolo Bonzini Date: Fri Dec 16 10:39:32 2022 +0100 KVM: remove support for kernel-ir
Re: [PATCH v3 1/6] xen/riscv: introduce dummy asm/init.h
On 10/01/2023 17:02, Jan Beulich wrote: Arm maintainers, Hi Jan, On 10.01.2023 16:17, Oleksii Kurochko wrote: --- /dev/null +++ b/xen/arch/riscv/include/asm/init.h @@ -0,0 +1,12 @@ +#ifndef _XEN_ASM_INIT_H +#define _XEN_ASM_INIT_H + +#endif /* _XEN_ASM_INIT_H */ instead of having RISC-V introduce an empty stub matching what x86 has, what would it take to empty Arm's as well, allowing both present ones to go away and no new one to be introduced? The only thing you have in there is struct init_info, which doesn't feel like it's properly placed in this header (x86 has such stuff in setup.h) ... Yes. setup.h should be a good place even though the header is getting quite crowded. I am happy to send a patch for it. Cheers, -- Julien Grall
Re: [PATCH v3 3/6] xen/riscv: introduce stack stuff
On Wed, Jan 11, 2023 at 1:18 AM Oleksii Kurochko
wrote:
>
> The patch introduces and sets up a stack in order to go to C environment
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Alistair
> ---
> Changes in V3:
> - reorder headers in alphabetical order
> - merge changes related to start_xen() function from "[PATCH v2 7/8]
> xen/riscv: print hello message from C env" to this patch
> - remove unneeded parentheses in definition of STACK_SIZE
> ---
> Changes in V2:
> - introduce STACK_SIZE define.
> - use consistent padding between instruction mnemonic and operand(s)
> ---
> xen/arch/riscv/Makefile | 1 +
> xen/arch/riscv/include/asm/config.h | 2 ++
> xen/arch/riscv/riscv64/head.S | 6 +-
> xen/arch/riscv/setup.c | 14 ++
> 4 files changed, 22 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/riscv/setup.c
>
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index 248f2cbb3e..5a67a3f493 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_RISCV_64) += riscv64/
> +obj-y += setup.o
>
> $(TARGET): $(TARGET)-syms
> $(OBJCOPY) -O binary -S $< $@
> diff --git a/xen/arch/riscv/include/asm/config.h
> b/xen/arch/riscv/include/asm/config.h
> index 0370f865f3..763a922a04 100644
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -43,6 +43,8 @@
>
> #define SMP_CACHE_BYTES (1 << 6)
>
> +#define STACK_SIZE PAGE_SIZE
> +
> #endif /* __RISCV_CONFIG_H__ */
> /*
> * Local variables:
> diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S
> index 990edb70a0..d444dd8aad 100644
> --- a/xen/arch/riscv/riscv64/head.S
> +++ b/xen/arch/riscv/riscv64/head.S
> @@ -1,4 +1,8 @@
> .section .text.header, "ax", %progbits
>
> ENTRY(start)
> -j start
> +la sp, cpu0_boot_stack
> +li t0, STACK_SIZE
> +add sp, sp, t0
> +
> +tailstart_xen
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> new file mode 100644
> index 00..13e24e2fe1
> --- /dev/null
> +++ b/xen/arch/riscv/setup.c
> @@ -0,0 +1,14 @@
> +#include
> +#include
> +
> +/* Xen stack for bringing up the first CPU. */
> +unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> +__aligned(STACK_SIZE);
> +
> +void __init noreturn start_xen(void)
> +{
> +for ( ;; )
> +asm volatile ("wfi");
> +
> +unreachable();
> +}
> --
> 2.38.1
>
>
Re: [PATCH] bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plx
On Tue, 10 Jan 2023, Philippe Mathieu-Daudé wrote: The 'hwaddr' type is defined in "exec/hwaddr.h" as: hwaddr is the type of a physical address (its size can be different from 'target_ulong'). All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx: $ fgrep define include/exec/hwaddr.h #define HWADDR_H #define HWADDR_BITS 64 #define HWADDR_MAX UINT64_MAX #define TARGET_FMT_plx "%016" PRIx64 ^^ #define HWADDR_PRId PRId64 #define HWADDR_PRIi PRIi64 #define HWADDR_PRIo PRIo64 #define HWADDR_PRIu PRIu64 #define HWADDR_PRIx PRIx64 Why are there both TARGET_FMT_plx and HWADDR_PRIx? Why not just use HWADDR_PRIx instead? Regards, BALATON Zoltan
[PATCH] bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plx
The 'hwaddr' type is defined in "exec/hwaddr.h" as:
hwaddr is the type of a physical address
(its size can be different from 'target_ulong').
All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx:
$ fgrep define include/exec/hwaddr.h
#define HWADDR_H
#define HWADDR_BITS 64
#define HWADDR_MAX UINT64_MAX
#define TARGET_FMT_plx "%016" PRIx64
^^
#define HWADDR_PRId PRId64
#define HWADDR_PRIi PRIi64
#define HWADDR_PRIo PRIo64
#define HWADDR_PRIu PRIu64
#define HWADDR_PRIx PRIx64
#define HWADDR_PRIX PRIX64
Since hwaddr's size can be *different* from target_ulong, it is
very confusing to read one of its format using the 'TARGET_FMT_'
prefix, normally used for the target_long / target_ulong types:
$ fgrep TARGET_FMT_ include/exec/cpu-defs.h
#define TARGET_FMT_lx "%08x"
#define TARGET_FMT_ld "%d"
#define TARGET_FMT_lu "%u"
#define TARGET_FMT_lx "%016" PRIx64
#define TARGET_FMT_ld "%" PRId64
#define TARGET_FMT_lu "%" PRIu64
Apparently this format was missed during commit a8170e5e97
("Rename target_phys_addr_t to hwaddr"), so complete it by
doing a bulk-rename with:
$ sed -i -e s/TARGET_FMT_plx/HWADDR_FMT_plx/g $(git grep -l TARGET_FMT_plx)
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/cputlb.c | 2 +-
hw/arm/strongarm.c | 24
hw/block/pflash_cfi01.c | 2 +-
hw/char/digic-uart.c| 4 ++--
hw/char/etraxfs_ser.c | 4 ++--
hw/core/loader.c| 8
hw/core/sysbus.c| 4 ++--
hw/display/cirrus_vga.c | 4 ++--
hw/display/g364fb.c | 4 ++--
hw/display/vga.c| 8
hw/dma/etraxfs_dma.c| 14 +++---
hw/dma/pl330.c | 14 +++---
hw/dma/xilinx_axidma.c | 4 ++--
hw/dma/xlnx_csu_dma.c | 4 ++--
hw/i2c/mpc_i2c.c| 4 ++--
hw/i386/multiboot.c | 8
hw/i386/xen/xen-hvm.c | 8
hw/i386/xen/xen-mapcache.c | 16
hw/i386/xen/xen_platform.c | 4 ++--
hw/intc/arm_gicv3_dist.c| 8
hw/intc/arm_gicv3_its.c | 14 +++---
hw/intc/arm_gicv3_redist.c | 8
hw/intc/exynos4210_combiner.c | 10 +-
hw/misc/auxbus.c| 2 +-
hw/misc/ivshmem.c | 6 +++---
hw/misc/macio/mac_dbdma.c | 4 ++--
hw/misc/mst_fpga.c | 4 ++--
hw/net/allwinner-sun8i-emac.c | 4 ++--
hw/net/allwinner_emac.c | 4 ++--
hw/net/fsl_etsec/etsec.c| 4 ++--
hw/net/fsl_etsec/rings.c| 4 ++--
hw/net/pcnet.c | 4 ++--
hw/net/rocker/rocker.c | 26 +-
hw/net/rocker/rocker_desc.c | 2 +-
hw/net/xilinx_axienet.c | 4 ++--
hw/net/xilinx_ethlite.c | 6 +++---
hw/pci-bridge/pci_expander_bridge.c | 2 +-
hw/pci-host/bonito.c| 14 +++---
hw/pci-host/ppce500.c | 4 ++--
hw/pci/pci_host.c | 4 ++--
hw/ppc/ppc4xx_sdram.c | 2 +-
hw/rtc/exynos4210_rtc.c | 4 ++--
hw/sh4/sh7750.c | 4 ++--
hw/ssi/xilinx_spi.c | 4 ++--
hw/ssi/xilinx_spips.c | 8
hw/timer/digic-timer.c | 4 ++--
hw/timer/etraxfs_timer.c| 2 +-
hw/timer/exynos4210_mct.c | 2 +-
hw/timer/exynos4210_pwm.c | 4 ++--
hw/virtio/virtio-mmio.c | 4 ++--
hw/xen/xen_pt.c | 4 ++--
include/exec/hwaddr.h | 2 +-
monitor/misc.c | 2 +-
softmmu/memory.c| 18 +-
softmmu/memory_mapping.c| 4 ++--
softmmu/physmem.c | 10 +-
target/i386/monitor.c | 6 +++---
target/loongarch/tlb_helper.c | 2 +-
target/microblaze/op_helper.c | 2 +-
target/mips/tcg/sysemu/tlb_helper.c | 2 +-
target/ppc/mmu-hash32.c | 14 +++---
target/ppc/mmu-hash64.c | 12 ++--
target/ppc/mmu_common.c | 26 +-
target/ppc/mmu_helper.c | 4 ++--
target/riscv/cpu_helper.c | 10 +-
target/riscv/monitor.c | 2 +-
target/sparc/ldst_helper.c | 6 +++---
target/sparc/mmu_helper.c | 10 +-
target/tricore/helper.c | 2 +-
69 files changed, 227 insertions(+), 227 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 4948729917..4e040a1cb9 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1142,7 +1142,7 @@ void tlb_set_page_full(CPUState *cpu, int mmu_idx,
&xlat, &sz, fu
[xen-unstable test] 175694: tolerable FAIL
flight 175694 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175694/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail in 175671 pass in 175694 test-amd64-i386-xl-vhd 21 guest-start/debian.repeat fail in 175671 pass in 175694 test-amd64-i386-migrupgrade 10 xen-install/src_host fail pass in 175671 test-amd64-i386-migrupgrade 11 xen-install/dst_host fail pass in 175671 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175671 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175671 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175671 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175671 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175671 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175671 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175671 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175671 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175671 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175671 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175671 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175671 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass
[qemu-mainline test] 175703: regressions - FAIL
flight 175703 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175703/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 175623 build-amd64 6 xen-buildfail REGR. vs. 175623 build-i3866 xen-buildfail REGR. vs. 175623 build-arm64-xsm 6 xen-buildfail REGR. vs. 175623 build-i386-xsm6 xen-buildfail REGR. vs. 175623 build-arm64 6 xen-buildfail REGR. vs. 175623 build-armhf 6 xen-buildfail REGR. vs. 175623 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1
[ovmf test] 175707: all pass - PUSHED
flight 175707 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175707/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ec54ce1f1ab41b92782b37ae59e752fff0ef9c41 baseline version: ovmf 717f35a9f2d883a74998f7deb3d2cdf95bddf039 Last test of basis 175702 2023-01-10 14:40:41 Z0 days Testing same since 175707 2023-01-10 17:40:54 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel dann frazier Laszlo Ersek jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 717f35a9f2..ec54ce1f1a ec54ce1f1ab41b92782b37ae59e752fff0ef9c41 -> xen-tested-master
Re: [PATCH v3 1/6] xen/riscv: introduce dummy asm/init.h
Hello Jan, Sorry for breaking into the conversation. On Tue, 2023-01-10 at 18:02 +0100, Jan Beulich wrote: > Arm maintainers, > > On 10.01.2023 16:17, Oleksii Kurochko wrote: > > --- /dev/null > > +++ b/xen/arch/riscv/include/asm/init.h > > @@ -0,0 +1,12 @@ > > +#ifndef _XEN_ASM_INIT_H > > +#define _XEN_ASM_INIT_H > > + > > +#endif /* _XEN_ASM_INIT_H */ > > instead of having RISC-V introduce an empty stub matching what x86 > has, Have you had a chance to look at the answer (Re: [PATCH v1 0/8] Basic early_printk and smoke test implementation) of Andrew: https://lore.kernel.org/xen-devel/299d913c-8095-ad90-ea3b-d46ef74d4...@citrix.com/#t I agree with his point regarding the usage of __has_include() to not produce empty headers stubs for RISCV and for future architectures too. > If maintainers are OK I can start to use __has_include() in the > correspondent files.what would it take to empty Arm's as > well, allowing both present ones to > go away and no new one to be introduced? The only thing you have in > there > is struct init_info, which doesn't feel like it's properly placed in > this > header (x86 has such stuff in setup.h) ... > > Jan ~Oleksii
Re: [PATCH v2 6/8] x86/hvm: Enable guest access to MSR_PKRS
On 10/01/2023 5:18 pm, Andrew Cooper wrote:
> Have guest_{rd,wr}msr(), via hvm_{get,set}_reg(), access either the live
> register, or stashed state, depending on context. Include MSR_PKRS for
> migration, and let the guest have full access.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Kevin Tian
>
> v2:
> * Rebase over the get/set_reg() infrastructure.
> ---
> xen/arch/x86/hvm/hvm.c | 1 +
> xen/arch/x86/hvm/vmx/vmx.c | 17 +
> xen/arch/x86/msr.c | 10 ++
> 3 files changed, 28 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 927a221660e8..c6c1eea18003 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1333,6 +1333,7 @@ static int cf_check hvm_load_cpu_xsave_states(
> static const uint32_t msrs_to_send[] = {
> MSR_SPEC_CTRL,
> MSR_INTEL_MISC_FEATURES_ENABLES,
> +MSR_PKRS,
> MSR_IA32_BNDCFGS,
> MSR_IA32_XSS,
> MSR_VIRT_SPEC_CTRL,
Needs the following hunk too:
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c6c1eea18003..86cab7aa2627 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1487,6 +1487,7 @@ static int cf_check hvm_load_cpu_msrs(struct
domain *d, hvm_domain_context_t *h)
case MSR_SPEC_CTRL:
case MSR_INTEL_MISC_FEATURES_ENABLES:
+ case MSR_PKRS:
case MSR_IA32_BNDCFGS:
case MSR_IA32_XSS:
case MSR_VIRT_SPEC_CTRL:
for the receive side of migration to work.
~Andrew
[PATCH v2 4/8] x86: Initial support for WRMSRNS
WRMSR Non-Serialising is an optimisation intended for cases where an MSR needs
updating, but architectural serialising properties are not needed.
In is anticipated that this will apply to most if not all MSRs modified on
context switch paths.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* New
---
tools/libs/light/libxl_cpuid.c | 1 +
tools/misc/xen-cpuid.c | 1 +
xen/arch/x86/include/asm/msr.h | 12
xen/include/public/arch-x86/cpufeatureset.h | 1 +
4 files changed, 15 insertions(+)
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index cbd4e511e8ab..8da78773a886 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -235,6 +235,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
*cpuid, const char* str)
{"fzrm", 0x0007, 1, CPUID_REG_EAX, 10, 1},
{"fsrs", 0x0007, 1, CPUID_REG_EAX, 11, 1},
{"fsrcs",0x0007, 1, CPUID_REG_EAX, 12, 1},
+{"wrmsrns", 0x0007, 1, CPUID_REG_EAX, 19, 1},
{"intel-psfd", 0x0007, 2, CPUID_REG_EDX, 0, 1},
{"mcdt-no", 0x0007, 2, CPUID_REG_EDX, 5, 1},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index ea7ff320e0e4..f482c4e28f30 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -189,6 +189,7 @@ static const char *const str_7a1[32] =
[10] = "fzrm", [11] = "fsrs",
[12] = "fsrcs",
+/* 18 */[19] = "wrmsrns",
};
static const char *const str_e21a[32] =
diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
index dd1eee04a637..191e54068856 100644
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -38,6 +38,18 @@ static inline void wrmsrl(unsigned int msr, __u64 val)
wrmsr(msr, lo, hi);
}
+/* Non-serialising WRMSR, when available. Falls back to a serialising WRMSR.
*/
+static inline void wrmsr_ns(uint32_t msr, uint32_t lo, uint32_t hi)
+{
+/*
+ * WRMSR is 2 bytes. WRMSRNS is 3 bytes. Pad WRMSR with a redundant CS
+ * prefix to avoid a trailing NOP.
+ */
+alternative_input(".byte 0x2e; wrmsr",
+ ".byte 0x0f,0x01,0xc6", X86_FEATURE_WRMSRNS,
+ "c" (msr), "a" (lo), "d" (hi));
+}
+
/* rdmsr with exception handling */
#define rdmsr_safe(msr,val) ({\
int rc_; \
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index ad7e89dd4c40..5444bc5d8374 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -281,6 +281,7 @@ XEN_CPUFEATURE(AVX512_BF16, 10*32+ 5) /*A AVX512 BFloat16
Instructions */
XEN_CPUFEATURE(FZRM, 10*32+10) /*A Fast Zero-length REP MOVSB */
XEN_CPUFEATURE(FSRS, 10*32+11) /*A Fast Short REP STOSB */
XEN_CPUFEATURE(FSRCS,10*32+12) /*A Fast Short REP CMPSB/SCASB */
+XEN_CPUFEATURE(WRMSRNS, 10*32+19) /* WRMSR Non-Serialising */
/* AMD-defined CPU features, CPUID level 0x8021.eax, word 11 */
XEN_CPUFEATURE(LFENCE_DISPATCH,11*32+ 2) /*A LFENCE always serializing */
--
2.11.0
[PATCH v2 8/8] x86/hvm: Support PKS for HAP guests
With all infrastructure in place, advertise the PKS CPUID bit to HAP guests,
and let them set CR4.PKS.
Experiment with a tweak to the layout of hvm_cr4_guest_valid_bits() so future
additions will be just a single added line.
The current context switching behaviour is tied to how VT-x works, so leave a
safety check in the short term.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/cpuid.c| 9 +
xen/arch/x86/hvm/hvm.c | 4 +++-
xen/include/public/arch-x86/cpufeatureset.h | 2 +-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index acc2f606cea8..b22725c492e7 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -579,6 +579,15 @@ static void __init calculate_hvm_max_policy(void)
__clear_bit(X86_FEATURE_XSAVES, hvm_featureset);
}
+/*
+ * Xen doesn't use PKS, so the guest support for it has opted to not use
+ * the VMCS load/save controls for efficiency reasons. This depends on
+ * the exact vmentry/exit behaviour, so don't expose PKS in other
+ * situations until someone has cross-checked the behaviour for safety.
+ */
+if ( !cpu_has_vmx )
+__clear_bit(X86_FEATURE_PKS, hvm_featureset);
+
guest_common_feature_adjustments(hvm_featureset);
sanitise_featureset(hvm_featureset);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c6c1eea18003..606f0e864981 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -969,7 +969,9 @@ unsigned long hvm_cr4_guest_valid_bits(const struct domain
*d)
(p->feat.smep ? X86_CR4_SMEP : 0) |
(p->feat.smap ? X86_CR4_SMAP : 0) |
(p->feat.pku ? X86_CR4_PKE : 0) |
-(cet ? X86_CR4_CET : 0));
+(cet ? X86_CR4_CET : 0) |
+(p->feat.pks ? X86_CR4_PKS : 0) |
+0);
}
static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t
*h)
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index 5444bc5d8374..3b85bcca1537 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -227,7 +227,7 @@ XEN_CPUFEATURE(CLDEMOTE, 6*32+25) /*A CLDEMOTE
instruction */
XEN_CPUFEATURE(MOVDIRI, 6*32+27) /*a MOVDIRI instruction */
XEN_CPUFEATURE(MOVDIR64B, 6*32+28) /*a MOVDIR64B instruction */
XEN_CPUFEATURE(ENQCMD,6*32+29) /* ENQCMD{,S} instructions */
-XEN_CPUFEATURE(PKS, 6*32+31) /* Protection Key for Supervisor */
+XEN_CPUFEATURE(PKS, 6*32+31) /*H Protection Key for Supervisor */
/* AMD-defined CPU features, CPUID level 0x8007.edx, word 7 */
XEN_CPUFEATURE(HW_PSTATE, 7*32+ 7) /* Hardware Pstates */
--
2.11.0
[PATCH v2 7/8] x86/pagewalk: Support PKS
PKS is very similar to the existing PKU behaviour, operating on pagewalks for
any supervisor mapping.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/guest_pt.h | 5 +
xen/arch/x86/include/asm/hvm/hvm.h | 3 +++
xen/arch/x86/mm/guest_walk.c| 9 +
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/include/asm/guest_pt.h
b/xen/arch/x86/include/asm/guest_pt.h
index 6647ccfb8520..6802db2a415a 100644
--- a/xen/arch/x86/include/asm/guest_pt.h
+++ b/xen/arch/x86/include/asm/guest_pt.h
@@ -282,6 +282,11 @@ static always_inline bool guest_pku_enabled(const struct
vcpu *v)
return !is_pv_vcpu(v) && hvm_pku_enabled(v);
}
+static always_inline bool guest_pks_enabled(const struct vcpu *v)
+{
+return !is_pv_vcpu(v) && hvm_pks_enabled(v);
+}
+
/* Helpers for identifying whether guest entries have reserved bits set. */
/* Bits reserved because of maxphysaddr, and (lack of) EFER.NX */
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h
b/xen/arch/x86/include/asm/hvm/hvm.h
index 93254651f2f5..65768c797ea7 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -407,6 +407,8 @@ int hvm_get_param(struct domain *d, uint32_t index,
uint64_t *value);
((v)->arch.hvm.guest_efer & EFER_NXE)
#define hvm_pku_enabled(v) \
(hvm_paging_enabled(v) && ((v)->arch.hvm.guest_cr[4] & X86_CR4_PKE))
+#define hvm_pks_enabled(v) \
+(hvm_paging_enabled(v) && ((v)->arch.hvm.guest_cr[4] & X86_CR4_PKS))
/* Can we use superpages in the HAP p2m table? */
#define hap_has_1gb (!!(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_1GB))
@@ -911,6 +913,7 @@ static inline void hvm_set_reg(struct vcpu *v, unsigned int
reg, uint64_t val)
#define hvm_smap_enabled(v) ((void)(v), false)
#define hvm_nx_enabled(v) ((void)(v), false)
#define hvm_pku_enabled(v) ((void)(v), false)
+#define hvm_pks_enabled(v) ((void)(v), false)
#define arch_vcpu_block(v) ((void)(v))
diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 161a61b8f5ca..76b4e0425887 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -406,16 +406,17 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain
*p2m,
#if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
/*
* If all access checks are thus far ok, check Protection Key for 64bit
- * data accesses to user mappings.
+ * data accesses.
*
* N.B. In the case that the walk ended with a superpage, the fabricated
* gw->l1e contains the appropriate leaf pkey.
*/
-if ( (ar & _PAGE_USER) && !(walk & PFEC_insn_fetch) &&
- guest_pku_enabled(v) )
+if ( !(walk & PFEC_insn_fetch) &&
+ ((ar & _PAGE_USER) ? guest_pku_enabled(v)
+: guest_pks_enabled(v)) )
{
unsigned int pkey = guest_l1e_get_pkey(gw->l1e);
-unsigned int pkr = rdpkru();
+unsigned int pkr = (ar & _PAGE_USER) ? rdpkru() : rdpkrs();
unsigned int pk_ar = (pkr >> (pkey * PKEY_WIDTH)) & (PKEY_AD |
PKEY_WD);
if ( (pk_ar & PKEY_AD) ||
--
2.11.0
[PATCH v2 2/8] x86/prot-key: Enumeration for Protection Key Supervisor
Protection Key Supervisor works in a very similar way to Protection Key User,
except that instead of a PKRU register used by the {RD,WR}PKRU instructions,
the supervisor protection settings live in MSR_PKRS and is accessed using
normal {RD,WR}MSR instructions.
PKS has the same problematic interactions with PV guests as PKU (more infact,
given the guest kernel's CPL), so we'll only support this for HVM guests for
now.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/libs/light/libxl_cpuid.c | 1 +
tools/misc/xen-cpuid.c | 2 +-
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/include/asm/msr-index.h| 2 ++
xen/arch/x86/include/asm/x86-defns.h| 1 +
xen/include/public/arch-x86/cpufeatureset.h | 1 +
6 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index 2aa23225f42c..cbd4e511e8ab 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -211,6 +211,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
*cpuid, const char* str)
{"avx512-vpopcntdq",0x0007,0,CPUID_REG_ECX, 14, 1},
{"rdpid",0x0007, 0, CPUID_REG_ECX, 22, 1},
{"cldemote", 0x0007, 0, CPUID_REG_ECX, 25, 1},
+{"pks", 0x0007, 0, CPUID_REG_ECX, 31, 1},
{"avx512-4vnniw",0x0007, 0, CPUID_REG_EDX, 2, 1},
{"avx512-4fmaps",0x0007, 0, CPUID_REG_EDX, 3, 1},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index d5833e9ce879..ea7ff320e0e4 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -134,7 +134,7 @@ static const char *const str_7c0[32] =
/* 24 */ [25] = "cldemote",
/* 26 */ [27] = "movdiri",
[28] = "movdir64b",[29] = "enqcmd",
-[30] = "sgx-lc",
+[30] = "sgx-lc", [31] = "pks",
};
static const char *const str_e7d[32] =
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm/cpufeature.h
index 044cfd9f882d..0a301013c3d9 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -121,6 +121,7 @@
#define cpu_has_movdiri boot_cpu_has(X86_FEATURE_MOVDIRI)
#define cpu_has_movdir64b boot_cpu_has(X86_FEATURE_MOVDIR64B)
#define cpu_has_enqcmd boot_cpu_has(X86_FEATURE_ENQCMD)
+#define cpu_has_pks boot_cpu_has(X86_FEATURE_PKS)
/* CPUID level 0x8007.edx */
#define cpu_has_hw_pstate boot_cpu_has(X86_FEATURE_HW_PSTATE)
diff --git a/xen/arch/x86/include/asm/msr-index.h
b/xen/arch/x86/include/asm/msr-index.h
index 0a8852f3c246..7615d8087f46 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -148,6 +148,8 @@
#define MSR_PL3_SSP 0x06a7
#define MSR_INTERRUPT_SSP_TABLE 0x06a8
+#define MSR_PKRS0x06e1
+
#define MSR_X2APIC_FIRST0x0800
#define MSR_X2APIC_LAST 0x08ff
diff --git a/xen/arch/x86/include/asm/x86-defns.h
b/xen/arch/x86/include/asm/x86-defns.h
index 42b5f382d438..fe1caba6f819 100644
--- a/xen/arch/x86/include/asm/x86-defns.h
+++ b/xen/arch/x86/include/asm/x86-defns.h
@@ -74,6 +74,7 @@
#define X86_CR4_SMAP 0x0020 /* enable SMAP */
#define X86_CR4_PKE0x0040 /* enable PKE */
#define X86_CR4_CET0x0080 /* Control-flow Enforcement Technology */
+#define X86_CR4_PKS0x0100 /* Protection Key Supervisor */
/*
* XSTATE component flags in XCR0
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index 7915f5826f57..ad7e89dd4c40 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -227,6 +227,7 @@ XEN_CPUFEATURE(CLDEMOTE, 6*32+25) /*A CLDEMOTE
instruction */
XEN_CPUFEATURE(MOVDIRI, 6*32+27) /*a MOVDIRI instruction */
XEN_CPUFEATURE(MOVDIR64B, 6*32+28) /*a MOVDIR64B instruction */
XEN_CPUFEATURE(ENQCMD,6*32+29) /* ENQCMD{,S} instructions */
+XEN_CPUFEATURE(PKS, 6*32+31) /* Protection Key for Supervisor */
/* AMD-defined CPU features, CPUID level 0x8007.edx, word 7 */
XEN_CPUFEATURE(HW_PSTATE, 7*32+ 7) /* Hardware Pstates */
--
2.11.0
[PATCH v2 5/8] x86/hvm: Context switch MSR_PKRS
Under PKS, MSR_PKRS is available and based on the CPUID policy alone, and
usable independently of CR4.PKS. See the large comment in prot-key.h for
details of the context switching arrangement.
Use WRMSRNS right away, as we don't care about serialsing properties for
context switching this MSR.
Sanitise MSR_PKRS on boot. In anticipation of wanting to use PKS for Xen in
the future, arrange for the sanitisation to occur prior to potentially setting
CR4.PKS; if PKEY0.{AD,WD} leak in from a previous context, we will triple
fault immediately on setting CR4.PKS.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Kevin Tian
v2:
* Use WRMSRNS
* Sanitise MSR_PKS on boot.
---
xen/arch/x86/cpu/common.c | 2 ++
xen/arch/x86/hvm/vmx/vmx.c | 9 +++
xen/arch/x86/include/asm/msr.h | 9 +++
xen/arch/x86/include/asm/prot-key.h | 54 +
xen/arch/x86/setup.c| 4 +++
xen/arch/x86/smpboot.c | 4 +++
6 files changed, 82 insertions(+)
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 2bcdd08b2fb5..f44c907e8a43 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -58,6 +58,8 @@ static unsigned int forced_caps[NCAPINTS];
DEFINE_PER_CPU(bool, full_gdt_loaded);
+DEFINE_PER_CPU(uint32_t, pkrs);
+
void __init setup_clear_cpu_cap(unsigned int cap)
{
const uint32_t *dfs;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 43a4865d1c76..b1f493f009fd 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include
static bool_t __initdata opt_force_ept;
@@ -536,6 +537,7 @@ static void vmx_restore_host_msrs(void)
static void vmx_save_guest_msrs(struct vcpu *v)
{
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
struct vcpu_msrs *msrs = v->arch.msrs;
/*
@@ -549,10 +551,14 @@ static void vmx_save_guest_msrs(struct vcpu *v)
rdmsrl(MSR_RTIT_OUTPUT_MASK, msrs->rtit.output_mask);
rdmsrl(MSR_RTIT_STATUS, msrs->rtit.status);
}
+
+if ( cp->feat.pks )
+msrs->pkrs = rdpkrs_and_cache();
}
static void vmx_restore_guest_msrs(struct vcpu *v)
{
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
const struct vcpu_msrs *msrs = v->arch.msrs;
write_gs_shadow(v->arch.hvm.vmx.shadow_gs);
@@ -569,6 +575,9 @@ static void vmx_restore_guest_msrs(struct vcpu *v)
wrmsrl(MSR_RTIT_OUTPUT_MASK, msrs->rtit.output_mask);
wrmsrl(MSR_RTIT_STATUS, msrs->rtit.status);
}
+
+if ( cp->feat.pks )
+wrpkrs(msrs->pkrs);
}
void vmx_update_cpu_exec_control(struct vcpu *v)
diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
index 191e54068856..7946b6b24c11 100644
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -373,6 +373,15 @@ struct vcpu_msrs
};
} rtit;
+/*
+ * 0x06e1 - MSR_PKRS - Protection Key Supervisor.
+ *
+ * Exposed R/W to guests. Xen doesn't use PKS yet, so only context
+ * switched per vcpu. When in current context, live value is in hardware,
+ * and this value is stale.
+ */
+uint32_t pkrs;
+
/* 0x0da0 - MSR_IA32_XSS */
struct {
uint64_t raw;
diff --git a/xen/arch/x86/include/asm/prot-key.h
b/xen/arch/x86/include/asm/prot-key.h
index 63a2e22f3fa0..0dcd31b7ea68 100644
--- a/xen/arch/x86/include/asm/prot-key.h
+++ b/xen/arch/x86/include/asm/prot-key.h
@@ -5,8 +5,11 @@
#ifndef ASM_PROT_KEY_H
#define ASM_PROT_KEY_H
+#include
#include
+#include
+
#define PKEY_AD 1 /* Access Disable */
#define PKEY_WD 2 /* Write Disable */
@@ -28,4 +31,55 @@ static inline void wrpkru(uint32_t pkru)
:: "a" (pkru), "d" (0), "c" (0) );
}
+/*
+ * Xen does not use PKS.
+ *
+ * Guest kernel use is expected to be one default key, except for tiny windows
+ * with a double write to switch to a non-default key in a permitted critical
+ * section.
+ *
+ * As such, we want MSR_PKRS un-intercepted. Furthermore, as we only need it
+ * in Xen for emulation or migration purposes (i.e. possibly never in a
+ * domain's lifetime), we don't want to re-sync the hardware value on every
+ * vmexit.
+ *
+ * Therefore, we read and cache the guest value in ctxt_switch_from(), in the
+ * expectation that we can short-circuit the write in ctxt_switch_to().
+ * During regular operations in current context, the guest value is in
+ * hardware and the per-cpu cache is stale.
+ */
+DECLARE_PER_CPU(uint32_t, pkrs);
+
+static inline uint32_t rdpkrs(void)
+{
+uint32_t pkrs, tmp;
+
+rdmsr(MSR_PKRS, pkrs, tmp);
+
+return pkrs;
+}
+
+static inline uint32_t rdpkrs_and_cache(void)
+{
+return this_cpu(pkrs) = rdpkrs();
+}
+
+static inline void wrpkrs(uint32_t pkrs)
+{
+uint32_t *this_pkrs = &this_cpu(pkrs);
+
+if ( *
[PATCH v2 1/8] x86/boot: Sanitise PKRU on boot
While the reset value of the register is 0, it might not be after kexec/etc.
If PKEY0.{WD,AD} have leaked in from an earlier context, construction of a PV
dom0 will explode.
Sequencing wise, this must come after setting CR4.PKE, and before we touch any
user mappings.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
For sequencing, it could also come after setting XCR0.PKRU too, but then we'd
need to construct an empty XSAVE area to XRSTOR from, and that would be even
more horrible to arrange.
---
xen/arch/x86/cpu/common.c | 3 +++
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/setup.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 0412dbc915e5..fe92f29c2dc6 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -936,6 +936,9 @@ void cpu_init(void)
write_debugreg(6, X86_DR6_DEFAULT);
write_debugreg(7, X86_DR7_DEFAULT);
+ if (cpu_has_pku)
+ wrpkru(0);
+
/*
* If the platform is performing a Secure Launch via SKINIT, GIF is
* clear to prevent external interrupts interfering with Secure
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm/cpufeature.h
index a3ad9ebee4e9..044cfd9f882d 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -109,6 +109,7 @@
/* CPUID level 0x0007:0.ecx */
#define cpu_has_avx512_vbmi boot_cpu_has(X86_FEATURE_AVX512_VBMI)
+#define cpu_has_pku boot_cpu_has(X86_FEATURE_PKU)
#define cpu_has_avx512_vbmi2boot_cpu_has(X86_FEATURE_AVX512_VBMI2)
#define cpu_has_gfniboot_cpu_has(X86_FEATURE_GFNI)
#define cpu_has_vaesboot_cpu_has(X86_FEATURE_VAES)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 566422600d94..6deadcf74763 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1798,7 +1798,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
if ( boot_cpu_has(X86_FEATURE_FSGSBASE) )
set_in_cr4(X86_CR4_FSGSBASE);
-if ( boot_cpu_has(X86_FEATURE_PKU) )
+if ( cpu_has_pku )
set_in_cr4(X86_CR4_PKE);
if ( opt_invpcid && cpu_has_invpcid )
--
2.11.0
[PATCH v2 3/8] x86/prot-key: Split PKRU infrastructure out of asm/processor.h
asm/processor.h is in desperate need of splitting up, and protection key
functionality in only used in the emulator and pagewalk. Introduce a new
asm/prot-key.h and move the relevant content over.
Rename the PKRU_* constants to drop the user part and to use the architectural
terminology.
Drop the read_pkru_{ad,wd}() helpers entirely. The pkru infix is about to
become wrong, and the sole user is shorter and easier to follow without the
helpers.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* Mask pk_ar
---
xen/arch/x86/cpu/common.c| 1 +
xen/arch/x86/include/asm/processor.h | 38
xen/arch/x86/include/asm/prot-key.h | 31 +
xen/arch/x86/mm/guest_walk.c | 9 ++---
xen/arch/x86/x86_emulate.c | 2 ++
5 files changed, 40 insertions(+), 41 deletions(-)
create mode 100644 xen/arch/x86/include/asm/prot-key.h
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index fe92f29c2dc6..2bcdd08b2fb5 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/xen/arch/x86/include/asm/processor.h
b/xen/arch/x86/include/asm/processor.h
index 60b902060914..b95d2483212a 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -374,44 +374,6 @@ static always_inline void set_in_cr4 (unsigned long mask)
write_cr4(read_cr4() | mask);
}
-static inline unsigned int rdpkru(void)
-{
-unsigned int pkru;
-
-asm volatile (".byte 0x0f,0x01,0xee"
-: "=a" (pkru) : "c" (0) : "dx");
-
-return pkru;
-}
-
-static inline void wrpkru(unsigned int pkru)
-{
-asm volatile ( ".byte 0x0f, 0x01, 0xef"
- :: "a" (pkru), "d" (0), "c" (0) );
-}
-
-/* Macros for PKRU domain */
-#define PKRU_READ (0)
-#define PKRU_WRITE (1)
-#define PKRU_ATTRS (2)
-
-/*
- * PKRU defines 32 bits, there are 16 domains and 2 attribute bits per
- * domain in pkru, pkeys is index to a defined domain, so the value of
- * pte_pkeys * PKRU_ATTRS + R/W is offset of a defined domain attribute.
- */
-static inline bool_t read_pkru_ad(uint32_t pkru, unsigned int pkey)
-{
-ASSERT(pkey < 16);
-return (pkru >> (pkey * PKRU_ATTRS + PKRU_READ)) & 1;
-}
-
-static inline bool_t read_pkru_wd(uint32_t pkru, unsigned int pkey)
-{
-ASSERT(pkey < 16);
-return (pkru >> (pkey * PKRU_ATTRS + PKRU_WRITE)) & 1;
-}
-
static always_inline void __monitor(const void *eax, unsigned long ecx,
unsigned long edx)
{
diff --git a/xen/arch/x86/include/asm/prot-key.h
b/xen/arch/x86/include/asm/prot-key.h
new file mode 100644
index ..63a2e22f3fa0
--- /dev/null
+++ b/xen/arch/x86/include/asm/prot-key.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021-2022 Citrix Systems Ltd.
+ */
+#ifndef ASM_PROT_KEY_H
+#define ASM_PROT_KEY_H
+
+#include
+
+#define PKEY_AD 1 /* Access Disable */
+#define PKEY_WD 2 /* Write Disable */
+
+#define PKEY_WIDTH 2 /* Two bits per protection key */
+
+static inline uint32_t rdpkru(void)
+{
+uint32_t pkru;
+
+asm volatile ( ".byte 0x0f,0x01,0xee"
+ : "=a" (pkru) : "c" (0) : "dx" );
+
+return pkru;
+}
+
+static inline void wrpkru(uint32_t pkru)
+{
+asm volatile ( ".byte 0x0f,0x01,0xef"
+ :: "a" (pkru), "d" (0), "c" (0) );
+}
+
+#endif /* ASM_PROT_KEY_H */
diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 70dacc477f9a..161a61b8f5ca 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -26,7 +26,9 @@
#include
#include
#include
+
#include
+#include
#include
#include
@@ -413,10 +415,11 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain
*p2m,
guest_pku_enabled(v) )
{
unsigned int pkey = guest_l1e_get_pkey(gw->l1e);
-unsigned int pkru = rdpkru();
+unsigned int pkr = rdpkru();
+unsigned int pk_ar = (pkr >> (pkey * PKEY_WIDTH)) & (PKEY_AD |
PKEY_WD);
-if ( read_pkru_ad(pkru, pkey) ||
- ((walk & PFEC_write_access) && read_pkru_wd(pkru, pkey) &&
+if ( (pk_ar & PKEY_AD) ||
+ ((walk & PFEC_write_access) && (pk_ar & PKEY_WD) &&
((walk & PFEC_user_mode) || guest_wp_enabled(v))) )
{
gw->pfec |= PFEC_prot_key;
diff --git a/xen/arch/x86/x86_emulate.c b/xen/arch/x86/x86_emulate.c
index 720740f29b84..8c7d18521807 100644
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -12,8 +12,10 @@
#include
#include
#include
+
#include
#include /* current_cpu_info */
+#include
#include
#include /* cpu_has_amd_erratum() */
#include
--
2.11.0
[PATCH v2 0/8] x86: Protection Key Supervisor support
Only 14 months after v1... This time with testing on real hardware (not that any bugs were found) and against an updated XTF comprehensive pagewalk test. # time ./xtf-runner hvm64 pagetable-emulation~hap --- Xen Test Framework --- Environment: HVM 64bit (Long mode 4 levels) Test pagetable-emulation Info: Intel, Fam 6, Model 143, Stepping 3, paddr 46, vaddr 48 Features: PSE PAE PGE PAT PSE36 PCID NX PAGE1G SMEP SMAP PKU PKS Paging mode heuristic: Hap Using physical addresses 4000 and 2000 Test L1e Test L2e Test L2e Superpage Test L3e Test L3e Superpage Test L4e Test L4e Superpage Completed 28835840 tests Test result: SUCCESS Combined test results: test-hvm64-pagetable-emulation~hap SUCCESS real 1m26.315s user 0m0.039s sys 0m0.086s This test is going to get even more silly when CET-SS becomes supported. Andrew Cooper (8): x86/boot: Sanitise PKRU on boot x86/prot-key: Enumeration for Protection Key Supervisor x86/prot-key: Split PKRU infrastructure out of asm/processor.h x86: Initial support for WRMSRNS x86/hvm: Context switch MSR_PKRS x86/hvm: Enable guest access to MSR_PKRS x86/pagewalk: Support PKS x86/hvm: Support PKS for HAP guests tools/libs/light/libxl_cpuid.c | 2 + tools/misc/xen-cpuid.c | 3 +- xen/arch/x86/cpu/common.c | 6 ++ xen/arch/x86/cpuid.c| 9 +++ xen/arch/x86/hvm/hvm.c | 5 +- xen/arch/x86/hvm/vmx/vmx.c | 26 + xen/arch/x86/include/asm/cpufeature.h | 2 + xen/arch/x86/include/asm/guest_pt.h | 5 ++ xen/arch/x86/include/asm/hvm/hvm.h | 3 + xen/arch/x86/include/asm/msr-index.h| 2 + xen/arch/x86/include/asm/msr.h | 21 +++ xen/arch/x86/include/asm/processor.h| 38 - xen/arch/x86/include/asm/prot-key.h | 85 + xen/arch/x86/include/asm/x86-defns.h| 1 + xen/arch/x86/mm/guest_walk.c| 16 -- xen/arch/x86/msr.c | 10 xen/arch/x86/setup.c| 6 +- xen/arch/x86/smpboot.c | 4 ++ xen/arch/x86/x86_emulate.c | 2 + xen/include/public/arch-x86/cpufeatureset.h | 2 + 20 files changed, 201 insertions(+), 47 deletions(-) create mode 100644 xen/arch/x86/include/asm/prot-key.h -- 2.11.0
[PATCH v2 6/8] x86/hvm: Enable guest access to MSR_PKRS
Have guest_{rd,wr}msr(), via hvm_{get,set}_reg(), access either the live
register, or stashed state, depending on context. Include MSR_PKRS for
migration, and let the guest have full access.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Kevin Tian
v2:
* Rebase over the get/set_reg() infrastructure.
---
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/hvm/vmx/vmx.c | 17 +
xen/arch/x86/msr.c | 10 ++
3 files changed, 28 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 927a221660e8..c6c1eea18003 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1333,6 +1333,7 @@ static int cf_check hvm_load_cpu_xsave_states(
static const uint32_t msrs_to_send[] = {
MSR_SPEC_CTRL,
MSR_INTEL_MISC_FEATURES_ENABLES,
+MSR_PKRS,
MSR_IA32_BNDCFGS,
MSR_IA32_XSS,
MSR_VIRT_SPEC_CTRL,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b1f493f009fd..57827779c305 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -657,6 +657,11 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu
*v)
else
vmx_set_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW);
+if ( cp->feat.pks )
+vmx_clear_msr_intercept(v, MSR_PKRS, VMX_MSR_RW);
+else
+vmx_set_msr_intercept(v, MSR_PKRS, VMX_MSR_RW);
+
out:
vmx_vmcs_exit(v);
@@ -2455,6 +2460,7 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v,
unsigned int reg)
{
const struct vcpu *curr = current;
struct domain *d = v->domain;
+const struct vcpu_msrs *msrs = v->arch.msrs;
uint64_t val = 0;
int rc;
@@ -2471,6 +2477,9 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v,
unsigned int reg)
}
return val;
+case MSR_PKRS:
+return (v == curr) ? rdpkrs() : msrs->pkrs;
+
case MSR_SHADOW_GS_BASE:
if ( v != curr )
return v->arch.hvm.vmx.shadow_gs;
@@ -2499,6 +2508,8 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v,
unsigned int reg)
static void cf_check vmx_set_reg(struct vcpu *v, unsigned int reg, uint64_t
val)
{
+const struct vcpu *curr = current;
+struct vcpu_msrs *msrs = v->arch.msrs;
struct domain *d = v->domain;
int rc;
@@ -2514,6 +2525,12 @@ static void cf_check vmx_set_reg(struct vcpu *v,
unsigned int reg, uint64_t val)
domain_crash(d);
}
return;
+
+case MSR_PKRS:
+msrs->pkrs = val;
+if ( v == curr )
+wrpkrs(val);
+return;
}
/* Logic which maybe requires remote VMCS acquisition. */
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 317b154d244d..7ddf0078c3a2 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -325,6 +325,11 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
*val)
*val = 0;
break;
+case MSR_PKRS:
+if ( !cp->feat.pks )
+goto gp_fault;
+goto get_reg;
+
case MSR_X2APIC_FIRST ... MSR_X2APIC_LAST:
if ( !is_hvm_domain(d) || v != curr )
goto gp_fault;
@@ -616,6 +621,11 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
break;
goto gp_fault;
+case MSR_PKRS:
+if ( !cp->feat.pks || val != (uint32_t)val )
+goto gp_fault;
+goto set_reg;
+
case MSR_X2APIC_FIRST ... MSR_X2APIC_LAST:
if ( !is_hvm_domain(d) || v != curr )
goto gp_fault;
--
2.11.0
[linux-linus test] 175689: regressions - FAIL
flight 175689 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175689/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 173462 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 173462 test-amd64-amd64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-pair12 xen-boot/src_hostfail REGR. vs. 173462 test-amd64-amd64-pair13 xen-boot/dst_hostfail REGR. vs. 173462 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-win7-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-win7-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-qemuu-nested-amd 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-xl-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-pvhv2-amd 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-freebsd11-amd64 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-pygrub 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-shadow8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-pvshim8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-debianhvm-amd64 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-qemuu-ovmf-amd64 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-examine 8 reboot fail REGR. vs. 173462 test-amd64-coresched-amd64-xl 8 xen-bootfail REGR. vs. 173462 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-examine 8 reboot
Re: [PATCH v3 1/6] xen/riscv: introduce dummy asm/init.h
Arm maintainers, On 10.01.2023 16:17, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/include/asm/init.h > @@ -0,0 +1,12 @@ > +#ifndef _XEN_ASM_INIT_H > +#define _XEN_ASM_INIT_H > + > +#endif /* _XEN_ASM_INIT_H */ instead of having RISC-V introduce an empty stub matching what x86 has, what would it take to empty Arm's as well, allowing both present ones to go away and no new one to be introduced? The only thing you have in there is struct init_info, which doesn't feel like it's properly placed in this header (x86 has such stuff in setup.h) ... Jan
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 10.01.2023 16:17, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko > --- > Changes in V3: > - Nothing changed > --- > Changes in V2: > - Remove unneeded now types from I guess you went a little too far: Types used in common code, even if you do not build that yet, will want declaring right away imo. Of course I should finally try and get rid of at least some of the being-phased-out ones (s8 and s16 look to be relatively low hanging fruit, for example, and of these only s16 looks to be used in common code) ... Jan
Re: [PATCH v2 03/17] xen/arm: implement node distance helpers for Arm
On 10.01.2023 09:49, Wei Chen wrote:
> --- a/xen/arch/arm/include/asm/numa.h
> +++ b/xen/arch/arm/include/asm/numa.h
> @@ -28,6 +28,20 @@ enum dt_numa_status {
> DT_NUMA_OFF,
> };
>
> +/*
> + * In ACPI spec, 0-9 are the reserved values for node distance,
> + * 10 indicates local node distance, 20 indicates remote node
> + * distance. Set node distance map in device tree will follow
> + * the ACPI's definition.
> + */
> +#define NUMA_DISTANCE_UDF_MIN 0
> +#define NUMA_DISTANCE_UDF_MAX 9
> +#define NUMA_LOCAL_DISTANCE 10
> +#define NUMA_REMOTE_DISTANCE20
In the absence of a caller of numa_set_distance() it is entirely unclear
whether this tying to ACPI used values is actually appropriate.
> --- a/xen/arch/arm/numa.c
> +++ b/xen/arch/arm/numa.c
> @@ -2,7 +2,7 @@
> /*
> * Arm Architecture support layer for NUMA.
> *
> - * Copyright (C) 2021 Arm Ltd
> + * Copyright (C) 2022 Arm Ltd
I don't think it makes sense to change such after the fact. And certainly
not in an unrelated patch.
> @@ -22,6 +22,11 @@
>
> static enum dt_numa_status __read_mostly device_tree_numa;
>
> +static unsigned char __read_mostly
> +node_distance_map[MAX_NUMNODES][MAX_NUMNODES] = {
> +{ 0 }
> +};
__ro_after_init?
> @@ -42,3 +47,48 @@ int __init arch_numa_setup(const char *opt)
> {
> return -EINVAL;
> }
> +
> +void __init numa_set_distance(nodeid_t from, nodeid_t to,
> + unsigned int distance)
> +{
> +if ( from >= MAX_NUMNODES || to >= MAX_NUMNODES )
> +{
> +printk(KERN_WARNING
> + "NUMA: invalid nodes: from=%"PRIu8" to=%"PRIu8"
> MAX=%"PRIu8"\n",
> + from, to, MAX_NUMNODES);
> +return;
> +}
> +
> +/* NUMA defines 0xff as an unreachable node and 0-9 are undefined */
> +if ( distance >= NUMA_NO_DISTANCE ||
> +(distance >= NUMA_DISTANCE_UDF_MIN &&
Nit: Indentation.
> + distance <= NUMA_DISTANCE_UDF_MAX) ||
> +(from == to && distance != NUMA_LOCAL_DISTANCE) )
> +{
> +printk(KERN_WARNING
> + "NUMA: invalid distance: from=%"PRIu8" to=%"PRIu8"
> distance=%"PRIu32"\n",
> + from, to, distance);
> +return;
> +}
> +
> +node_distance_map[from][to] = distance;
> +}
> +
> +unsigned char __node_distance(nodeid_t from, nodeid_t to)
> +{
> +/* When NUMA is off, any distance will be treated as remote. */
> +if ( numa_disabled() )
> +return NUMA_REMOTE_DISTANCE;
> +
> +/*
> + * Check whether the nodes are in the matrix range.
> + * When any node is out of range, except from and to nodes are the
> + * same, we treat them as unreachable (return 0xFF)
> + */
> +if ( from >= MAX_NUMNODES || to >= MAX_NUMNODES )
I guess using ARRAY_SIZE() here would be more future-proof.
Jan
Re: [PATCH v2 02/17] xen/arm: implement helpers to get and update NUMA status
On 10.01.2023 09:49, Wei Chen wrote:
> --- a/xen/arch/arm/include/asm/numa.h
> +++ b/xen/arch/arm/include/asm/numa.h
> @@ -22,6 +22,12 @@ typedef u8 nodeid_t;
> */
> #define NR_NODE_MEMBLKS NR_MEM_BANKS
>
> +enum dt_numa_status {
> +DT_NUMA_INIT,
I don't see any use of this. I also think the name isn't good, as INIT
can be taken for "initializer" as well as "initialized". Suggesting an
alternative would require knowing what the future plans with this are;
right now ...
> +DT_NUMA_ON,
> +DT_NUMA_OFF,
> +};
... the other two are also used only in a single file, at which point
their placing in a header is also questionable.
> --- /dev/null
> +++ b/xen/arch/arm/numa.c
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Arm Architecture support layer for NUMA.
> + *
> + * Copyright (C) 2021 Arm Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
[ovmf test] 175702: all pass - PUSHED
flight 175702 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175702/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 717f35a9f2d883a74998f7deb3d2cdf95bddf039 baseline version: ovmf 82dd766f25225b0812bbac628c60d2b48f2346e4 Last test of basis 175686 2023-01-10 06:40:46 Z0 days Testing same since 175702 2023-01-10 14:40:41 Z0 days1 attempts People who touched revisions under test: Moritz Fischer jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 82dd766f25..717f35a9f2 717f35a9f2d883a74998f7deb3d2cdf95bddf039 -> xen-tested-master
Re: [PATCH 2/2] x86/vmx: Support for CPUs without model-specific LBR
On 09.01.2023 13:08, Andrew Cooper wrote: > Ice Lake (server at least) has both Arch LBR and model-specific LBR. Sapphire > Rapids does not have model-specific LBR at all. I.e. On SPR and later, > model_specific_lbr will always be NULL, so we must make changes to avoid > reliably hitting the domain_crash(). > > The Arch LBR spec states that CPUs without model-specific LBR implement > MSR_DBG_CTL.LBR by discarding writes and always returning 0. > > Do this for any CPU for which we lack model-specific LBR information. > > Adjust the now-stale comment, now that the Arch LBR spec has created a way to > signal "no model specific LBR" to guests. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich
Re: [PATCH 1/2] x86/vmx: Calculate model-specific LBRs once at start of day
On 10/01/2023 4:26 pm, Jan Beulich wrote:
> On 09.01.2023 13:08, Andrew Cooper wrote:
>> There is no point repeating this calculation at runtime, especially as it is
>> in the fallback path of the WRSMR/RDMSR handlers.
>>
>> Move the infrastructure higher in vmx.c to avoid forward declarations,
>> renaming last_branch_msr_get() to get_model_specific_lbr() to highlight that
>> these are model-specific only.
>>
>> No practical change.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> with one nit:
>
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -396,6 +396,142 @@ void vmx_pi_hooks_deassign(struct domain *d)
>> domain_unpause(d);
>> }
>>
>> +static const struct lbr_info {
>> +u32 base, count;
>> +} p4_lbr[] = {
>> +{ MSR_P4_LER_FROM_LIP, 1 },
>> +{ MSR_P4_LER_TO_LIP,1 },
>> +{ MSR_P4_LASTBRANCH_TOS,1 },
>> +{ MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
>> +{ MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
>> +{ 0, 0 }
>> +}, c2_lbr[] = {
>> +{ MSR_IA32_LASTINTFROMIP, 1 },
>> +{ MSR_IA32_LASTINTTOIP, 1 },
>> +{ MSR_C2_LASTBRANCH_TOS,1 },
>> +{ MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_C2_LASTBRANCH_FROM_TO },
>> +{ MSR_C2_LASTBRANCH_0_TO_IP,NUM_MSR_C2_LASTBRANCH_FROM_TO },
>> +{ 0, 0 }
>> +}, nh_lbr[] = {
>> +{ MSR_IA32_LASTINTFROMIP, 1 },
>> +{ MSR_IA32_LASTINTTOIP, 1 },
>> +{ MSR_NHL_LBR_SELECT, 1 },
>> +{ MSR_NHL_LASTBRANCH_TOS, 1 },
>> +{ MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
>> +{ MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
>> +{ 0, 0 }
>> +}, sk_lbr[] = {
>> +{ MSR_IA32_LASTINTFROMIP, 1 },
>> +{ MSR_IA32_LASTINTTOIP, 1 },
>> +{ MSR_NHL_LBR_SELECT, 1 },
>> +{ MSR_NHL_LASTBRANCH_TOS, 1 },
>> +{ MSR_SKL_LASTBRANCH_0_FROM_IP, NUM_MSR_SKL_LASTBRANCH },
>> +{ MSR_SKL_LASTBRANCH_0_TO_IP, NUM_MSR_SKL_LASTBRANCH },
>> +{ MSR_SKL_LASTBRANCH_0_INFO,NUM_MSR_SKL_LASTBRANCH },
>> +{ 0, 0 }
>> +}, at_lbr[] = {
>> +{ MSR_IA32_LASTINTFROMIP, 1 },
>> +{ MSR_IA32_LASTINTTOIP, 1 },
>> +{ MSR_C2_LASTBRANCH_TOS,1 },
>> +{ MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
>> +{ MSR_C2_LASTBRANCH_0_TO_IP,NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
>> +{ 0, 0 }
>> +}, sm_lbr[] = {
>> +{ MSR_IA32_LASTINTFROMIP, 1 },
>> +{ MSR_IA32_LASTINTTOIP, 1 },
>> +{ MSR_SM_LBR_SELECT,1 },
>> +{ MSR_SM_LASTBRANCH_TOS,1 },
>> +{ MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
>> +{ MSR_C2_LASTBRANCH_0_TO_IP,NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
>> +{ 0, 0 }
>> +}, gm_lbr[] = {
>> +{ MSR_IA32_LASTINTFROMIP, 1 },
>> +{ MSR_IA32_LASTINTTOIP, 1 },
>> +{ MSR_SM_LBR_SELECT,1 },
>> +{ MSR_SM_LASTBRANCH_TOS,1 },
>> +{ MSR_GM_LASTBRANCH_0_FROM_IP, NUM_MSR_GM_LASTBRANCH_FROM_TO },
>> +{ MSR_GM_LASTBRANCH_0_TO_IP,NUM_MSR_GM_LASTBRANCH_FROM_TO },
>> +{ 0, 0 }
>> +};
>> +static const struct lbr_info * __ro_after_init model_specific_lbr;
>> +
>> +static const struct __init lbr_info *get_model_specific_lbr(void)
> Please move __init:
>
> static const struct lbr_info *__init get_model_specific_lbr(void)
Yeah, I noticed and fixed both style errors here. Also an extraneous
space before __ro_after_init.
~Andrew
Re: [PATCH 1/2] x86/vmx: Calculate model-specific LBRs once at start of day
On 09.01.2023 13:08, Andrew Cooper wrote:
> There is no point repeating this calculation at runtime, especially as it is
> in the fallback path of the WRSMR/RDMSR handlers.
>
> Move the infrastructure higher in vmx.c to avoid forward declarations,
> renaming last_branch_msr_get() to get_model_specific_lbr() to highlight that
> these are model-specific only.
>
> No practical change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one nit:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -396,6 +396,142 @@ void vmx_pi_hooks_deassign(struct domain *d)
> domain_unpause(d);
> }
>
> +static const struct lbr_info {
> +u32 base, count;
> +} p4_lbr[] = {
> +{ MSR_P4_LER_FROM_LIP, 1 },
> +{ MSR_P4_LER_TO_LIP,1 },
> +{ MSR_P4_LASTBRANCH_TOS,1 },
> +{ MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
> +{ MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
> +{ 0, 0 }
> +}, c2_lbr[] = {
> +{ MSR_IA32_LASTINTFROMIP, 1 },
> +{ MSR_IA32_LASTINTTOIP, 1 },
> +{ MSR_C2_LASTBRANCH_TOS,1 },
> +{ MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_C2_LASTBRANCH_FROM_TO },
> +{ MSR_C2_LASTBRANCH_0_TO_IP,NUM_MSR_C2_LASTBRANCH_FROM_TO },
> +{ 0, 0 }
> +}, nh_lbr[] = {
> +{ MSR_IA32_LASTINTFROMIP, 1 },
> +{ MSR_IA32_LASTINTTOIP, 1 },
> +{ MSR_NHL_LBR_SELECT, 1 },
> +{ MSR_NHL_LASTBRANCH_TOS, 1 },
> +{ MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
> +{ MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO },
> +{ 0, 0 }
> +}, sk_lbr[] = {
> +{ MSR_IA32_LASTINTFROMIP, 1 },
> +{ MSR_IA32_LASTINTTOIP, 1 },
> +{ MSR_NHL_LBR_SELECT, 1 },
> +{ MSR_NHL_LASTBRANCH_TOS, 1 },
> +{ MSR_SKL_LASTBRANCH_0_FROM_IP, NUM_MSR_SKL_LASTBRANCH },
> +{ MSR_SKL_LASTBRANCH_0_TO_IP, NUM_MSR_SKL_LASTBRANCH },
> +{ MSR_SKL_LASTBRANCH_0_INFO,NUM_MSR_SKL_LASTBRANCH },
> +{ 0, 0 }
> +}, at_lbr[] = {
> +{ MSR_IA32_LASTINTFROMIP, 1 },
> +{ MSR_IA32_LASTINTTOIP, 1 },
> +{ MSR_C2_LASTBRANCH_TOS,1 },
> +{ MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
> +{ MSR_C2_LASTBRANCH_0_TO_IP,NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
> +{ 0, 0 }
> +}, sm_lbr[] = {
> +{ MSR_IA32_LASTINTFROMIP, 1 },
> +{ MSR_IA32_LASTINTTOIP, 1 },
> +{ MSR_SM_LBR_SELECT,1 },
> +{ MSR_SM_LASTBRANCH_TOS,1 },
> +{ MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
> +{ MSR_C2_LASTBRANCH_0_TO_IP,NUM_MSR_ATOM_LASTBRANCH_FROM_TO },
> +{ 0, 0 }
> +}, gm_lbr[] = {
> +{ MSR_IA32_LASTINTFROMIP, 1 },
> +{ MSR_IA32_LASTINTTOIP, 1 },
> +{ MSR_SM_LBR_SELECT,1 },
> +{ MSR_SM_LASTBRANCH_TOS,1 },
> +{ MSR_GM_LASTBRANCH_0_FROM_IP, NUM_MSR_GM_LASTBRANCH_FROM_TO },
> +{ MSR_GM_LASTBRANCH_0_TO_IP,NUM_MSR_GM_LASTBRANCH_FROM_TO },
> +{ 0, 0 }
> +};
> +static const struct lbr_info * __ro_after_init model_specific_lbr;
> +
> +static const struct __init lbr_info *get_model_specific_lbr(void)
Please move __init:
static const struct lbr_info *__init get_model_specific_lbr(void)
Jan
[PATCH] automation: rename RISCV_64 container and jobs
All RISCV_64-related stuff was renamed to be consistent with
ARM (arm32 is cross build as RISCV_64).
The patch is based on the following patch series:
[PATCH *] Basic early_printk and smoke test implementation
Signed-off-by: Oleksii Kurochko
---
...v64.dockerfile => current-riscv64.dockerfile} | 0
automation/gitlab-ci/build.yaml | 16
automation/gitlab-ci/test.yaml | 4 ++--
automation/scripts/containerize | 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
rename automation/build/archlinux/{riscv64.dockerfile =>
current-riscv64.dockerfile} (100%)
diff --git a/automation/build/archlinux/riscv64.dockerfile
b/automation/build/archlinux/current-riscv64.dockerfile
similarity index 100%
rename from automation/build/archlinux/riscv64.dockerfile
rename to automation/build/archlinux/current-riscv64.dockerfile
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 6784974619..7ccd153375 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -647,31 +647,31 @@ alpine-3.12-gcc-debug-arm64-boot-cpupools:
CONFIG_BOOT_TIME_CPUPOOLS=y
# RISC-V 64 cross-build
-riscv64-cross-gcc:
+archlinux-current-gcc-riscv64:
extends: .gcc-riscv64-cross-build
variables:
-CONTAINER: archlinux:riscv64
+CONTAINER: archlinux:current-riscv64
KBUILD_DEFCONFIG: tiny64_defconfig
HYPERVISOR_ONLY: y
-riscv64-cross-gcc-debug:
+archlinux-current-gcc-riscv64-debug:
extends: .gcc-riscv64-cross-build-debug
variables:
-CONTAINER: archlinux:riscv64
+CONTAINER: archlinux:current-riscv64
KBUILD_DEFCONFIG: tiny64_defconfig
HYPERVISOR_ONLY: y
-riscv64-cross-gcc-randconfig:
+archlinux-current-gcc-riscv64-randconfig:
extends: .gcc-riscv64-cross-build
variables:
-CONTAINER: archlinux:riscv64
+CONTAINER: archlinux:current-riscv64
KBUILD_DEFCONFIG: tiny64_defconfig
RANDCONFIG: y
-riscv64-cross-gcc-debug-randconfig:
+archlinux-current-gcc-riscv64-debug-randconfig:
extends: .gcc-riscv64-cross-build-debug
variables:
-CONTAINER: archlinux:riscv64
+CONTAINER: archlinux:current-riscv64
KBUILD_DEFCONFIG: tiny64_defconfig
RANDCONFIG: y
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 64f47a0ab9..4ca3e54862 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -57,7 +57,7 @@
.qemu-riscv64:
extends: .test-jobs-common
variables:
-CONTAINER: archlinux:riscv64
+CONTAINER: archlinux:current-riscv64
LOGFILE: qemu-smoke-riscv64.log
artifacts:
paths:
@@ -252,7 +252,7 @@ qemu-smoke-riscv64-gcc:
script:
- ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE}
needs:
-- riscv64-cross-gcc
+- archlinux-current-gcc-riscv64
# Yocto test jobs
yocto-qemuarm64:
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 0f4645c4cc..9e508918bf 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -27,7 +27,7 @@ case "_${CONTAINER}" in
_alpine) CONTAINER="${BASE}/alpine:3.12" ;;
_alpine-arm64v8) CONTAINER="${BASE}/alpine:3.12-arm64v8" ;;
_archlinux|_arch) CONTAINER="${BASE}/archlinux:current" ;;
-_riscv64) CONTAINER="${BASE}/archlinux:riscv64" ;;
+_riscv64) CONTAINER="${BASE}/archlinux:current-riscv64" ;;
_centos7) CONTAINER="${BASE}/centos:7" ;;
_centos72) CONTAINER="${BASE}/centos:7.2" ;;
_fedora) CONTAINER="${BASE}/fedora:29";;
--
2.38.1
Re: [PATCH v3 5/6] xen/riscv: introduce early_printk basic stuff
On 10.01.2023 16:17, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/Kconfig.debug
> +++ b/xen/arch/riscv/Kconfig.debug
> @@ -0,0 +1,7 @@
> +config EARLY_PRINTK
> +bool "Enable early printk"
> +default DEBUG
> +depends on RISCV_64 || RISCV_32
You're in a RISC-V-specific Kconfig - do you really need this line?
> --- /dev/null
> +++ b/xen/arch/riscv/early_printk.c
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * RISC-V early printk using SBI
> + *
> + * Copyright (C) 2021 Bobby Eshleman
> + */
> +#include
> +#include
> +
> +/*
> + * TODO:
> + * sbi_console_putchar is already planned for deprecation
> + * so it should be reworked to use UART directly.
> +*/
> +void early_puts(const char *s, size_t nr)
> +{
> +while ( nr-- > 0 )
> +{
> +if (*s == '\n')
Nit (style): Missing blanks.
> +sbi_console_putchar('\r');
> +sbi_console_putchar(*s);
> +s++;
> +}
> +}
> +
> +void early_printk(const char *str)
> +{
> +while (*str)
Again.
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -1,12 +1,16 @@
> #include
> #include
>
> +#include
> +
> /* Xen stack for bringing up the first CPU. */
> unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> __aligned(STACK_SIZE);
>
> void __init noreturn start_xen(void)
> {
> +early_printk("Hello from C env\n");
> +
> for ( ;; )
> asm volatile ("wfi");
While this is only context here, it affects an earlier patch in the
series; this wants to be
for ( ; ; )
asm volatile ( "wfi" );
Jan
Re: [XEN PATCH] tools: Fix build with recent QEMU, use "--enable-trace-backends"
On Tue, Jan 10, 2023 at 10:25 AM Anthony PERARD
wrote:
>
> The configure option "--enable-trace-backend" isn't accepted anymore
> and we should use "--enable-trace-backends" instead which was
> introduce in 2014 and allow multiple backends.
>
> "--enable-trace-backends" was introduced by:
> 5b808275f3bb ("trace: Multi-backend tracing")
> The backward compatible option "--enable-trace-backend" is removed by
> 10229ec3b0ff ("configure: remove backwards-compatibility and obsolete
> options")
>
> As we already use ./configure options that wouldn't be accepted by
> older version of QEMU's configure, we will simply use the new spelling
> for the option and avoid trying to detect which spelling to use.
>
> We already make use if "--firmwarepath=" which was introduced by
> 3d5eecab4a5a ("Add --firmwarepath to configure")
> which already include the new spelling for "--enable-trace-backends".
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
Thanks,
Jason
[XEN PATCH] tools: Fix build with recent QEMU, use "--enable-trace-backends"
The configure option "--enable-trace-backend" isn't accepted anymore
and we should use "--enable-trace-backends" instead which was
introduce in 2014 and allow multiple backends.
"--enable-trace-backends" was introduced by:
5b808275f3bb ("trace: Multi-backend tracing")
The backward compatible option "--enable-trace-backend" is removed by
10229ec3b0ff ("configure: remove backwards-compatibility and obsolete
options")
As we already use ./configure options that wouldn't be accepted by
older version of QEMU's configure, we will simply use the new spelling
for the option and avoid trying to detect which spelling to use.
We already make use if "--firmwarepath=" which was introduced by
3d5eecab4a5a ("Add --firmwarepath to configure")
which already include the new spelling for "--enable-trace-backends".
Signed-off-by: Anthony PERARD
---
tools/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index 9e28027835..4906fdbc23 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -218,9 +218,9 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
mkdir -p qemu-xen-build; \
cd qemu-xen-build; \
if $$source/scripts/tracetool.py --check-backend --backend log ; then \
- enable_trace_backend='--enable-trace-backend=log'; \
+ enable_trace_backend="--enable-trace-backends=log"; \
elif $$source/scripts/tracetool.py --check-backend --backend stderr ;
then \
- enable_trace_backend='--enable-trace-backend=stderr'; \
+ enable_trace_backend='--enable-trace-backends=stderr'; \
else \
enable_trace_backend='' ; \
fi ; \
--
Anthony PERARD
[PATCH v3 6/6] automation: add RISC-V smoke test
Add check if there is a message 'Hello from C env' presents
in log file to be sure that stack is set and C part of early printk
is working.
Signed-off-by: Oleksii Kurochko
Acked-by: Stefano Stabellini
---
Changes in V3:
- Nothing changed
- All mentioned comments by Stefano in Xen mailing list will be
fixed as a separate patch out of this patch series.
---
Changes in V2:
- Move changes in the dockerfile to separate patch and send it to
mailing list separately:
[PATCH] automation: add qemu-system-riscv to riscv64.dockerfile
- Update test.yaml to wire up smoke test
---
automation/gitlab-ci/test.yaml | 20
automation/scripts/qemu-smoke-riscv64.sh | 20
2 files changed, 40 insertions(+)
create mode 100755 automation/scripts/qemu-smoke-riscv64.sh
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index afd80adfe1..64f47a0ab9 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -54,6 +54,19 @@
tags:
- x86_64
+.qemu-riscv64:
+ extends: .test-jobs-common
+ variables:
+CONTAINER: archlinux:riscv64
+LOGFILE: qemu-smoke-riscv64.log
+ artifacts:
+paths:
+ - smoke.serial
+ - '*.log'
+when: always
+ tags:
+- x86_64
+
.yocto-test:
extends: .test-jobs-common
script:
@@ -234,6 +247,13 @@ qemu-smoke-x86-64-clang-pvh:
needs:
- debian-unstable-clang-debug
+qemu-smoke-riscv64-gcc:
+ extends: .qemu-riscv64
+ script:
+- ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE}
+ needs:
+- riscv64-cross-gcc
+
# Yocto test jobs
yocto-qemuarm64:
extends: .yocto-test-arm64
diff --git a/automation/scripts/qemu-smoke-riscv64.sh
b/automation/scripts/qemu-smoke-riscv64.sh
new file mode 100755
index 00..e0f06360bc
--- /dev/null
+++ b/automation/scripts/qemu-smoke-riscv64.sh
@@ -0,0 +1,20 @@
+#!/bin/bash
+
+set -ex
+
+# Run the test
+rm -f smoke.serial
+set +e
+
+timeout -k 1 2 \
+qemu-system-riscv64 \
+-M virt \
+-smp 1 \
+-nographic \
+-m 2g \
+-kernel binaries/xen \
+|& tee smoke.serial
+
+set -e
+(grep -q "Hello from C env" smoke.serial) || exit 1
+exit 0
--
2.38.1
[PATCH v3 4/6] xen/riscv: introduce sbi call to putchar to console
From: Bobby Eshleman
Originally SBI implementation for Xen was introduced by
Bobby Eshleman but it was removed
all the stuff for simplicity except SBI call for putting
character to console.
The patch introduces sbi_putchar() SBI call which is necessary
to implement initial early_printk.
Signed-off-by: Bobby Eshleman
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- update copyright's year
- rename define __CPU_SBI_H__ to __ASM_RISCV_SBI_H__
- fix identations
- change an author of the commit
---
Changes in V2:
- add an explanatory comment about sbi_console_putchar() function.
- order the files alphabetically in Makefile
---
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/include/asm/sbi.h | 34
xen/arch/riscv/sbi.c | 45
3 files changed, 80 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/sbi.h
create mode 100644 xen/arch/riscv/sbi.c
diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 5a67a3f493..fd916e1004 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RISCV_64) += riscv64/
+obj-y += sbi.o
obj-y += setup.o
$(TARGET): $(TARGET)-syms
diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h
new file mode 100644
index 00..0e6820a4ed
--- /dev/null
+++ b/xen/arch/riscv/include/asm/sbi.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: (GPL-2.0-or-later) */
+/*
+ * Copyright (c) 2021-2023 Vates SAS.
+ *
+ * Taken from xvisor, modified by Bobby Eshleman (bobby.eshle...@gmail.com).
+ *
+ * Taken/modified from Xvisor project with the following copyright:
+ *
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ */
+
+#ifndef __ASM_RISCV_SBI_H__
+#define __ASM_RISCV_SBI_H__
+
+#define SBI_EXT_0_1_CONSOLE_PUTCHAR0x1
+
+struct sbiret {
+long error;
+long value;
+};
+
+struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5);
+
+/**
+ * Writes given character to the console device.
+ *
+ * @param ch The data to be written to the console.
+ */
+void sbi_console_putchar(int ch);
+
+#endif /* __ASM_RISCV_SBI_H__ */
diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
new file mode 100644
index 00..dc0eb44bc6
--- /dev/null
+++ b/xen/arch/riscv/sbi.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Taken and modified from the xvisor project with the copyright Copyright (c)
+ * 2019 Western Digital Corporation or its affiliates and author Anup Patel
+ * (anup.pa...@wdc.com).
+ *
+ * Modified by Bobby Eshleman (bobby.eshle...@gmail.com).
+ *
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ * Copyright (c) 2021-2023 Vates SAS.
+ */
+
+#include
+#include
+
+struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+struct sbiret ret;
+
+register unsigned long a0 asm ("a0") = arg0;
+register unsigned long a1 asm ("a1") = arg1;
+register unsigned long a2 asm ("a2") = arg2;
+register unsigned long a3 asm ("a3") = arg3;
+register unsigned long a4 asm ("a4") = arg4;
+register unsigned long a5 asm ("a5") = arg5;
+register unsigned long a6 asm ("a6") = fid;
+register unsigned long a7 asm ("a7") = ext;
+
+asm volatile ("ecall"
+ : "+r" (a0), "+r" (a1)
+ : "r" (a2), "r" (a3), "r" (a4), "r" (a5), "r" (a6), "r" (a7)
+ : "memory");
+ret.error = a0;
+ret.value = a1;
+
+return ret;
+}
+
+void sbi_console_putchar(int ch)
+{
+sbi_ecall(SBI_EXT_0_1_CONSOLE_PUTCHAR, 0, ch, 0, 0, 0, 0, 0);
+}
--
2.38.1
[PATCH v3 3/6] xen/riscv: introduce stack stuff
The patch introduces and sets up a stack in order to go to C environment
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- reorder headers in alphabetical order
- merge changes related to start_xen() function from "[PATCH v2 7/8]
xen/riscv: print hello message from C env" to this patch
- remove unneeded parentheses in definition of STACK_SIZE
---
Changes in V2:
- introduce STACK_SIZE define.
- use consistent padding between instruction mnemonic and operand(s)
---
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/include/asm/config.h | 2 ++
xen/arch/riscv/riscv64/head.S | 6 +-
xen/arch/riscv/setup.c | 14 ++
4 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/riscv/setup.c
diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 248f2cbb3e..5a67a3f493 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RISCV_64) += riscv64/
+obj-y += setup.o
$(TARGET): $(TARGET)-syms
$(OBJCOPY) -O binary -S $< $@
diff --git a/xen/arch/riscv/include/asm/config.h
b/xen/arch/riscv/include/asm/config.h
index 0370f865f3..763a922a04 100644
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -43,6 +43,8 @@
#define SMP_CACHE_BYTES (1 << 6)
+#define STACK_SIZE PAGE_SIZE
+
#endif /* __RISCV_CONFIG_H__ */
/*
* Local variables:
diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S
index 990edb70a0..d444dd8aad 100644
--- a/xen/arch/riscv/riscv64/head.S
+++ b/xen/arch/riscv/riscv64/head.S
@@ -1,4 +1,8 @@
.section .text.header, "ax", %progbits
ENTRY(start)
-j start
+la sp, cpu0_boot_stack
+li t0, STACK_SIZE
+add sp, sp, t0
+
+tailstart_xen
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
new file mode 100644
index 00..13e24e2fe1
--- /dev/null
+++ b/xen/arch/riscv/setup.c
@@ -0,0 +1,14 @@
+#include
+#include
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
+__aligned(STACK_SIZE);
+
+void __init noreturn start_xen(void)
+{
+for ( ;; )
+asm volatile ("wfi");
+
+unreachable();
+}
--
2.38.1
[PATCH v3 1/6] xen/riscv: introduce dummy asm/init.h
The following patches require which includes Signed-off-by: Oleksii Kurochko --- Changes in V3: - Nothing changed --- Changes in V2: - Add explanation comment to the comment message --- xen/arch/riscv/include/asm/init.h | 12 1 file changed, 12 insertions(+) create mode 100644 xen/arch/riscv/include/asm/init.h diff --git a/xen/arch/riscv/include/asm/init.h b/xen/arch/riscv/include/asm/init.h new file mode 100644 index 00..237ec25e4e --- /dev/null +++ b/xen/arch/riscv/include/asm/init.h @@ -0,0 +1,12 @@ +#ifndef _XEN_ASM_INIT_H +#define _XEN_ASM_INIT_H + +#endif /* _XEN_ASM_INIT_H */ +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.38.1
[PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
Signed-off-by: Oleksii Kurochko --- Changes in V3: - Nothing changed --- Changes in V2: - Remove unneeded now types from --- xen/arch/riscv/include/asm/types.h | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 xen/arch/riscv/include/asm/types.h diff --git a/xen/arch/riscv/include/asm/types.h b/xen/arch/riscv/include/asm/types.h new file mode 100644 index 00..fbe352ef20 --- /dev/null +++ b/xen/arch/riscv/include/asm/types.h @@ -0,0 +1,22 @@ +#ifndef __RISCV_TYPES_H__ +#define __RISCV_TYPES_H__ + +#ifndef __ASSEMBLY__ + +#if defined(__SIZE_TYPE__) +typedef __SIZE_TYPE__ size_t; +#else +typedef unsigned long size_t; +#endif + +#endif /* __ASSEMBLY__ */ + +#endif /* __RISCV_TYPES_H__ */ +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.38.1
[PATCH v3 5/6] xen/riscv: introduce early_printk basic stuff
From: Bobby Eshleman
The patch introduces a basic stuff of early_printk functionality
which will be enough to print 'hello from C environment".
early_printk() function was changed in comparison with original as
common isn't being built now so there is no vscnprintf.
Because printk() relies on a serial driver (like the ns16550 driver)
and drivers require working virtual memory (ioremap()) there is not
print functionality early in Xen boot.
This commit adds early printk implementation built on the putc SBI call.
As sbi_console_putchar() is being already planned for deprecation
it is used temporary now and will be removed or reworked after
real uart will be ready.
Signed-off-by: Bobby Eshleman
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- reorder "include " in erly_printk.c
- change an author of the commit
---
Changes in V2:
- add license to early_printk.c
- add signed-off-by Bobby
- add RISCV_32 to Kconfig.debug to EARLY_PRINTK config
- update commit message
- order the files alphabetically in Makefile
---
xen/arch/riscv/Kconfig.debug | 7 +
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/early_printk.c | 33 +++
xen/arch/riscv/include/asm/early_printk.h | 12 +
xen/arch/riscv/setup.c| 4 +++
5 files changed, 57 insertions(+)
create mode 100644 xen/arch/riscv/early_printk.c
create mode 100644 xen/arch/riscv/include/asm/early_printk.h
diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
index e69de29bb2..e21649781d 100644
--- a/xen/arch/riscv/Kconfig.debug
+++ b/xen/arch/riscv/Kconfig.debug
@@ -0,0 +1,7 @@
+config EARLY_PRINTK
+bool "Enable early printk"
+default DEBUG
+depends on RISCV_64 || RISCV_32
+help
+
+ Enables early printk debug messages
diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index fd916e1004..1a4f1a6015 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_RISCV_64) += riscv64/
obj-y += sbi.o
obj-y += setup.o
diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
new file mode 100644
index 00..348c21bdaa
--- /dev/null
+++ b/xen/arch/riscv/early_printk.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * RISC-V early printk using SBI
+ *
+ * Copyright (C) 2021 Bobby Eshleman
+ */
+#include
+#include
+
+/*
+ * TODO:
+ * sbi_console_putchar is already planned for deprecation
+ * so it should be reworked to use UART directly.
+*/
+void early_puts(const char *s, size_t nr)
+{
+while ( nr-- > 0 )
+{
+if (*s == '\n')
+sbi_console_putchar('\r');
+sbi_console_putchar(*s);
+s++;
+}
+}
+
+void early_printk(const char *str)
+{
+while (*str)
+{
+early_puts(str, 1);
+str++;
+}
+}
diff --git a/xen/arch/riscv/include/asm/early_printk.h
b/xen/arch/riscv/include/asm/early_printk.h
new file mode 100644
index 00..05106e160d
--- /dev/null
+++ b/xen/arch/riscv/include/asm/early_printk.h
@@ -0,0 +1,12 @@
+#ifndef __EARLY_PRINTK_H__
+#define __EARLY_PRINTK_H__
+
+#include
+
+#ifdef CONFIG_EARLY_PRINTK
+void early_printk(const char *str);
+#else
+static inline void early_printk(const char *s) {};
+#endif
+
+#endif /* __EARLY_PRINTK_H__ */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 13e24e2fe1..d09ffe1454 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -1,12 +1,16 @@
#include
#include
+#include
+
/* Xen stack for bringing up the first CPU. */
unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__aligned(STACK_SIZE);
void __init noreturn start_xen(void)
{
+early_printk("Hello from C env\n");
+
for ( ;; )
asm volatile ("wfi");
--
2.38.1
[PATCH v3 0/6] Basic early_printk and smoke test implementation
The patch series introduces the following: - the minimal set of headers and changes inside them. - SBI (RISC-V Supervisor Binary Interface) things necessary for basic early_printk implementation. - things needed to set up the stack. - early_printk() function to print only strings. - RISC-V smoke test which checks if "Hello from C env" message is present in serial.tmp --- Changes in V3: - Most of "[PATCH v2 7/8] xen/riscv: print hello message from C env" was merged with [PATCH v2 3/6] xen/riscv: introduce stack stuff. - "[PATCH v2 7/8] xen/riscv: print hello message from C env" was merged with "[PATCH v2 6/8] xen/riscv: introduce early_printk basic stuff". - "[PATCH v2 5/8] xen/include: include in " was removed as it has been already merged to mainline staging. - code style fixes. --- Changes in V2: - update commit patches commit messages according to the mailing list comments - Remove unneeded types in - Introduce definition of STACK_SIZE - order the files alphabetically in Makefile - Add license to early_printk.c - Add RISCV_32 dependecy to config EARLY_PRINTK in Kconfig.debug - Move dockerfile changes to separate config and sent them as separate patch to mailing list. - Update test.yaml to wire up smoke test --- Bobby Eshleman (2): xen/riscv: introduce sbi call to putchar to console xen/riscv: introduce early_printk basic stuff Oleksii Kurochko (4): xen/riscv: introduce dummy asm/init.h xen/riscv: introduce asm/types.h header file xen/riscv: introduce stack stuff automation: add RISC-V smoke test automation/gitlab-ci/test.yaml| 20 ++ automation/scripts/qemu-smoke-riscv64.sh | 20 ++ xen/arch/riscv/Kconfig.debug | 7 xen/arch/riscv/Makefile | 3 ++ xen/arch/riscv/early_printk.c | 33 + xen/arch/riscv/include/asm/config.h | 2 + xen/arch/riscv/include/asm/early_printk.h | 12 ++ xen/arch/riscv/include/asm/init.h | 12 ++ xen/arch/riscv/include/asm/sbi.h | 34 + xen/arch/riscv/include/asm/types.h| 22 +++ xen/arch/riscv/riscv64/head.S | 6 ++- xen/arch/riscv/sbi.c | 45 +++ xen/arch/riscv/setup.c| 18 + 13 files changed, 233 insertions(+), 1 deletion(-) create mode 100755 automation/scripts/qemu-smoke-riscv64.sh create mode 100644 xen/arch/riscv/early_printk.c create mode 100644 xen/arch/riscv/include/asm/early_printk.h create mode 100644 xen/arch/riscv/include/asm/init.h create mode 100644 xen/arch/riscv/include/asm/sbi.h create mode 100644 xen/arch/riscv/include/asm/types.h create mode 100644 xen/arch/riscv/sbi.c create mode 100644 xen/arch/riscv/setup.c -- 2.38.1
[qemu-mainline test] 175691: regressions - FAIL
flight 175691 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175691/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 175623 build-amd64 6 xen-buildfail REGR. vs. 175623 build-i3866 xen-buildfail REGR. vs. 175623 build-arm64-xsm 6 xen-buildfail REGR. vs. 175623 build-i386-xsm6 xen-buildfail REGR. vs. 175623 build-arm64 6 xen-buildfail REGR. vs. 175623 build-armhf 6 xen-buildfail REGR. vs. 175623 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1
Xenalyze on ARM ( NXP S32G3 with Cortex-A53)
>> Hello, >> I'm trying to measure the performance of Xen on the S32G3 microprocessor, unfortunately, after following the BSP-Linux to install Xen, I found that Xentrace is not available or not compatible with ARM architecture. I have seen some studies on Xilinx, and how they made Xentrace compatible with ARM, but I have no resources or access to get that and make it work on my Board. If there is any help I would appreciate it and thanks in advance. >> I have some extra questions, and it will be helpful to share your ideas with >> me, * Is it possible to run a native application ( C-code) on the virtual machine, turn on a LED, have access to the GPIO, or send some messages using Can-Interface? * My Board has no Ethernet, and no Extern SD Card, is there any method I can use to build a kernel for an operating system with my laptop, and transfer it to the board? * Any suggestions in detail to measure the interrupt latency, Xen Overhead, and switch context (time to switch from one VM to another, that's what I wanted to measure with Xenalyze) >> Best regards >> Youssef El Mesdadi
Re: Usage of Xen Security Data in VulnerableCode
On 10/01/2023 1:33 pm, Tushar Goel wrote: > Hey, > > We would like to integrate the xen security data[1][2] data > in vulnerablecode[3] which is a FOSS db of FOSS vulnerability data. > We were not able to know under which license this security data comes. > We would be grateful to have your acknowledgement over > usage of the xen security data in vulnerablecode and > have some kind of licensing declaration from your side. > > [1] - https://xenbits.xen.org/xsa/xsa.json > [2] - https://github.com/nexB/vulnerablecode/pull/1044 > [3] - https://github.com/nexB/vulnerablecode Hmm, good question... In practice, it is public domain, not least because we publish it to Mitre and various public mailing lists, but I'm not aware of having explicitly tried to choose a license. Maybe we want to make it CC-BY-4 to require people to reference back to the canonical upstream ? ~Andrew
Usage of Xen Security Data in VulnerableCode
Hey, We would like to integrate the xen security data[1][2] data in vulnerablecode[3] which is a FOSS db of FOSS vulnerability data. We were not able to know under which license this security data comes. We would be grateful to have your acknowledgement over usage of the xen security data in vulnerablecode and have some kind of licensing declaration from your side. [1] - https://xenbits.xen.org/xsa/xsa.json [2] - https://github.com/nexB/vulnerablecode/pull/1044 [3] - https://github.com/nexB/vulnerablecode Regards,
Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru
On 1/10/2023 3:16 AM, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
> > Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> > as noted in docs/igd-assign.txt in the Qemu source code.
> >
> > Currently, when the xl toolstack is used to configure a Xen HVM guest with
> > Intel IGD passthrough to the guest with the Qemu upstream device model,
> > a Qemu emulated PCI device will occupy slot 2 and the Intel IGD will occupy
> > a different slot. This problem often prevents the guest from booting.
> >
> > The only available workaround is not good: Configure Xen HVM guests to use
> > the old and no longer maintained Qemu traditional device model available
> > from xenbits.xen.org which does reserve slot 2 for the Intel IGD.
> >
> > To implement this feature in the Qemu upstream device model for Xen HVM
> > guests, introduce the following new functions, types, and macros:
> >
> > * XEN_PT_DEVICE_CLASS declaration, based on the existing TYPE_XEN_PT_DEVICE
> > * XEN_PT_DEVICE_GET_CLASS macro helper function for XEN_PT_DEVICE_CLASS
> > * typedef XenPTQdevRealize function pointer
> > * XEN_PCI_IGD_SLOT_MASK, the value of slot_reserved_mask to reserve slot 2
> > * xen_igd_reserve_slot and xen_igd_clear_slot functions
> >
> > The new xen_igd_reserve_slot function uses the existing slot_reserved_mask
> > member of PCIBus to reserve PCI slot 2 for Xen HVM guests configured using
> > the xl toolstack with the gfx_passthru option enabled, which sets the
> > igd-passthru=on option to Qemu for the Xen HVM machine type.
> >
> > The new xen_igd_reserve_slot function also needs to be implemented in
> > hw/xen/xen_pt_stub.c to prevent FTBFS during the link stage for the case
> > when Qemu is configured with --enable-xen and --disable-xen-pci-passthrough,
> > in which case it does nothing.
> >
> > The new xen_igd_clear_slot function overrides qdev->realize of the parent
> > PCI device class to enable the Intel IGD to occupy slot 2 on the PCI bus
> > since slot 2 was reserved by xen_igd_reserve_slot when the PCI bus was
> > created in hw/i386/pc_piix.c for the case when igd-passthru=on.
> >
> > Move the call to xen_host_pci_device_get, and the associated error
> > handling, from xen_pt_realize to the new xen_igd_clear_slot function to
> > initialize the device class and vendor values which enables the checks for
> > the Intel IGD to succeed. The verification that the host device is an
> > Intel IGD to be passed through is done by checking the domain, bus, slot,
> > and function values as well as by checking that gfx_passthru is enabled,
> > the device class is VGA, and the device vendor in Intel.
> >
> > Signed-off-by: Chuck Zmudzinski
> > ---
> > Notes that might be helpful to reviewers of patched code in hw/xen:
> >
> > The new functions and types are based on recommendations from Qemu docs:
> > https://qemu.readthedocs.io/en/latest/devel/qom.html
> >
> > Notes that might be helpful to reviewers of patched code in hw/i386:
> >
> > The small patch to hw/i386/pc_piix.c is protected by CONFIG_XEN so it does
> > not affect builds that do not have CONFIG_XEN defined.
> >
> > xen_igd_gfx_pt_enabled() in the patched hw/i386/pc_piix.c file is an
> > existing function that is only true when Qemu is built with
> > xen-pci-passthrough enabled and the administrator has configured the Xen
> > HVM guest with Qemu's igd-passthru=on option.
> >
> > v2: Remove From: tag at top of commit message
> >
> > v3: Changed the test for the Intel IGD in xen_igd_clear_slot:
> >
> > if (is_igd_vga_passthrough(&s->real_device) &&
> > (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL)) {
> >
> > is changed to
> >
> > if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
> > && (s->hostaddr.function == 0)) {
> >
> > I hoped that I could use the test in v2, since it matches the
> > other tests for the Intel IGD in Qemu and Xen, but those tests
> > do not work because the necessary data structures are not set with
> > their values yet. So instead use the test that the administrator
> > has enabled gfx_passthru and the device address on the host is
> > 02.0. This test does detect the Intel IGD correctly.
> >
> > v4: Use brchu...@aol.com instead of brchu...@netscape.net for the author's
> > email address to match the address used by the same author in commits
> > be9c61da and c0e86b76
> >
> > Change variable for XEN_PT_DEVICE_CLASS: xptc changed to xpdc
> >
> > v5: The patch of xen_pt.c was re-worked to allow a more consistent test
> > for the Intel IGD that uses the same criteria as in other places.
> > This involved moving the call to xen_host_pci_device_get from
> > xen_pt_realize to xen_igd_clear_slot and updating the checks for the
> > Intel IGD in xen_igd_clear_slot:
> >
> > if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
> > && (s->hostaddr.function == 0)) {
>
Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner when host address not provided
Hi Penny,
On 10/01/2023 03:38, Penny Zheng wrote:
-Original Message-
From: Julien Grall
Sent: Tuesday, January 10, 2023 2:23 AM
To: Penny Zheng ; xen-devel@lists.xenproject.org
Cc: Wei Chen ; Stefano Stabellini
; Bertrand Marquis ;
Volodymyr Babchuk
Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner
when host address not provided
Hi Penny,
Hi Julien,
On 09/01/2023 11:58, Penny Zheng wrote:
-Original Message-
From: Julien Grall
Sent: Monday, January 9, 2023 6:58 PM
To: Penny Zheng ; xen-
de...@lists.xenproject.org
Cc: Wei Chen ; Stefano Stabellini
; Bertrand Marquis
; Volodymyr Babchuk
Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner
when host address not provided
On 09/01/2023 07:49, Penny Zheng wrote:
Hi Julien
Hi Penny,
Happy new year
Happy new year too!
-Original Message-
From: Julien Grall
Sent: Sunday, January 8, 2023 8:53 PM
To: Penny Zheng ; xen-
de...@lists.xenproject.org
Cc: Wei Chen ; Stefano Stabellini
; Bertrand Marquis
; Volodymyr Babchuk
Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to
owner when host address not provided
Hi,
A few concerns explained why I didn't choose "struct meminfo" over
two pointers "struct membank*" and "struct meminfo*".
1) memory usage is the main reason.
If we use "struct meminfo" over the current "struct membank*" and
"struct meminfo*", "struct shm_meminfo" will become a array of 256
"struct shm_membank", with "struct shm_membank" being also an 256-
item
array, that is 256 * 256, too big for a structure and If I
remembered clearly,
it will lead to "more than PAGE_SIZE" compiling error.
I am not aware of any place where we would restrict the size of kinfo
in upstream. Can you give me a pointer?
If I remembered correctly, my first version of "struct shm_meminfo" is
this
"big"(256 * 256) structure, and it leads to the whole xen binary is
. ;\
Ah so the problem is because shm_mem is used in bootinfo. Then I think we
should create a distinct structure when dealing with domain information.
Yes, If I use the latter "struct shm_info", keeping the shm memory info out of
the bootinfo,
I think we could avoid "bigger than 2MB" error.
Hmm, out of curiosity, The way to create "distinct" structure is like creating
another section
for these distinct structures in lds, just like the existing .dtb section?
No. I meant defining a new structure (i.e. struct {}) that would be used
in kernel_info. So you don't grow the one used by bootinfo.
FWIT, either reworking meminfo or using a different structure, are
both leading to sizing down the array, hmmm, I don't know which size
is suitable. That's why I prefer pointer and dynamic allocation.
I would expect that in most cases, you will need only one bank when
the host address is not provided. So I think this is a bit odd to me to
impose a "large"
allocation for them.
Only if user is not defining size as something like (2^a + 2^b + 2^c +
...). ;\ So maybe 8 or 16 is enough?
struct new_meminfo {
"new" is a bit strange. The name would want to be changed. Or maybe better
the structure been defined within the next structure and anonymized.
unsigned int nr_banks;
struct membank bank[8];
};
Correct me if I'm wrong:
The "struct shm_membank" you are suggesting is looking like this, right?
struct shm_membank {
char shm_id[MAX_SHM_ID_LENGTH];
unsigned int nr_shm_borrowers;
struct new_meminfo shm_banks;
unsigned long total_size;
};
AFAIU, shm_membank would still be used to get the information from the
host device-tree. If so, then I am afraid this is not an option to me because it
would make the code to reserve memory more complex.
Instead, we should create a separate structure that will only be used for
domain shared memory information.
Ah, so you are suggesting we should extract the domain shared memory
information only
when dealing with the information from the host device-tree, something like
this:
struct shm_info {
char shm_id[MAX_SHM_ID_LENGTH];
unsigned int nr_shm_borrowers;
}
I am not entirely sure what you are suggesting. So I will wait for the
code to understand.
Cheers,
--
Julien Grall
Re: [PATCH v2 4/8] xen/riscv: introduce sbi call to putchar to console
(+ George) On 10/01/2023 12:43, Julien Grall wrote: On 10/01/2023 08:21, Oleksii wrote: Hi, Hi Oleksii, On Mon, 2023-01-09 at 16:03 +, Julien Grall wrote: Hi, On 09/01/2023 15:46, Oleksii Kurochko wrote: The patch introduce sbi_putchar() SBI call which is necessary to implement initial early_printk Signed-off-by: Oleksii Kurochko --- Changes in V2: - add an explanatory comment about sbi_console_putchar() function. - order the files alphabetically in Makefile --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/include/asm/sbi.h | 34 xen/arch/riscv/sbi.c | 44 3 files changed, 79 insertions(+) create mode 100644 xen/arch/riscv/include/asm/sbi.h create mode 100644 xen/arch/riscv/sbi.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 5a67a3f493..fd916e1004 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,4 +1,5 @@ obj-$(CONFIG_RISCV_64) += riscv64/ +obj-y += sbi.o obj-y += setup.o $(TARGET): $(TARGET)-syms diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h new file mode 100644 index 00..34b53f8eaf --- /dev/null +++ b/xen/arch/riscv/include/asm/sbi.h @@ -0,0 +1,34 @@ +/* SPDX-License-Identifier: (GPL-2.0-or-later) */ +/* + * Copyright (c) 2021 Vates SAS. + * + * Taken from xvisor, modified by Bobby Eshleman (bobby.eshle...@gmail.com). Hmmm... I missed this one in v1. Is this mostly code from Bobby? If so, please update the commit message accordingly. FAOD, this comment applies for any future code you take from anyone. I will try to remember to mention it but please take pro-active action to check/mention where the code is coming from. Sure, I will try to be more attentive next time. Probably it is out of scope a little bit but could you please share with me a link or clarify in which cases I have to add Copytrigt(c) or should I add a new comment with "Modfied by Oleksii ... ", or it is not necessary at all? Maybe have I to put some other information related to copyrigts? From my experience, in Xen, we tend to use the signed-off-by rather in-file copyright. So I don't exactly know what would be the rule. Maybe George can help here? Cheers, -- Julien Grall
Re: [PATCH v2 4/8] xen/riscv: introduce sbi call to putchar to console
On 10/01/2023 08:21, Oleksii wrote: Hi, Hi Oleksii, On Mon, 2023-01-09 at 16:03 +, Julien Grall wrote: Hi, On 09/01/2023 15:46, Oleksii Kurochko wrote: The patch introduce sbi_putchar() SBI call which is necessary to implement initial early_printk Signed-off-by: Oleksii Kurochko --- Changes in V2: - add an explanatory comment about sbi_console_putchar() function. - order the files alphabetically in Makefile --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/include/asm/sbi.h | 34 xen/arch/riscv/sbi.c | 44 3 files changed, 79 insertions(+) create mode 100644 xen/arch/riscv/include/asm/sbi.h create mode 100644 xen/arch/riscv/sbi.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 5a67a3f493..fd916e1004 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,4 +1,5 @@ obj-$(CONFIG_RISCV_64) += riscv64/ +obj-y += sbi.o obj-y += setup.o $(TARGET): $(TARGET)-syms diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h new file mode 100644 index 00..34b53f8eaf --- /dev/null +++ b/xen/arch/riscv/include/asm/sbi.h @@ -0,0 +1,34 @@ +/* SPDX-License-Identifier: (GPL-2.0-or-later) */ +/* + * Copyright (c) 2021 Vates SAS. + * + * Taken from xvisor, modified by Bobby Eshleman (bobby.eshle...@gmail.com). Hmmm... I missed this one in v1. Is this mostly code from Bobby? If so, please update the commit message accordingly. FAOD, this comment applies for any future code you take from anyone. I will try to remember to mention it but please take pro-active action to check/mention where the code is coming from. Sure, I will try to be more attentive next time. Probably it is out of scope a little bit but could you please share with me a link or clarify in which cases I have to add Copytrigt(c) or should I add a new comment with "Modfied by Oleksii ... ", or it is not necessary at all? Maybe have I to put some other information related to copyrigts? From my experience, in Xen, we tend to use the signed-off-by rather in-file copyright. So I don't exactly know what would be the rule. Maybe George can help here? Cheers, -- Julien Grall
Re: [XEN v4] xen/arm: Probe the load/entry point address of an uImage correctly
On 09.01.23 11:36, Oleksandr Tyshchenko wrote: > > > On 08.01.23 18:06, Julien Grall wrote: > > Hello Julien, Ayan, all > >> Hi Ayan, >> ... >> The changes look good to me (with a few of comments below). That >> said, before acking the code, I would like an existing user of uImage >> (maybe EPAM or Arm?) to confirm they are happy with the change. > > I have just re-checked current patch in our typical Xen based > environment (no dom0less, Linux in Dom0) and didn't notice issues with > it. But we use zImage for Dom0's kernel, so kernel_uimage_probe() is > not called. > > > I CCed Dmytro Firsov who is playing with Zephyr in Dom0 and *might* > use uImage. Hi Oleksandr, Julien, all Current Xenutils/Zephyr Dom0 setup uses standard format for Zephyr on arm64 which is zImage. Thus uImage changes will not affect me.
[libvirt test] 175684: tolerable FAIL - PUSHED
flight 175684 libvirt real [real] flight 175698 libvirt real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/175684/ http://logs.test-lab.xenproject.org/osstest/logs/175698/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 175698-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175638 test-arm64-arm64-libvirt-qcow2 17 guest-start/debian.repeat fail like 175638 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175638 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175638 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: libvirt 49ff47269b71a762ca5de4595f6ec915043e05ce baseline version: libvirt ffd286ac6f25374d16f4eaa7ff64e30c77541b41 Last test of basis 175638 2023-01-09 04:18:55 Z1 days Testing same since 175684 2023-01-10 04:18:53 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Erik Skultety Jiang Jiacheng Ján Tomko Pavel Hrdina Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw
[qemu-mainline bisection] complete build-arm64
branch xen-unstable xenbranch xen-unstable job build-arm64 testid xen-build Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 3d83b78285d6e96636130f7d449fd02e2d4deee0 Bug not present: 528d9f33cad5245c1099d77084c78bb2244d5143 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/175697/ commit 3d83b78285d6e96636130f7d449fd02e2d4deee0 Merge: 528d9f33ca fb418b51b7 Author: Peter Maydell Date: Sun Jan 8 14:27:40 2023 + Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging * Atomic memslot updates for KVM (Emanuele, David) * Always send errors to logfile when daemonized (Greg) * Add support for IDE CompactFlash card (Lubomir) * First round of build system cleanups (myself) * First round of feature removals (myself) * Reduce "qemu/accel.h" inclusion (Philippe) # gpg: Signature made Thu 05 Jan 2023 23:51:09 GMT # gpg:using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg:issuer "pbonz...@redhat.com" # gpg: Good signature from "Paolo Bonzini " [full] # gpg: aka "Paolo Bonzini " [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (24 commits) i386: SGX: remove deprecated member of SGXInfo target/i386: Add SGX aex-notify and EDECCSSA support util: remove support -chardev tty and -chardev parport util: remove support for hex numbers with a scaling suffix KVM: remove support for kernel-irqchip=off docs: do not talk about past removal as happening in the future meson: accept relative symlinks in "meson introspect --installed" data meson: cleanup compiler detection meson: support meson 0.64 -Doptimization=plain configure: test all warnings tests/qapi-schema: remove Meson workaround meson: cleanup dummy-cpus.c rules meson: tweak hardening options for Windows configure: remove backwards-compatibility and obsolete options configure: preserve qemu-ga variables configure: cleanup $cpu tests configure: remove dead function configure: remove useless write_c_skeleton ide: Add "ide-cf" driver, a CompactFlash card ide: Add 8-bit data mode ... Signed-off-by: Peter Maydell commit fb418b51b7b43c34873f4b9af3da7031b7452115 Author: Paolo Bonzini Date: Fri Dec 16 11:02:48 2022 +0100 i386: SGX: remove deprecated member of SGXInfo Signed-off-by: Paolo Bonzini commit d45f24fe7525d8a8aaa4ca6d9d214dc41819caa5 Author: Kai Huang Date: Wed Nov 9 15:48:34 2022 +1300 target/i386: Add SGX aex-notify and EDECCSSA support The new SGX Asynchronous Exit (AEX) notification mechanism (AEX-notify) allows one enclave to receive a notification in the ERESUME after the enclave exit due to an AEX. EDECCSSA is a new SGX user leaf function (ENCLU[EDECCSSA]) to facilitate the AEX notification handling. Whether the hardware supports to create enclave with AEX-notify support is enumerated via CPUID.(EAX=0x12,ECX=0x1):EAX[10]. The new EDECCSSA user leaf function is enumerated via CPUID.(EAX=0x12,ECX=0x0):EAX[11]. Add support to allow to expose the new SGX AEX-notify feature and the new EDECCSSA user leaf function to KVM guest. Link: https://lore.kernel.org/lkml/166760360549.4906.809756297092548496.tip-bot2@tip-bot2/ Link: https://lore.kernel.org/lkml/166760360934.4906.2427175408052308969.tip-bot2@tip-bot2/ Reviewed-by: Yang Zhong Signed-off-by: Kai Huang Message-Id: <20221109024834.172705-1-kai.hu...@intel.com> Signed-off-by: Paolo Bonzini commit 6f9f630836df355b9ca3f4641e6b7be71f6af076 Author: Paolo Bonzini Date: Fri Dec 16 10:56:53 2022 +0100 util: remove support -chardev tty and -chardev parport These were deprecated in 6.0 and can now be removed. Signed-off-by: Paolo Bonzini commit 8b902e3d2309595567e4957b96e971c4f3ca455e Author: Paolo Bonzini Date: Fri Dec 16 10:50:05 2022 +0100 util: remove support for hex numbers with a scaling suffix This was deprecated in 6.0 and can now be removed. Signed-off-by: Paolo Bonzini commit eaaaf8abdc9a9f3493f2cb6a751660dff3f9db57 Author: Paolo Bonzini Date: Fri Dec 16 10:39:32 2022 +0100 KVM: remove support for kernel-ir
Re: [PATCH v2 6/8] xen/riscv: introduce early_printk basic stuff
On Tue, Jan 10, 2023 at 5:29 PM Bobby Eshleman wrote:
>
>
>
> On Mon, Jan 9, 2023 at 4:28 PM Alistair Francis wrote:
>>
>> On Tue, Jan 10, 2023 at 1:47 AM Oleksii Kurochko
>> wrote:
>> >
>> > The patch introduces a basic stuff of early_printk functionality
>> > which will be enough to print 'hello from C environment".
>> > early_printk() function was changed in comparison with original as
>> > common isn't being built now so there is no vscnprintf.
>> >
>> > Because printk() relies on a serial driver (like the ns16550 driver)
>> > and drivers require working virtual memory (ioremap()) there is not
>> > print functionality early in Xen boot.
>> >
>> > This commit adds early printk implementation built on the putc SBI call.
>> >
>> > As sbi_console_putchar() is being already planned for deprecation
>> > it is used temporary now and will be removed or reworked after
>> > real uart will be ready.
>>
>> There was a discussion to add a new SBI putchar replacement. It
>> doesn't seem to be completed yet, but there might be an SBI
>> replacement for this in the future as well.
>>
>> Alistair
>
>
> Are you referring to the Debug Console Extension (EID #0x4442434E "DBCN")”?
>
> https://lists.riscv.org/g/tech-prs/topic/96051183#84
That's the one!
Alistair
>
> Best,
> Bobby
>
>>
>> >
>> > Signed-off-by: Bobby Eshleman
>> > Signed-off-by: Oleksii Kurochko
>> > ---
>> > Changes in V2:
>> > - add license to early_printk.c
>> > - add signed-off-by Bobby
>> > - add RISCV_32 to Kconfig.debug to EARLY_PRINTK config
>> > - update commit message
>> > - order the files alphabetically in Makefile
>> > ---
>> > xen/arch/riscv/Kconfig.debug | 7 +
>> > xen/arch/riscv/Makefile | 1 +
>> > xen/arch/riscv/early_printk.c | 33 +++
>> > xen/arch/riscv/include/asm/early_printk.h | 12 +
>> > 4 files changed, 53 insertions(+)
>> > create mode 100644 xen/arch/riscv/early_printk.c
>> > create mode 100644 xen/arch/riscv/include/asm/early_printk.h
>> >
>> > diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
>> > index e69de29bb2..6ba0bd1e5a 100644
>> > --- a/xen/arch/riscv/Kconfig.debug
>> > +++ b/xen/arch/riscv/Kconfig.debug
>> > @@ -0,0 +1,7 @@
>> > +config EARLY_PRINTK
>> > +bool "Enable early printk config"
>> > +default DEBUG
>> > +depends on RISCV_64 || RISCV_32
>> > +help
>> > +
>> > + Enables early printk debug messages
>> > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
>> > index fd916e1004..1a4f1a6015 100644
>> > --- a/xen/arch/riscv/Makefile
>> > +++ b/xen/arch/riscv/Makefile
>> > @@ -1,3 +1,4 @@
>> > +obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
>> > obj-$(CONFIG_RISCV_64) += riscv64/
>> > obj-y += sbi.o
>> > obj-y += setup.o
>> > diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
>> > new file mode 100644
>> > index 00..88da5169ed
>> > --- /dev/null
>> > +++ b/xen/arch/riscv/early_printk.c
>> > @@ -0,0 +1,33 @@
>> > +/* SPDX-License-Identifier: GPL-2.0 */
>> > +/*
>> > + * RISC-V early printk using SBI
>> > + *
>> > + * Copyright (C) 2021 Bobby Eshleman
>> > + */
>> > +#include
>> > +#include
>> > +
>> > +/*
>> > + * TODO:
>> > + * sbi_console_putchar is already planned for deprication
>> > + * so it should be reworked to use UART directly.
>> > +*/
>> > +void early_puts(const char *s, size_t nr)
>> > +{
>> > +while ( nr-- > 0 )
>> > +{
>> > +if (*s == '\n')
>> > +sbi_console_putchar('\r');
>> > +sbi_console_putchar(*s);
>> > +s++;
>> > +}
>> > +}
>> > +
>> > +void early_printk(const char *str)
>> > +{
>> > +while (*str)
>> > +{
>> > +early_puts(str, 1);
>> > +str++;
>> > +}
>> > +}
>> > diff --git a/xen/arch/riscv/include/asm/early_printk.h
>> > b/xen/arch/riscv/include/asm/early_printk.h
>> > new file mode 100644
>> > index 00..05106e160d
>> > --- /dev/null
>> > +++ b/xen/arch/riscv/include/asm/early_printk.h
>> > @@ -0,0 +1,12 @@
>> > +#ifndef __EARLY_PRINTK_H__
>> > +#define __EARLY_PRINTK_H__
>> > +
>> > +#include
>> > +
>> > +#ifdef CONFIG_EARLY_PRINTK
>> > +void early_printk(const char *str);
>> > +#else
>> > +static inline void early_printk(const char *s) {};
>> > +#endif
>> > +
>> > +#endif /* __EARLY_PRINTK_H__ */
>> > --
>> > 2.38.1
>> >
>> >
Re: [PATCH v2 17/17] docs: update numa command line to support Arm
On 10.01.2023 09:49, Wei Chen wrote: > Current numa command in documentation is x86 only. Remove > x86 from numa command's arch limitation in this patch. > > Signed-off-by: Wei Chen Acked-by: Jan Beulich Of course not on its own, only on top of all the earlier patches. Jan
Re: Problem with pat_enable() and commit 72cbc8f04fe2
On 10.01.23 10:38, Jan Beulich wrote:
On 10.01.2023 06:59, Juergen Gross wrote:
On 10.01.23 06:47, Juergen Gross wrote:
On 09.01.23 19:28, Michael Kelley (LINUX) wrote:
I've come across a case with a VM running on Hyper-V that doesn't get
MTRRs, but the PAT is functional. (This is a Confidential VM using
AMD's SEV-SNP encryption technology with the vTOM option.) In this
case, the changes in commit 72cbc8f04fe2 ("x86/PAT: Have pat_enabled()
properly reflect state when running on Xen") apply. pat_enabled() returns
"true", but the MTRRs are not enabled.
But with this commit, there's a problem. Consider memremap() on a RAM
region, called with MEMREMAP_WB plus MEMREMAP_DEC as the 3rd
argument. Because of the request for a decrypted mapping,
arch_memremap_can_ram_remap() returns false, and a new mapping
must be created, which is appropriate.
The following call stack results:
memremap()
arch_memremap_wb()
ioremap_cache()
__ioremap_caller()
memtype_reserve() <--- pcm is _PAGE_CACHE_MODE_WB
pat_x_mtrr_type() <-- only called after commit 72cbc8f04fe2
pat_x_mtrr_type() returns _PAGE_CACHE_MODE_UC_MINUS because
mtrr_type_lookup() fails. As a result, memremap() erroneously creates the
new mapping as uncached. This uncached mapping is causing a significant
performance problem in certain Hyper-V Confidential VM configurations.
Any thoughts on resolving this? Should memtype_reserve() be checking
both pat_enabled() *and* whether MTRRs are enabled before calling
pat_x_mtrr_type()? Or does that defeat the purpose of commit
72cbc8f04fe2 in the Xen environment?
I think pat_x_mtrr_type() should return _PAGE_CACHE_MODE_UC_MINUS only if
mtrr_type_lookup() is not failing and is returning a mode other than WB.
I agree.
Another idea would be to let the mtrr_type_lookup() stub in
arch/x86/include/asm/mtrr.h return MTRR_TYPE_WRBACK, enabling to simplify
pud_set_huge() and pmd_set_huge() by removing the check for MTRR_TYPE_INVALID.
But that has a risk of ending up misleading: When there are no MTRRs, there
simply is no default type (in the absence of inspecting other criteria).
I've sent a patch checking for MTRR_TYPE_INVALID in pat_x_mtrr_type(). This
seemed to be a less intrusive change.
The idea to modify the stub came up as a result of looking at mtrr_type_lookup()
use cases after writing my patch. All users now take an action if the returned
type is not WB and not INVALID. So it would be a modification tailored for
today's mtrr_type_lookup() users only.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 01/17] xen/arm: use NR_MEM_BANKS to override default NR_NODE_MEMBLKS
On 10.01.2023 09:49, Wei Chen wrote: > --- a/xen/arch/arm/include/asm/numa.h > +++ b/xen/arch/arm/include/asm/numa.h > @@ -3,9 +3,26 @@ > > #include > > +#include > + > typedef u8 nodeid_t; > > -#ifndef CONFIG_NUMA > +#ifdef CONFIG_NUMA > + > +/* > + * It is very likely that if you have more than 64 nodes, you may > + * need a lot more than 2 regions per node. So, for Arm, we would > + * just define NR_NODE_MEMBLKS as an alias to NR_MEM_BANKS. > + * And in the future NR_MEM_BANKS will be bumped for new platforms, > + * but for now leave NR_MEM_BANKS as it is on Arm. This avoid to > + * have different way to define the value based NUMA vs non-NUMA. > + * > + * Further discussions can be found here: > + * https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg02322.html > + */ > +#define NR_NODE_MEMBLKS NR_MEM_BANKS But isn't NR_MEM_BANKS a system-wide setting, which doesn't really make sense to use as a per-node one? IOW aren't you now allowing NR_MEM_BANKS regions on each node, which taken together will be much more than NR_MEM_BANKS that you can deal with on the whole system? Jan
Re: Problem with pat_enable() and commit 72cbc8f04fe2
On 10.01.2023 06:59, Juergen Gross wrote:
> On 10.01.23 06:47, Juergen Gross wrote:
>> On 09.01.23 19:28, Michael Kelley (LINUX) wrote:
>>> I've come across a case with a VM running on Hyper-V that doesn't get
>>> MTRRs, but the PAT is functional. (This is a Confidential VM using
>>> AMD's SEV-SNP encryption technology with the vTOM option.) In this
>>> case, the changes in commit 72cbc8f04fe2 ("x86/PAT: Have pat_enabled()
>>> properly reflect state when running on Xen") apply. pat_enabled() returns
>>> "true", but the MTRRs are not enabled.
>>>
>>> But with this commit, there's a problem. Consider memremap() on a RAM
>>> region, called with MEMREMAP_WB plus MEMREMAP_DEC as the 3rd
>>> argument. Because of the request for a decrypted mapping,
>>> arch_memremap_can_ram_remap() returns false, and a new mapping
>>> must be created, which is appropriate.
>>>
>>> The following call stack results:
>>>
>>> memremap()
>>> arch_memremap_wb()
>>> ioremap_cache()
>>> __ioremap_caller()
>>> memtype_reserve() <--- pcm is _PAGE_CACHE_MODE_WB
>>> pat_x_mtrr_type() <-- only called after commit 72cbc8f04fe2
>>>
>>> pat_x_mtrr_type() returns _PAGE_CACHE_MODE_UC_MINUS because
>>> mtrr_type_lookup() fails. As a result, memremap() erroneously creates the
>>> new mapping as uncached. This uncached mapping is causing a significant
>>> performance problem in certain Hyper-V Confidential VM configurations.
>>>
>>> Any thoughts on resolving this? Should memtype_reserve() be checking
>>> both pat_enabled() *and* whether MTRRs are enabled before calling
>>> pat_x_mtrr_type()? Or does that defeat the purpose of commit
>>> 72cbc8f04fe2 in the Xen environment?
>>
>> I think pat_x_mtrr_type() should return _PAGE_CACHE_MODE_UC_MINUS only if
>> mtrr_type_lookup() is not failing and is returning a mode other than WB.
I agree.
> Another idea would be to let the mtrr_type_lookup() stub in
> arch/x86/include/asm/mtrr.h return MTRR_TYPE_WRBACK, enabling to simplify
> pud_set_huge() and pmd_set_huge() by removing the check for MTRR_TYPE_INVALID.
But that has a risk of ending up misleading: When there are no MTRRs, there
simply is no default type (in the absence of inspecting other criteria).
Jan
[xen-unstable test] 175671: tolerable FAIL - PUSHED
flight 175671 xen-unstable real [real] flight 175692 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/175671/ http://logs.test-lab.xenproject.org/osstest/logs/175692/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 175692-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 175651 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175651 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175651 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175651 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175651 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175651 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175651 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175651 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175651 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175651 test-amd64-i386-xl-vhd 21 guest-start/debian.repeatfail like 175651 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175651 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175651 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfa
[PATCH v2 11/17] xen/arm: keep guest still be NUMA unware
The NUMA information provided in the host Device-Tree
are only for Xen. For dom0, we want to hide them as they
may be different (for now, dom0 is still not aware of NUMA)
The CPU and memory nodes are recreated from scratch for the
domain. So we already skip the "numa-node-id" property for
these two types of nodes.
However, some devices like PCIe may have "numa-node-id"
property too. We have to skip them as well.
Signed-off-by: Wei Chen
Reviewed-by: Stefano Stabellini
---
v1 -> v2:
1. Add Rb
---
xen/arch/arm/domain_build.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 829cea8de8..8258048d0e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1185,6 +1185,10 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
continue;
}
+/* Dom0 is currently NUMA unaware */
+if ( dt_property_name_is_equal(prop, "numa-node-id") )
+continue;
+
res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);
if ( res )
@@ -2540,6 +2544,8 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
DT_MATCH_TYPE("memory"),
/* The memory mapped timer is not supported by Xen. */
DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"),
+/* Numa info doesn't need to be exposed to Domain-0 */
+DT_MATCH_COMPATIBLE("numa-distance-map-v1"),
{ /* sentinel */ },
};
static const struct dt_device_match timer_matches[] __initconst =
--
2.25.1
[PATCH v2 09/17] xen/arm: introduce a helper to parse device tree NUMA distance map
A NUMA aware device tree will provide a "distance-map" node to
describe distance between any two nodes. This patch introduce a
new helper to parse this distance map.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Get rid of useless braces.
2. Use new NUMA status helper.
3. Use PRIu32 to replace u in print messages.
4. Fix opposite = __node_distance(to, from).
5. disable dtb numa info table when we find an invalid data
in dtb.
---
xen/arch/arm/numa_device_tree.c | 107
1 file changed, 107 insertions(+)
diff --git a/xen/arch/arm/numa_device_tree.c b/xen/arch/arm/numa_device_tree.c
index 793a410fd4..88056e7ef8 100644
--- a/xen/arch/arm/numa_device_tree.c
+++ b/xen/arch/arm/numa_device_tree.c
@@ -151,3 +151,110 @@ invalid_data:
numa_fw_bad();
return -EINVAL;
}
+
+/* Parse NUMA distance map v1 */
+static int __init fdt_parse_numa_distance_map_v1(const void *fdt, int node)
+{
+const struct fdt_property *prop;
+const __be32 *matrix;
+unsigned int i, entry_count;
+int len;
+
+printk(XENLOG_INFO "NUMA: parsing numa-distance-map\n");
+
+prop = fdt_get_property(fdt, node, "distance-matrix", &len);
+if ( !prop )
+{
+printk(XENLOG_WARNING
+ "NUMA: No distance-matrix property in distance-map\n");
+goto invalid_data;
+}
+
+if ( len % sizeof(__be32) != 0 )
+{
+printk(XENLOG_WARNING
+ "distance-matrix in node is not a multiple of u32\n");
+goto invalid_data;
+}
+
+entry_count = len / sizeof(__be32);
+if ( entry_count == 0 )
+{
+printk(XENLOG_WARNING "NUMA: Invalid distance-matrix\n");
+goto invalid_data;
+}
+
+matrix = (const __be32 *)prop->data;
+for ( i = 0; i + 2 < entry_count; i += 3 )
+{
+unsigned int from, to, distance, opposite;
+
+from = dt_next_cell(1, &matrix);
+to = dt_next_cell(1, &matrix);
+distance = dt_next_cell(1, &matrix);
+if ( (from == to && distance != NUMA_LOCAL_DISTANCE) ||
+(from != to && distance <= NUMA_LOCAL_DISTANCE) )
+{
+printk(XENLOG_WARNING
+ "NUMA: Invalid distance:
NODE#%"PRIu32"->NODE#%"PRIu32":%"PRIu32"\n",
+ from, to, distance);
+goto invalid_data;
+}
+
+printk(XENLOG_INFO "NUMA: distance:
NODE#%"PRIu32"->NODE#%"PRIu32":%"PRIu32"\n",
+ from, to, distance);
+
+/* Get opposite way distance */
+opposite = __node_distance(to, from);
+if ( opposite == 0 )
+{
+/* Bi-directions are not set, set both */
+numa_set_distance(from, to, distance);
+numa_set_distance(to, from, distance);
+}
+else
+{
+/*
+ * Opposite way distance has been set to a different value.
+ * It may be a firmware device tree bug?
+ */
+if ( opposite != distance )
+{
+/*
+ * In device tree NUMA distance-matrix binding:
+ *
https://www.kernel.org/doc/Documentation/devicetree/bindings/numa.txt
+ * There is a notes mentions:
+ * "Each entry represents distance from first node to
+ * second node. The distances are equal in either
+ * direction."
+ *
+ * That means device tree doesn't permit this case.
+ * But in ACPI spec, it cares to specifically permit this
+ * case:
+ * "Except for the relative distance from a System Locality
+ * to itself, each relative distance is stored twice in the
+ * matrix. This provides the capability to describe the
+ * scenario where the relative distances for the two
+ * directions between System Localities is different."
+ *
+ * That means a real machine allows such NUMA configuration.
+ * So, place a WARNING here to notice system administrators,
+ * is it the specail case that they hijack the device tree
+ * to support their rare machines?
+ */
+printk(XENLOG_WARNING
+ "Un-matched bi-direction!
NODE#%"PRIu32"->NODE#%"PRIu32":%"PRIu32",
NODE#%"PRIu32"->NODE#%"PRIu32":%"PRIu32"\n",
+ from, to, distance, to, from, opposite);
+}
+
+/* Opposite way distance has been set, just set this way */
+numa_set_distance(from, to, distance);
+}
+}
+
+return 0;
+
+invalid_data:
+numa_fw_bad();
+return -EINVAL;
+}
--
2.25.1
[PATCH v2 14/17] xen/arm: use CONFIG_NUMA to gate node_online_map in smpboot
node_online_map in smpboot still need for Arm when NUMA is turn
off by Kconfig.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. No change.
---
xen/arch/arm/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 5ee6ab11e9..3ae359bbeb 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -41,8 +41,10 @@ integer_param("maxcpus", max_cpus);
/* CPU logical map: map xen cpuid to an MPIDR */
register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
+#ifndef CONFIG_NUMA
/* Fake one node for now. See also asm/numa.h */
nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
+#endif
/* Xen stack for bringing up the first CPU. */
static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
--
2.25.1
[PATCH v2 07/17] xen/arm: introduce a helper to parse device tree processor node
Processor NUMA ID information is stored in device tree's processor
node as "numa-node-id". We need a new helper to parse this ID from
processor node. If we get this ID from processor node, this ID's
validity still need to be checked. Once we got a invalid NUMA ID
from any processor node, the device tree will be marked as NUMA
information invalid.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Move numa_disabled from fdt_numa_processor_affinity_init
to fdt_parse_numa_cpu_node.
2. Move invalid NUMA id check to fdt_parse_numa_cpu_node.
3. Return ENODATA for normal dtb without NUMA info.
4. Use NUMA status helpers instead of SRAT functions.
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/include/asm/numa.h | 2 ++
xen/arch/arm/numa.c | 2 +-
xen/arch/arm/numa_device_tree.c | 64 +
4 files changed, 68 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/numa_device_tree.c
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9073398d6e..bbc68e3735 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,6 +39,7 @@ obj-y += mem_access.o
obj-y += mm.o
obj-y += monitor.o
obj-$(CONFIG_NUMA) += numa.o
+obj-$(CONFIG_DEVICE_TREE_NUMA) += numa_device_tree.o
obj-y += p2m.o
obj-y += percpu.o
obj-y += platform.o
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index e0c909cbb7..923ffbfd42 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -28,6 +28,8 @@ enum dt_numa_status {
DT_NUMA_OFF,
};
+extern enum dt_numa_status device_tree_numa;
+
/*
* In ACPI spec, 0-9 are the reserved values for node distance,
* 10 indicates local node distance, 20 indicates remote node
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 4dd7cf10ba..3e02cec646 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -20,7 +20,7 @@
#include
#include
-static enum dt_numa_status __read_mostly device_tree_numa;
+enum dt_numa_status __read_mostly device_tree_numa;
static unsigned char __read_mostly
node_distance_map[MAX_NUMNODES][MAX_NUMNODES] = {
diff --git a/xen/arch/arm/numa_device_tree.c b/xen/arch/arm/numa_device_tree.c
new file mode 100644
index 00..c031053d24
--- /dev/null
+++ b/xen/arch/arm/numa_device_tree.c
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Arm Architecture support layer for device tree NUMA.
+ *
+ * Copyright (C) 2022 Arm Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v2 16/17] xen/arm: Provide Kconfig options for Arm to enable NUMA
Arm platforms support both ACPI and device tree. We don't want users to select device tree NUMA or ACPI NUMA manually. We hope users can just enable NUMA for Arm, and device tree NUMA and ACPI NUMA can be selected depends on device tree feature and ACPI feature status automatically. In this case, these two kinds of NUMA support code can be co-exist in one Xen binary. Xen can check feature flags to decide using device tree or ACPI as NUMA based firmware. So in this patch, we introduce a generic option: CONFIG_ARM_NUMA for users to enable NUMA for Arm. And one CONFIG_DEVICE_TREE_NUMA option for ARM_NUMA to select when HAS_DEVICE_TREE option is enabled. Once when ACPI NUMA for Arm is supported, ACPI_NUMA can be selected here too. Signed-off-by: Wei Chen --- v1 -> v2: 1. Remove the condition of selecting DEVICE_TREE_NUMA. --- xen/arch/arm/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 239d3aed3c..e751ad50d1 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -39,6 +39,17 @@ config ACPI config ARM_EFI bool +config ARM_NUMA + bool "Arm NUMA (Non-Uniform Memory Access) Support (UNSUPPORTED)" if UNSUPPORTED + depends on HAS_DEVICE_TREE + select DEVICE_TREE_NUMA + help + Enable Non-Uniform Memory Access (NUMA) for Arm architecutres + +config DEVICE_TREE_NUMA + bool + select NUMA + config GICV3 bool "GICv3 driver" depends on !NEW_VGIC -- 2.25.1
[PATCH v2 13/17] xen/arm: implement numa_node_to_arch_nid for device tree NUMA
Device tree based NUMA doesn't have the proximity domain like
ACPI. So we can return node id directly as arch nid.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Use numa_node_to_arch_nid instead of dummy node_to_pxm.
---
xen/arch/arm/include/asm/numa.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 34eec9378c..a0b8d7a11c 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -47,6 +47,15 @@ extern void numa_detect_cpu_node(unsigned int cpu);
extern int numa_device_tree_init(const void *fdt);
extern void numa_init(void);
+/*
+ * Device tree NUMA doesn't have architecural node id.
+ * So we can just return node id as arch nid.
+ */
+static inline unsigned int numa_node_to_arch_nid(nodeid_t n)
+{
+return n;
+}
+
#else
/* Fake one node for now. See also node_online_map. */
--
2.25.1
[PATCH v2 15/17] xen/arm: Set correct per-cpu cpu_core_mask
From: Henry Wang
In the common sysctl command XEN_SYSCTL_physinfo, the cores_per_socket
is calculated based on the cpu_core_mask of CPU0. Currently on Arm
this is a fixed value 1 (can be checked via xl info), which is not
correct. This is because during the Arm cpu online process,
set_cpu_sibling_map() only sets the per-cpu cpu_core_mask for itself.
cores_per_socket refers to the number of cores that belong to the same
socket (NUMA node). Therefore, this commit introduces a helper function
numa_set_cpu_core_mask(cpu), which sets the per-cpu cpu_core_mask to
the cpus in the same NUMA node as cpu. Calling this function at the
boot time can ensure the correct cpu_core_mask, leading to the correct
cores_per_socket to be returned by XEN_SYSCTL_physinfo.
Signed-off-by: Henry Wang
---
v1 -> v2:
1. New patch
---
xen/arch/arm/include/asm/numa.h | 7 +++
xen/arch/arm/numa.c | 11 +++
xen/arch/arm/setup.c| 5 +
3 files changed, 23 insertions(+)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index a0b8d7a11c..e66fb0a11f 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -46,6 +46,7 @@ extern void numa_set_distance(nodeid_t from, nodeid_t to,
extern void numa_detect_cpu_node(unsigned int cpu);
extern int numa_device_tree_init(const void *fdt);
extern void numa_init(void);
+extern void numa_set_cpu_core_mask(int cpu);
/*
* Device tree NUMA doesn't have architecural node id.
@@ -62,6 +63,12 @@ static inline unsigned int numa_node_to_arch_nid(nodeid_t n)
#define cpu_to_node(cpu) 0
#define node_to_cpumask(node) (cpu_online_map)
+static inline void numa_set_cpu_core_mask(int cpu)
+{
+cpumask_or(per_cpu(cpu_core_mask, cpu),
+ per_cpu(cpu_core_mask, cpu), &cpu_possible_map);
+}
+
/*
* TODO: make first_valid_mfn static when NUMA is supported on Arm, this
* is required because the dummy helpers are using it.
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index e9081d45ce..ef245e39a8 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -52,6 +52,17 @@ int __init arch_numa_setup(const char *opt)
return -EINVAL;
}
+void numa_set_cpu_core_mask(int cpu)
+{
+nodeid_t node = cpu_to_node[cpu];
+
+if ( node == NUMA_NO_NODE )
+node = 0;
+
+cpumask_or(per_cpu(cpu_core_mask, cpu),
+ per_cpu(cpu_core_mask, cpu), &node_to_cpumask(node));
+}
+
void __init numa_set_distance(nodeid_t from, nodeid_t to,
unsigned int distance)
{
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4cdc7e2edb..d45becedee 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1136,6 +1136,11 @@ void __init start_xen(unsigned long boot_phys_offset,
}
printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+
+/* Set per-cpu cpu_core_mask to cpus that belongs to the same NUMA node. */
+for_each_online_cpu ( i )
+numa_set_cpu_core_mask(i);
+
/* TODO: smp_cpus_done(); */
/* This should be done in a vpmu driver but we do not have one yet. */
--
2.25.1
[PATCH v2 17/17] docs: update numa command line to support Arm
Current numa command in documentation is x86 only. Remove x86 from numa command's arch limitation in this patch. Signed-off-by: Wei Chen --- v1 -> v2: 1. Update Arm NUMA status in SUPPORT.md to "Tech Preview". --- SUPPORT.md| 1 + docs/misc/xen-command-line.pandoc | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 295369998e..b73d04a028 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -401,6 +401,7 @@ on embedded platforms and the x86 PV shim. Enables NUMA aware scheduling in Xen Status, x86: Supported +Status, Arm: Tech Preview ## Scalability diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 923910f553..40da980b67 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1878,7 +1878,7 @@ i.e. a limit on the number of guests it is possible to start each having assigned a device sharing a common interrupt line. Accepts values between 1 and 255. -### numa (x86) +### numa > `= on | off | fake= | noacpi` > Default: `on` -- 2.25.1
[PATCH v2 12/17] xen/arm: enable device tree based NUMA in system init
In this patch, we can start to create NUMA system that is
based on device tree.
Signed-off-by: Wei Chen
---
v1->v2:
1. replace ~0 by INVALID_PADDR.
2. only print error messages for invalid dtb data.
3. remove unnecessary return.
4. remove the parameter of numa_init.
---
xen/arch/arm/include/asm/numa.h | 5 +++
xen/arch/arm/numa.c | 57 +
xen/arch/arm/setup.c| 7
3 files changed, 69 insertions(+)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 1213d30ce0..34eec9378c 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -45,6 +45,7 @@ extern void numa_set_distance(nodeid_t from, nodeid_t to,
unsigned int distance);
extern void numa_detect_cpu_node(unsigned int cpu);
extern int numa_device_tree_init(const void *fdt);
+extern void numa_init(void);
#else
@@ -86,6 +87,10 @@ static inline void numa_detect_cpu_node(unsigned int cpu)
{
}
+static inline void numa_init(void)
+{
+}
+
#endif
#define arch_want_default_dmazone() (false)
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 3e02cec646..e9081d45ce 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -18,7 +18,11 @@
*
*/
#include
+#include
+#include
#include
+#include
+#include
enum dt_numa_status __read_mostly device_tree_numa;
@@ -103,6 +107,59 @@ unsigned char __node_distance(nodeid_t from, nodeid_t to)
EXPORT_SYMBOL(__node_distance);
+void __init numa_init(void)
+{
+unsigned int idx;
+paddr_t ram_start = INVALID_PADDR;
+paddr_t ram_size = 0;
+paddr_t ram_end = 0;
+
+/* NUMA has been turned off through Xen parameters */
+if ( numa_off )
+goto mem_init;
+
+/* Initialize NUMA from device tree when system is not ACPI booted */
+if ( acpi_disabled )
+{
+int ret = numa_device_tree_init(device_tree_flattened);
+if ( ret )
+{
+numa_off = true;
+if ( ret == -EINVAL )
+printk(XENLOG_WARNING
+ "Init NUMA from device tree failed, ret=%d\n", ret);
+}
+}
+else
+{
+/* We don't support NUMA for ACPI boot currently */
+printk(XENLOG_WARNING
+ "ACPI NUMA has not been supported yet, NUMA off!\n");
+numa_off = true;
+}
+
+mem_init:
+/*
+ * Find the minimal and maximum address of RAM, NUMA will
+ * build a memory to node mapping table for the whole range.
+ */
+ram_start = bootinfo.mem.bank[0].start;
+ram_size = bootinfo.mem.bank[0].size;
+ram_end = ram_start + ram_size;
+for ( idx = 1 ; idx < bootinfo.mem.nr_banks; idx++ )
+{
+paddr_t bank_start = bootinfo.mem.bank[idx].start;
+paddr_t bank_size = bootinfo.mem.bank[idx].size;
+paddr_t bank_end = bank_start + bank_size;
+
+ram_size = ram_size + bank_size;
+ram_start = min(ram_start, bank_start);
+ram_end = max(ram_end, bank_end);
+}
+
+numa_initmem_init(PFN_UP(ram_start), PFN_DOWN(ram_end));
+}
+
int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)
{
if ( idx >= bootinfo.mem.nr_banks )
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 8c02cf6cd4..4cdc7e2edb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1031,6 +1031,13 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Parse the ACPI tables for possible boot-time configuration */
acpi_boot_table_init();
+/*
+ * Try to initialize NUMA system, if failed, the system will
+ * fallback to uniform system which means system has only 1
+ * NUMA node.
+ */
+numa_init();
+
end_boot_allocator();
/*
--
2.25.1
[PATCH v2 03/17] xen/arm: implement node distance helpers for Arm
We will parse NUMA nodes distances from device tree. So we need
a matrix to record the distances between any two nodes we parsed.
Accordingly, we provide this node_set_distance API for device tree
NUMA to set the distance for any two nodes in this patch. When
NUMA initialization failed, __node_distance will return
NUMA_REMOTE_DISTANCE, this will help us avoid doing rollback
for distance maxtrix when NUMA initialization failed.
As both x86 and Arm have implemented __node_distance, so we move
its definition from asm/numa.h to xen/numa.h. At same time, the
outdated u8 return value of x86 has been changed to unsigned char.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Use unsigned int/char instead of uint32_t/u8.
2. Re-org the commit message.
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/include/asm/numa.h | 14 +
xen/arch/arm/numa.c | 52 -
xen/arch/x86/include/asm/numa.h | 1 -
xen/arch/x86/srat.c | 2 +-
xen/include/xen/numa.h | 1 +
6 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 4d076b278b..9073398d6e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-y += mem_access.o
obj-y += mm.o
obj-y += monitor.o
+obj-$(CONFIG_NUMA) += numa.o
obj-y += p2m.o
obj-y += percpu.o
obj-y += platform.o
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 52ca414e47..dbdb632711 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -28,6 +28,20 @@ enum dt_numa_status {
DT_NUMA_OFF,
};
+/*
+ * In ACPI spec, 0-9 are the reserved values for node distance,
+ * 10 indicates local node distance, 20 indicates remote node
+ * distance. Set node distance map in device tree will follow
+ * the ACPI's definition.
+ */
+#define NUMA_DISTANCE_UDF_MIN 0
+#define NUMA_DISTANCE_UDF_MAX 9
+#define NUMA_LOCAL_DISTANCE 10
+#define NUMA_REMOTE_DISTANCE20
+
+extern void numa_set_distance(nodeid_t from, nodeid_t to,
+ unsigned int distance);
+
#else
/* Fake one node for now. See also node_online_map. */
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 1c02b6a25d..34851ceacf 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -2,7 +2,7 @@
/*
* Arm Architecture support layer for NUMA.
*
- * Copyright (C) 2021 Arm Ltd
+ * Copyright (C) 2022 Arm Ltd
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -22,6 +22,11 @@
static enum dt_numa_status __read_mostly device_tree_numa;
+static unsigned char __read_mostly
+node_distance_map[MAX_NUMNODES][MAX_NUMNODES] = {
+{ 0 }
+};
+
void __init numa_fw_bad(void)
{
printk(KERN_ERR "NUMA: device tree numa info table not used.\n");
@@ -42,3 +47,48 @@ int __init arch_numa_setup(const char *opt)
{
return -EINVAL;
}
+
+void __init numa_set_distance(nodeid_t from, nodeid_t to,
+ unsigned int distance)
+{
+if ( from >= MAX_NUMNODES || to >= MAX_NUMNODES )
+{
+printk(KERN_WARNING
+ "NUMA: invalid nodes: from=%"PRIu8" to=%"PRIu8" MAX=%"PRIu8"\n",
+ from, to, MAX_NUMNODES);
+return;
+}
+
+/* NUMA defines 0xff as an unreachable node and 0-9 are undefined */
+if ( distance >= NUMA_NO_DISTANCE ||
+(distance >= NUMA_DISTANCE_UDF_MIN &&
+ distance <= NUMA_DISTANCE_UDF_MAX) ||
+(from == to && distance != NUMA_LOCAL_DISTANCE) )
+{
+printk(KERN_WARNING
+ "NUMA: invalid distance: from=%"PRIu8" to=%"PRIu8"
distance=%"PRIu32"\n",
+ from, to, distance);
+return;
+}
+
+node_distance_map[from][to] = distance;
+}
+
+unsigned char __node_distance(nodeid_t from, nodeid_t to)
+{
+/* When NUMA is off, any distance will be treated as remote. */
+if ( numa_disabled() )
+return NUMA_REMOTE_DISTANCE;
+
+/*
+ * Check whether the nodes are in the matrix range.
+ * When any node is out of range, except from and to nodes are the
+ * same, we treat them as unreachable (return 0xFF)
+ */
+if ( from >= MAX_NUMNODES || to >= MAX_NUMNODES )
+return from == to ? NUMA_LOCAL_DISTANCE : NUMA_NO_DISTANCE;
+
+return node_distance_map[from][to];
+}
+
+EXPORT_SYMBOL(__node_distance);
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index 61efe60a95..18b71ddfef 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -21,7 +21,6 @@ extern void init_cpu_to_node(void);
#define arch_want_default_dmazone() (num_online_nodes() > 1)
void srat_parse_regions(paddr_t addr);
-extern u8 __node_distance(nodeid_t a, nodeid_t b);
unsigned int arch_get_dma_bitsize(void);
#endif
diff --git a/xen/arch/x86
[PATCH v2 10/17] xen/arm: unified entry to parse all NUMA data from device tree
In this function, we scan the whole device tree to parse CPU node id,
memory node id and distance-map. Though early_scan_node will invoke
a handler to process memory nodes. If we want to parse memory node id
in that handler, we have to embed NUMA parse code in that handler.
But we still need to scan whole device tree to find CPU NUMA id and
distance-map. In this case, we include memory NUMA id parse in this
function too. Another benefit is that we have a unique entry for device
tree NUMA data parse.
Signed-off-by: Wei Chen
---
v1->v2:
1. Fix typos in commit message.
2. Fix code style and align parameters.
3. Use strncmp to replace memcmp.
---
xen/arch/arm/include/asm/numa.h | 1 +
xen/arch/arm/numa_device_tree.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 923ffbfd42..1213d30ce0 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -44,6 +44,7 @@ extern enum dt_numa_status device_tree_numa;
extern void numa_set_distance(nodeid_t from, nodeid_t to,
unsigned int distance);
extern void numa_detect_cpu_node(unsigned int cpu);
+extern int numa_device_tree_init(const void *fdt);
#else
diff --git a/xen/arch/arm/numa_device_tree.c b/xen/arch/arm/numa_device_tree.c
index 88056e7ef8..4009b9b6de 100644
--- a/xen/arch/arm/numa_device_tree.c
+++ b/xen/arch/arm/numa_device_tree.c
@@ -258,3 +258,33 @@ invalid_data:
numa_fw_bad();
return -EINVAL;
}
+
+static int __init fdt_scan_numa_nodes(const void *fdt, int node,
+ const char *uname, int depth,
+ unsigned int address_cells,
+ unsigned int size_cells, void *data)
+{
+int len, ret = 0;
+const void *prop;
+
+prop = fdt_getprop(fdt, node, "device_type", &len);
+if ( prop )
+{
+if ( strncmp(prop, "cpu", len) == 0 )
+ret = fdt_parse_numa_cpu_node(fdt, node);
+else if ( strncmp(prop, "memory", len) == 0 )
+ret = fdt_parse_numa_memory_node(fdt, node, uname,
+address_cells, size_cells);
+}
+else if ( fdt_node_check_compatible(fdt, node,
+"numa-distance-map-v1") == 0 )
+ret = fdt_parse_numa_distance_map_v1(fdt, node);
+
+return ret;
+}
+
+/* Initialize NUMA from device tree */
+int __init numa_device_tree_init(const void *fdt)
+{
+return device_tree_for_each_node(fdt, 0, fdt_scan_numa_nodes, NULL);
+}
--
2.25.1
[PATCH v2 06/17] xen/arm: Add boot and secondary CPU to NUMA system
In this patch, we make NUMA node online and add cpu to
its NUMA node. This will make NUMA-aware components
have NUMA affinity data to support their work.
To keep the mostly the same behavior of x86, we use
numa_detect_cpu_node to online node. The difference is that,
we have prepared cpu_to_node in dt_smp_init_cpus, so we don't
need to setup cpu_to_node in numa_detect_cpu_node.
Signed-off-by: Wei Chen
---
v2 -> v3:
1. Use unsigned int instead of int for cpu id.
2. Use static inline for stub to do type check.
v1 -> v2:
1. Use numa_detect_cpu_node to online node.
2. Use macros instead of static inline functions to stub
numa_detect_cpu_node.
---
xen/arch/arm/include/asm/numa.h | 9 +
xen/arch/arm/numa.c | 10 ++
xen/arch/arm/setup.c| 5 +
3 files changed, 24 insertions(+)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 3bc28416b4..e0c909cbb7 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -41,6 +41,7 @@ enum dt_numa_status {
extern void numa_set_distance(nodeid_t from, nodeid_t to,
unsigned int distance);
+extern void numa_detect_cpu_node(unsigned int cpu);
#else
@@ -74,6 +75,14 @@ static inline void numa_set_node(unsigned int cpu, nodeid_t
node)
{
}
+static inline void numa_add_cpu(unsigned int cpu)
+{
+}
+
+static inline void numa_detect_cpu_node(unsigned int cpu)
+{
+}
+
#endif
#define arch_want_default_dmazone() (false)
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index dcfcd85fcf..4dd7cf10ba 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -74,6 +74,16 @@ void __init numa_set_distance(nodeid_t from, nodeid_t to,
node_distance_map[from][to] = distance;
}
+void numa_detect_cpu_node(unsigned int cpu)
+{
+nodeid_t node = cpu_to_node[cpu];
+
+if ( node == NUMA_NO_NODE )
+node = 0;
+
+node_set_online(node);
+}
+
unsigned char __node_distance(nodeid_t from, nodeid_t to)
{
/* When NUMA is off, any distance will be treated as remote. */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1f26f67b90..8c02cf6cd4 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1115,6 +1115,11 @@ void __init start_xen(unsigned long boot_phys_offset,
for_each_present_cpu ( i )
{
+/* Detect and online node based on cpu_to_node[]. */
+numa_detect_cpu_node(i);
+/* Set up node_to_cpumask based on cpu_to_node[]. */
+numa_add_cpu(i);
+
if ( (num_online_cpus() < nr_cpu_ids) && !cpu_online(i) )
{
int ret = cpu_up(i);
--
2.25.1
[PATCH v2 08/17] xen/arm: introduce a helper to parse device tree memory node
Memory blocks' NUMA ID information is stored in device tree's
memory nodes as "numa-node-id". We need a new helper to parse
and verify this ID from memory nodes.
Signed-off-by: Wei Chen
---
v1->v2:
1. Move numa_disabled check to fdt_parse_numa_memory_node.
2. Use numa_bad to replace bad_srat.
3. Replace tabs by spaces.
4. Align parameters.
5. return ENODATA for a normal dtb without numa info.
6. Un-addressed comment:
"Why not parse numa-node-id and call fdt_numa_memory_affinity_init
from xen/arch/arm/bootfdt.c:device_tree_get_meminfo. Is it because
device_tree_get_meminfo is called too early?"
I checked the device_tree_get_meminfo code and I think the answer
is similar as I reply in RFC. I prefer a unify numa initialization
entry. Don't want to make numa parse code in different places.
7. Use node id as dummy PXM for numa_update_node_memblks.
---
xen/arch/arm/numa_device_tree.c | 89 +
1 file changed, 89 insertions(+)
diff --git a/xen/arch/arm/numa_device_tree.c b/xen/arch/arm/numa_device_tree.c
index c031053d24..793a410fd4 100644
--- a/xen/arch/arm/numa_device_tree.c
+++ b/xen/arch/arm/numa_device_tree.c
@@ -34,6 +34,26 @@ static int __init fdt_numa_processor_affinity_init(nodeid_t
node)
return 0;
}
+/* Callback for parsing of the memory regions affinity */
+static int __init fdt_numa_memory_affinity_init(nodeid_t node,
+paddr_t start, paddr_t size)
+{
+if ( !numa_memblks_available() )
+{
+dprintk(XENLOG_WARNING,
+"Too many numa entry, try bigger NR_NODE_MEMBLKS\n");
+return -EINVAL;
+}
+
+numa_fw_nid_name = "numa-node-id";
+if ( !numa_update_node_memblks(node, node, start, size, false) )
+return -EINVAL;
+
+device_tree_numa = DT_NUMA_ON;
+
+return 0;
+}
+
/* Parse CPU NUMA node info */
static int __init fdt_parse_numa_cpu_node(const void *fdt, int node)
{
@@ -62,3 +82,72 @@ static int __init fdt_parse_numa_cpu_node(const void *fdt,
int node)
return fdt_numa_processor_affinity_init(nid);
}
+
+/* Parse memory node NUMA info */
+static int __init fdt_parse_numa_memory_node(const void *fdt, int node,
+ const char *name,
+ unsigned int addr_cells,
+ unsigned int size_cells)
+{
+unsigned int nid;
+int ret = 0, len;
+paddr_t addr, size;
+const struct fdt_property *prop;
+unsigned int idx, ranges;
+const __be32 *addresses;
+
+if ( numa_disabled() )
+return -EINVAL;
+
+/*
+ * device_tree_get_u32 will return NUMA_NO_NODE when this memory
+ * DT node doesn't have numa-node-id. This can help us to
+ * distinguish a bad DTB and a normal DTB without NUMA info.
+ */
+nid = device_tree_get_u32(fdt, node, "numa-node-id", NUMA_NO_NODE);
+if ( node == NUMA_NO_NODE )
+{
+numa_fw_bad();
+return -ENODATA;
+}
+else if ( nid >= MAX_NUMNODES )
+{
+printk(XENLOG_WARNING "Node id %u exceeds maximum value\n", nid);
+goto invalid_data;
+}
+
+prop = fdt_get_property(fdt, node, "reg", &len);
+if ( !prop )
+{
+printk(XENLOG_WARNING
+ "fdt: node `%s': missing `reg' property\n", name);
+goto invalid_data;
+}
+
+addresses = (const __be32 *)prop->data;
+ranges = len / (sizeof(__be32)* (addr_cells + size_cells));
+for ( idx = 0; idx < ranges; idx++ )
+{
+device_tree_get_reg(&addresses, addr_cells, size_cells, &addr, &size);
+/* Skip zero size ranges */
+if ( !size )
+continue;
+
+ret = fdt_numa_memory_affinity_init(nid, addr, size);
+if ( ret )
+goto invalid_data;
+}
+
+if ( idx == 0 )
+{
+printk(XENLOG_ERR
+ "bad property in memory node, idx=%d ret=%d\n", idx, ret);
+goto invalid_data;
+}
+
+return 0;
+
+invalid_data:
+numa_fw_bad();
+return -EINVAL;
+}
--
2.25.1
[PATCH v2 05/17] xen/arm: build NUMA cpu_to_node map in dt_smp_init_cpus
NUMA implementation has a cpu_to_node array to store CPU to NODE
map. Xen is using CPU logical ID in runtime components, so we
use CPU logical ID as CPU index in cpu_to_node.
In device tree case, cpu_logical_map is created in dt_smp_init_cpus.
So, when NUMA is enabled, dt_smp_init_cpus will fetch CPU NUMA id
at the same time for cpu_to_node.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Use static inline to replace macros to perform
function paramerters type check.
2. Add numa_disabled to gate the numa-node-id check for
CONFIG_NUMA on but numa disabled user case.
3. Use macro instead of static inline function to stub
numa_set_node.
---
xen/arch/arm/include/asm/numa.h | 4
xen/arch/arm/smpboot.c | 36 +
2 files changed, 40 insertions(+)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index dbdb632711..3bc28416b4 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -70,6 +70,10 @@ static inline bool arch_numa_broken(void)
return true;
}
+static inline void numa_set_node(unsigned int cpu, nodeid_t node)
+{
+}
+
#endif
#define arch_want_default_dmazone() (false)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 412ae22869..5ee6ab11e9 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -118,7 +118,12 @@ static void __init dt_smp_init_cpus(void)
{
[0 ... NR_CPUS - 1] = MPIDR_INVALID
};
+static nodeid_t node_map[NR_CPUS] __initdata =
+{
+[0 ... NR_CPUS - 1] = NUMA_NO_NODE
+};
bool bootcpu_valid = false;
+unsigned int nid = 0;
int rc;
mpidr = system_cpuinfo.mpidr.bits & MPIDR_HWID_MASK;
@@ -169,6 +174,28 @@ static void __init dt_smp_init_cpus(void)
continue;
}
+if ( IS_ENABLED(CONFIG_NUMA) )
+{
+/*
+ * When CONFIG_NUMA is set, try to fetch numa infomation
+ * from CPU dts node, otherwise the nid is always 0.
+ */
+if ( !dt_property_read_u32(cpu, "numa-node-id", &nid) )
+{
+printk(XENLOG_WARNING
+ "cpu[%d] dts path: %s: doesn't have numa
information!\n",
+ cpuidx, dt_node_full_name(cpu));
+/*
+ * During the early stage of NUMA initialization, when Xen
+ * found any CPU dts node doesn't have numa-node-id info, the
+ * NUMA will be treated as off, all CPU will be set to a FAKE
+ * node 0. So if we get numa-node-id failed here, we should
+ * set nid to 0.
+ */
+nid = 0;
+}
+}
+
/*
* 8 MSBs must be set to 0 in the DT since the reg property
* defines the MPIDR[23:0]
@@ -228,9 +255,13 @@ static void __init dt_smp_init_cpus(void)
{
printk("cpu%d init failed (hwid %"PRIregister"): %d\n", i, hwid,
rc);
tmp_map[i] = MPIDR_INVALID;
+node_map[i] = NUMA_NO_NODE;
}
else
+{
tmp_map[i] = hwid;
+node_map[i] = nid;
+}
}
if ( !bootcpu_valid )
@@ -246,6 +277,11 @@ static void __init dt_smp_init_cpus(void)
continue;
cpumask_set_cpu(i, &cpu_possible_map);
cpu_logical_map(i) = tmp_map[i];
+
+nid = node_map[i];
+if ( nid >= MAX_NUMNODES )
+nid = 0;
+numa_set_node(i, nid);
}
}
--
2.25.1
[PATCH v2 01/17] xen/arm: use NR_MEM_BANKS to override default NR_NODE_MEMBLKS
As a memory range described in device tree cannot be split across multiple nodes. And it is very likely than if you have more than 64 nodes, you may need a lot more than 2 regions per node. So the default NR_NODE_MEMBLKS value (MAX_NUMNODES * 2) makes no sense on Arm. So, for Arm, we would just define NR_NODE_MEMBLKS as an alias to NR_MEM_BANKS. And in the future NR_MEM_BANKS will be user-configurable via kconfig, but for now leave NR_MEM_BANKS as 128 on Arm. This avoid to have different way to define the value based NUMA vs non-NUMA. Further discussions can be found here[1]. [1] https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg02322.html Signed-off-by: Wei Chen --- v1 -> v2: 1. Add code comments to explain using NR_MEM_BANKS for Arm 2. Refine commit messages. --- xen/arch/arm/include/asm/numa.h | 19 ++- xen/include/xen/numa.h | 9 + 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h index e2bee2bd82..7d6ae36a19 100644 --- a/xen/arch/arm/include/asm/numa.h +++ b/xen/arch/arm/include/asm/numa.h @@ -3,9 +3,26 @@ #include +#include + typedef u8 nodeid_t; -#ifndef CONFIG_NUMA +#ifdef CONFIG_NUMA + +/* + * It is very likely that if you have more than 64 nodes, you may + * need a lot more than 2 regions per node. So, for Arm, we would + * just define NR_NODE_MEMBLKS as an alias to NR_MEM_BANKS. + * And in the future NR_MEM_BANKS will be bumped for new platforms, + * but for now leave NR_MEM_BANKS as it is on Arm. This avoid to + * have different way to define the value based NUMA vs non-NUMA. + * + * Further discussions can be found here: + * https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg02322.html + */ +#define NR_NODE_MEMBLKS NR_MEM_BANKS + +#else /* Fake one node for now. See also node_online_map. */ #define cpu_to_node(cpu) 0 diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h index 29b8c2df89..b86d0851fc 100644 --- a/xen/include/xen/numa.h +++ b/xen/include/xen/numa.h @@ -13,7 +13,16 @@ #define MAX_NUMNODES 1 #endif +/* + * Some architectures may have different considerations for + * number of node memory blocks. They can define their + * NR_NODE_MEMBLKS in asm/numa.h to reflect their architectural + * implementation. If the arch does not have specific implementation, + * the following default NR_NODE_MEMBLKS will be used. + */ +#ifndef NR_NODE_MEMBLKS #define NR_NODE_MEMBLKS (MAX_NUMNODES * 2) +#endif #define vcpu_to_node(v) (cpu_to_node((v)->processor)) -- 2.25.1
[PATCH v2 02/17] xen/arm: implement helpers to get and update NUMA status
NUMA has one global and one implementation specific switches. For
ACPI NUMA implementation, Xen has acpi_numa, so we introduce
device_tree_numa for device tree NUMA implementation. And use
enumerations to indicate init, off and on status.
arch_numa_disabled will get device_tree_numa status, but for
arch_numa_setup we have not provided boot arguments to setup
device_tree_numa. So we just return -EINVAL in this patch.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Use arch_numa_disabled to replace numa_enable_with_firmware.
2. Introduce enumerations for device tree numa status.
3. Use common numa_disabled, drop Arm version numa_disabled.
4. Introduce arch_numa_setup for Arm.
5. Rename bad_srat to numa_bad.
6. Add numa_enable_with_firmware helper.
7. Add numa_disabled helper.
8. Refine commit message.
---
xen/arch/arm/include/asm/numa.h | 17 +
xen/arch/arm/numa.c | 44 +
xen/arch/x86/include/asm/numa.h | 1 -
xen/include/xen/numa.h | 1 +
4 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/numa.c
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 7d6ae36a19..52ca414e47 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -22,6 +22,12 @@ typedef u8 nodeid_t;
*/
#define NR_NODE_MEMBLKS NR_MEM_BANKS
+enum dt_numa_status {
+DT_NUMA_INIT,
+DT_NUMA_ON,
+DT_NUMA_OFF,
+};
+
#else
/* Fake one node for now. See also node_online_map. */
@@ -39,6 +45,17 @@ extern mfn_t first_valid_mfn;
#define node_start_pfn(nid) (mfn_x(first_valid_mfn))
#define __node_distance(a, b) (20)
+#define numa_disabled() (true)
+static inline bool arch_numa_unavailable(void)
+{
+return true;
+}
+
+static inline bool arch_numa_broken(void)
+{
+return true;
+}
+
#endif
#define arch_want_default_dmazone() (false)
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
new file mode 100644
index 00..1c02b6a25d
--- /dev/null
+++ b/xen/arch/arm/numa.c
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Arm Architecture support layer for NUMA.
+ *
+ * Copyright (C) 2021 Arm Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v2 04/17] xen/arm: use arch_get_ram_range to memory ranges from bootinfo
Implement the same helper "arch_get_ram_range" as x86 for NUMA
code to get memory bank from Arm bootinfo.
Signed-off-by: Wei Chen
---
v2 -> v3:
1. Use arch_get_ram_range instead of arch_get_memory_map.
v1 -> v2:
1. Use arch_get_memory_map to replace arch_get_memory_bank_range
and arch_get_memory_bank_number.
---
xen/arch/arm/numa.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 34851ceacf..dcfcd85fcf 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -92,3 +92,14 @@ unsigned char __node_distance(nodeid_t from, nodeid_t to)
}
EXPORT_SYMBOL(__node_distance);
+
+int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)
+{
+if ( idx >= bootinfo.mem.nr_banks )
+return -ENOENT;
+
+*start = bootinfo.mem.bank[idx].start;
+*end = *start + bootinfo.mem.bank[idx].size;
+
+return 0;
+}
--
2.25.1
[PATCH v2 00/17] Device tree based NUMA support for Arm - Part#3
(The Arm device tree based NUMA support patch set contains 35 patches. In order to make stuff easier for reviewers, I split them into 3 parts: 1. Preparation. I have re-sorted the patch series. And moved independent patches to the head of the series - merged in [1] 2. Move generically usable code from x86 to common - merged in [2] 3. Add new code to support Arm - this series. This series only contains the third part patches. As the whole NUMA series has been reviewed for 1 round in [3], so this series would be v2) Xen memory allocation and scheduler modules are NUMA aware. But actually, on x86 has implemented the architecture APIs to support NUMA. Arm was providing a set of fake architecture APIs to make it compatible with NUMA awared memory allocation and scheduler. Arm system was working well as a single node NUMA system with these fake APIs, because we didn't have multiple nodes NUMA system on Arm. But in recent years, more and more Arm devices support multiple nodes NUMA system. So now we have a new problem. When Xen is running on these Arm devices, Xen still treat them as single node SMP systems. The NUMA affinity capability of Xen memory allocation and scheduler becomes meaningless. Because they rely on input data that does not reflect real NUMA layout. Xen still think the access time for all of the memory is the same for all CPUs. However, Xen may allocate memory to a VM from different NUMA nodes with different access speeds. This difference can be amplified in workloads inside VM, causing performance instability and timeouts. So in this patch series, we implement a set of NUMA API to use device tree to describe the NUMA layout. We reuse most of the code of x86 NUMA to create and maintain the mapping between memory and CPU, create the matrix between any two NUMA nodes. Except ACPI and some x86 specified code, we have moved other code to common. In next stage, when we implement ACPI based NUMA for Arm64, we may move the ACPI NUMA code to common too, but in current stage, we keep it as x86 only. This patch serires has been tested and booted well on one Arm64 NUMA machine and one HPE x86 NUMA machine. [1] https://lists.xenproject.org/archives/html/xen-devel/2022-06/msg00499.html [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01043.html [3] https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg01903.html Henry Wang (1): xen/arm: Set correct per-cpu cpu_core_mask Wei Chen (16): xen/arm: use NR_MEM_BANKS to override default NR_NODE_MEMBLKS xen/arm: implement helpers to get and update NUMA status xen/arm: implement node distance helpers for Arm xen/arm: use arch_get_ram_range to memory ranges from bootinfo xen/arm: build NUMA cpu_to_node map in dt_smp_init_cpus xen/arm: Add boot and secondary CPU to NUMA system xen/arm: introduce a helper to parse device tree processor node xen/arm: introduce a helper to parse device tree memory node xen/arm: introduce a helper to parse device tree NUMA distance map xen/arm: unified entry to parse all NUMA data from device tree xen/arm: keep guest still be NUMA unware xen/arm: enable device tree based NUMA in system init xen/arm: implement numa_node_to_arch_nid for device tree NUMA xen/arm: use CONFIG_NUMA to gate node_online_map in smpboot xen/arm: Provide Kconfig options for Arm to enable NUMA docs: update numa command line to support Arm SUPPORT.md| 1 + docs/misc/xen-command-line.pandoc | 2 +- xen/arch/arm/Kconfig | 11 ++ xen/arch/arm/Makefile | 2 + xen/arch/arm/domain_build.c | 6 + xen/arch/arm/include/asm/numa.h | 87 - xen/arch/arm/numa.c | 183 +++ xen/arch/arm/numa_device_tree.c | 290 ++ xen/arch/arm/setup.c | 17 ++ xen/arch/arm/smpboot.c| 38 xen/arch/x86/include/asm/numa.h | 2 - xen/arch/x86/srat.c | 2 +- xen/include/xen/numa.h| 11 ++ 13 files changed, 647 insertions(+), 5 deletions(-) create mode 100644 xen/arch/arm/numa.c create mode 100644 xen/arch/arm/numa_device_tree.c -- 2.25.1
[ovmf test] 175686: all pass - PUSHED
flight 175686 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175686/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 82dd766f25225b0812bbac628c60d2b48f2346e4 baseline version: ovmf 2cc6d4c8ed54e36fd9638dafdb293dd9a4c54cf9 Last test of basis 175683 2023-01-10 04:10:46 Z0 days Testing same since 175686 2023-01-10 06:40:46 Z0 days1 attempts People who touched revisions under test: Chao Li jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 2cc6d4c8ed..82dd766f25 82dd766f25225b0812bbac628c60d2b48f2346e4 -> xen-tested-master
Re: [PATCH v2 3/8] xen/riscv: introduce stack stuff
On Mon, 2023-01-09 at 16:11 +, Julien Grall wrote: > Hi, > > On 09/01/2023 15:46, Oleksii Kurochko wrote: > > The patch introduces and sets up a stack in order to go to C > > environment > > > > Signed-off-by: Oleksii Kurochko > > It looks like the comments from Andrew were missed. > I will double check which one. Thanks. > > --- > > Changes in V2: > > - introduce STACK_SIZE define. > > - use consistent padding between instruction mnemonic and > > operand(s) > > --- > > xen/arch/riscv/Makefile | 1 + > > xen/arch/riscv/include/asm/config.h | 2 ++ > > xen/arch/riscv/riscv64/head.S | 8 +++- > > xen/arch/riscv/setup.c | 6 ++ > > 4 files changed, 16 insertions(+), 1 deletion(-) > > create mode 100644 xen/arch/riscv/setup.c > > > > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile > > index 248f2cbb3e..5a67a3f493 100644 > > --- a/xen/arch/riscv/Makefile > > +++ b/xen/arch/riscv/Makefile > > @@ -1,4 +1,5 @@ > > obj-$(CONFIG_RISCV_64) += riscv64/ > > +obj-y += setup.o > > > > $(TARGET): $(TARGET)-syms > > $(OBJCOPY) -O binary -S $< $@ > > diff --git a/xen/arch/riscv/include/asm/config.h > > b/xen/arch/riscv/include/asm/config.h > > index 0370f865f3..bdd2237f01 100644 > > --- a/xen/arch/riscv/include/asm/config.h > > +++ b/xen/arch/riscv/include/asm/config.h > > @@ -43,6 +43,8 @@ > > > > #define SMP_CACHE_BYTES (1 << 6) > > > > +#define STACK_SIZE (PAGE_SIZE) > > + > > #endif /* __RISCV_CONFIG_H__ */ > > /* > > * Local variables: > > diff --git a/xen/arch/riscv/riscv64/head.S > > b/xen/arch/riscv/riscv64/head.S > > index 990edb70a0..c1f33a1934 100644 > > --- a/xen/arch/riscv/riscv64/head.S > > +++ b/xen/arch/riscv/riscv64/head.S > > @@ -1,4 +1,10 @@ > > .section .text.header, "ax", %progbits > > > > ENTRY(start) > > - j start > > + la sp, cpu0_boot_stack > > + li t0, STACK_SIZE > > + add sp, sp, t0 > > + > > +_start_hang: > > + wfi > > + j _start_hang > > diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c > > new file mode 100644 > > index 00..41ef4912bd > > --- /dev/null > > +++ b/xen/arch/riscv/setup.c > > @@ -0,0 +1,6 @@ > > +#include > > +#include > > Why do you need to include ? > It is needed to use __aligned define which looks better then __attribute__((__aligned__(SOMETHING))) > In any case, please order the include alphabetically. I haven't look > at Thanks. I didn't now that headers should be in alphabetic order too. > the rest of the series. But please go through the series and check > that > generic comments (like this one) are addressed everywhere. > > Cheers, > ~Oleksii
Re: [PATCH v2 4/8] xen/riscv: introduce sbi call to putchar to console
Hi, On Mon, 2023-01-09 at 16:03 +, Julien Grall wrote: > Hi, > > On 09/01/2023 15:46, Oleksii Kurochko wrote: > > The patch introduce sbi_putchar() SBI call which is necessary > > to implement initial early_printk > > > > Signed-off-by: Oleksii Kurochko > > --- > > Changes in V2: > > - add an explanatory comment about sbi_console_putchar() > > function. > > - order the files alphabetically in Makefile > > --- > > xen/arch/riscv/Makefile | 1 + > > xen/arch/riscv/include/asm/sbi.h | 34 > > xen/arch/riscv/sbi.c | 44 > > > > 3 files changed, 79 insertions(+) > > create mode 100644 xen/arch/riscv/include/asm/sbi.h > > create mode 100644 xen/arch/riscv/sbi.c > > > > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile > > index 5a67a3f493..fd916e1004 100644 > > --- a/xen/arch/riscv/Makefile > > +++ b/xen/arch/riscv/Makefile > > @@ -1,4 +1,5 @@ > > obj-$(CONFIG_RISCV_64) += riscv64/ > > +obj-y += sbi.o > > obj-y += setup.o > > > > $(TARGET): $(TARGET)-syms > > diff --git a/xen/arch/riscv/include/asm/sbi.h > > b/xen/arch/riscv/include/asm/sbi.h > > new file mode 100644 > > index 00..34b53f8eaf > > --- /dev/null > > +++ b/xen/arch/riscv/include/asm/sbi.h > > @@ -0,0 +1,34 @@ > > +/* SPDX-License-Identifier: (GPL-2.0-or-later) */ > > +/* > > + * Copyright (c) 2021 Vates SAS. > > + * > > + * Taken from xvisor, modified by Bobby Eshleman > > (bobby.eshle...@gmail.com). > Hmmm... I missed this one in v1. Is this mostly code from Bobby? If > so, > please update the commit message accordingly. > > FAOD, this comment applies for any future code you take from anyone. > I > will try to remember to mention it but please take pro-active action > to > check/mention where the code is coming from. > Sure, I will try to be more attentive next time. Probably it is out of scope a little bit but could you please share with me a link or clarify in which cases I have to add Copytrigt(c) or should I add a new comment with "Modfied by Oleksii ... ", or it is not necessary at all? Maybe have I to put some other information related to copyrigts? Thanks in advance. > Cheers, > ~Oleksii
Re: [PATCH v2 4/8] xen/riscv: introduce sbi call to putchar to console
On Mon, 2023-01-09 at 17:00 +0100, Jan Beulich wrote:
> On 09.01.2023 16:46, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/sbi.h
> > @@ -0,0 +1,34 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-or-later) */
> > +/*
> > + * Copyright (c) 2021 Vates SAS.
> > + *
> > + * Taken from xvisor, modified by Bobby Eshleman
> > (bobby.eshle...@gmail.com).
> > + *
> > + * Taken/modified from Xvisor project with the following
> > copyright:
> > + *
> > + * Copyright (c) 2019 Western Digital Corporation or its
> > affiliates.
> > + */
> > +
> > +#ifndef __CPU_SBI_H__
> > +#define __CPU_SBI_H__
>
> Didn't you mean to change this?
Thanks.
My fault. Missed that. I will double check that and take into account
in new patch series.
>
> > +#define SBI_EXT_0_1_CONSOLE_PUTCHAR0x1
> > +
> > +struct sbiret {
> > + long error;
> > + long value;
> > +};
> > +
> > +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> > unsigned long arg0,
> > + unsigned long arg1, unsigned long arg2,
> > + unsigned long arg3, unsigned long arg4,
> > + unsigned long arg5);
>
> Please get indentation right here as well as for the definition.
Thanks for clarification.
> Possible
> forms are
>
> struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> unsigned long arg0, unsigned long arg1,
> unsigned long arg2, unsigned long arg3,
> unsigned long arg4, unsigned long arg5);
>
> or
>
> struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> unsigned long arg0, unsigned long arg1,
> unsigned long arg2, unsigned long arg3,
> unsigned long arg4, unsigned long arg5);
>
> Jan
Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru
On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> as noted in docs/igd-assign.txt in the Qemu source code.
>
> Currently, when the xl toolstack is used to configure a Xen HVM guest with
> Intel IGD passthrough to the guest with the Qemu upstream device model,
> a Qemu emulated PCI device will occupy slot 2 and the Intel IGD will occupy
> a different slot. This problem often prevents the guest from booting.
>
> The only available workaround is not good: Configure Xen HVM guests to use
> the old and no longer maintained Qemu traditional device model available
> from xenbits.xen.org which does reserve slot 2 for the Intel IGD.
>
> To implement this feature in the Qemu upstream device model for Xen HVM
> guests, introduce the following new functions, types, and macros:
>
> * XEN_PT_DEVICE_CLASS declaration, based on the existing TYPE_XEN_PT_DEVICE
> * XEN_PT_DEVICE_GET_CLASS macro helper function for XEN_PT_DEVICE_CLASS
> * typedef XenPTQdevRealize function pointer
> * XEN_PCI_IGD_SLOT_MASK, the value of slot_reserved_mask to reserve slot 2
> * xen_igd_reserve_slot and xen_igd_clear_slot functions
>
> The new xen_igd_reserve_slot function uses the existing slot_reserved_mask
> member of PCIBus to reserve PCI slot 2 for Xen HVM guests configured using
> the xl toolstack with the gfx_passthru option enabled, which sets the
> igd-passthru=on option to Qemu for the Xen HVM machine type.
>
> The new xen_igd_reserve_slot function also needs to be implemented in
> hw/xen/xen_pt_stub.c to prevent FTBFS during the link stage for the case
> when Qemu is configured with --enable-xen and --disable-xen-pci-passthrough,
> in which case it does nothing.
>
> The new xen_igd_clear_slot function overrides qdev->realize of the parent
> PCI device class to enable the Intel IGD to occupy slot 2 on the PCI bus
> since slot 2 was reserved by xen_igd_reserve_slot when the PCI bus was
> created in hw/i386/pc_piix.c for the case when igd-passthru=on.
>
> Move the call to xen_host_pci_device_get, and the associated error
> handling, from xen_pt_realize to the new xen_igd_clear_slot function to
> initialize the device class and vendor values which enables the checks for
> the Intel IGD to succeed. The verification that the host device is an
> Intel IGD to be passed through is done by checking the domain, bus, slot,
> and function values as well as by checking that gfx_passthru is enabled,
> the device class is VGA, and the device vendor in Intel.
>
> Signed-off-by: Chuck Zmudzinski
> ---
> Notes that might be helpful to reviewers of patched code in hw/xen:
>
> The new functions and types are based on recommendations from Qemu docs:
> https://qemu.readthedocs.io/en/latest/devel/qom.html
>
> Notes that might be helpful to reviewers of patched code in hw/i386:
>
> The small patch to hw/i386/pc_piix.c is protected by CONFIG_XEN so it does
> not affect builds that do not have CONFIG_XEN defined.
>
> xen_igd_gfx_pt_enabled() in the patched hw/i386/pc_piix.c file is an
> existing function that is only true when Qemu is built with
> xen-pci-passthrough enabled and the administrator has configured the Xen
> HVM guest with Qemu's igd-passthru=on option.
>
> v2: Remove From: tag at top of commit message
>
> v3: Changed the test for the Intel IGD in xen_igd_clear_slot:
>
> if (is_igd_vga_passthrough(&s->real_device) &&
> (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL)) {
>
> is changed to
>
> if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
> && (s->hostaddr.function == 0)) {
>
> I hoped that I could use the test in v2, since it matches the
> other tests for the Intel IGD in Qemu and Xen, but those tests
> do not work because the necessary data structures are not set with
> their values yet. So instead use the test that the administrator
> has enabled gfx_passthru and the device address on the host is
> 02.0. This test does detect the Intel IGD correctly.
>
> v4: Use brchu...@aol.com instead of brchu...@netscape.net for the author's
> email address to match the address used by the same author in commits
> be9c61da and c0e86b76
>
> Change variable for XEN_PT_DEVICE_CLASS: xptc changed to xpdc
>
> v5: The patch of xen_pt.c was re-worked to allow a more consistent test
> for the Intel IGD that uses the same criteria as in other places.
> This involved moving the call to xen_host_pci_device_get from
> xen_pt_realize to xen_igd_clear_slot and updating the checks for the
> Intel IGD in xen_igd_clear_slot:
>
> if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
> && (s->hostaddr.function == 0)) {
>
> is changed to
>
> if (is_igd_vga_passthrough(&s->real_device) &&
> s->real_device.domain == 0 && s->real_device.bus == 0 &&
> s->real_device.dev == 2 && s->real_device.func == 0 &&
> s->real_device.vend
Re: [PATCH v2 8/8] automation: add RISC-V smoke test
On Mon, 2023-01-09 at 18:21 -0800, Stefano Stabellini wrote:
> On Mon, 9 Jan 2023, Oleksii Kurochko wrote:
> > Add check if there is a message 'Hello from C env' presents
> > in log file to be sure that stack is set and C part of early printk
> > is working.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V2:
> > - Move changes in the dockerfile to separate patch and send it
> > to
> > mailing list separately:
> > [PATCH] automation: add qemu-system-riscv to
> > riscv64.dockerfile
> > - Update test.yaml to wire up smoke test
> > ---
> > automation/gitlab-ci/test.yaml | 20
> > automation/scripts/qemu-smoke-riscv64.sh | 20
> > 2 files changed, 40 insertions(+)
> > create mode 100755 automation/scripts/qemu-smoke-riscv64.sh
> >
> > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-
> > ci/test.yaml
> > index afd80adfe1..64f47a0ab9 100644
> > --- a/automation/gitlab-ci/test.yaml
> > +++ b/automation/gitlab-ci/test.yaml
> > @@ -54,6 +54,19 @@
> > tags:
> > - x86_64
> >
> > +.qemu-riscv64:
> > + extends: .test-jobs-common
> > + variables:
> > + CONTAINER: archlinux:riscv64
>
> I realize that it is committed now, but following the arm32
> convention
> the name of the arch container (currently archlinux:riscv64) would
> be:
>
> CONTAINER: archlinux:current-riscv64
>
> I know this is not related to this patch, but I am taking the
> opportunity to mention it now in case we get an opportunity to fix it
> in
> the future for consistency.
>
>
> > + LOGFILE: qemu-smoke-riscv64.log
> > + artifacts:
> > + paths:
> > + - smoke.serial
> > + - '*.log'
> > + when: always
> > + tags:
> > + - x86_64
> > +
> > .yocto-test:
> > extends: .test-jobs-common
> > script:
> > @@ -234,6 +247,13 @@ qemu-smoke-x86-64-clang-pvh:
> > needs:
> > - debian-unstable-clang-debug
> >
> > +qemu-smoke-riscv64-gcc:
> > + extends: .qemu-riscv64
> > + script:
> > + - ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee
> > ${LOGFILE}
> > + needs:
> > + - riscv64-cross-gcc
>
> Similarly here the "needs" dependency should be called
> arch-current-gcc-riscv for consistency with arm32.
>
> Basically we already have a crossbuild and crosstest environment up
> and
> running in gitlab-ci and it is the one for arm32. You can just base
> all
> the naming convention on that.
>
> I realize that riscv64-cross-gcc is also already exported by
> build.yaml,
> but I am mentioning it in case we get an opportunity to fix it in the
> future.
>
> Nonetheless this patch on its own is OK so
>
> Acked-by: Stefano Stabellini
>
Thanks for the comments.
I think it will be nice to fix that from the start so I will do a
separete patch out of this patch series (when it will be merged) which
will fix all this names related to RISCV.
>
> > # Yocto test jobs
> > yocto-qemuarm64:
> > extends: .yocto-test-arm64
> > diff --git a/automation/scripts/qemu-smoke-riscv64.sh
> > b/automation/scripts/qemu-smoke-riscv64.sh
> > new file mode 100755
> > index 00..e0f06360bc
> > --- /dev/null
> > +++ b/automation/scripts/qemu-smoke-riscv64.sh
> > @@ -0,0 +1,20 @@
> > +#!/bin/bash
> > +
> > +set -ex
> > +
> > +# Run the test
> > +rm -f smoke.serial
> > +set +e
> > +
> > +timeout -k 1 2 \
> > +qemu-system-riscv64 \
> > + -M virt \
> > + -smp 1 \
> > + -nographic \
> > + -m 2g \
> > + -kernel binaries/xen \
> > + |& tee smoke.serial
> > +
> > +set -e
> > +(grep -q "Hello from C env" smoke.serial) || exit 1
> > +exit 0
> > --
> > 2.38.1
> >
~Oleksii
Re: [PATCH v2] x86/xen: Remove the unused function p2m_index()
On 05.01.23 10:01, Jiapeng Chong wrote: The function p2m_index is defined in the p2m.c file, but not called elsewhere, so remove this unused function. arch/x86/xen/p2m.c:137:24: warning: unused function 'p2m_index'. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3557 Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Pushed to xen/tip.git for-linus-6.2 Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v1] xen/pvcalls: free active map buffer on pvcalls_front_free_map
On 20.12.22 15:50, Oleksii Moisieiev wrote: Data buffer for active map is allocated in alloc_active_ring and freed in free_active_ring function, which is used only for the error cleanup. pvcalls_front_release is calling pvcalls_front_free_map which ends foreign access for this buffer, but doesn't free allocated pages. Call free_active_ring to clean all allocated resources. Signed-off-by: Oleksii Moisieiev Pushed to xen/tip.git for-linus-6.2 Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2] xen: make remove callback of xen driver void returned
On 13.12.22 16:46, Dawei Li wrote:
Since commit fc7a6209d571 ("bus: Make remove callback return void")
forces bus_type::remove be void-returned, it doesn't make much sense for
any bus based driver implementing remove callbalk to return non-void to
its caller.
This change is for xen bus based drivers.
Acked-by: Juergen Gross
Signed-off-by: Dawei Li
Pushed to xen/tip.git for-linus-6.2
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2] hvc/xen: lock console list traversal
On 30.11.22 17:36, Roger Pau Monne wrote:
The currently lockless access to the xen console list in
vtermno_to_xencons() is incorrect, as additions and removals from the
list can happen anytime, and as such the traversal of the list to get
the private console data for a given termno needs to happen with the
lock held. Note users that modify the list already do so with the
lock taken.
Adjust current lock takers to use the _irq{save,restore} helpers,
since the context in which vtermno_to_xencons() is called can have
interrupts disabled. Use the _irq{save,restore} set of helpers to
switch the current callers to disable interrupts in the locked region.
I haven't checked if existing users could instead use the _irq
variant, as I think it's safer to use _irq{save,restore} upfront.
While there switch from using list_for_each_entry_safe to
list_for_each_entry: the current entry cursor won't be removed as
part of the code in the loop body, so using the _safe variant is
pointless.
Fixes: 02e19f9c7cac ('hvc_xen: implement multiconsole support')
Signed-off-by: Roger Pau Monné
Pushed to xen/tip.git for-linus-6.2
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[qemu-mainline test] 175681: regressions - FAIL
flight 175681 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175681/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 175623 build-amd64 6 xen-buildfail REGR. vs. 175623 build-i3866 xen-buildfail REGR. vs. 175623 build-arm64-xsm 6 xen-buildfail REGR. vs. 175623 build-i386-xsm6 xen-buildfail REGR. vs. 175623 build-arm64 6 xen-buildfail REGR. vs. 175623 build-armhf 6 xen-buildfail REGR. vs. 175623 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1
