[xen-unstable test] 175714: tolerable FAIL - PUSHED
flight 175714 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175714/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175694 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175694 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175694 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175694 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175694 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175694 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175694 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175694 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175694 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175694 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175694 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175694 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-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen 4d975798e11579fdf405b348543061129e01b0fb baseline version: xen 692d04a9ca429ca5
Re: No package 'pixman-1' found
Hello, I installed the pixman package, but Xen can't find it. On Tuesday, December 20, 2022 at 02:05:48 PM GMT+3:30, Jason Long wrote: Hello, How to solve the pixman error: $ sudo ./configure checking build system type... x86_64-pc-solaris2.11 checking host system type... x86_64-pc-solaris2.11 Will build the following subsystems: xen tools stubdom docs configure: creating ./config.status config.status: creating config/Toplevel.mk config.status: creating config/Paths.mk === configuring in tools (/home/Hypervisor/xen-4.16.2/tools) configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr/local' --cache-file=/dev/null --srcdir=. checking build system type... x86_64-pc-solaris2.11 checking host system type... x86_64-pc-solaris2.11 checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking for flex... /usr/bin/flex checking for abi-dumper... no checking for perl... /usr/bin/perl checking for awk... /usr/bin/awk checking for ocamlc... no checking for ocaml... no checking for ocamldep... no checking for ocamlmktop... no checking for ocamlmklib... no checking for ocamldoc... no checking for ocamlbuild... no checking for ocamlfind... no checking for gawk... /usr/bin/awk checking for go... no checking for checkpolicy... no checking for bash... /usr/bin/bash checking for python3... python3 checking for python3... /usr/bin/python3 checking for python3... /usr/bin/python3 checking for python version >= 2.6 ... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/ggrep checking for egrep... /usr/bin/ggrep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for python3-config... /usr/bin/python3-config checking Python.h usability... yes checking Python.h presence... yes checking for Python.h... yes checking for PyArg_ParseTuple... yes checking whether Python setup.py brokenly enables -D_FORTIFY_SOURCE... no checking for iasl... /usr/sbin/iasl checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for uuid_clear in -luuid... yes checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking for clear in -lcurses... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for glib... yes checking for pixman... no configure: error: Package requirements (pixman-1 >= 0.21.8) were not met: No package 'pixman-1' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables pixman_CFLAGS and pixman_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for tools Thank you.
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
> 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
It looks then I didn't understand which one of types are needed.
In "[PATCH v1 2/8] xen/riscv: introduce asm/types.h header file" all
types were introduced as most of them are used in :
__{u|s}{8|16|32|64}. Thereby it looks like the following types in
should be present from the start:
typedef __signed__ char __s8;
typedef unsigned char __u8;
typedef __signed__ short __s16;
typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
#if defined(CONFIG_RISCV_32)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#elif defined (CONFIG_RISCV_64)
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
#endif
Then it turns out that there is no any sense in:
typedef signed char s8;
typedef unsigned char u8;
typedef signed short s16;
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef signed long long s64;
typedef unsigned long long u64;
OR
typedef signed long s64;
typedef unsigned long u64;
As I understand instead of them should be used: {u|s}int_t.
All other types such as {v,p}addr_t, register_t and definitions
PRIvaddr, INVALID_PADDR, PRIpaadr, PRIregister should be present in
from the start.
Am I right?
> 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
~Oleksii
Re: [PATCH v2 10/19] tools/xenstore: change per-domain node accounting interface
On 20.12.22 21:15, Julien Grall wrote:
Hi,
On 13/12/2022 16:00, Juergen Gross wrote:
Rework the interface and the internals of the per-domain node
accounting:
- rename the functions to domain_nbentry_*() in order to better match
the related counter name
- switch from node pointer to domid as interface, as all nodes have the
owner filled in
The downside is now you have may place open-coding "...->perms->p[0].id". IHMO
this is making the code more complicated. So can you introduce a few wrappers
that would take a node and then convert to the owner?
Okay.
- use a common internal function for adding a value to the counter
For the transaction case add a helper function to get the list head
of the per-transaction changed domains, enabling to eliminate the
transaction_entry_*() functions.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 22 ++---
tools/xenstore/xenstored_domain.c | 122 +++--
tools/xenstore/xenstored_domain.h | 10 +-
tools/xenstore/xenstored_transaction.c | 15 +--
tools/xenstore/xenstored_transaction.h | 7 +-
5 files changed, 72 insertions(+), 104 deletions(-)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index f96714e1b8..61569cecbb 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1459,7 +1459,7 @@ static void destroy_node_rm(struct connection *conn,
struct node *node)
static int destroy_node(struct connection *conn, struct node *node)
{
destroy_node_rm(conn, node);
- domain_entry_dec(conn, node);
+ domain_nbentry_dec(conn, node->perms.p[0].id);
/*
* It is not possible to easily revert the changes in a transaction.
@@ -1498,7 +1498,7 @@ static struct node *create_node(struct connection *conn,
const void *ctx,
for (i = node; i; i = i->parent) {
/* i->parent is set for each new node, so check quota. */
if (i->parent &&
- domain_entry(conn) >= quota_nb_entry_per_domain) {
+ domain_nbentry(conn) >= quota_nb_entry_per_domain) {
ret = ENOSPC;
goto err;
}
@@ -1509,7 +1509,7 @@ static struct node *create_node(struct connection *conn,
const void *ctx,
/* Account for new node */
if (i->parent) {
- if (domain_entry_inc(conn, i)) {
+ if (domain_nbentry_inc(conn, i->perms.p[0].id)) {
destroy_node_rm(conn, i);
return NULL;
}
@@ -1662,7 +1662,7 @@ static int delnode_sub(const void *ctx, struct
connection *conn,
watch_exact = strcmp(root, node->name);
fire_watches(conn, ctx, node->name, node, watch_exact, NULL);
- domain_entry_dec(conn, node);
+ domain_nbentry_dec(conn, node->perms.p[0].id);
return WALK_TREE_RM_CHILDENTRY;
}
@@ -1802,25 +1802,25 @@ static int do_set_perms(const void *ctx, struct
connection *conn,
return EPERM;
old_perms = node->perms;
- domain_entry_dec(conn, node);
+ domain_nbentry_dec(conn, node->perms.p[0].id);
node->perms = perms;
- if (domain_entry_inc(conn, node)) {
+ if (domain_nbentry_inc(conn, node->perms.p[0].id)) {
node->perms = old_perms;
/*
* This should never fail because we had a reference on the
* domain before and Xenstored is single-threaded.
*/
- domain_entry_inc(conn, node);
+ domain_nbentry_inc(conn, node->perms.p[0].id);
return ENOMEM;
}
if (write_node(conn, node, false)) {
int saved_errno = errno;
- domain_entry_dec(conn, node);
+ domain_nbentry_dec(conn, node->perms.p[0].id);
node->perms = old_perms;
/* No failure possible as above. */
- domain_entry_inc(conn, node);
+ domain_nbentry_inc(conn, node->perms.p[0].id);
errno = saved_errno;
return errno;
@@ -2392,7 +2392,7 @@ void setup_structure(bool live_update)
manual_node("/tool/xenstored", NULL);
manual_node("@releaseDomain", NULL);
manual_node("@introduceDomain", NULL);
- domain_entry_fix(dom0_domid, 5, true);
+ domain_nbentry_fix(dom0_domid, 5, true);
}
check_store();
@@ -3400,7 +3400,7 @@ void read_state_node(const void *ctx, const void *state)
if (write_node_raw(NULL, &key, node, true))
barf("write node error restoring node");
- if (domain_entry_inc(&conn, node))
+ if (domain_nbentry_inc(&conn, node->perms.p[0].id))
barf("node accounting error restoring node");
talloc_free(node);
diff --git a/tools/xenstore/xenstored_domain.c
b/tools/xenstore/xenstored_domain.c
index 3216119e83..40b24056c5 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -249,7 +249,7 @@ static int domain_tree_remove_sub(const void *ctx, struct
connection *conn,
domain->nbentry--;
node->perms.p
Re: [PATCH v2 11/19] tools/xenstore: don't allow creating too many nodes in a transaction
On 20.12.22 21:18, Julien Grall wrote: Hi, On 13/12/2022 16:00, Juergen Gross wrote: The accounting for the number of nodes of a domain in an active transaction is not working correctly, as it allows to create arbitrary number of nodes. The transaction will finally fail due to exceeding the number of nodes quota, but before closing the transaction an unprivileged guest could cause Xenstore to use a lot of memory. As per the discussion in v1, the commit message needs to be reworded. I will look at this patch in more details once I have reached the 2nd series. I'll wait with the rewording until then. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 11.01.2023 09:47, Oleksii wrote:
> On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
>> 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
> It looks then I didn't understand which one of types are needed.
>
> In "[PATCH v1 2/8] xen/riscv: introduce asm/types.h header file" all
> types were introduced as most of them are used in :
> __{u|s}{8|16|32|64}. Thereby it looks like the following types in
> should be present from the start:
> typedef __signed__ char __s8;
> typedef unsigned char __u8;
>
> typedef __signed__ short __s16;
> typedef unsigned short __u16;
>
> typedef __signed__ int __s32;
> typedef unsigned int __u32;
>
> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> #if defined(CONFIG_RISCV_32)
> typedef __signed__ long long __s64;
> typedef unsigned long long __u64;
> #elif defined (CONFIG_RISCV_64)
> typedef __signed__ long __s64;
> typedef unsigned long __u64;
> #endif
> #endif
>
> Then it turns out that there is no any sense in:
> typedef signed char s8;
> typedef unsigned char u8;
>
> typedef signed short s16;
> typedef unsigned short u16;
>
> typedef signed int s32;
> typedef unsigned int u32;
>
> typedef signed long long s64;
> typedef unsigned long long u64;
> OR
> typedef signed long s64;
> typedef unsigned long u64;
> As I understand instead of them should be used: {u|s}int_t.
Hmm, the situation is worse than I thought (recalled) it was: You're
right, xen/types.h actually uses __{u,s}. So I'm sorry for mis-
guiding you; we'll need to do more cleanup first for asm/types.h to
become smaller.
Jan
Re: [PATCH v2 15/19] tools/xenstore: switch hashtable to use the talloc framework
On 20.12.22 22:50, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -115,47 +117,32 @@ hashtable_expand(struct hashtable *h)
if (h->primeindex == (prime_table_length - 1)) return 0;
newsize = primes[++(h->primeindex)];
- newtable = (struct entry **)calloc(newsize, sizeof(struct entry*));
- if (NULL != newtable)
+ newtable = talloc_realloc(h, h->table, struct entry *, newsize);
+ if (!newtable)
{
- /* This algorithm is not 'stable'. ie. it reverses the list
- * when it transfers entries between the tables */
- for (i = 0; i < h->tablelength; i++) {
- while (NULL != (e = h->table[i])) {
- h->table[i] = e->next;
- index = indexFor(newsize,e->h);
+ h->primeindex--;
+ return 0;
+ }
+
+ h->table = newtable;
+ memset(newtable + h->tablelength, 0,
+ (newsize - h->tablelength) * sizeof(*newtable));
+ for (i = 0; i < h->tablelength; i++) {
I understand this code is taken from the realloc path. However, isn't this
algorithm also not stable? If so, then I think we move the comment here.
I'm fine with that, even if I don't see how it would matter. There is no
guarantee regarding the order of entries for a given index.
+ for (pE = &(newtable[i]), e = *pE; e != NULL; e = *pE) {
+ index = indexFor(newsize,e->h);
Missing space after ",".
Will fix.
+ if (index == i)
+ {
+ pE = &(e->next);
+ }
+ else
+ {
+ *pE = e->next;
e->next = newtable[index];
newtable[index] = e;
}
}
- free(h->table);
- h->table = newtable;
- }
- /* Plan B: realloc instead */
- else
- {
- newtable = (struct entry **)
- realloc(h->table, newsize * sizeof(struct entry *));
- if (NULL == newtable) { (h->primeindex)--; return 0; }
- h->table = newtable;
- memset(newtable + h->tablelength, 0,
- (newsize - h->tablelength) * sizeof(*newtable));
- for (i = 0; i < h->tablelength; i++) {
- for (pE = &(newtable[i]), e = *pE; e != NULL; e = *pE) {
- index = indexFor(newsize,e->h);
- if (index == i)
- {
- pE = &(e->next);
- }
- else
- {
- *pE = e->next;
- e->next = newtable[index];
- newtable[index] = e;
- }
- }
- }
}
+
h->tablelength = newsize;
h->loadlimit = (unsigned int)
(((uint64_t)newsize * max_load_factor) / 100);
@@ -184,7 +171,7 @@ hashtable_insert(struct hashtable *h, void *k, void *v)
* element may be ok. Next time we insert, we'll try expanding
again.*/
hashtable_expand(h);
}
- e = (struct entry *)calloc(1, sizeof(struct entry));
+ e = talloc_zero(h, struct entry);
if (NULL == e) { --(h->entrycount); return 0; } /*oom*/
e->h = hash(h,k);
index = indexFor(h->tablelength,e->h);
@@ -238,8 +225,8 @@ hashtable_remove(struct hashtable *h, void *k)
h->entrycount--;
v = e->v;
if (h->flags & HASHTABLE_FREE_KEY)
- free(e->k);
- free(e);
+ talloc_free(e->k);
+ talloc_free(e);
return v;
}
pE = &(e->next);
@@ -280,25 +267,20 @@ void
hashtable_destroy(struct hashtable *h)
{
unsigned int i;
- struct entry *e, *f;
+ struct entry *e;
struct entry **table = h->table;
for (i = 0; i < h->tablelength; i++)
{
- e = table[i];
- while (NULL != e)
+ for (e = table[i]; e; e = e->next)
{
- f = e;
- e = e->next;
if (h->flags & HASHTABLE_FREE_KEY)
- free(f->k);
+ talloc_free(e->k);
if (h->flags & HASHTABLE_FREE_VALUE)
- free(f->v);
- free(f);
AFAIU, the loop is reworked so you let talloc to free each element with the
parent. Using a while loop is definitely cleaner, but now you will end up to
have two separate loop for the elements.
There is a risk that the overall performance of hashtable_destroy() will be
worse as the data accessed in one loop may not fit in the cache. So you will
have to reload it on the second loop.
Therefore, I think it would be better to keep the loop as-is.
What about a completely different approach? I could make the key and value
talloc children of e when _inserting_ the element and the related flag is
set. This would reduce hashtable_destroy to a single talloc_free().
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [XEN PATCH] tools: Fix build with recent QEMU, use "--enable-trace-backends"
On 10.01.2023 16:18, 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
I've committed this, and I'll queue this for backporting unless you
(or anyone else) tell(s) me otherwise.
Jan
[qemu-mainline test] 175719: regressions - FAIL
flight 175719 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175719/ 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
Re: [PATCH v7 1/2] KVM: x86/cpuid: generalize kvm_update_kvm_cpuid_base() and also capture limit
On Fri, 2023-01-06 at 10:35 +, Paul Durrant wrote: > A subsequent patch will need to acquire the CPUID leaf range for emulated > Xen so explicitly pass the signature of the hypervisor we're interested in > to the new function. Also introduce a new kvm_hypervisor_cpuid structure > so we can neatly store both the base and limit leaf indices. > > Signed-off-by: Paul Durrant > --- Reviewed-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v7 2/2] KVM: x86/xen: update Xen CPUID Leaf 4 (tsc info) sub-leaves, if present
On Fri, 2023-01-06 at 10:36 +, Paul Durrant wrote: > The scaling information in subleaf 1 should match the values set by KVM in > the 'vcpu_info' sub-structure 'time_info' (a.k.a. pvclock_vcpu_time_info) > which is shared with the guest, but is not directly available to the VMM. > The offset values are not set since a TSC offset is already applied. > The TSC frequency should also be set in sub-leaf 2. > > Signed-off-by: Paul Durrant > --- Reviewed-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature
RE: [PATCH v2 01/17] xen/arm: use NR_MEM_BANKS to override default NR_NODE_MEMBLKS
Hi Jan, > -Original Message- > From: Jan Beulich > Sent: 2023年1月10日 18:00 > To: Wei Chen > Cc: nd ; Stefano Stabellini ; Julien > Grall ; Bertrand Marquis ; > Volodymyr Babchuk ; Andrew Cooper > ; George Dunlap ; Wei > Liu ; xen-devel@lists.xenproject.org > Subject: 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? > Thanks of pointing out this. Yes NR_MEM_BANKS a system-wide setting, but we just use it to define the MAX memory banks for single node, this does not mean that there are really so many banks on these nodes. When a system only contains one node NR_MEM_BANKS equals to NR_NODE_MEMBLKS. Our idea is that, if the total memory banks of all nodes exceed the NR_MEM_BANKS, we will bump NR_MEM_BANKS. But I am open to this question, if there are more suggestions from maintainers. Cheers, Wei Chen > Jan
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 1/11/23 11:08, Jan Beulich wrote:
On 11.01.2023 09:47, Oleksii wrote:
On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
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
It looks then I didn't understand which one of types are needed.
In "[PATCH v1 2/8] xen/riscv: introduce asm/types.h header file" all
types were introduced as most of them are used in :
__{u|s}{8|16|32|64}. Thereby it looks like the following types in
should be present from the start:
typedef __signed__ char __s8;
typedef unsigned char __u8;
typedef __signed__ short __s16;
typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
#if defined(CONFIG_RISCV_32)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#elif defined (CONFIG_RISCV_64)
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
#endif
Then it turns out that there is no any sense in:
typedef signed char s8;
typedef unsigned char u8;
typedef signed short s16;
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef signed long long s64;
typedef unsigned long long u64;
OR
typedef signed long s64;
typedef unsigned long u64;
As I understand instead of them should be used: {u|s}int_t.
Hmm, the situation is worse than I thought (recalled) it was: You're
right, xen/types.h actually uses __{u,s}. So I'm sorry for mis-
guiding you; we'll need to do more cleanup first for asm/types.h to
become smaller.
What is the reason for not declaring __{u,s} directly in xen/types.h
as type alias to {u,s}?
IIUC __{u,s} and {u,s} are needed by code ported from Linux while
Xen code should use {u|s}int_t instead, right?
--
Xenia
Re: [PATCH] automation: rename RISCV_64 container and jobs
On 10/01/2023 4:25 pm, Oleksii Kurochko wrote: > 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 This rename will break Xen 4.17 Now, as 4.17's RISC-V support was so token that it wasn't even properly wired into CI, then this is probably fine. But we absolutely do need to be aware of the consequence before taking the patch. ~Andrew
Re: [PATCH] automation: rename RISCV_64 container and jobs
On 11/01/2023 11:44, Andrew Cooper wrote: > > > On 10/01/2023 4:25 pm, Oleksii Kurochko wrote: >> 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 > > This rename will break Xen 4.17 I guess only if we decide to remove the old container from registry, which we do not need to do. We already have a few containers in the registry whose dockerfiles no longer appear in xen.git but are kept in gitlab for backwards compatibility. > > Now, as 4.17's RISC-V support was so token that it wasn't even properly > wired into CI, then this is probably fine. > > But we absolutely do need to be aware of the consequence before taking > the patch. > > ~Andrew ~Michal
[PATCH v2 14/16] xen/xenbus: move to_xenbus_device() to use container_of_const()
The driver core is changing to pass some pointers as const, so move
to_xenbus_device() to use container_of_const() to handle this change.
to_xenbus_device() now properly keeps the const-ness of the pointer passed
into it, while as before it could be lost.
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Oleksandr Tyshchenko
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Greg Kroah-Hartman
---
include/xen/xenbus.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index eaa932b99d8a..b31f77f9c50c 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -96,10 +96,7 @@ struct xenbus_device {
unsigned int spurious_threshold;
};
-static inline struct xenbus_device *to_xenbus_device(struct device *dev)
-{
- return container_of(dev, struct xenbus_device, dev);
-}
+#define to_xenbus_device(__dev)container_of_const(__dev, struct
xenbus_device, dev)
struct xenbus_device_id
{
--
2.39.0
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 11.01.2023 11:22, Xenia Ragiadakou wrote:
>
> On 1/11/23 11:08, Jan Beulich wrote:
>> On 11.01.2023 09:47, Oleksii wrote:
>>> On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
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
>>> It looks then I didn't understand which one of types are needed.
>>>
>>> In "[PATCH v1 2/8] xen/riscv: introduce asm/types.h header file" all
>>> types were introduced as most of them are used in :
>>> __{u|s}{8|16|32|64}. Thereby it looks like the following types in
>>> should be present from the start:
>>>typedef __signed__ char __s8;
>>>typedef unsigned char __u8;
>>>
>>>typedef __signed__ short __s16;
>>>typedef unsigned short __u16;
>>>
>>>typedef __signed__ int __s32;
>>>typedef unsigned int __u32;
>>>
>>>#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>>>#if defined(CONFIG_RISCV_32)
>>> typedef __signed__ long long __s64;
>>> typedef unsigned long long __u64;
>>>#elif defined (CONFIG_RISCV_64)
>>> typedef __signed__ long __s64;
>>> typedef unsigned long __u64;
>>>#endif
>>>#endif
>>>
>>> Then it turns out that there is no any sense in:
>>>typedef signed char s8;
>>>typedef unsigned char u8;
>>>
>>>typedef signed short s16;
>>>typedef unsigned short u16;
>>>
>>>typedef signed int s32;
>>>typedef unsigned int u32;
>>>
>>>typedef signed long long s64;
>>>typedef unsigned long long u64;
>>> OR
>>>typedef signed long s64;
>>>typedef unsigned long u64;
>>> As I understand instead of them should be used: {u|s}int_t.
>>
>> Hmm, the situation is worse than I thought (recalled) it was: You're
>> right, xen/types.h actually uses __{u,s}. So I'm sorry for mis-
>> guiding you; we'll need to do more cleanup first for asm/types.h to
>> become smaller.
>
> What is the reason for not declaring __{u,s} directly in xen/types.h
> as type alias to {u,s}?
>
> IIUC __{u,s} and {u,s} are needed by code ported from Linux while
> Xen code should use {u|s}int_t instead, right?
Yes. Hence in the long run only Linux files should get to see __{u,s}
and {u,s}, perhaps from a new linux-types.h.
Jan
Re: Wake-up from suspend to RAM broken under `retbleed=stuff`
On 11/01/2023 11:20 am, Peter Zijlstra wrote:
> On Mon, Jan 09, 2023 at 04:05:31AM +, Joan Bruguera wrote:
>> This fixes wakeup for me on both QEMU and real HW
>> (just a proof of concept, don't merge)
>>
>> diff --git a/arch/x86/kernel/callthunks.c b/arch/x86/kernel/callthunks.c
>> index ffea98f9064b..8704bcc0ce32 100644
>> --- a/arch/x86/kernel/callthunks.c
>> +++ b/arch/x86/kernel/callthunks.c
>> @@ -7,6 +7,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -150,6 +151,10 @@ static bool skip_addr(void *dest)
>> if (dest >= (void *)hypercall_page &&
>> dest < (void*)hypercall_page + PAGE_SIZE)
>> return true;
>> +#endif
>> +#ifdef CONFIG_PM_SLEEP
>> +if (dest == restore_processor_state)
>> +return true;
>> #endif
>> return false;
>> }
>> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
>> index 236447ee9beb..e667894936f7 100644
>> --- a/arch/x86/power/cpu.c
>> +++ b/arch/x86/power/cpu.c
>> @@ -281,6 +281,9 @@ static void notrace __restore_processor_state(struct
>> saved_context *ctxt)
>> /* Needed by apm.c */
>> void notrace restore_processor_state(void)
>> {
>> +/* Restore GS before calling anything to avoid crash on call depth
>> accounting */
>> +native_wrmsrl(MSR_GS_BASE, saved_context.kernelmode_gs_base);
>> +
>> __restore_processor_state(&saved_context);
>> }
> Yeah, I can see why, but I'm not really comfortable with this. TBH, I
> don't see how the whole resume code is correct to begin with. At the
> very least it needs a heavy dose of noinstr.
>
> Rafael, what cr3 is active when we call restore_processor_state()?
>
> Specifically, the problem is that I don't feel comfortable doing any
> sort of weird code until all the CR and segment registers have been
> restored, however, write_cr*() are paravirt functions that result in
> CALL, which then gives us a bit of a checken and egg problem.
>
> I'm also wondering how well retbleed=stuff works on Xen, if at all. If
> we can ignore Xen, things are a little earier perhaps.
I really would like retbleed=stuff to work under Xen PV, because then we
can arrange to start turning off some even more expensive mitigations
that Xen does on behalf of guests.
I have a suspicion that these paths will be used under Xen PV, even if
only for dom0. The abstraction for host S3/4/5 are not great. That
said, at all points that guest code is executing, even after a logical
S3 resume, it will have a good GS_BASE (Assuming the teardown logic
doesn't self-clobber.)
The bigger issue with stuff accounting is that nothing AFAICT accounts
for the fact that any hypercall potentially empties the RSB in otherwise
synchronous program flow.
~Andrew
[PATCH] xen: Remove the arch specific header init.h
From: Julien Grall
Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
a structure that should not be used by any common code.
The structure init_info is used to store information to setup the CPU
currently being brought-up. setup.h seems to be more suitable even though
the header is getting quite crowded.
Looking through the history, was introduced at the same
time as the ia64 port because for some reasons most of the macros
where duplicated. This was changed in 72c07f413879 and I don't
foresee any reason to require arch specific definition for init.h
in the near future.
Therefore remove asm/init.h for both x86 and arm (the only definition
is moved in setup.h). With that RISC-V will not need to introduce
an empty header.
Suggested-by: Jan Beulich
Signed-off-by: Julien Grall
---
cc: Oleksii Kurochko
---
xen/arch/arm/arm32/asm-offsets.c | 1 +
xen/arch/arm/arm64/asm-offsets.c | 1 +
xen/arch/arm/include/asm/init.h | 20
xen/arch/arm/include/asm/setup.h | 8
xen/arch/x86/acpi/power.c| 1 -
xen/arch/x86/include/asm/init.h | 4
xen/include/xen/init.h | 2 --
7 files changed, 10 insertions(+), 27 deletions(-)
delete mode 100644 xen/arch/arm/include/asm/init.h
delete mode 100644 xen/arch/x86/include/asm/init.h
diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index 2116ba5b95bf..05c692bb2822 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#define DEFINE(_sym, _val) \
asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index 280ddb55bfd4..7226cd9b2eb0 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#define DEFINE(_sym, _val) \
diff --git a/xen/arch/arm/include/asm/init.h b/xen/arch/arm/include/asm/init.h
deleted file mode 100644
index 5ac8cf8797d6..
--- a/xen/arch/arm/include/asm/init.h
+++ /dev/null
@@ -1,20 +0,0 @@
-#ifndef _XEN_ASM_INIT_H
-#define _XEN_ASM_INIT_H
-
-struct init_info
-{
-/* Pointer to the stack, used by head.S when entering in C */
-unsigned char *stack;
-/* Logical CPU ID, used by start_secondary */
-unsigned int cpuid;
-};
-
-#endif /* _XEN_ASM_INIT_H */
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index fdbf68aadcaa..a926f30a2be4 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -168,6 +168,14 @@ int map_range_to_domain(const struct dt_device_node *dev,
extern const char __ro_after_init_start[], __ro_after_init_end[];
+struct init_info
+{
+/* Pointer to the stack, used by head.S when entering in C */
+unsigned char *stack;
+/* Logical CPU ID, used by start_secondary */
+unsigned int cpuid;
+};
+
#endif
/*
* Local variables:
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index b76f673acb1a..d23335391c67 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/xen/arch/x86/include/asm/init.h b/xen/arch/x86/include/asm/init.h
deleted file mode 100644
index 5295b35e6337..
--- a/xen/arch/x86/include/asm/init.h
+++ /dev/null
@@ -1,4 +0,0 @@
-#ifndef _XEN_ASM_INIT_H
-#define _XEN_ASM_INIT_H
-
-#endif /* _XEN_ASM_INIT_H */
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index 0af0e234ec80..1d7c0216bc80 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -1,8 +1,6 @@
#ifndef _LINUX_INIT_H
#define _LINUX_INIT_H
-#include
-
/*
* Mark functions and data as being only used at initialization
* or exit time.
--
2.38.1
Re: Wake-up from suspend to RAM broken under `retbleed=stuff`
On 11.01.2023 12:39, Andrew Cooper wrote: > The bigger issue with stuff accounting is that nothing AFAICT accounts > for the fact that any hypercall potentially empties the RSB in otherwise > synchronous program flow. But that's not just at hypercall boundaries, but effectively anywhere (i.e. whenever the hypervisor decides to de-schedule the vCPU)? Jan
Re: [PATCH] xen: Remove the arch specific header init.h
On 11/01/2023 11:44 am, Julien Grall wrote: > From: Julien Grall > > Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains > a structure that should not be used by any common code. > > The structure init_info is used to store information to setup the CPU > currently being brought-up. setup.h seems to be more suitable even though > the header is getting quite crowded. > > Looking through the history, was introduced at the same > time as the ia64 port because for some reasons most of the macros > where duplicated. This was changed in 72c07f413879 and I don't > foresee any reason to require arch specific definition for init.h > in the near future. > > Therefore remove asm/init.h for both x86 and arm (the only definition > is moved in setup.h). With that RISC-V will not need to introduce > an empty header. > > Suggested-by: Jan Beulich > Signed-off-by: Julien Grall Acked-by: Andrew Cooper
Re: [PATCH] xen: Remove the arch specific header init.h
On Wed, Jan 11, 2023 at 9:44 PM Julien Grall wrote:
>
> From: Julien Grall
>
> Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
> a structure that should not be used by any common code.
>
> The structure init_info is used to store information to setup the CPU
> currently being brought-up. setup.h seems to be more suitable even though
> the header is getting quite crowded.
>
> Looking through the history, was introduced at the same
> time as the ia64 port because for some reasons most of the macros
> where duplicated. This was changed in 72c07f413879 and I don't
> foresee any reason to require arch specific definition for init.h
> in the near future.
>
> Therefore remove asm/init.h for both x86 and arm (the only definition
> is moved in setup.h). With that RISC-V will not need to introduce
> an empty header.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Julien Grall
Acked-by: Alistair Francis
Alistair
>
> ---
> cc: Oleksii Kurochko
> ---
> xen/arch/arm/arm32/asm-offsets.c | 1 +
> xen/arch/arm/arm64/asm-offsets.c | 1 +
> xen/arch/arm/include/asm/init.h | 20
> xen/arch/arm/include/asm/setup.h | 8
> xen/arch/x86/acpi/power.c| 1 -
> xen/arch/x86/include/asm/init.h | 4
> xen/include/xen/init.h | 2 --
> 7 files changed, 10 insertions(+), 27 deletions(-)
> delete mode 100644 xen/arch/arm/include/asm/init.h
> delete mode 100644 xen/arch/x86/include/asm/init.h
>
> diff --git a/xen/arch/arm/arm32/asm-offsets.c
> b/xen/arch/arm/arm32/asm-offsets.c
> index 2116ba5b95bf..05c692bb2822 100644
> --- a/xen/arch/arm/arm32/asm-offsets.c
> +++ b/xen/arch/arm/arm32/asm-offsets.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> #define DEFINE(_sym, _val) \
> asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \
> diff --git a/xen/arch/arm/arm64/asm-offsets.c
> b/xen/arch/arm/arm64/asm-offsets.c
> index 280ddb55bfd4..7226cd9b2eb0 100644
> --- a/xen/arch/arm/arm64/asm-offsets.c
> +++ b/xen/arch/arm/arm64/asm-offsets.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define DEFINE(_sym, _val) \
> diff --git a/xen/arch/arm/include/asm/init.h b/xen/arch/arm/include/asm/init.h
> deleted file mode 100644
> index 5ac8cf8797d6..
> --- a/xen/arch/arm/include/asm/init.h
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -#ifndef _XEN_ASM_INIT_H
> -#define _XEN_ASM_INIT_H
> -
> -struct init_info
> -{
> -/* Pointer to the stack, used by head.S when entering in C */
> -unsigned char *stack;
> -/* Logical CPU ID, used by start_secondary */
> -unsigned int cpuid;
> -};
> -
> -#endif /* _XEN_ASM_INIT_H */
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/xen/arch/arm/include/asm/setup.h
> b/xen/arch/arm/include/asm/setup.h
> index fdbf68aadcaa..a926f30a2be4 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -168,6 +168,14 @@ int map_range_to_domain(const struct dt_device_node *dev,
>
> extern const char __ro_after_init_start[], __ro_after_init_end[];
>
> +struct init_info
> +{
> +/* Pointer to the stack, used by head.S when entering in C */
> +unsigned char *stack;
> +/* Logical CPU ID, used by start_secondary */
> +unsigned int cpuid;
> +};
> +
> #endif
> /*
> * Local variables:
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index b76f673acb1a..d23335391c67 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/xen/arch/x86/include/asm/init.h b/xen/arch/x86/include/asm/init.h
> deleted file mode 100644
> index 5295b35e6337..
> --- a/xen/arch/x86/include/asm/init.h
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -#ifndef _XEN_ASM_INIT_H
> -#define _XEN_ASM_INIT_H
> -
> -#endif /* _XEN_ASM_INIT_H */
> diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
> index 0af0e234ec80..1d7c0216bc80 100644
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -1,8 +1,6 @@
> #ifndef _LINUX_INIT_H
> #define _LINUX_INIT_H
>
> -#include
> -
> /*
> * Mark functions and data as being only used at initialization
> * or exit time.
> --
> 2.38.1
>
>
Re: [PATCH v2 14/16] xen/xenbus: move to_xenbus_device() to use container_of_const()
On 11.01.23 12:30, Greg Kroah-Hartman wrote: The driver core is changing to pass some pointers as const, so move to_xenbus_device() to use container_of_const() to handle this change. to_xenbus_device() now properly keeps the const-ness of the pointer passed into it, while as before it could be lost. Cc: Juergen Gross Cc: Stefano Stabellini Cc: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org Signed-off-by: Greg Kroah-Hartman Acked-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] xen: Remove the arch specific header init.h
> On 11 Jan 2023, at 11:44, Julien Grall wrote: > > From: Julien Grall > > Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains > a structure that should not be used by any common code. > > The structure init_info is used to store information to setup the CPU > currently being brought-up. setup.h seems to be more suitable even though > the header is getting quite crowded. > > Looking through the history, was introduced at the same > time as the ia64 port because for some reasons most of the macros > where duplicated. This was changed in 72c07f413879 and I don't > foresee any reason to require arch specific definition for init.h > in the near future. > > Therefore remove asm/init.h for both x86 and arm (the only definition > is moved in setup.h). With that RISC-V will not need to introduce > an empty header. > > Suggested-by: Jan Beulich > Signed-off-by: Julien Grall > Hi Julien, The arm part looks good to me, I’ve also built x86, arm32 and arm64 and no problems found. Reviewed-by: Luca Fancellu
[GIT PULL] xen: branch for v6.2-rc4
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.2-rc4-tag xen: branch for v6.2-rc4 It contains: - 2 cleanup patches - a fix of a memory leak in the Xen pvfront driver - a fix of a locking issue in the Xen hypervisor console driver Thanks. Juergen arch/x86/xen/p2m.c | 5 drivers/block/xen-blkback/xenbus.c | 4 +-- drivers/block/xen-blkfront.c| 3 +-- drivers/char/tpm/xen-tpmfront.c | 3 +-- drivers/gpu/drm/xen/xen_drm_front.c | 3 +-- drivers/input/misc/xen-kbdfront.c | 5 ++-- drivers/net/xen-netback/xenbus.c| 3 +-- drivers/net/xen-netfront.c | 4 +-- drivers/pci/xen-pcifront.c | 4 +-- drivers/scsi/xen-scsifront.c| 4 +-- drivers/tty/hvc/hvc_xen.c | 50 +++-- drivers/usb/host/xen-hcd.c | 4 +-- drivers/video/fbdev/xen-fbfront.c | 6 ++--- drivers/xen/pvcalls-back.c | 3 +-- drivers/xen/pvcalls-front.c | 7 +++--- drivers/xen/xen-pciback/xenbus.c| 4 +-- drivers/xen/xen-scsiback.c | 4 +-- include/xen/xenbus.h| 2 +- net/9p/trans_xen.c | 3 +-- sound/xen/xen_snd_front.c | 3 +-- 20 files changed, 54 insertions(+), 70 deletions(-) Dawei Li (1): xen: make remove callback of xen driver void returned Jiapeng Chong (1): x86/xen: Remove the unused function p2m_index() Oleksii Moisieiev (1): xen/pvcalls: free active map buffer on pvcalls_front_free_map Roger Pau Monne (1): hvc/xen: lock console list traversal
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 1/11/23 13:38, Jan Beulich wrote:
On 11.01.2023 11:22, Xenia Ragiadakou wrote:
On 1/11/23 11:08, Jan Beulich wrote:
On 11.01.2023 09:47, Oleksii wrote:
On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
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
It looks then I didn't understand which one of types are needed.
In "[PATCH v1 2/8] xen/riscv: introduce asm/types.h header file" all
types were introduced as most of them are used in :
__{u|s}{8|16|32|64}. Thereby it looks like the following types in
should be present from the start:
typedef __signed__ char __s8;
typedef unsigned char __u8;
typedef __signed__ short __s16;
typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
#if defined(CONFIG_RISCV_32)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#elif defined (CONFIG_RISCV_64)
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
#endif
Then it turns out that there is no any sense in:
typedef signed char s8;
typedef unsigned char u8;
typedef signed short s16;
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef signed long long s64;
typedef unsigned long long u64;
OR
typedef signed long s64;
typedef unsigned long u64;
As I understand instead of them should be used: {u|s}int_t.
Hmm, the situation is worse than I thought (recalled) it was: You're
right, xen/types.h actually uses __{u,s}. So I'm sorry for mis-
guiding you; we'll need to do more cleanup first for asm/types.h to
become smaller.
What is the reason for not declaring __{u,s} directly in xen/types.h
as type alias to {u,s}?
IIUC __{u,s} and {u,s} are needed by code ported from Linux while
Xen code should use {u|s}int_t instead, right?
Yes. Hence in the long run only Linux files should get to see __{u,s}
and {u,s}, perhaps from a new linux-types.h.
Thanks for the clarification. Could you please help me understand also
why __signed__ keyword is required when declaring __{u,s}?
I mean why __{u,s} cannot be declared using the signed type
specifier, just like {u,s}?
--
Xenia
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 11.01.2023 13:30, Xenia Ragiadakou wrote:
> Could you please help me understand also
> why __signed__ keyword is required when declaring __{u,s}?
> I mean why __{u,s} cannot be declared using the signed type
> specifier, just like {u,s}?
I'm afraid I can't, as this looks to have been (blindly?) imported
from Linux very, very long ago. Having put time in going through
our own history, I'm afraid I don't want to go further and see
whether I could spot the reason for you by going through Linux'es.
Jan
Re: [PATCH] xen: Remove the arch specific header init.h
On 11.01.2023 12:44, Julien Grall wrote: > From: Julien Grall > > Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains > a structure that should not be used by any common code. > > The structure init_info is used to store information to setup the CPU > currently being brought-up. setup.h seems to be more suitable even though > the header is getting quite crowded. > > Looking through the history, was introduced at the same > time as the ia64 port because for some reasons most of the macros > where duplicated. This was changed in 72c07f413879 and I don't > foresee any reason to require arch specific definition for init.h > in the near future. > > Therefore remove asm/init.h for both x86 and arm (the only definition > is moved in setup.h). With that RISC-V will not need to introduce > an empty header. > > Suggested-by: Jan Beulich > Signed-off-by: Julien Grall Reviewed-by: Jan Beulich
[linux-linus test] 175717: regressions - FAIL
flight 175717 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175717/ 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-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-amd64-amd64-xl-credit2 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
[xen-unstable-smoke test] 175721: tolerable all pass - PUSHED
flight 175721 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175721/ 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 e66d450b6e0ffec635639df993ab43ce28b3383f baseline version: xen 4d975798e11579fdf405b348543061129e01b0fb Last test of basis 175712 2023-01-10 22:00:26 Z0 days Testing same since 175721 2023-01-11 10:03:26 Z0 days1 attempts People who touched revisions under test: Anthony PERARD 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 4d975798e1..e66d450b6e e66d450b6e0ffec635639df993ab43ce28b3383f -> smoke
[PATCH v2 0/9] x86/shadow: misc tidying
... or so I hope. The main observation was that we still have both hash_vcpu_for_each() and hash_domain_for_each(), where the latter was introduced in 2014/15 to replace the former. Only some eight years later we can now complete this conversion. Everything else addresses other things noticed along the road. Note that patch 8 conflicts contextually but not functionally with patches 3 and 4 from "x86/mm: address aspects noticed during XSA-410 work". 1: replace sh_reset_l3_up_pointers() 2: drop hash_vcpu_foreach() 3: rename hash_domain_foreach() 4: drop a few uses of mfn_valid() 5: L2H shadow type is PV32-only 6: x86/shadow: re-work 4-level SHADOW_FOREACH_L2E() 7: reduce effort of hash calculation 8: call sh_detach_old_tables() directly 9: harden shadow_size() Jan
[PATCH v2 1/9] x86/shadow: replace sh_reset_l3_up_pointers()
Rather than doing a separate hash walk (and then even using the vCPU
variant, which is to go away), do the up-pointer-clearing right in
sh_unpin(), as an alternative to the (now further limited) enlisting on
a "free floating" list fragment. This utilizes the fact that such list
fragments are traversed only for multi-page shadows (in shadow_free()).
Furthermore sh_terminate_list() is a safe guard only anyway, which isn't
in use in the common case (it actually does anything only for BIGMEM
configurations).
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -116,6 +116,9 @@ struct shadow_domain {
/* OOS */
bool_t oos_active;
+/* Domain is in the process of leaving SHOPT_LINUX_L3_TOPLEVEL mode. */
+bool unpinning_l3;
+
#ifdef CONFIG_HVM
/* Has this domain ever used HVMOP_pagetable_dying? */
bool_t pagetable_dying_op;
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2302,29 +2302,6 @@ void shadow_prepare_page_type_change(str
/**/
-/* Reset the up-pointers of every L3 shadow to 0.
- * This is called when l3 shadows stop being pinnable, to clear out all
- * the list-head bits so the up-pointer field is properly inititalised. */
-static int cf_check sh_clear_up_pointer(
-struct vcpu *v, mfn_t smfn, mfn_t unused)
-{
-mfn_to_page(smfn)->up = 0;
-return 0;
-}
-
-void sh_reset_l3_up_pointers(struct vcpu *v)
-{
-static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
-[SH_type_l3_64_shadow] = sh_clear_up_pointer,
-};
-
-HASH_CALLBACKS_CHECK(SHF_L3_64);
-hash_vcpu_foreach(v, SHF_L3_64, callbacks, INVALID_MFN);
-}
-
-
-/**/
-
static void sh_update_paging_modes(struct vcpu *v)
{
struct domain *d = v->domain;
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -960,6 +960,8 @@ sh_make_shadow(struct vcpu *v, mfn_t gmf
}
if ( l4count > 2 * d->max_vcpus )
{
+d->arch.paging.shadow.unpinning_l3 = true;
+
/* Unpin all the pinned l3 tables, and don't pin any more. */
page_list_for_each_safe(sp, t,
&d->arch.paging.shadow.pinned_shadows)
{
@@ -967,7 +969,8 @@ sh_make_shadow(struct vcpu *v, mfn_t gmf
sh_unpin(d, page_to_mfn(sp));
}
d->arch.paging.shadow.opt_flags &= ~SHOPT_LINUX_L3_TOPLEVEL;
-sh_reset_l3_up_pointers(v);
+
+d->arch.paging.shadow.unpinning_l3 = false;
}
}
#endif
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -497,11 +497,6 @@ void shadow_blow_tables(struct domain *d
*/
int sh_remove_all_mappings(struct domain *d, mfn_t gmfn, gfn_t gfn);
-/* Reset the up-pointers of every L3 shadow to 0.
- * This is called when l3 shadows stop being pinnable, to clear out all
- * the list-head bits so the up-pointer field is properly inititalised. */
-void sh_reset_l3_up_pointers(struct vcpu *v);
-
/**
* Flags used in the return value of the shadow_set_lXe() functions...
*/
@@ -721,7 +716,7 @@ static inline void sh_unpin(struct domai
{
struct page_list_head tmp_list, *pin_list;
struct page_info *sp, *next;
-unsigned int i, head_type;
+unsigned int i, head_type, sz;
ASSERT(mfn_valid(smfn));
sp = mfn_to_page(smfn);
@@ -733,20 +728,30 @@ static inline void sh_unpin(struct domai
return;
sp->u.sh.pinned = 0;
-/* Cut the sub-list out of the list of pinned shadows,
- * stitching it back into a list fragment of its own. */
+sz = shadow_size(head_type);
+
+/*
+ * Cut the sub-list out of the list of pinned shadows, stitching
+ * multi-page shadows back into a list fragment of their own.
+ */
pin_list = &d->arch.paging.shadow.pinned_shadows;
INIT_PAGE_LIST_HEAD(&tmp_list);
-for ( i = 0; i < shadow_size(head_type); i++ )
+for ( i = 0; i < sz; i++ )
{
ASSERT(sp->u.sh.type == head_type);
ASSERT(!i || !sp->u.sh.head);
next = page_list_next(sp, pin_list);
page_list_del(sp, pin_list);
-page_list_add_tail(sp, &tmp_list);
+if ( sz > 1 )
+page_list_add_tail(sp, &tmp_list);
+else if ( head_type == SH_type_l3_64_shadow &&
+ d->arch.paging.shadow.unpinning_l3 )
+sp->up = 0;
sp = next;
}
-sh_terminate_list(&tmp_list);
+
+if ( sz > 1 )
+sh_terminate_list(&tmp_list);
sh_put_ref(d, smfn, 0);
}
[PATCH v2 2/9] x86/shadow: drop hash_vcpu_foreach()
The domain based variant is easily usable by shadow_audit_tables(); all
that's needed is conversion of the callback functions.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1640,59 +1640,11 @@ bool shadow_hash_delete(struct domain *d
return true;
}
-typedef int (*hash_vcpu_callback_t)(struct vcpu *v, mfn_t smfn, mfn_t
other_mfn);
typedef int (*hash_domain_callback_t)(struct domain *d, mfn_t smfn, mfn_t
other_mfn);
#define HASH_CALLBACKS_CHECK(mask) \
BUILD_BUG_ON((mask) > (1U << ARRAY_SIZE(callbacks)) - 1)
-static void hash_vcpu_foreach(struct vcpu *v, unsigned int callback_mask,
- const hash_vcpu_callback_t callbacks[],
- mfn_t callback_mfn)
-/* Walk the hash table looking at the types of the entries and
- * calling the appropriate callback function for each entry.
- * The mask determines which shadow types we call back for, and the array
- * of callbacks tells us which function to call.
- * Any callback may return non-zero to let us skip the rest of the scan.
- *
- * WARNING: Callbacks MUST NOT add or remove hash entries unless they
- * then return non-zero to terminate the scan. */
-{
-int i, done = 0;
-struct domain *d = v->domain;
-struct page_info *x;
-
-ASSERT(paging_locked_by_me(d));
-
-/* Can be called via p2m code &c after shadow teardown. */
-if ( unlikely(!d->arch.paging.shadow.hash_table) )
-return;
-
-/* Say we're here, to stop hash-lookups reordering the chains */
-ASSERT(d->arch.paging.shadow.hash_walking == 0);
-d->arch.paging.shadow.hash_walking = 1;
-
-for ( i = 0; i < SHADOW_HASH_BUCKETS; i++ )
-{
-/* WARNING: This is not safe against changes to the hash table.
- * The callback *must* return non-zero if it has inserted or
- * deleted anything from the hash (lookups are OK, though). */
-for ( x = d->arch.paging.shadow.hash_table[i]; x; x = next_shadow(x) )
-{
-if ( callback_mask & (1 << x->u.sh.type) )
-{
-ASSERT(x->u.sh.type <= SH_type_max_shadow);
-ASSERT(callbacks[x->u.sh.type] != NULL);
-done = callbacks[x->u.sh.type](v, page_to_mfn(x),
- callback_mfn);
-if ( done ) break;
-}
-}
-if ( done ) break;
-}
-d->arch.paging.shadow.hash_walking = 0;
-}
-
static void hash_domain_foreach(struct domain *d,
unsigned int callback_mask,
const hash_domain_callback_t callbacks[],
@@ -3211,7 +3163,7 @@ int shadow_domctl(struct domain *d,
void shadow_audit_tables(struct vcpu *v)
{
/* Dispatch table for getting per-type functions */
-static const hash_vcpu_callback_t callbacks[SH_type_unused] = {
+static const hash_domain_callback_t callbacks[SH_type_unused] = {
#if SHADOW_AUDIT & (SHADOW_AUDIT_ENTRIES | SHADOW_AUDIT_ENTRIES_FULL)
# ifdef CONFIG_HVM
[SH_type_l1_32_shadow] = SHADOW_INTERNAL_NAME(sh_audit_l1_table, 2),
@@ -3258,7 +3210,7 @@ void shadow_audit_tables(struct vcpu *v)
HASH_CALLBACKS_CHECK(SHADOW_AUDIT & (SHADOW_AUDIT_ENTRIES |
SHADOW_AUDIT_ENTRIES_FULL)
? SHF_page_type_mask : 0);
-hash_vcpu_foreach(v, mask, callbacks, INVALID_MFN);
+hash_domain_foreach(v->domain, mask, callbacks, INVALID_MFN);
}
#ifdef CONFIG_PV
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -326,32 +326,32 @@ static void sh_audit_gw(struct vcpu *v,
if ( mfn_valid(gw->l4mfn)
&& mfn_valid((smfn = get_shadow_status(d, gw->l4mfn,
SH_type_l4_shadow))) )
-(void) sh_audit_l4_table(v, smfn, INVALID_MFN);
+sh_audit_l4_table(d, smfn, INVALID_MFN);
if ( mfn_valid(gw->l3mfn)
&& mfn_valid((smfn = get_shadow_status(d, gw->l3mfn,
SH_type_l3_shadow))) )
-(void) sh_audit_l3_table(v, smfn, INVALID_MFN);
+sh_audit_l3_table(d, smfn, INVALID_MFN);
#endif /* PAE or 64... */
if ( mfn_valid(gw->l2mfn) )
{
if ( mfn_valid((smfn = get_shadow_status(d, gw->l2mfn,
SH_type_l2_shadow))) )
-(void) sh_audit_l2_table(v, smfn, INVALID_MFN);
+sh_audit_l2_table(d, smfn, INVALID_MFN);
#if GUEST_PAGING_LEVELS >= 4 /* 32-bit PV only */
if ( mfn_valid((smfn = get_shadow_status(d, gw->l2mfn,
SH_type_l2h_shadow))) )
-(void) sh_audit_l2_table(v, smfn, INVALID_MFN);
+sh_audit_l2_table(d, smfn, INVALID_MFN);
#endif
}
if ( mfn_valid(gw->l1mfn)
&& mfn_valid((smfn = get_shadow_status(d, gw->l1m
[qemu-mainline test] 175722: regressions - FAIL
flight 175722 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175722/ 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-arm64-pvops 6 kernel-build fail 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-debian
[PATCH v2 3/9] x86/shadow: rename hash_domain_foreach()
The "domain" in there has become meaningless; drop it.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1640,15 +1640,15 @@ bool shadow_hash_delete(struct domain *d
return true;
}
-typedef int (*hash_domain_callback_t)(struct domain *d, mfn_t smfn, mfn_t
other_mfn);
+typedef int (*hash_callback_t)(struct domain *d, mfn_t smfn, mfn_t other_mfn);
#define HASH_CALLBACKS_CHECK(mask) \
BUILD_BUG_ON((mask) > (1U << ARRAY_SIZE(callbacks)) - 1)
-static void hash_domain_foreach(struct domain *d,
-unsigned int callback_mask,
-const hash_domain_callback_t callbacks[],
-mfn_t callback_mfn)
+static void hash_foreach(struct domain *d,
+ unsigned int callback_mask,
+ const hash_callback_t callbacks[],
+ mfn_t callback_mfn)
/* Walk the hash table looking at the types of the entries and
* calling the appropriate callback function for each entry.
* The mask determines which shadow types we call back for, and the array
@@ -1784,7 +1784,7 @@ int sh_remove_write_access(struct domain
unsigned long fault_addr)
{
/* Dispatch table for getting per-type functions */
-static const hash_domain_callback_t callbacks[SH_type_unused] = {
+static const hash_callback_t callbacks[SH_type_unused] = {
#ifdef CONFIG_HVM
[SH_type_l1_32_shadow] =
SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, 2),
[SH_type_fl1_32_shadow] =
SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, 2),
@@ -1969,7 +1969,7 @@ int sh_remove_write_access(struct domain
else
perfc_incr(shadow_writeable_bf);
HASH_CALLBACKS_CHECK(SHF_L1_ANY | SHF_FL1_ANY);
-hash_domain_foreach(d, SHF_L1_ANY | SHF_FL1_ANY, callbacks, gmfn);
+hash_foreach(d, SHF_L1_ANY | SHF_FL1_ANY, callbacks, gmfn);
/* If that didn't catch the mapping, then there's some non-pagetable
* mapping -- ioreq page, grant mapping, &c. */
@@ -1997,7 +1997,7 @@ int sh_remove_all_mappings(struct domain
struct page_info *page = mfn_to_page(gmfn);
/* Dispatch table for getting per-type functions */
-static const hash_domain_callback_t callbacks[SH_type_unused] = {
+static const hash_callback_t callbacks[SH_type_unused] = {
[SH_type_l1_32_shadow] = SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1,
2),
[SH_type_fl1_32_shadow] = SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1,
2),
[SH_type_l1_pae_shadow] = SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1,
3),
@@ -2021,7 +2021,7 @@ int sh_remove_all_mappings(struct domain
/* Brute-force search of all the shadows, by walking the hash */
perfc_incr(shadow_mappings_bf);
HASH_CALLBACKS_CHECK(SHF_L1_ANY | SHF_FL1_ANY);
-hash_domain_foreach(d, SHF_L1_ANY | SHF_FL1_ANY, callbacks, gmfn);
+hash_foreach(d, SHF_L1_ANY | SHF_FL1_ANY, callbacks, gmfn);
/* If that didn't catch the mapping, something is very wrong */
if ( !sh_check_page_has_no_refs(page) )
@@ -2128,7 +2128,7 @@ void sh_remove_shadows(struct domain *d,
/* Dispatch table for getting per-type functions: each level must
* be called with the function to remove a lower-level shadow. */
-static const hash_domain_callback_t callbacks[SH_type_unused] = {
+static const hash_callback_t callbacks[SH_type_unused] = {
#ifdef CONFIG_HVM
[SH_type_l2_32_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l1_shadow, 2),
[SH_type_l2_pae_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l1_shadow, 3),
@@ -2173,9 +2173,9 @@ void sh_remove_shadows(struct domain *d,
/*
* Lower-level shadows need to be excised from upper-level shadows. This
- * call to hash_domain_foreach() looks dangerous but is in fact OK: each
- * call will remove at most one shadow, and terminate immediately when
- * it does remove it, so we never walk the hash after doing a deletion.
+ * call to hash_foreach() looks dangerous but is in fact OK: each call
+ * will remove at most one shadow, and terminate immediately when it does
+ * remove it, so we never walk the hash after doing a deletion.
*/
#define DO_UNSHADOW(_type) do { \
t = (_type);\
@@ -2199,7 +2199,7 @@ void sh_remove_shadows(struct domain *d,
(pg->shadow_flags & (1 << t)) )\
{ \
HASH_CALLBACKS_CHECK(SHF_page_type_mask); \
-hash_domain_foreach(d, masks[t], callbacks, smfn); \
+hash_foreach(d, masks[t], callbacks, smfn); \
} \
} while (0)
@@ -3163,7 +31
[PATCH v2 4/9] x86/shadow: drop a few uses of mfn_valid()
v->arch.paging.shadow.shadow_table[], v->arch.paging.shadow.oos[],
v->arch.paging.shadow.oos_{snapshot[],fixup[].smfn[]} as well as the
hash table are all only ever written with valid MFNs or INVALID_MFN.
Avoid the somewhat expensive mfn_valid() when checking MFNs coming from
these arrays.
Signed-off-by: Jan Beulich
---
There are many more uses which can likely be replaced, but I think we're
better off doing this in piecemeal fashion.
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -171,7 +171,7 @@ static void sh_oos_audit(struct domain *
for ( idx = 0; idx < SHADOW_OOS_PAGES; idx++ )
{
mfn_t *oos = v->arch.paging.shadow.oos;
-if ( !mfn_valid(oos[idx]) )
+if ( mfn_eq(oos[idx], INVALID_MFN) )
continue;
expected_idx = mfn_x(oos[idx]) % SHADOW_OOS_PAGES;
@@ -327,8 +327,7 @@ void oos_fixup_add(struct domain *d, mfn
int i;
for ( i = 0; i < SHADOW_OOS_FIXUPS; i++ )
{
-if ( mfn_valid(oos_fixup[idx].smfn[i])
- && mfn_eq(oos_fixup[idx].smfn[i], smfn)
+if ( mfn_eq(oos_fixup[idx].smfn[i], smfn)
&& (oos_fixup[idx].off[i] == off) )
return;
}
@@ -461,7 +460,7 @@ static void oos_hash_add(struct vcpu *v,
idx = mfn_x(gmfn) % SHADOW_OOS_PAGES;
oidx = idx;
-if ( mfn_valid(oos[idx])
+if ( !mfn_eq(oos[idx], INVALID_MFN)
&& (mfn_x(oos[idx]) % SHADOW_OOS_PAGES) == idx )
{
/* Punt the current occupant into the next slot */
@@ -470,8 +469,8 @@ static void oos_hash_add(struct vcpu *v,
swap = 1;
idx = (idx + 1) % SHADOW_OOS_PAGES;
}
-if ( mfn_valid(oos[idx]) )
- {
+if ( !mfn_eq(oos[idx], INVALID_MFN) )
+{
/* Crush the current occupant. */
_sh_resync(v, oos[idx], &oos_fixup[idx], oos_snapshot[idx]);
perfc_incr(shadow_unsync_evict);
@@ -607,7 +606,7 @@ void sh_resync_all(struct vcpu *v, int s
/* First: resync all of this vcpu's oos pages */
for ( idx = 0; idx < SHADOW_OOS_PAGES; idx++ )
-if ( mfn_valid(oos[idx]) )
+if ( !mfn_eq(oos[idx], INVALID_MFN) )
{
/* Write-protect and sync contents */
_sh_resync(v, oos[idx], &oos_fixup[idx], oos_snapshot[idx]);
@@ -630,7 +629,7 @@ void sh_resync_all(struct vcpu *v, int s
for ( idx = 0; idx < SHADOW_OOS_PAGES; idx++ )
{
-if ( !mfn_valid(oos[idx]) )
+if ( mfn_eq(oos[idx], INVALID_MFN) )
continue;
if ( skip )
@@ -2183,7 +2182,7 @@ void sh_remove_shadows(struct domain *d,
!(pg->shadow_flags & (1 << t)) ) \
break; \
smfn = shadow_hash_lookup(d, mfn_x(gmfn), t); \
-if ( unlikely(!mfn_valid(smfn)) ) \
+if ( unlikely(mfn_eq(smfn, INVALID_MFN)) ) \
{ \
printk(XENLOG_G_ERR "gmfn %"PRI_mfn" has flags %#x" \
" but no type-%#x shadow\n", \
@@ -2751,7 +2750,7 @@ void shadow_teardown(struct domain *d, b
int i;
mfn_t *oos_snapshot = v->arch.paging.shadow.oos_snapshot;
for ( i = 0; i < SHADOW_OOS_PAGES; i++ )
-if ( mfn_valid(oos_snapshot[i]) )
+if ( !mfn_eq(oos_snapshot[i], INVALID_MFN) )
{
shadow_free(d, oos_snapshot[i]);
oos_snapshot[i] = INVALID_MFN;
@@ -2934,7 +2933,7 @@ static int shadow_one_bit_disable(struct
int i;
mfn_t *oos_snapshot = v->arch.paging.shadow.oos_snapshot;
for ( i = 0; i < SHADOW_OOS_PAGES; i++ )
-if ( mfn_valid(oos_snapshot[i]) )
+if ( !mfn_eq(oos_snapshot[i], INVALID_MFN) )
{
shadow_free(d, oos_snapshot[i]);
oos_snapshot[i] = INVALID_MFN;
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -110,7 +110,7 @@ get_fl1_shadow_status(struct domain *d,
/* Look for FL1 shadows in the hash table */
{
mfn_t smfn = shadow_hash_lookup(d, gfn_x(gfn), SH_type_fl1_shadow);
-ASSERT(!mfn_valid(smfn) || mfn_to_page(smfn)->u.sh.head);
+ASSERT(mfn_eq(smfn, INVALID_MFN) || mfn_to_page(smfn)->u.sh.head);
return smfn;
}
@@ -2680,7 +2680,7 @@ static int cf_check sh_page_fault(
mfn_t smfn = pagetable_get_mfn(
v->arch.paging.shadow.shadow_table[i]);
-if ( mfn_valid(smfn) && (mfn_x(smfn) != 0) )
+if ( mfn_x(smfn) )
{
used |=
[PATCH v2 5/9] x86/shadow: L2H shadow type is PV32-only
Like for the various HVM-only types, save a little bit of code by suitably
"masking" this type out when !PV32.
Signed-off-by: Jan Beulich
---
I wasn't really sure whether it would be worthwhile to also update the
"#else" part of shadow_size(). Doing so would be a little tricky, as the
type to return 0 for has no name right now; I'd need to move down the
#undef to allow for that. Thoughts?
---
v2: Merely comment out the sh_type_to_size[] entry.
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1740,9 +1740,11 @@ void sh_destroy_shadow(struct domain *d,
case SH_type_fl1_64_shadow:
SHADOW_INTERNAL_NAME(sh_destroy_l1_shadow, 4)(d, smfn);
break;
+#ifdef CONFIG_PV32
case SH_type_l2h_64_shadow:
ASSERT(is_pv_32bit_domain(d));
/* Fall through... */
+#endif
case SH_type_l2_64_shadow:
SHADOW_INTERNAL_NAME(sh_destroy_l2_shadow, 4)(d, smfn);
break;
@@ -2095,7 +2097,9 @@ static int sh_remove_shadow_via_pointer(
#endif
case SH_type_l1_64_shadow:
case SH_type_l2_64_shadow:
+#ifdef CONFIG_PV32
case SH_type_l2h_64_shadow:
+#endif
case SH_type_l3_64_shadow:
case SH_type_l4_64_shadow:
SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, 4)(d, vaddr, pmfn);
@@ -2133,7 +2137,9 @@ void sh_remove_shadows(struct domain *d,
[SH_type_l2_pae_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l1_shadow, 3),
#endif
[SH_type_l2_64_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l1_shadow, 4),
+#ifdef CONFIG_PV32
[SH_type_l2h_64_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l1_shadow, 4),
+#endif
[SH_type_l3_64_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l2_shadow, 4),
[SH_type_l4_64_shadow] = SHADOW_INTERNAL_NAME(sh_remove_l3_shadow, 4),
};
@@ -2146,7 +2152,9 @@ void sh_remove_shadows(struct domain *d,
#endif
[SH_type_l1_64_shadow] = SHF_L2H_64 | SHF_L2_64,
[SH_type_l2_64_shadow] = SHF_L3_64,
+#ifdef CONFIG_PV32
[SH_type_l2h_64_shadow] = SHF_L3_64,
+#endif
[SH_type_l3_64_shadow] = SHF_L4_64,
};
@@ -2210,7 +2218,9 @@ void sh_remove_shadows(struct domain *d,
#endif
DO_UNSHADOW(SH_type_l4_64_shadow);
DO_UNSHADOW(SH_type_l3_64_shadow);
+#ifdef CONFIG_PV32
DO_UNSHADOW(SH_type_l2h_64_shadow);
+#endif
DO_UNSHADOW(SH_type_l2_64_shadow);
DO_UNSHADOW(SH_type_l1_64_shadow);
@@ -3175,7 +3185,9 @@ void shadow_audit_tables(struct vcpu *v)
[SH_type_l1_64_shadow] = SHADOW_INTERNAL_NAME(sh_audit_l1_table, 4),
[SH_type_fl1_64_shadow] = SHADOW_INTERNAL_NAME(sh_audit_fl1_table, 4),
[SH_type_l2_64_shadow] = SHADOW_INTERNAL_NAME(sh_audit_l2_table, 4),
+# ifdef CONFIG_PV32
[SH_type_l2h_64_shadow] = SHADOW_INTERNAL_NAME(sh_audit_l2_table, 4),
+# endif
[SH_type_l3_64_shadow] = SHADOW_INTERNAL_NAME(sh_audit_l3_table, 4),
[SH_type_l4_64_shadow] = SHADOW_INTERNAL_NAME(sh_audit_l4_table, 4),
#endif
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -56,7 +56,7 @@ const uint8_t sh_type_to_size[] = {
[SH_type_l1_64_shadow] = 1,
[SH_type_fl1_64_shadow] = 1,
[SH_type_l2_64_shadow] = 1,
-[SH_type_l2h_64_shadow] = 1,
+/* [SH_type_l2h_64_shadow] = 1, PV32-only */
[SH_type_l3_64_shadow] = 1,
[SH_type_l4_64_shadow] = 1,
[SH_type_p2m_table] = 1,
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -97,6 +97,13 @@ static void sh_flush_local(const struct
flush_local(guest_flush_tlb_flags(d));
}
+#if GUEST_PAGING_LEVELS >= 4 && defined(CONFIG_PV32)
+#define ASSERT_VALID_L2(t) \
+ASSERT((t) == SH_type_l2_shadow || (t) == SH_type_l2h_shadow)
+#else
+#define ASSERT_VALID_L2(t) ASSERT((t) == SH_type_l2_shadow)
+#endif
+
/**/
/* Hash table mapping from guest pagetables to shadows
*
@@ -337,7 +344,7 @@ static void sh_audit_gw(struct vcpu *v,
if ( mfn_valid((smfn = get_shadow_status(d, gw->l2mfn,
SH_type_l2_shadow))) )
sh_audit_l2_table(d, smfn, INVALID_MFN);
-#if GUEST_PAGING_LEVELS >= 4 /* 32-bit PV only */
+#if GUEST_PAGING_LEVELS >= 4 && defined(CONFIG_PV32)
if ( mfn_valid((smfn = get_shadow_status(d, gw->l2mfn,
SH_type_l2h_shadow))) )
sh_audit_l2_table(d, smfn, INVALID_MFN);
@@ -859,13 +866,12 @@ do {
int _i; \
int _xen = !shadow_mode_external(_dom); \
shadow_l2e_t *_sp = map_domain_page((_sl2mfn)); \
-ASSERT(mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow ||\
- mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2h_64_shadow);\
+ASSERT_VALID_L2(mfn_to_page(_sl2mfn)->u.sh.type); \
for ( _i = 0; _i < SHAD
[PATCH v2 6/9] x86/shadow: re-work 4-level SHADOW_FOREACH_L2E()
First of all move the almost loop-invariant condition out of the loop;
transform it into an altered loop boundary. Since the new local variable
wants to be "unsigned int" and named without violating name space rules,
convert the loop induction variable accordingly.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -863,23 +863,20 @@ do {
/* 64-bit l2: touch all entries except for PAE compat guests. */
#define SHADOW_FOREACH_L2E(_sl2mfn, _sl2e, _gl2p, _done, _dom, _code) \
do {\
-int _i; \
-int _xen = !shadow_mode_external(_dom); \
+unsigned int i_, end_ = SHADOW_L2_PAGETABLE_ENTRIES;\
shadow_l2e_t *_sp = map_domain_page((_sl2mfn)); \
ASSERT_VALID_L2(mfn_to_page(_sl2mfn)->u.sh.type); \
-for ( _i = 0; _i < SHADOW_L2_PAGETABLE_ENTRIES; _i++ ) \
+if ( !shadow_mode_external(_dom) && \
+ is_pv_32bit_domain(_dom) &&\
+ mfn_to_page(_sl2mfn)->u.sh.type != SH_type_l2_64_shadow ) \
+end_ = COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom);\
+for ( i_ = 0; i_ < end_; ++i_ ) \
{ \
-if ( (!(_xen)) \
- || !is_pv_32bit_domain(_dom) \
- || mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow \
- || (_i < COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom)) ) \
-{ \
-(_sl2e) = _sp + _i; \
-if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT ) \
-{_code} \
-if ( _done ) break; \
-increment_ptr_to_guest_entry(_gl2p);\
-} \
+(_sl2e) = _sp + i_; \
+if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT ) \
+{ _code } \
+if ( _done ) break; \
+increment_ptr_to_guest_entry(_gl2p);\
} \
unmap_domain_page(_sp); \
} while (0)
[PATCH v2 7/9] x86/shadow: reduce effort of hash calculation
The "n" input is a GFN/MFN value and hence bounded by the physical
address bits in use on a system. The hash quality won't improve by also
including the upper always-zero bits in the calculation. To keep things
as compile-time-constant as they were before, use PADDR_BITS (not
paddr_bits) for loop bounding. This reduces loop iterations from 8 to 5.
While there also drop the unnecessary conversion to an array of unsigned
char, moving the value off the stack altogether (at least with
optimization enabled).
Signed-off-by: Jan Beulich
---
I was tempted to also change the type "i" (unsigned) right here, but
then thought this might be going too far ...
---
v2: Also eliminate the unsigned char * alias of "n".
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1397,10 +1397,13 @@ static unsigned int shadow_get_allocatio
typedef u32 key_t;
static inline key_t sh_hash(unsigned long n, unsigned int t)
{
-unsigned char *p = (unsigned char *)&n;
key_t k = t;
int i;
-for ( i = 0; i < sizeof(n) ; i++ ) k = (u32)p[i] + (k<<6) + (k<<16) - k;
+
+BUILD_BUG_ON(PADDR_BITS > BITS_PER_LONG + PAGE_SHIFT);
+for ( i = 0; i < (PADDR_BITS - PAGE_SHIFT + 7) / 8; i++, n >>= 8 )
+k = (uint8_t)n + (k << 6) + (k << 16) - k;
+
return k % SHADOW_HASH_BUCKETS;
}
[PATCH v2 8/9] x86/shadow: call sh_detach_old_tables() directly
There's nothing really mode specific in this function anymore (the
varying number of valid entries in v->arch.paging.shadow.shadow_table[]
is dealt with fine by the zero check, and we have other similar cases of
iterating through the full array in common.c), and hence there's neither
a need to have multiple instances of it, nor does it need calling
through a function pointer.
Signed-off-by: Jan Beulich
---
I've retained the C++-style comment in the function as this style is
used elsewhere as well in shadow code. I wouldn't mind changing the
comment to conform to ./CODING_STYLE.
---
v2: New.
--- a/xen/arch/x86/include/asm/paging.h
+++ b/xen/arch/x86/include/asm/paging.h
@@ -98,7 +98,6 @@
struct shadow_paging_mode {
#ifdef CONFIG_SHADOW_PAGING
-void (*detach_old_tables )(struct vcpu *v);
#ifdef CONFIG_PV
void (*write_guest_entry )(struct vcpu *v, intpte_t *p,
intpte_t new, mfn_t gmfn);
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2264,6 +2264,29 @@ void shadow_prepare_page_type_change(str
shadow_remove_all_shadows(d, page_to_mfn(page));
}
+/*
+ * Removes v->arch.paging.shadow.shadow_table[].
+ * Does all appropriate management/bookkeeping/refcounting/etc...
+ */
+static void sh_detach_old_tables(struct vcpu *v)
+{
+struct domain *d = v->domain;
+unsigned int i;
+
+
+ vcpu->arch.paging.shadow.shadow_table[]
+
+
+for ( i = 0; i < ARRAY_SIZE(v->arch.paging.shadow.shadow_table); ++i )
+{
+mfn_t smfn = pagetable_get_mfn(v->arch.paging.shadow.shadow_table[i]);
+
+if ( mfn_x(smfn) )
+sh_put_ref(d, smfn, 0);
+v->arch.paging.shadow.shadow_table[i] = pagetable_null();
+}
+}
+
/**/
static void sh_update_paging_modes(struct vcpu *v)
@@ -2312,7 +2335,7 @@ static void sh_update_paging_modes(struc
// First, tear down any old shadow tables held by this vcpu.
//
if ( v->arch.paging.mode )
-v->arch.paging.mode->shadow.detach_old_tables(v);
+sh_detach_old_tables(v);
#ifdef CONFIG_HVM
if ( is_hvm_domain(d) )
@@ -2700,7 +2723,7 @@ void shadow_vcpu_teardown(struct vcpu *v
if ( !paging_mode_shadow(d) || !v->arch.paging.mode )
goto out;
-v->arch.paging.mode->shadow.detach_old_tables(v);
+sh_detach_old_tables(v);
#ifdef CONFIG_HVM
if ( shadow_mode_external(d) )
{
@@ -2935,7 +2958,7 @@ static int shadow_one_bit_disable(struct
for_each_vcpu(d, v)
{
if ( v->arch.paging.mode )
-v->arch.paging.mode->shadow.detach_old_tables(v);
+sh_detach_old_tables(v);
if ( !(v->arch.flags & TF_kernel_mode) )
make_cr3(v, pagetable_get_mfn(v->arch.guest_table_user));
else
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3207,30 +3207,6 @@ sh_update_linear_entries(struct vcpu *v)
sh_flush_local(d);
}
-
-/*
- * Removes v->arch.paging.shadow.shadow_table[].
- * Does all appropriate management/bookkeeping/refcounting/etc...
- */
-static void cf_check sh_detach_old_tables(struct vcpu *v)
-{
-struct domain *d = v->domain;
-mfn_t smfn;
-unsigned int i;
-
-
- vcpu->arch.paging.shadow.shadow_table[]
-
-
-for_each_shadow_table(v, i)
-{
-smfn = pagetable_get_mfn(v->arch.paging.shadow.shadow_table[i]);
-if ( mfn_x(smfn) )
-sh_put_ref(d, smfn, 0);
-v->arch.paging.shadow.shadow_table[i] = pagetable_null();
-}
-}
-
static void cf_check sh_update_cr3(struct vcpu *v, int do_locking, bool
noflush)
/* Updates vcpu->arch.cr3 after the guest has changed CR3.
* Paravirtual guests should set v->arch.guest_table (and guest_table_user,
@@ -4211,7 +4187,6 @@ const struct paging_mode sh_paging_mode
.update_paging_modes = shadow_update_paging_modes,
.flush_tlb = shadow_flush_tlb,
.guest_levels = GUEST_PAGING_LEVELS,
-.shadow.detach_old_tables = sh_detach_old_tables,
#ifdef CONFIG_PV
.shadow.write_guest_entry = sh_write_guest_entry,
.shadow.cmpxchg_guest_entry= sh_cmpxchg_guest_entry,
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -236,7 +236,6 @@ static inline shadow_l4e_t shadow_l4e_fr
#define sh_unhook_pae_mappings INTERNAL_NAME(sh_unhook_pae_mappings)
#define sh_unhook_64b_mappings INTERNAL_NAME(sh_unhook_64b_mappings)
#define sh_paging_mode INTERNAL_NAME(sh_paging_mode)
-#define sh_detach_old_tables INTERNAL_NAME(sh_detach_old_tables)
#define sh_audit_l1_table INTERNAL_NAME(sh_audit_l1_table)
#define sh_audit_fl1_table INTERNAL_NAME(sh_audit_fl1_table)
#define sh_audit_l2_table INTERNAL_NAME(sh_audit_l2_table)
[PATCH v2 9/9] x86/shadow: harden shadow_size()
Make HVM=y release build behavior prone against array overrun, by
(ab)using array_access_nospec(). This is in particular to guard against
e.g. SH_type_unused making it here unintentionally.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -27,6 +27,7 @@
// been included...
#include
#include
+#include
#include
#include
#include
@@ -368,7 +369,7 @@ shadow_size(unsigned int shadow_type)
{
#ifdef CONFIG_HVM
ASSERT(shadow_type < ARRAY_SIZE(sh_type_to_size));
-return sh_type_to_size[shadow_type];
+return array_access_nospec(sh_type_to_size, shadow_type);
#else
ASSERT(shadow_type < SH_type_unused);
return shadow_type != SH_type_none;
Re: [PATCH 14/22] x86/domain_page: remove the fast paths when mfn is not in the directmap
On 16.12.2022 12:48, Julien Grall wrote: > From: Hongyan Xia > > When mfn is not in direct map, never use mfn_to_virt for any mappings. > > We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with > arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The > extra comparison in arch_mfns_in_direct_map() looks different but because > DIRECTMAP_VIRT_END is always higher, it does not make any difference. > > Lastly, domain_page_map_to_mfn() needs to gain to a special case for > the PMAP. > > Signed-off-by: Hongyan Xia > Signed-off-by: Julien Grall This looks plausible, but cannot really be fully judged upon before the mapcache_current_vcpu() aspects pointed out earlier have been sorted. As to using pmap - assuming you've done an audit and the number of simultaneous mappings that can be in use can be proven to not exceed the number of slots available, can you please say so in the description? I have to admit though that I'm wary - this isn't a per-CPU number of slots aiui, but a global one. But then you also have a BUG_ON() there restricting the use to early boot. The reasoning for this is also missing (and might address my concern). Jan
Re: [PATCH 15/22] xen/page_alloc: add a path for xenheap when there is no direct map
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> When there is not an always-mapped direct map, xenheap allocations need
> to be mapped and unmapped on-demand.
Hmm, that's still putting mappings in the directmap, which I thought we
mean to be doing away with. If that's just a temporary step, then please
say so here.
> I have left the call to map_pages_to_xen() and destroy_xen_mappings()
> in the split heap for now. I am not entirely convinced this is necessary
> because in that setup only the xenheap would be always mapped and
> this doesn't contain any guest memory (aside the grant-table).
> So map/unmapping for every allocation seems unnecessary.
But if you're unmapping, that heap won't be "always mapped" anymore. So
why would it need mapping initially?
> Changes since Hongyan's version:
> * Rebase
> * Fix indentation in alloc_xenheap_pages()
Looks like you did in one of the two instances only, as ...
> @@ -2230,17 +2231,36 @@ void *alloc_xenheap_pages(unsigned int order,
> unsigned int memflags)
> if ( unlikely(pg == NULL) )
> return NULL;
>
> +ret = page_to_virt(pg);
> +
> +if ( !arch_has_directmap() &&
> + map_pages_to_xen((unsigned long)ret, page_to_mfn(pg), 1UL << order,
> + PAGE_HYPERVISOR) )
> +{
> +/* Failed to map xenheap pages. */
> +free_heap_pages(pg, order, false);
> +return NULL;
> +}
... this looks wrong.
An important aspect here is that to be sure of no recursion,
map_pages_to_xen() and destroy_xen_mappings() may no longer use Xen
heap pages. May be worth saying explicitly in the description (I can't
think of a good place in code where such a comment could be put _and_
be likely to be noticed at the right point in time).
> void free_xenheap_pages(void *v, unsigned int order)
> {
> +unsigned long va = (unsigned long)v & PAGE_MASK;
> +
> ASSERT_ALLOC_CONTEXT();
>
> if ( v == NULL )
> return;
>
> +if ( !arch_has_directmap() &&
> + destroy_xen_mappings(va, va + (1UL << (order + PAGE_SHIFT))) )
> +dprintk(XENLOG_WARNING,
> +"Error while destroying xenheap mappings at %p, order %u\n",
> +v, order);
Doesn't failure here mean (intended) security henceforth isn't guaranteed
anymore? If so, a mere dprintk() can't really be sufficient to "handle"
the error.
Jan
[PATCH v2] x86/ucode/AMD: apply the patch early on every logical thread
The original issue has been reported on AMD Bulldozer-based CPUs where
ucode loading loses the LWP feature bit in order to gain the IBPB bit.
LWP disabling is per-SMT/CMT core modification and needs to happen on
each sibling thread despite the shared microcode engine. Otherwise,
logical CPUs will end up with different cpuid capabilities.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216211
Guests running under Xen happen to be not affected because of levelling
logic for the feature masking/override MSRs which causes the LWP bit to
fall out and hides the issue. The latest recommendation from AMD, after
discussing this bug, is to load ucode on every logical CPU.
In Linux kernel this issue has been addressed by e7ad18d1169c
("x86/microcode/AMD: Apply the patch early on every logical thread").
Follow the same approach in Xen.
Introduce SAME_UCODE match result and use it for early AMD ucode
loading. Late loading is still performed only on the first of SMT/CMT
siblings and only if a newer ucode revision has been provided (unless
allow_same option is specified).
Intel's side of things is modified for consistency but provides no
functional change.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Expanded the commit message with the levelling section
- Adjusted comment for OLD_UCODE
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
---
xen/arch/x86/cpu/microcode/amd.c | 16 +---
xen/arch/x86/cpu/microcode/intel.c | 9 +++--
xen/arch/x86/cpu/microcode/private.h | 3 ++-
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 4b097187a0..96db10a2e0 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -176,8 +176,13 @@ static enum microcode_match_result compare_revisions(
if ( new_rev > old_rev )
return NEW_UCODE;
-if ( opt_ucode_allow_same && new_rev == old_rev )
-return NEW_UCODE;
+if ( new_rev == old_rev )
+{
+if ( opt_ucode_allow_same )
+return NEW_UCODE;
+else
+return SAME_UCODE;
+}
return OLD_UCODE;
}
@@ -220,8 +225,13 @@ static int cf_check apply_microcode(const struct
microcode_patch *patch)
unsigned int cpu = smp_processor_id();
struct cpu_signature *sig = &per_cpu(cpu_sig, cpu);
uint32_t rev, old_rev = sig->rev;
+enum microcode_match_result result = microcode_fits(patch);
-if ( microcode_fits(patch) != NEW_UCODE )
+/*
+ * Allow application of the same revision to pick up SMT-specific changes
+ * even if the revision of the other SMT thread is already up-to-date.
+ */
+if ( result != NEW_UCODE && result != SAME_UCODE )
return -EINVAL;
if ( check_final_patch_levels(sig) )
diff --git a/xen/arch/x86/cpu/microcode/intel.c
b/xen/arch/x86/cpu/microcode/intel.c
index f7fec4b4ed..59a99eee4e 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -232,8 +232,13 @@ static enum microcode_match_result compare_revisions(
if ( new_rev > old_rev )
return NEW_UCODE;
-if ( opt_ucode_allow_same && new_rev == old_rev )
-return NEW_UCODE;
+if ( new_rev == old_rev )
+{
+if ( opt_ucode_allow_same )
+return NEW_UCODE;
+else
+return SAME_UCODE;
+}
/*
* Treat pre-production as always applicable - anyone using pre-production
diff --git a/xen/arch/x86/cpu/microcode/private.h
b/xen/arch/x86/cpu/microcode/private.h
index 73b095d5bf..626aeb4d08 100644
--- a/xen/arch/x86/cpu/microcode/private.h
+++ b/xen/arch/x86/cpu/microcode/private.h
@@ -6,7 +6,8 @@
extern bool opt_ucode_allow_same;
enum microcode_match_result {
-OLD_UCODE, /* signature matched, but revision id is older or equal */
+OLD_UCODE, /* signature matched, but revision id is older */
+SAME_UCODE, /* signature matched, but revision id is the same */
NEW_UCODE, /* signature matched, but revision id is newer */
MIS_UCODE, /* signature mismatched */
};
--
2.17.1
[libvirt test] 175718: tolerable FAIL - PUSHED
flight 175718 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/175718/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175684 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeatfail like 175684 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175684 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175684 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-xsm 15 migrate-support-checkfail never pass test-amd64-i386-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 a5738ab74c2ab449522ddf661808262fc92e28d7 baseline version: libvirt 49ff47269b71a762ca5de4595f6ec915043e05ce Last test of basis 175684 2023-01-10 04:18:53 Z1 days Testing same since 175718 2023-01-11 04:20:41 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrangé Jiri Denemark Laine Stump Martin Kletzander 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 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs,
Re: [PATCH 16/22] x86/setup: leave early boot slightly earlier
On 16.12.2022 12:48, Julien Grall wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1648,6 +1648,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>
> numa_initmem_init(0, raw_max_page);
>
> +/*
> + * When we do not have a direct map, memory for metadata of heap nodes in
> + * init_node_heap() is allocated from xenheap, which needs to be mapped
> and
> + * unmapped on demand. However, we cannot just take memory from the boot
> + * allocator to create the PTEs while we are passing memory to the heap
> + * allocator during end_boot_allocator().
> + *
> + * To solve this race, we need to leave early boot before
> + * end_boot_allocator() so that Xen PTE pages are allocated from the heap
> + * instead of the boot allocator. We can do this because the metadata for
> + * the 1st node is statically allocated, and by the time we need memory
> to
> + * create mappings for the 2nd node, we already have enough memory in the
> + * heap allocator in the 1st node.
> + */
Is this "enough" guaranteed, or merely a hope (and true in the common case,
but maybe not when the 1st node ends up having very little memory)?
> +system_state = SYS_STATE_boot;
> +
> if ( max_page - 1 > virt_to_mfn(HYPERVISOR_VIRT_END - 1) )
> {
> unsigned long limit = virt_to_mfn(HYPERVISOR_VIRT_END - 1);
> @@ -1677,8 +1693,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> else
> end_boot_allocator();
>
> -system_state = SYS_STATE_boot;
I'm afraid I don't view this as viable - there are assumptions not just in
the page table allocation functions that SYS_STATE_boot (or higher) means
that end_boot_allocator() has run (e.g. acpi_os_map_memory()). You also do
this for x86 only. I think system_state wants leaving alone here, and an
arch specific approach wants creating for the page table allocation you
talk of.
Jan
[RFC PATCH 1/8] xen/arm: enable SVE extension for Xen
Enable Xen to handle the SVE extension, add code in cpufeature module
to handle ZCR SVE register, disable trapping SVE feature on system
boot, it will be restored later on vcpu creation and running.
While there, correct coding style for the comment on coprocessor
trapping.
Change the KConfig entry to make ARM64_SVE symbol selectable, by
default it will be not selected.
Create sve module and sve_asm.S that contains assembly routines for
the SVE feature, this code is inspired from linux and it uses
instruction encoding to be compatible with compilers that does not
support SVE.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/Kconfig | 3 +-
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/cpufeature.c | 7 ++--
xen/arch/arm/arm64/sve.c | 38 +++
xen/arch/arm/arm64/sve_asm.S | 48
xen/arch/arm/cpufeature.c| 6 ++-
xen/arch/arm/domain.c| 4 ++
xen/arch/arm/include/asm/arm64/sve.h | 43 +
xen/arch/arm/include/asm/arm64/sysregs.h | 1 +
xen/arch/arm/include/asm/cpufeature.h| 14 +++
xen/arch/arm/include/asm/domain.h| 1 +
xen/arch/arm/include/asm/processor.h | 2 +
xen/arch/arm/setup.c | 5 ++-
xen/arch/arm/traps.c | 34 -
14 files changed, 188 insertions(+), 19 deletions(-)
create mode 100644 xen/arch/arm/arm64/sve.c
create mode 100644 xen/arch/arm/arm64/sve_asm.S
create mode 100644 xen/arch/arm/include/asm/arm64/sve.h
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 239d3aed3c7f..2a5151f3c718 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -112,11 +112,10 @@ config ARM64_PTR_AUTH
This feature is not supported in Xen.
config ARM64_SVE
- def_bool n
+ bool "Enable Scalar Vector Extension support" if EXPERT
depends on ARM_64
help
Scalar Vector Extension support.
- This feature is not supported in Xen.
config ARM64_MTE
def_bool n
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 6d507da0d44d..1d59c3b0ec89 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -12,6 +12,7 @@ obj-y += insn.o
obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-y += smc.o
obj-y += smpboot.o
+obj-$(CONFIG_ARM64_SVE) += sve.o sve_asm.o
obj-y += traps.o
obj-y += vfp.o
obj-y += vsysreg.o
diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
index d9039d37b2d1..b4656ff4d80f 100644
--- a/xen/arch/arm/arm64/cpufeature.c
+++ b/xen/arch/arm/arm64/cpufeature.c
@@ -455,15 +455,11 @@ static const struct arm64_ftr_bits ftr_id_dfr1[] = {
ARM64_FTR_END,
};
-#if 0
-/* TODO: use this to sanitize SVE once we support it */
-
static const struct arm64_ftr_bits ftr_zcr[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
ZCR_ELx_LEN_SHIFT, ZCR_ELx_LEN_SIZE, 0),/* LEN */
ARM64_FTR_END,
};
-#endif
/*
* Common ftr bits for a 32bit register with all hidden, strict
@@ -603,6 +599,9 @@ void update_system_features(const struct cpuinfo_arm *new)
SANITIZE_ID_REG(zfr64, 0, aa64zfr0);
+ if ( cpu_has_sve )
+ SANITIZE_REG(zcr64, 0, zcr);
+
/*
* Comment from Linux:
* Userspace may perform DC ZVA instructions. Mismatched block sizes
diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
new file mode 100644
index ..326389278292
--- /dev/null
+++ b/xen/arch/arm/arm64/sve.c
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Arm SVE feature code
+ *
+ * Copyright (C) 2022 ARM Ltd.
+ */
+
+#include
+#include
+#include
+
+extern unsigned int sve_get_hw_vl(void);
+
+register_t compute_max_zcr(void)
+{
+register_t zcr = vl_to_zcr(SVE_VL_MAX_BITS);
+unsigned int hw_vl;
+
+/*
+ * Set the maximum SVE vector length, doing that we will know the VL
+ * supported by the platform, calling sve_get_hw_vl()
+ */
+WRITE_SYSREG(zcr, ZCR_EL2);
+
+/*
+ * Read the maximum VL, which could be lower than what we imposed before,
+ * hw_vl contains VL in bytes, multiply it by 8 to use vl_to_zcr() later
+ */
+hw_vl = sve_get_hw_vl() * 8U;
+
+return vl_to_zcr(hw_vl);
+}
+
+/* Takes a vector length in bits and returns the ZCR_ELx encoding */
+register_t vl_to_zcr(uint16_t vl)
+{
+return ((vl / SVE_VL_MULTIPLE_VAL) - 1U) & ZCR_ELx_LEN_MASK;
+}
diff --git a/xen/arch/arm/arm64/sve_asm.S b/xen/arch/arm/arm64/sve_asm.S
new file mode 100644
index ..4d1549344733
--- /dev/null
+++ b/xen/arch/arm/arm64/sve_asm.S
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Arm SVE assembly routines
+ *
+ * Copyright (C) 2022 ARM Ltd.
+ *
+ * Some macros and instruction encoding in this file are taken from linux
6.1.1,
+ * file arch/arm64/inc
[RFC PATCH 0/8] SVE feature for arm guests
This serie is introducing the possibility for Dom0 and DomU guests to use sve/sve2 instructions. SVE feature introduces new instruction and registers to improve performances on floating point operations. The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and when available the ID_AA64ZFR0_EL1 register provides additional information about the implemented version and other SVE feature. New registers added by the SVE feature are Z0-Z31, P0-P15, FFR, ZCR_ELx. Z0-Z31 are scalable vector register whose size is implementation defined and goes from 128 bits to maximum 2048, the term vector length will be used to refer to this quantity. P0-P15 are predicate registers and the size is the vector length divided by 8, same size is the FFR (First Fault Register). ZCR_ELx is a register that can control and restrict the maximum vector length used by the exception level and all the lower exception levels, so for example EL3 can restrict the vector length usable by EL3,2,1,0. The platform has a maximum implemented vector length, so for every value written in ZCR register, if this value is above the implemented length, then the lower value will be used. The RDVL instruction can be used to check what vector length is the HW using after setting ZCR. For an SVE guest, the V0-V31 registers are part of the Z0-Z31, so there is no need to save them separately, saving Z0-Z31 will save implicitly also V0-V31. SVE usage can be trapped using a flag in CPTR_EL2, hence in this serie the register is added to the domain state, to be able to trap only the guests that are not allowed to use SVE. This serie is introducing a command line parameter to enable Dom0 to use SVE and to set its maximum vector length that by default is 0 which means the guest is not allowed to use SVE. Values from 128 to 2048 mean the guest can use SVE with the selected value used as maximum allowed vector length (which could be lower if the implemented one is lower). For DomUs, an XL parameter with the same way of use is introduced and a dom0less DTB binding is created. The context switch is the most critical part because there can be big registers to be saved, in this serie an easy approach is used and the context is saved/restored every time for the guests that are allowed to use SVE. Luca Fancellu (8): xen/arm: enable SVE extension for Xen xen/arm: add sve_vl_bits field to domain xen/arm: Expose SVE feature to the guest xen/arm: add SVE exception class handling arm/sve: save/restore SVE context switch xen/arm: enable Dom0 to use SVE feature xen/tools: add sve parameter in XL configuration xen/arm: add sve property for dom0less domUs docs/man/xl.cfg.5.pod.in | 11 ++ docs/misc/arm/device-tree/booting.txt| 7 + docs/misc/xen-command-line.pandoc| 12 ++ tools/golang/xenlight/helpers.gen.go | 2 + tools/golang/xenlight/types.gen.go | 1 + tools/include/libxl.h| 5 + tools/libs/light/libxl_arm.c | 2 + tools/libs/light/libxl_types.idl | 1 + tools/xl/xl_parse.c | 10 ++ xen/arch/arm/Kconfig | 3 +- xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/cpufeature.c | 7 +- xen/arch/arm/arm64/sve.c | 104 + xen/arch/arm/arm64/sve_asm.S | 189 +++ xen/arch/arm/arm64/vfp.c | 79 ++ xen/arch/arm/arm64/vsysreg.c | 39 - xen/arch/arm/cpufeature.c| 6 +- xen/arch/arm/domain.c| 61 xen/arch/arm/domain_build.c | 11 ++ xen/arch/arm/include/asm/arm64/sve.h | 72 + xen/arch/arm/include/asm/arm64/sysregs.h | 4 + xen/arch/arm/include/asm/arm64/vfp.h | 10 ++ xen/arch/arm/include/asm/cpufeature.h| 14 ++ xen/arch/arm/include/asm/domain.h| 8 + xen/arch/arm/include/asm/processor.h | 3 + xen/arch/arm/setup.c | 5 +- xen/arch/arm/traps.c | 46 -- xen/include/public/arch-arm.h| 2 + xen/include/public/domctl.h | 2 +- 29 files changed, 661 insertions(+), 56 deletions(-) create mode 100644 xen/arch/arm/arm64/sve.c create mode 100644 xen/arch/arm/arm64/sve_asm.S create mode 100644 xen/arch/arm/include/asm/arm64/sve.h -- 2.17.1
[RFC PATCH 5/8] arm/sve: save/restore SVE context switch
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain and how many bits
are supported by the platform.
Save P0-15 whose length is maximum 256 bits each, in this case the
memory used is from the fpregs field in struct vfp_state,
because V0-31 are part of Z0-31 and this space would have been
unused for SVE domain otherwise.
Create zcr_el1 field in arch_vcpu and save/restore ZCR_EL1 value
on context switch.
Remove headers from sve.c that are already included using
xen/sched.h.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/arm64/sve.c | 58 +-
xen/arch/arm/arm64/sve_asm.S | 141 +++
xen/arch/arm/arm64/vfp.c | 79 +++--
xen/arch/arm/domain.c| 12 ++
xen/arch/arm/include/asm/arm64/sve.h | 13 +++
xen/arch/arm/include/asm/arm64/sysregs.h | 3 +
xen/arch/arm/include/asm/arm64/vfp.h | 10 ++
xen/arch/arm/include/asm/domain.h| 1 +
8 files changed, 280 insertions(+), 37 deletions(-)
diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
index b7695834f4ba..c7b325700fe4 100644
--- a/xen/arch/arm/arm64/sve.c
+++ b/xen/arch/arm/arm64/sve.c
@@ -5,12 +5,29 @@
* Copyright (C) 2022 ARM Ltd.
*/
-#include
-#include
+#include
+#include
#include
-#include
extern unsigned int sve_get_hw_vl(void);
+extern void sve_save_ctx(uint64_t *sve_ctx, uint64_t *pregs, int save_ffr);
+extern void sve_load_ctx(uint64_t const *sve_ctx, uint64_t const *pregs,
+ int restore_ffr);
+
+static inline uint16_t sve_zreg_ctx_size(uint16_t vl)
+{
+/*
+ * Z0-31 registers size in bytes is computed from VL that is in bits, so VL
+ * in bytes is VL/8.
+ */
+return (vl / 8U) * 32U;
+}
+
+static inline uint16_t sve_ffrreg_ctx_size(uint16_t vl)
+{
+/* FFR register size is VL/8, which is in bytes (VL/8)/8 */
+return (vl / 64U);
+}
register_t compute_max_zcr(void)
{
@@ -45,3 +62,38 @@ uint16_t get_sys_vl_len(void)
return ((system_cpuinfo.zcr64.bits[0] & ZCR_ELx_LEN_MASK) + 1U) *
SVE_VL_MULTIPLE_VAL;
}
+
+int sve_context_init(struct vcpu *v)
+{
+uint64_t *ctx = _xzalloc(sve_zreg_ctx_size(v->domain->arch.sve_vl_bits) +
+ sve_ffrreg_ctx_size(v->domain->arch.sve_vl_bits),
+ L1_CACHE_BYTES);
+
+if ( !ctx )
+return -ENOMEM;
+
+v->arch.vfp.sve_context = ctx;
+
+return 0;
+}
+
+void sve_context_free(struct vcpu *v)
+{
+xfree(v->arch.vfp.sve_context);
+}
+
+void sve_save_state(struct vcpu *v)
+{
+uint64_t *sve_ctx_zreg_end = v->arch.vfp.sve_context +
+(sve_zreg_ctx_size(v->domain->arch.sve_vl_bits) /
sizeof(uint64_t));
+
+sve_save_ctx(sve_ctx_zreg_end, v->arch.vfp.fpregs, 1);
+}
+
+void sve_restore_state(struct vcpu *v)
+{
+uint64_t *sve_ctx_zreg_end = v->arch.vfp.sve_context +
+(sve_zreg_ctx_size(v->domain->arch.sve_vl_bits) /
sizeof(uint64_t));
+
+sve_load_ctx(sve_ctx_zreg_end, v->arch.vfp.fpregs, 1);
+}
diff --git a/xen/arch/arm/arm64/sve_asm.S b/xen/arch/arm/arm64/sve_asm.S
index 4d1549344733..8c37d7bc95d5 100644
--- a/xen/arch/arm/arm64/sve_asm.S
+++ b/xen/arch/arm/arm64/sve_asm.S
@@ -17,6 +17,18 @@
.endif
.endm
+.macro _sve_check_zreg znr
+.if (\znr) < 0 || (\znr) > 31
+.error "Bad Scalable Vector Extension vector register number \znr."
+.endif
+.endm
+
+.macro _sve_check_preg pnr
+.if (\pnr) < 0 || (\pnr) > 15
+.error "Bad Scalable Vector Extension predicate register number \pnr."
+.endif
+.endm
+
.macro _check_num n, min, max
.if (\n) < (\min) || (\n) > (\max)
.error "Number \n out of range [\min,\max]"
@@ -26,6 +38,54 @@
/* SVE instruction encodings for non-SVE-capable assemblers */
/* (pre binutils 2.28, all kernel capable clang versions support SVE) */
+/* STR (vector): STR Z\nz, [X\nxbase, #\offset, MUL VL] */
+.macro _sve_str_v nz, nxbase, offset=0
+_sve_check_zreg \nz
+_check_general_reg \nxbase
+_check_num (\offset), -0x100, 0xff
+.inst 0xe5804000\
+| (\nz) \
+| ((\nxbase) << 5) \
+| (((\offset) & 7) << 10) \
+| (((\offset) & 0x1f8) << 13)
+.endm
+
+/* LDR (vector): LDR Z\nz, [X\nxbase, #\offset, MUL VL] */
+.macro _sve_ldr_v nz, nxbase, offset=0
+_sve_check_zreg \nz
+_check_general_reg \nxbase
+_check_num (\offset), -0x100, 0xff
+.inst 0x85804000\
+| (\nz) \
+| ((\nxbase) << 5) \
+| (((\offset) & 7) << 10) \
+| (((\offset) & 0x1f8) << 13)
+.endm
+
+/* STR (predicate): STR P\np, [X\nxbase, #\offset, MUL VL] */
+.macro _sve_str_p np, nxbase, offset=0
+_sve_check_preg \np
[RFC PATCH 2/8] xen/arm: add sve_vl_bits field to domain
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and the number of SVE register bits that are allowed
for this domain.
The field is used also to allow or forbid a domain to use SVE,
because a value equal to zero means the guest is not allowed to
use the feature.
When the guest is allowed to use SVE, the zcr_el2 register is
updated on context switch to restict the domain on the allowed
number of bits chosen, this value is the minimum among the chosen
value and the platform supported value.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/arm64/sve.c | 9 ++
xen/arch/arm/domain.c| 45
xen/arch/arm/include/asm/arm64/sve.h | 12
xen/arch/arm/include/asm/domain.h| 6
xen/include/public/arch-arm.h| 2 ++
xen/include/public/domctl.h | 2 +-
6 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
index 326389278292..b7695834f4ba 100644
--- a/xen/arch/arm/arm64/sve.c
+++ b/xen/arch/arm/arm64/sve.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
@@ -36,3 +37,11 @@ register_t vl_to_zcr(uint16_t vl)
{
return ((vl / SVE_VL_MULTIPLE_VAL) - 1U) & ZCR_ELx_LEN_MASK;
}
+
+/* Get the system sanitized value for VL in bits */
+uint16_t get_sys_vl_len(void)
+{
+/* ZCR_ELx len field is ((len+1) * 128) = vector bits length */
+return ((system_cpuinfo.zcr64.bits[0] & ZCR_ELx_LEN_MASK) + 1U) *
+SVE_VL_MULTIPLE_VAL;
+}
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8ea3843ea8e8..27f38729302b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,11 @@ static void ctxt_switch_to(struct vcpu *n)
WRITE_SYSREG(n->arch.cptr_el2, CPTR_EL2);
+#ifdef CONFIG_ARM64_SVE
+if ( is_sve_domain(n->domain) )
+WRITE_SYSREG(n->arch.zcr_el2, ZCR_EL2);
+#endif
+
/* VFP */
vfp_restore_state(n);
@@ -551,6 +557,11 @@ int arch_vcpu_create(struct vcpu *v)
v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
v->arch.cptr_el2 = get_default_cptr_flags();
+if ( is_sve_domain(v->domain) )
+{
+v->arch.cptr_el2 &= ~HCPTR_CP(8);
+v->arch.zcr_el2 = vl_to_zcr(v->domain->arch.sve_vl_bits);
+}
v->arch.hcr_el2 = get_default_hcr_flags();
@@ -595,6 +606,7 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
unsigned int max_vcpus;
unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu);
+unsigned int sve_vl_bits = config->arch.sve_vl_bits;
if ( (config->flags & ~flags_optional) != flags_required )
{
@@ -603,6 +615,36 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
return -EINVAL;
}
+/* Check feature flags */
+if ( sve_vl_bits > 0 ) {
+unsigned int zcr_max_bits;
+
+if ( !cpu_has_sve )
+{
+dprintk(XENLOG_INFO, "SVE is unsupported on this machine.\n");
+return -EINVAL;
+}
+else if ( !is_vl_valid(sve_vl_bits) )
+{
+dprintk(XENLOG_INFO, "Unsupported SVE vector length (%u)\n",
+sve_vl_bits);
+return -EINVAL;
+}
+/*
+ * get_sys_vl_len() is the common safe value among all cpus, so if the
+ * value specified by the user is above that value, use the safe value
+ * instead.
+ */
+zcr_max_bits = get_sys_vl_len();
+if ( sve_vl_bits > zcr_max_bits )
+{
+config->arch.sve_vl_bits = zcr_max_bits;
+dprintk(XENLOG_INFO,
+"SVE vector length lowered to %u, safe value among CPUs\n",
+zcr_max_bits);
+}
+}
+
/* The P2M table must always be shared between the CPU and the IOMMU */
if ( config->iommu_opts & XEN_DOMCTL_IOMMU_no_sharept )
{
@@ -745,6 +787,9 @@ int arch_domain_create(struct domain *d,
if ( (rc = domain_vpci_init(d)) != 0 )
goto fail;
+/* Copy sve_vl_bits to the domain configuration */
+d->arch.sve_vl_bits = config->arch.sve_vl_bits;
+
return 0;
fail:
diff --git a/xen/arch/arm/include/asm/arm64/sve.h
b/xen/arch/arm/include/asm/arm64/sve.h
index bd56e2f24230..f4a660e402ca 100644
--- a/xen/arch/arm/include/asm/arm64/sve.h
+++ b/xen/arch/arm/include/asm/arm64/sve.h
@@ -13,10 +13,17 @@
/* Vector length must be multiple of 128 */
#define SVE_VL_MULTIPLE_VAL (128U)
+static inline bool is_vl_valid(uint16_t vl)
+{
+/* SVE vector length is multiple of 128 and maximum 2048 */
+return ((vl % SVE_VL_MULTIPLE_VAL) == 0) && (vl <= SVE_VL_MAX_BITS);
+}
+
#ifdef CONFIG_ARM64_SVE
Re: [PATCH 17/22] x86/setup: vmap heap nodes when they are outside the direct map
On 16.12.2022 12:48, Julien Grall wrote:
> @@ -597,22 +598,43 @@ static unsigned long init_node_heap(int node, unsigned
> long mfn,
> needed = 0;
> }
> else if ( *use_tail && nr >= needed &&
> - arch_mfns_in_directmap(mfn + nr - needed, needed) &&
>(!xenheap_bits ||
> !((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
> {
> -_heap[node] = mfn_to_virt(mfn + nr - needed);
> -avail[node] = mfn_to_virt(mfn + nr - 1) +
> - PAGE_SIZE - sizeof(**avail) * NR_ZONES;
> -}
> -else if ( nr >= needed &&
By replacing these two well-formed lines with ...
> - arch_mfns_in_directmap(mfn, needed) &&
> +if ( arch_mfns_in_directmap(mfn + nr - needed, needed) )
> +{
> +_heap[node] = mfn_to_virt(mfn + nr - needed);
> +avail[node] = mfn_to_virt(mfn + nr - 1) +
> + PAGE_SIZE - sizeof(**avail) * NR_ZONES;
> +}
> +else
> +{
> +mfn_t needed_start = _mfn(mfn + nr - needed);
> +
> +_heap[node] = vmap_contig_pages(needed_start, needed);
> +BUG_ON(!_heap[node]);
> +avail[node] = (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
> + sizeof(**avail) * NR_ZONES;
> +}
> +} else if ( nr >= needed &&
... this, you're not only violating style here, but you also ...
>(!xenheap_bits ||
> !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
... break indentation for these two lines.
Jan
[RFC PATCH 7/8] xen/tools: add sve parameter in XL configuration
Add sve parameter in XL configuration to allow guests to use
SVE feature.
Signed-off-by: Luca Fancellu
---
docs/man/xl.cfg.5.pod.in | 11 +++
tools/golang/xenlight/helpers.gen.go | 2 ++
tools/golang/xenlight/types.gen.go | 1 +
tools/include/libxl.h| 5 +
tools/libs/light/libxl_arm.c | 2 ++
tools/libs/light/libxl_types.idl | 1 +
tools/xl/xl_parse.c | 10 ++
7 files changed, 32 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 024bceeb61b2..60412f7e32a0 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2903,6 +2903,17 @@ Currently, only the "sbsa_uart" model is supported for
ARM.
=back
+=item B
+
+To enable SVE, user must specify a number different from zero, maximum 2048 and
+multiple of 128. That value will be the maximum number of SVE registers bits
+that the hypervisor will impose to this guest. If the platform has a lower bits
+value, then the lower value will be chosen.
+A value equal to zero is the default and it means this guest is not allowed to
+use SVE.
+
+=back
+
=head3 x86
=over 4
diff --git a/tools/golang/xenlight/helpers.gen.go
b/tools/golang/xenlight/helpers.gen.go
index 3ac4938858f2..7f3b1e758b00 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1117,6 +1117,7 @@ default:
return fmt.Errorf("invalid union key '%v'", x.Type)}
x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version)
x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart)
+x.ArchArm.Sve = int(xc.arch_arm.sve)
if err := x.ArchX86.MsrRelaxed.fromC(&xc.arch_x86.msr_relaxed);err != nil {
return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err)
}
@@ -1602,6 +1603,7 @@ default:
return fmt.Errorf("invalid union key '%v'", x.Type)}
xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion)
xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart)
+xc.arch_arm.sve = C.int(x.Sve)
if err := x.ArchX86.MsrRelaxed.toC(&xc.arch_x86.msr_relaxed); err != nil {
return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err)
}
diff --git a/tools/golang/xenlight/types.gen.go
b/tools/golang/xenlight/types.gen.go
index 16ce879e3fb7..ed144325682e 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -537,6 +537,7 @@ TypeUnion DomainBuildInfoTypeUnion
ArchArm struct {
GicVersion GicVersion
Vuart VuartType
+Sve uint32
}
ArchX86 struct {
MsrRelaxed Defbool
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index d652895075a0..1057962e2e3f 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -278,6 +278,11 @@
*/
#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE 1
+/*
+ * libxl_domain_build_info has the arch_arm.sve field.
+ */
+#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SVE 1
+
/*
* LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing
* 'soft reset' for domains and there is 'soft_reset' shutdown reason
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index ddc7b2a15975..31f30e054bf4 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -211,6 +211,8 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
return ERROR_FAIL;
}
+config->arch.sve_vl_bits = d_config->b_info.arch_arm.sve;
+
return 0;
}
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 0cfad8508dbd..27e22523c7c2 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -663,6 +663,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
("vuart", libxl_vuart_type),
+ ("sve", uint32),
])),
("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
])),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 853e9f357a1a..49b2f28807e5 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2828,6 +2828,16 @@ skip_usbdev:
}
}
+if (!xlu_cfg_get_long (config, "sve", &l, 0)) {
+if (((l % 128) != 0) || (l > 2048)) {
+fprintf(stderr,
+"Invalid sve value: %ld. Needs to be <= 2048 and multiple"
+" of 128\n", l);
+exit(-ERROR_FAIL);
+}
+b_info->arch_arm.sve = l;
+}
+
parse_vkb_list(config, d_config);
d_config->virtios = NULL;
--
2.17.1
[RFC PATCH 4/8] xen/arm: add SVE exception class handling
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/processor.h | 1 +
xen/arch/arm/traps.c | 12
2 files changed, 13 insertions(+)
diff --git a/xen/arch/arm/include/asm/processor.h
b/xen/arch/arm/include/asm/processor.h
index 0e38926b94db..625c2bd0cd6c 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -426,6 +426,7 @@
#define HSR_EC_HVC640x16
#define HSR_EC_SMC640x17
#define HSR_EC_SYSREG 0x18
+#define HSR_EC_SVE 0x19
#endif
#define HSR_EC_INSTR_ABORT_LOWER_EL 0x20
#define HSR_EC_INSTR_ABORT_CURR_EL 0x21
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 45163fd3afb0..66e07197aea5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2168,6 +2168,13 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
perfc_incr(trap_sysreg);
do_sysreg(regs, hsr);
break;
+case HSR_EC_SVE:
+GUEST_BUG_ON(regs_mode_is_32bit(regs));
+gprintk(XENLOG_WARNING,
+"Domain id %d tried to use SVE while not allowed\n",
+current->domain->domain_id);
+inject_undef_exception(regs, hsr);
+break;
#endif
case HSR_EC_INSTR_ABORT_LOWER_EL:
@@ -2197,6 +2204,11 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs)
case HSR_EC_BRK:
do_trap_brk(regs, hsr);
break;
+case HSR_EC_SVE:
+/* An SVE exception is a bug somewhere in hypervisor code */
+printk("SVE trap at EL2.\n");
+do_unexpected_trap("Hypervisor", regs);
+break;
#endif
case HSR_EC_DATA_ABORT_CURR_EL:
case HSR_EC_INSTR_ABORT_CURR_EL:
--
2.17.1
[RFC PATCH 8/8] xen/arm: add sve property for dom0less domUs
Add a device tree property in the dom0less domU configuration
to enable the guest to use SVE.
Update documentation.
Signed-off-by: Luca Fancellu
---
docs/misc/arm/device-tree/booting.txt | 7 +++
xen/arch/arm/domain_build.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 3879340b5e0a..3d1ce652317e 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -193,6 +193,13 @@ with the following properties:
Optional. Handle to a xen,cpupool device tree node that identifies the
cpupool where the guest will be started at boot.
+- sve
+
+Optional. A number that, when above 0, enables SVE for this guest and sets
+its maximum SVE vector length. The default value is 0, that means this
+guest is not allowed to use SVE, the maximum value allowed is 2048, any
+other value must be multiple of 128.
+
- xen,enhanced
A string property. Possible property values are:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 48c3fdc28063..05b2bfc9195f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3959,6 +3959,13 @@ void __init create_domUs(void)
d_cfg.max_maptrack_frames = val;
}
+if ( dt_property_read_u32(node, "sve", &val) )
+{
+if ( val > UINT16_MAX )
+panic("sve property value (%"PRIu32") overflow\n", val);
+d_cfg.arch.sve_vl_bits = val;
+}
+
/*
* The variable max_init_domid is initialized with zero, so here it's
* very important to use the pre-increment operator to call
--
2.17.1
[RFC PATCH 3/8] xen/arm: Expose SVE feature to the guest
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/arm64/vsysreg.c | 39 ++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index 758750983c11..10048bb4d221 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -18,6 +18,7 @@
#include
+#include
#include
#include
#include
@@ -295,7 +296,28 @@ void do_sysreg(struct cpu_user_regs *regs,
GENERATE_TID3_INFO(MVFR0_EL1, mvfr, 0)
GENERATE_TID3_INFO(MVFR1_EL1, mvfr, 1)
GENERATE_TID3_INFO(MVFR2_EL1, mvfr, 2)
-GENERATE_TID3_INFO(ID_AA64PFR0_EL1, pfr64, 0)
+
+case HSR_SYSREG_ID_AA64PFR0_EL1:
+{
+register_t guest_reg_value = guest_cpuinfo.pfr64.bits[0];
+
+if ( is_sve_domain(v->domain) )
+{
+/* 4 is the SVE field width in id_aa64pfr0_el1 */
+uint64_t mask = GENMASK(ID_AA64PFR0_SVE_SHIFT + 4 - 1,
+ID_AA64PFR0_SVE_SHIFT);
+/* sysval is the sve field on the system */
+uint64_t sysval = cpuid_feature_extract_unsigned_field_width(
+system_cpuinfo.pfr64.bits[0],
+ID_AA64PFR0_SVE_SHIFT, 4);
+guest_reg_value &= ~mask;
+guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask;
+}
+
+return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+ guest_reg_value);
+}
+
GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
@@ -306,7 +328,20 @@ void do_sysreg(struct cpu_user_regs *regs,
GENERATE_TID3_INFO(ID_AA64MMFR2_EL1, mm64, 2)
GENERATE_TID3_INFO(ID_AA64AFR0_EL1, aux64, 0)
GENERATE_TID3_INFO(ID_AA64AFR1_EL1, aux64, 1)
-GENERATE_TID3_INFO(ID_AA64ZFR0_EL1, zfr64, 0)
+
+case HSR_SYSREG_ID_AA64ZFR0_EL1:
+{
+/*
+ * When the guest has the SVE feature enabled, the whole
id_aa64zfr0_el1
+ * needs to be exposed.
+ */
+register_t guest_reg_value = guest_cpuinfo.zfr64.bits[0];
+if ( is_sve_domain(v->domain) )
+guest_reg_value = system_cpuinfo.zfr64.bits[0];
+
+return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+ guest_reg_value);
+}
/*
* Those cases are catching all Reserved registers trapped by TID3 which
--
2.17.1
[RFC PATCH 6/8] xen/arm: enable Dom0 to use SVE feature
Add a command line parameter to allow Dom0 the use of SVE resources,
the command line parameter dom0_sve controls the feature on this
domain and sets the maximum SVE vector length for Dom0.
Signed-off-by: Luca Fancellu
---
docs/misc/xen-command-line.pandoc| 12
xen/arch/arm/arm64/sve.c | 5 +
xen/arch/arm/domain_build.c | 4
xen/arch/arm/include/asm/arm64/sve.h | 4
4 files changed, 25 insertions(+)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index 923910f553c5..940a96f4207c 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -995,6 +995,18 @@ restrictions set up here. Note that the values to be
specified here are
ACPI PXM ones, not Xen internal node numbers. `relaxed` sets up vCPU
affinities to prefer but be not limited to the specified node(s).
+### dom0_sve (arm)
+> `= `
+
+> Default: `0`
+
+Enable arm SVE usage for Dom0 domain and sets the maximum SVE vector length.
+Values above 0 means feature is enabled for Dom0, otherwise feature is
disabled.
+Possible values are from 0 to maximum 2048, being multiple of 128, that will be
+the maximum vector length.
+Please note that the specified value is a maximum allowed vector length, so if
+the platform supports only a lower value, the lower one will be chosen.
+
### dom0_vcpus_pin
> `= `
diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
index c7b325700fe4..9f8c5d21a59f 100644
--- a/xen/arch/arm/arm64/sve.c
+++ b/xen/arch/arm/arm64/sve.c
@@ -5,10 +5,15 @@
* Copyright (C) 2022 ARM Ltd.
*/
+#include
#include
#include
#include
+/* opt_dom0_sve: allow Dom0 to use SVE and set maximum vector length. */
+unsigned int __initdata opt_dom0_sve;
+integer_param("dom0_sve", opt_dom0_sve);
+
extern unsigned int sve_get_hw_vl(void);
extern void sve_save_ctx(uint64_t *sve_ctx, uint64_t *pregs, int save_ffr);
extern void sve_load_ctx(uint64_t const *sve_ctx, uint64_t const *pregs,
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 829cea8de84f..48c3fdc28063 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -4075,6 +4076,9 @@ void __init create_dom0(void)
if ( iommu_enabled )
dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+if ( opt_dom0_sve > 0 )
+dom0_cfg.arch.sve_vl_bits = opt_dom0_sve;
+
dom0 = domain_create(0, &dom0_cfg, CDF_privileged | CDF_directmap);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0\n");
diff --git a/xen/arch/arm/include/asm/arm64/sve.h
b/xen/arch/arm/include/asm/arm64/sve.h
index 28c31b329233..dc6e747cec9e 100644
--- a/xen/arch/arm/include/asm/arm64/sve.h
+++ b/xen/arch/arm/include/asm/arm64/sve.h
@@ -21,6 +21,8 @@ static inline bool is_vl_valid(uint16_t vl)
#ifdef CONFIG_ARM64_SVE
+extern unsigned int opt_dom0_sve;
+
register_t compute_max_zcr(void);
register_t vl_to_zcr(uint16_t vl);
uint16_t get_sys_vl_len(void);
@@ -31,6 +33,8 @@ void sve_restore_state(struct vcpu *v);
#else /* !CONFIG_ARM64_SVE */
+#define opt_dom0_sve (0)
+
static inline register_t compute_max_zcr(void)
{
return 0;
--
2.17.1
Re: [PATCH 18/22] x86/setup: do not create valid mappings when directmap=no
On 16.12.2022 12:48, Julien Grall wrote: > From: Hongyan Xia > > Create empty mappings in the second e820 pass. Also, destroy existing > direct map mappings created in the first pass. Could you remind me (perhaps say a word here) why these need creating then in the first place? Jan
Re: [PATCH v3 2/6] xen/riscv: introduce asm/types.h header file
On 1/11/23 15:17, Jan Beulich wrote:
On 11.01.2023 13:30, Xenia Ragiadakou wrote:
Could you please help me understand also
why __signed__ keyword is required when declaring __{u,s}?
I mean why __{u,s} cannot be declared using the signed type
specifier, just like {u,s}?
I'm afraid I can't, as this looks to have been (blindly?) imported
from Linux very, very long ago. Having put time in going through
our own history, I'm afraid I don't want to go further and see
whether I could spot the reason for you by going through Linux'es.
Sorry, I was not aiming to drag you (or anyone) into spotting why Linux
uses __signed__ when declaring __s. AfAIU these types are exported
and used in userspace and maybe the reason is to support building with
pre-standard C compilers.
I am just wondering why Xen, that is compiled with std=c99, uses
__signed__. If there is no reason, I think this difference between the
declarations of __{u,s} and {u,s} is misleading and confusing (to
me at least).
--
Xenia
Re: [PATCH v2 1/8] x86/iommu: introduce AMD-Vi and Intel VT-d Kconfig options
On 04.01.2023 09:44, Xenia Ragiadakou wrote: > Introduce two new Kconfig options, AMD_IOMMU and INTEL_IOMMU, to allow code > specific to each IOMMU technology to be separated and, when not required, > stripped. AMD_IOMMU will be used to enable IOMMU support for platforms that > implement the AMD I/O Virtualization Technology. INTEL_IOMMU will be used to > enable IOMMU support for platforms that implement the Intel Virtualization > Technology for Directed I/O. > > Since, at this point, disabling any of them would cause Xen to not compile, > the options are not visible to the user and are enabled by default if X86. > > Signed-off-by: Xenia Ragiadakou Reviewed-by: Jan Beulich
Re: [PATCH v2 2/8] x86/iommu: amd_iommu_perdev_intremap is AMD-Vi specific
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
> @@ -116,7 +115,11 @@ static int __init cf_check parse_iommu_param(const char
> *s)
> iommu_verbose = 1;
> }
> else if ( (val = parse_boolean("amd-iommu-perdev-intremap", s, ss))
> >= 0 )
> +#ifdef CONFIG_AMD_IOMMU
> amd_iommu_perdev_intremap = val;
> +#else
> +no_config_param("AMD_IOMMU", "amd-iommu-perdev-intremap", s, ss);
The string literal wants to be "iommu", I think. Please see other uses of
no_config_param().
Jan
Re: [PATCH v2 2/8] x86/iommu: amd_iommu_perdev_intremap is AMD-Vi specific
On 1/11/23 17:03, Jan Beulich wrote:
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
@@ -116,7 +115,11 @@ static int __init cf_check parse_iommu_param(const char *s)
iommu_verbose = 1;
}
else if ( (val = parse_boolean("amd-iommu-perdev-intremap", s, ss))
>= 0 )
+#ifdef CONFIG_AMD_IOMMU
amd_iommu_perdev_intremap = val;
+#else
+no_config_param("AMD_IOMMU", "amd-iommu-perdev-intremap", s, ss);
The string literal wants to be "iommu", I think. Please see other uses of
no_config_param().
Thanks for reviewing this. You are right. I will fix it.
--
Xenia
Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru
On 1/10/23 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)) {
>>
>> is changed to
>>
>> if (is_igd_vga_passthrough(&s->real_device) &&
>> s->r
[xen-unstable test] 175720: tolerable FAIL
flight 175720 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175720/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-i386 7 xen-install fail pass in 175714 test-amd64-i386-pair 10 xen-install/src_host fail pass in 175714 test-amd64-i386-xl-vhd 22 guest-start.2 fail pass in 175714 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175714 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175714 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175714 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175714 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175714 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175714 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175714 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175714 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175714 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175714 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175714 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175714 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-checkfail never pass test-armhf-ar
Re: [RFC PATCH 0/8] SVE feature for arm guests
Hi Luca, On 11/01/2023 14:38, Luca Fancellu wrote: This serie is introducing the possibility for Dom0 and DomU guests to use sve/sve2 instructions. SVE feature introduces new instruction and registers to improve performances on floating point operations. The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and when available the ID_AA64ZFR0_EL1 register provides additional information about the implemented version and other SVE feature. New registers added by the SVE feature are Z0-Z31, P0-P15, FFR, ZCR_ELx. Z0-Z31 are scalable vector register whose size is implementation defined and goes from 128 bits to maximum 2048, the term vector length will be used to refer to this quantity. P0-P15 are predicate registers and the size is the vector length divided by 8, same size is the FFR (First Fault Register). ZCR_ELx is a register that can control and restrict the maximum vector length used by the exception level and all the lower exception levels, so for example EL3 can restrict the vector length usable by EL3,2,1,0. The platform has a maximum implemented vector length, so for every value written in ZCR register, if this value is above the implemented length, then the lower value will be used. The RDVL instruction can be used to check what vector length is the HW using after setting ZCR. For an SVE guest, the V0-V31 registers are part of the Z0-Z31, so there is no need to save them separately, saving Z0-Z31 will save implicitly also V0-V31. SVE usage can be trapped using a flag in CPTR_EL2, hence in this serie the register is added to the domain state, to be able to trap only the guests that are not allowed to use SVE. This serie is introducing a command line parameter to enable Dom0 to use SVE and to set its maximum vector length that by default is 0 which means the guest is not allowed to use SVE. Values from 128 to 2048 mean the guest can use SVE with the selected value used as maximum allowed vector length (which could be lower if the implemented one is lower). For DomUs, an XL parameter with the same way of use is introduced and a dom0less DTB binding is created. The context switch is the most critical part because there can be big registers to be saved, in this serie an easy approach is used and the context is saved/restored every time for the guests that are allowed to use SVE. This would be OK for an initial approach. But I would be worry to officially support SVE because of the potential large impact on other users. What's the long term plan? Cheers, -- Julien Grall
[qemu-mainline test] 175725: regressions - FAIL
flight 175725 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175725/ 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
Re: [RFC PATCH 1/8] xen/arm: enable SVE extension for Xen
Hi Luca,
As this is an RFC, I will be mostly making general comments.
On 11/01/2023 14:38, Luca Fancellu wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 99577adb6c69..8ea3843ea8e8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -181,6 +181,8 @@ static void ctxt_switch_to(struct vcpu *n)
/* VGIC */
gic_restore_state(n);
+WRITE_SYSREG(n->arch.cptr_el2, CPTR_EL2);
Shouldn't this need an isb() afterwards do ensure that any previously
trapped will be accessible?
[...]
@@ -122,6 +137,7 @@ __initcall(update_serrors_cpu_caps);
void init_traps(void)
{
+register_t cptr_bits = get_default_cptr_flags();
/*
* Setup Hyp vector base. Note they might get updated with the
* branch predictor hardening.
@@ -135,17 +151,15 @@ void init_traps(void)
/* Trap CP15 c15 used for implementation defined registers */
WRITE_SYSREG(HSTR_T(15), HSTR_EL2);
-/* Trap all coprocessor registers (0-13) except cp10 and
- * cp11 for VFP.
- *
- * /!\ All coprocessors except cp10 and cp11 cannot be used in Xen.
- *
- * On ARM64 the TCPx bits which we set here (0..9,12,13) are all
- * RES1, i.e. they would trap whether we did this write or not.
+#ifdef CONFIG_ARM64_SVE
+/*
+ * Don't trap SVE now, Xen might need to access ZCR reg in cpufeature code,
+ * trapping again or not will be handled on vcpu creation/scheduling later
*/
Instead of enable by default at boot, can we try to enable/disable only
when this is strictly needed?
-WRITE_SYSREG((HCPTR_CP_MASK & ~(HCPTR_CP(10) | HCPTR_CP(11))) |
- HCPTR_TTA | HCPTR_TAM,
- CPTR_EL2);
+cptr_bits &= ~HCPTR_CP(8);
+#endif
+
+WRITE_SYSREG(cptr_bits, CPTR_EL2);
/*
* Configure HCR_EL2 with the bare minimum to run Xen until a guest
Cheers,
--
Julien Grall
Re: [RFC PATCH 2/8] xen/arm: add sve_vl_bits field to domain
Hi Luca,
On 11/01/2023 14:38, Luca Fancellu wrote:
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and the number of SVE register bits that are allowed
for this domain.
The field is used also to allow or forbid a domain to use SVE,
because a value equal to zero means the guest is not allowed to
use the feature.
When the guest is allowed to use SVE, the zcr_el2 register is
updated on context switch to restict the domain on the allowed
number of bits chosen, this value is the minimum among the chosen
value and the platform supported value.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/arm64/sve.c | 9 ++
xen/arch/arm/domain.c| 45
xen/arch/arm/include/asm/arm64/sve.h | 12
xen/arch/arm/include/asm/domain.h| 6
xen/include/public/arch-arm.h| 2 ++
xen/include/public/domctl.h | 2 +-
6 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
index 326389278292..b7695834f4ba 100644
--- a/xen/arch/arm/arm64/sve.c
+++ b/xen/arch/arm/arm64/sve.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
@@ -36,3 +37,11 @@ register_t vl_to_zcr(uint16_t vl)
{
return ((vl / SVE_VL_MULTIPLE_VAL) - 1U) & ZCR_ELx_LEN_MASK;
}
+
+/* Get the system sanitized value for VL in bits */
+uint16_t get_sys_vl_len(void)
+{
+/* ZCR_ELx len field is ((len+1) * 128) = vector bits length */
+return ((system_cpuinfo.zcr64.bits[0] & ZCR_ELx_LEN_MASK) + 1U) *
+SVE_VL_MULTIPLE_VAL;
+}
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8ea3843ea8e8..27f38729302b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,11 @@ static void ctxt_switch_to(struct vcpu *n)
WRITE_SYSREG(n->arch.cptr_el2, CPTR_EL2);
+#ifdef CONFIG_ARM64_SVE
+if ( is_sve_domain(n->domain) )
+WRITE_SYSREG(n->arch.zcr_el2, ZCR_EL2);
+#endif
I would actually expect that is_sve_domain() returns false when the SVE
is not enabled. So can we simply remove the #ifdef?
+
/* VFP */
vfp_restore_state(n);
@@ -551,6 +557,11 @@ int arch_vcpu_create(struct vcpu *v)
v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
v->arch.cptr_el2 = get_default_cptr_flags();
+if ( is_sve_domain(v->domain) )
+{
+v->arch.cptr_el2 &= ~HCPTR_CP(8);
+v->arch.zcr_el2 = vl_to_zcr(v->domain->arch.sve_vl_bits);
+}
v->arch.hcr_el2 = get_default_hcr_flags();
@@ -595,6 +606,7 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
unsigned int max_vcpus;
unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu |
XEN_DOMCTL_CDF_vpmu);
+unsigned int sve_vl_bits = config->arch.sve_vl_bits;
if ( (config->flags & ~flags_optional) != flags_required )
{
@@ -603,6 +615,36 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
return -EINVAL;
}
+/* Check feature flags */
+if ( sve_vl_bits > 0 ) {
+unsigned int zcr_max_bits;
+
+if ( !cpu_has_sve )
+{
+dprintk(XENLOG_INFO, "SVE is unsupported on this machine.\n");
+return -EINVAL;
+}
+else if ( !is_vl_valid(sve_vl_bits) )
+{
+dprintk(XENLOG_INFO, "Unsupported SVE vector length (%u)\n",
+sve_vl_bits);
+return -EINVAL;
+}
+/*
+ * get_sys_vl_len() is the common safe value among all cpus, so if the
+ * value specified by the user is above that value, use the safe value
+ * instead.
+ */
+zcr_max_bits = get_sys_vl_len();
+if ( sve_vl_bits > zcr_max_bits )
+{
+config->arch.sve_vl_bits = zcr_max_bits;
+dprintk(XENLOG_INFO,
+"SVE vector length lowered to %u, safe value among CPUs\n",
+zcr_max_bits);
+}
I don't think Xen should "downgrade" the value. Instead, this should be
the decision from the tools. So we want to find a different way to
reproduce the value (Andrew may have some ideas here as he was looking
at it).
+}
+
/* The P2M table must always be shared between the CPU and the IOMMU */
if ( config->iommu_opts & XEN_DOMCTL_IOMMU_no_sharept )
{
@@ -745,6 +787,9 @@ int arch_domain_create(struct domain *d,
if ( (rc = domain_vpci_init(d)) != 0 )
goto fail;
+/* Copy sve_vl_bits to the domain configuration */
+d->arch.sve_vl_bits = config->arch.sve_vl_bits;
+
return 0;
fail:
diff --git a/xen/arch/arm/include/asm/arm64/sve.h
b/xen/arch/arm/
Re: Xenalyze on ARM ( NXP S32G3 with Cortex-A53)
(+Stefano) On 10/01/2023 14:20, El Mesdadi Youssef ESK UILD7 wrote: 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. xentrace should work on upstream Xen. What did you version did you try? Can you also clarify the error you are seen? 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? Yes if you assign (or provide para-virtualized driver) the GPIO/LED/Can-Interface to the guest. * 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? I am confused, if you don't have network and an external sdcard, then you did you first put Xen on your system? In theory you could transfer the binary (using base64) via the serial console. But that's hackish. Instead, I would recommend to speak with the board vendor and ask them how you can upload your own software. * 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) xentrace will be your best bet. Otherwise, you will need to implement custom tracing. Cheers, -- Julien Grall
Re: [PATCH v2 04/19] tools/xenstore: remove all watches when a domain has stopped
Hi Juergen, On 11/01/2023 06:36, Juergen Gross wrote: On 20.12.22 20:01, Julien Grall wrote: 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. Thanks for the confirmation! You can add my reviewed-by: Reviewed-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v2 07/19] tools/xenstore: introduce dummy nodes for special watch paths
Hi Juergen,
On 11/01/2023 06:41, Juergen Gross wrote:
On 20.12.22 20:39, Julien Grall wrote:
+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.
That works for me. If it is always logged, then I guess this would need
to be a syslog message as well.
Cheers,
--
Julien Grall
Re: [PATCH v2 10/19] tools/xenstore: change per-domain node accounting interface
Hi Juergen, On 11/01/2023 08:59, Juergen Gross wrote: ... to make sure domain_nbentry_add() is not returning a negative value. Then it would not work. A good example imagine you have a transaction removing nodes from tree but not adding any. Then the "ret" would be negative. Meanwhile the nodes are also removed outside of the transaction. So the sum of "d->nbentry + ret" would be negative resulting to a failure here. Thanks for catching this. I think the correct way to handle this is to return max(d->nbentry + ret, 0) in domain_nbentry_add(). The value might be imprecise, but always >= 0 and never wrong outside of a transaction collision. I am bit confused with your proposal. If the return value is imprecise, then what's the point of returning max(...) instead of simply 0? Cheers, -- Julien Grall
Re: [PATCH v2 15/19] tools/xenstore: switch hashtable to use the talloc framework
Hi,
On 11/01/2023 09:27, Juergen Gross wrote:
On 20.12.22 22:50, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -115,47 +117,32 @@ hashtable_expand(struct hashtable *h)
if (h->primeindex == (prime_table_length - 1)) return 0;
newsize = primes[++(h->primeindex)];
- newtable = (struct entry **)calloc(newsize, sizeof(struct entry*));
- if (NULL != newtable)
+ newtable = talloc_realloc(h, h->table, struct entry *, newsize);
+ if (!newtable)
{
- /* This algorithm is not 'stable'. ie. it reverses the list
- * when it transfers entries between the tables */
- for (i = 0; i < h->tablelength; i++) {
- while (NULL != (e = h->table[i])) {
- h->table[i] = e->next;
- index = indexFor(newsize,e->h);
+ h->primeindex--;
+ return 0;
+ }
+
+ h->table = newtable;
+ memset(newtable + h->tablelength, 0,
+ (newsize - h->tablelength) * sizeof(*newtable));
+ for (i = 0; i < h->tablelength; i++) {
I understand this code is taken from the realloc path. However, isn't
this algorithm also not stable? If so, then I think we move the
comment here.
I'm fine with that, even if I don't see how it would matter. There is no
guarantee regarding the order of entries for a given index.
That's a fair point. Feel free to ignore my comment then :).
+ if (index == i)
+ {
+ pE = &(e->next);
+ }
+ else
+ {
+ *pE = e->next;
e->next = newtable[index];
newtable[index] = e;
}
}
- free(h->table);
- h->table = newtable;
- }
- /* Plan B: realloc instead */
- else
- {
- newtable = (struct entry **)
- realloc(h->table, newsize * sizeof(struct entry *));
- if (NULL == newtable) { (h->primeindex)--; return 0; }
- h->table = newtable;
- memset(newtable + h->tablelength, 0,
- (newsize - h->tablelength) * sizeof(*newtable));
- for (i = 0; i < h->tablelength; i++) {
- for (pE = &(newtable[i]), e = *pE; e != NULL; e = *pE) {
- index = indexFor(newsize,e->h);
- if (index == i)
- {
- pE = &(e->next);
- }
- else
- {
- *pE = e->next;
- e->next = newtable[index];
- newtable[index] = e;
- }
- }
- }
}
+
h->tablelength = newsize;
h->loadlimit = (unsigned int)
(((uint64_t)newsize * max_load_factor) / 100);
@@ -184,7 +171,7 @@ hashtable_insert(struct hashtable *h, void *k,
void *v)
* element may be ok. Next time we insert, we'll try
expanding again.*/
hashtable_expand(h);
}
- e = (struct entry *)calloc(1, sizeof(struct entry));
+ e = talloc_zero(h, struct entry);
if (NULL == e) { --(h->entrycount); return 0; } /*oom*/
e->h = hash(h,k);
index = indexFor(h->tablelength,e->h);
@@ -238,8 +225,8 @@ hashtable_remove(struct hashtable *h, void *k)
h->entrycount--;
v = e->v;
if (h->flags & HASHTABLE_FREE_KEY)
- free(e->k);
- free(e);
+ talloc_free(e->k);
+ talloc_free(e);
return v;
}
pE = &(e->next);
@@ -280,25 +267,20 @@ void
hashtable_destroy(struct hashtable *h)
{
unsigned int i;
- struct entry *e, *f;
+ struct entry *e;
struct entry **table = h->table;
for (i = 0; i < h->tablelength; i++)
{
- e = table[i];
- while (NULL != e)
+ for (e = table[i]; e; e = e->next)
{
- f = e;
- e = e->next;
if (h->flags & HASHTABLE_FREE_KEY)
- free(f->k);
+ talloc_free(e->k);
if (h->flags & HASHTABLE_FREE_VALUE)
- free(f->v);
- free(f);
AFAIU, the loop is reworked so you let talloc to free each element
with the parent. Using a while loop is definitely cleaner, but now you
will end up to have two separate loop for the elements.
There is a risk that the overall performance of hashtable_destroy()
will be worse as the data accessed in one loop may not fit in the
cache. So you will have to reload it on the second loop.
Therefore, I think it would be better to keep the loop as-is.
What about a completely different approach? I could make the key and value
talloc children of e when _inserting_ the element and the related flag is
set. This would reduce hashtable_destroy to a single talloc_free().
I am fine with that.
Cheers,
--
Julien Grall
[RFC PATCH] build: include/compat: figure out which other compat headers are needed
Some compat headers depends on other compat headers that may not have been generated due to config option. This would be a generic way to deal with deps, instead of headers-$(call or $(CONFIG_TRACEBUFFER),$(CONFIG_HVM)) += compat/trace.h This is just an RFC, as it only deals with "hvm_op.h" and nothing is done to have make regenerate the new file when needed. Signed-off-by: Anthony PERARD --- xen/include/Makefile | 23 +++ 1 file changed, 23 insertions(+) diff --git a/xen/include/Makefile b/xen/include/Makefile index 65be310eca..5e6de97841 100644 --- a/xen/include/Makefile +++ b/xen/include/Makefile @@ -34,6 +34,29 @@ headers-$(CONFIG_TRACEBUFFER) += compat/trace.h headers-$(CONFIG_XENOPROF) += compat/xenoprof.h headers-$(CONFIG_XSM_FLASK) += compat/xsm/flask_op.h +# Find dependencies of compat headers. +# e.g. hvm/hvm_op.h needs trace.h; but if CONFIG_TRACEBUFFER=n, then trace.h would be missing. +# +# Using sed to remove ".." from path because unsure if something else is available +# There's `realpath`, but maynot be available +# realpath --relative-to=. -mL compat/hvm/../trace.h -> compat/trace.h +# `make` also have macro for that $(abspath), only recent version. +# +# The $(CC) line to gen deps is derived from $(cmd_compat_i) +include $(obj)/.compat-header-deps.d +$(obj)/.compat-header-deps.d: include/public/hvm/hvm_op.h + $(CC) -MM -MF $@.tmp $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(XEN_CFLAGS)) $< + for f in $$(cat $@.tmp | sed -r '1s/^[^:]*: //; s/ \\$$//'); do \ + echo $$f; \ + done | sed -r \ + -e 's#.*/public#compat#; : p; s#/[^/]+/../#/#; t p; s#$$# \\#' \ + -e '1i headers-y-deps := \\' -e '$$a \ ' \ + > $@ + +headers-y-deps := $(filter-out compat/xen-compat.h,$(headers-y-deps)) +# Add compat header dependencies and eliminates duplicates +headers-y := $(sort $(headers-y) $(headers-y-deps)) + cppflags-y:= -include public/xen-compat.h -DXEN_GENERATING_COMPAT_HEADERS cppflags-$(CONFIG_X86)+= -m32 -- Anthony PERARD
[xen-unstable-smoke test] 175728: tolerable all pass - PUSHED
flight 175728 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175728/ 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 fd42170b152b19ff12121f3b63674e882c087849 baseline version: xen e66d450b6e0ffec635639df993ab43ce28b3383f Last test of basis 175721 2023-01-11 10:03:26 Z0 days Testing same since 175728 2023-01-11 18:00:27 Z0 days1 attempts People who touched revisions under test: Alistair Francis 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 e66d450b6e..fd42170b15 fd42170b152b19ff12121f3b63674e882c087849 -> smoke
Re: [PATCH v4 3/3] x86/vmx: implement Notify VM Exit
On 13/12/2022 4:31 pm, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index a0d5e8d6ab..3d7c471a3f 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1290,6 +1296,17 @@ static int construct_vmcs(struct vcpu *v)
> v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK
>| (paging_mode_hap(d) ? 0 : (1U << TRAP_page_fault))
>| (v->arch.fully_eager_fpu ? 0 : (1U << TRAP_no_device));
> +if ( cpu_has_vmx_notify_vm_exiting )
> +{
> +__vmwrite(NOTIFY_WINDOW, vm_notify_window);
> +/*
> + * Disable #AC and #DB interception: by using VM Notify Xen is
> + * guaranteed to get a VM exit even if the guest manages to lock the
> + * CPU.
> + */
> +v->arch.hvm.vmx.exception_bitmap &= ~((1U << TRAP_debug) |
> + (1U << TRAP_alignment_check));
> +}
> vmx_update_exception_bitmap(v);
>
> v->arch.hvm.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index dabf4a3552..b11578777a 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1428,10 +1428,19 @@ static void cf_check vmx_update_host_cr3(struct vcpu
> *v)
>
> void vmx_update_debug_state(struct vcpu *v)
> {
> +unsigned int mask = 1u << TRAP_int3;
> +
> +if ( !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
> +/*
> + * Only allow toggling TRAP_debug if notify VM exit is enabled, as
> + * unconditionally setting TRAP_debug is part of the XSA-156 fix.
> + */
> +mask |= 1u << TRAP_debug;
> +
> if ( v->arch.hvm.debug_state_latch )
> -v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
> +v->arch.hvm.vmx.exception_bitmap |= mask;
> else
> -v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
> +v->arch.hvm.vmx.exception_bitmap &= ~mask;
>
> vmx_vmcs_enter(v);
> vmx_update_exception_bitmap(v);
> @@ -4180,6 +4189,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> switch ( vector )
> {
> case TRAP_debug:
> +if ( cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
> +goto exit_and_crash;
This breaks GDBSX and introspection.
For XSA-156, we were forced to intercept #DB unilaterally for safety,
but both GDBSX and Introspection can optionally intercepting #DB for
logical reasons too.
i.e. we can legitimately end up here even on an system with VM Notify.
What I can't figure out is why made any reference to MTF. MTF has
absolutely nothing to do with TRAP_debug.
Furthermore, there's no CPU in practice that has VM Notify but lacks
MTF, so the head of vmx_update_debug_state() looks like dead code...
~Andrew
[qemu-mainline test] 175727: regressions - FAIL
flight 175727 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175727/ 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
Re: Wake-up from suspend to RAM broken under `retbleed=stuff`
On 11/01/2023 11:45 am, Jan Beulich wrote: > On 11.01.2023 12:39, Andrew Cooper wrote: >> The bigger issue with stuff accounting is that nothing AFAICT accounts >> for the fact that any hypercall potentially empties the RSB in otherwise >> synchronous program flow. > But that's not just at hypercall boundaries, but effectively anywhere > (i.e. whenever the hypervisor decides to de-schedule the vCPU)? Correct, but it's only the RET instructions that reliably underflow the RSB which can be usefully attacked. The %rip at which Xen decides to de-schedule a vCPU are random from the point of view of an attacker. ~Andrew
[linux-linus test] 175723: regressions - FAIL
flight 175723 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175723/ 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-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-amd64-amd64-xl-credit2 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:[Multiple reverts] [RFC PATCH] build: include/compat: figure out which other compat headers are needed
On 11/01/2023 6:17 pm, Anthony PERARD wrote: > Some compat headers depends on other compat headers that may not have > been generated due to config option. > > This would be a generic way to deal with deps, instead of > headers-$(call or $(CONFIG_TRACEBUFFER),$(CONFIG_HVM)) += compat/trace.h > > This is just an RFC, as it only deals with "hvm_op.h" and nothing is > done to have make regenerate the new file when needed. > > Signed-off-by: Anthony PERARD > --- > xen/include/Makefile | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/xen/include/Makefile b/xen/include/Makefile > index 65be310eca..5e6de97841 100644 > --- a/xen/include/Makefile > +++ b/xen/include/Makefile > @@ -34,6 +34,29 @@ headers-$(CONFIG_TRACEBUFFER) += compat/trace.h > headers-$(CONFIG_XENOPROF) += compat/xenoprof.h > headers-$(CONFIG_XSM_FLASK) += compat/xsm/flask_op.h > > +# Find dependencies of compat headers. > +# e.g. hvm/hvm_op.h needs trace.h; but if CONFIG_TRACEBUFFER=n, then trace.h > would be missing. > +# > +# Using sed to remove ".." from path because unsure if something else is > available > +# There's `realpath`, but maynot be available > +#realpath --relative-to=. -mL compat/hvm/../trace.h -> compat/trace.h > +# `make` also have macro for that $(abspath), only recent version. > +# > +# The $(CC) line to gen deps is derived from $(cmd_compat_i) > +include $(obj)/.compat-header-deps.d > +$(obj)/.compat-header-deps.d: include/public/hvm/hvm_op.h > + $(CC) -MM -MF $@.tmp $(filter-out -Wa$(comma)% -include > %/include/xen/config.h,$(XEN_CFLAGS)) $< > + for f in $$(cat $@.tmp | sed -r '1s/^[^:]*: //; s/ \\$$//'); do \ > + echo $$f; \ > + done | sed -r \ > + -e 's#.*/public#compat#; : p; s#/[^/]+/../#/#; t p; s#$$# \\#' \ > + -e '1i headers-y-deps := \\' -e '$$a \ ' \ > + > $@ > + > +headers-y-deps := $(filter-out compat/xen-compat.h,$(headers-y-deps)) > +# Add compat header dependencies and eliminates duplicates > +headers-y := $(sort $(headers-y) $(headers-y-deps)) > + > cppflags-y:= -include public/xen-compat.h > -DXEN_GENERATING_COMPAT_HEADERS > cppflags-$(CONFIG_X86)+= -m32 > For posterity, https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is the issue in question. In file included from arch/x86/hvm/hvm.c:82: ./include/compat/hvm/hvm_op.h:6:10: fatal error: ../trace.h: No such file or directory 6 | #include "../trace.h" | ^~~~ compilation terminated. make[4]: *** [Rules.mk:246: arch/x86/hvm/hvm.o] Error 1 make[3]: *** [Rules.mk:320: arch/x86/hvm] Error 2 make[3]: *** Waiting for unfinished jobs All public headers use "../" relative includes for traversing the public/ hierarchy. This cannot feasibly change given our "copy this into your project" stance, but it means the compat headers have the same structure under compat/. This include is supposed to be including compat/trace.h but it was actually picking up x86's asm/trace.h, hence the build failure now that I've deleted the file. This demonstrates that trying to be clever with -iquote is a mistake. Nothing good can possibly come of having the <> and "" include paths being different. Therefore we must revert all uses of -iquote. But, that isn't the only bug. The real hvm_op.h legitimately includes the real trace.h, therefore the compat hvm_op.h legitimately includes the compat trace.h too. But generation of compat trace.h was made asymmetric because of 2c8fabb223. In hindsight, that's a public ABI breakage. The current configuration of this build of the hypervisor has no legitimate bearing on the headers needing to be installed to /usr/include/xen. Or put another way, it is a breakage to require Xen to have CONFIG_COMPAT+CONFIG_TRACEBUFFER enabled in the build simply to get the public API headers generated properly. So 2c8fabb223 needs reverting too. ~Andrew
Re: [PATCH v2 9/9] x86/shadow: harden shadow_size()
On 11/01/2023 1:57 pm, Jan Beulich wrote:
> Make HVM=y release build behavior prone against array overrun, by
> (ab)using array_access_nospec(). This is in particular to guard against
> e.g. SH_type_unused making it here unintentionally.
>
> Signed-off-by: Jan Beulich
> ---
> v2: New.
>
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -27,6 +27,7 @@
> // been included...
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -368,7 +369,7 @@ shadow_size(unsigned int shadow_type)
> {
> #ifdef CONFIG_HVM
> ASSERT(shadow_type < ARRAY_SIZE(sh_type_to_size));
> -return sh_type_to_size[shadow_type];
> +return array_access_nospec(sh_type_to_size, shadow_type);
I don't think this is warranted.
First, if the commit message were accurate, then it's a problem for all
arrays of size SH_type_unused, yet you've only adjusted a single instance.
Secondly, if it were reliably 16 then we could do the basically-free
"type &= 15;" modification. (It appears my change to do this
automatically hasn't been taken yet.), but we'll end up with lfence
variation here.
But the value isn't attacker controlled. shadow_type always comes from
Xen's metadata about the guest, not the guest itself. So I don't see
how this can conceivably be a speculative issue even in principle.
~Andrew
Re: [PATCH v2 8/9] x86/shadow: call sh_detach_old_tables() directly
On 11/01/2023 1:57 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2264,6 +2264,29 @@ void shadow_prepare_page_type_change(str
> shadow_remove_all_shadows(d, page_to_mfn(page));
> }
>
> +/*
> + * Removes v->arch.paging.shadow.shadow_table[].
> + * Does all appropriate management/bookkeeping/refcounting/etc...
> + */
> +static void sh_detach_old_tables(struct vcpu *v)
> +{
> +struct domain *d = v->domain;
> +unsigned int i;
> +
> +
> + vcpu->arch.paging.shadow.shadow_table[]
> +
Honestly, I don't see what the point of this comment is at all. I'd
suggest just dropping it as you move the function, which avoids the need
to debate over C++ comments.
Preferably with this done, Acked-by: Andrew Cooper
[qemu-mainline test] 175729: regressions - FAIL
flight 175729 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175729/ 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
Re: [PATCH v2 7/9] x86/shadow: reduce effort of hash calculation
On 11/01/2023 1:56 pm, Jan Beulich wrote: > The "n" input is a GFN/MFN value and hence bounded by the physical > address bits in use on a system. The hash quality won't improve by also > including the upper always-zero bits in the calculation. To keep things > as compile-time-constant as they were before, use PADDR_BITS (not > paddr_bits) for loop bounding. This reduces loop iterations from 8 to 5. > > While there also drop the unnecessary conversion to an array of unsigned > char, moving the value off the stack altogether (at least with > optimization enabled). I'm not sure this final bit in brackets is relevant. It wouldn't be on the stack without optimisations either, because ABI-wise, it will be in %rsi. I'd just drop it. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper
Re: [PATCH v2 4/9] x86/shadow: drop a few uses of mfn_valid()
On 11/01/2023 1:53 pm, Jan Beulich wrote:
> v->arch.paging.shadow.shadow_table[], v->arch.paging.shadow.oos[],
> v->arch.paging.shadow.oos_{snapshot[],fixup[].smfn[]} as well as the
> hash table are all only ever written with valid MFNs or INVALID_MFN.
> Avoid the somewhat expensive mfn_valid() when checking MFNs coming from
> these arrays.
>
> Signed-off-by: Jan Beulich
Technically I acked this in v1 because the comment wasn't a code
comment, but Acked-by: Andrew Cooper
nevertheless
RE: [PATCH 1/2] x86/vmx: Calculate model-specific LBRs once at start of day
> From: Andrew Cooper > Sent: Monday, January 9, 2023 8:08 PM > > 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: Kevin Tian
RE: [PATCH 2/2] x86/vmx: Support for CPUs without model-specific LBR
> From: Andrew Cooper > Sent: Monday, January 9, 2023 8:08 PM > > 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: Kevin Tian
[xen-unstable test] 175726: tolerable FAIL - PUSHED
flight 175726 xen-unstable real [real] flight 175731 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/175726/ http://logs.test-lab.xenproject.org/osstest/logs/175731/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail pass in 175731-retest test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 175731-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175720 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175720 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 175720 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 175720 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 175720 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 175720 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175720 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 175720 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 175720 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 175720 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 175720 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 175720 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
[xen-unstable-smoke test] 175732: tolerable all pass - PUSHED
flight 175732 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/175732/ 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 83d9679db057d5736c7b5a56db06bb6bb66c3914 baseline version: xen fd42170b152b19ff12121f3b63674e882c087849 Last test of basis 175728 2023-01-11 18:00:27 Z0 days Testing same since 175732 2023-01-12 00:00:28 Z0 days1 attempts People who touched revisions under test: Oleksii Kurochko 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 fd42170b15..83d9679db0 83d9679db057d5736c7b5a56db06bb6bb66c3914 -> smoke
[qemu-mainline test] 175733: regressions - FAIL
flight 175733 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/175733/ 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
Re: [PATCH v2 10/19] tools/xenstore: change per-domain node accounting interface
On 11.01.23 18:48, Julien Grall wrote: Hi Juergen, On 11/01/2023 08:59, Juergen Gross wrote: ... to make sure domain_nbentry_add() is not returning a negative value. Then it would not work. A good example imagine you have a transaction removing nodes from tree but not adding any. Then the "ret" would be negative. Meanwhile the nodes are also removed outside of the transaction. So the sum of "d->nbentry + ret" would be negative resulting to a failure here. Thanks for catching this. I think the correct way to handle this is to return max(d->nbentry + ret, 0) in domain_nbentry_add(). The value might be imprecise, but always >= 0 and never wrong outside of a transaction collision. I am bit confused with your proposal. If the return value is imprecise, then what's the point of returning max(...) instead of simply 0? Please have a look at the use case especially in domain_nbentry(). Returning always 0 would clearly break quota checks. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
RE: [PATCH v2 02/17] xen/arm: implement helpers to get and update NUMA status
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月11日 0:38
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject: 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 ...
>
static enum dt_numa_status __read_mostly device_tree_numa;
We use DT_NUMA_INIT to indicate device_tree_numa is in a default value
(System's initial value, hasn't done initialization). Maybe rename it
To DT_NUMA_UNINIT be better?
> > +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.
>
This is a good point, I will move them to that file.
> > --- /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
RE: [PATCH v2 03/17] xen/arm: implement node distance helpers for Arm
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月11日 0:47
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject: 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.
>
From Kernel's NUMA device tree binding, it seems DT NUMA are reusing
ACPI used values for distances [1].
> > --- 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.
>
I will retore it, and add a SPDX header.
> > @@ -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?
>
Yes.
> > @@ -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.
>
Ok.
> > + 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.
>
I will use it in next version.
[1]https://www.kernel.org/doc/Documentation/devicetree/bindings/numa.txt
Thanks,
Wei Chen
> Jan
[linux-linus test] 175730: regressions - FAIL
flight 175730 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175730/ 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-coresched-amd64-xl 8 xen-bootfail 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-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 173462 test-amd64-amd64-xl-credit2 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 v4 3/3] x86/vmx: implement Notify VM Exit
On 11.01.2023 22:05, Andrew Cooper wrote:
> On 13/12/2022 4:31 pm, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1428,10 +1428,19 @@ static void cf_check vmx_update_host_cr3(struct vcpu
>> *v)
>>
>> void vmx_update_debug_state(struct vcpu *v)
>> {
>> +unsigned int mask = 1u << TRAP_int3;
>> +
>> +if ( !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
>> +/*
>> + * Only allow toggling TRAP_debug if notify VM exit is enabled, as
>> + * unconditionally setting TRAP_debug is part of the XSA-156 fix.
>> + */
>> +mask |= 1u << TRAP_debug;
>> +
>> if ( v->arch.hvm.debug_state_latch )
>> -v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
>> +v->arch.hvm.vmx.exception_bitmap |= mask;
>> else
>> -v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
>> +v->arch.hvm.vmx.exception_bitmap &= ~mask;
>>
>> vmx_vmcs_enter(v);
>> vmx_update_exception_bitmap(v);
>> @@ -4180,6 +4189,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> switch ( vector )
>> {
>> case TRAP_debug:
>> +if ( cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting
>> )
>> +goto exit_and_crash;
>
> This breaks GDBSX and introspection.
>
> For XSA-156, we were forced to intercept #DB unilaterally for safety,
> but both GDBSX and Introspection can optionally intercepting #DB for
> logical reasons too.
>
> i.e. we can legitimately end up here even on an system with VM Notify.
>
>
> What I can't figure out is why made any reference to MTF. MTF has
> absolutely nothing to do with TRAP_debug.
Looking back I see that the two seemingly asymmetric conditions puzzled
me during review, but for some reason I didn't question the MTF part
as a whole; I think I simply wasn't sure and hence left it to the
VMX maintainers. I think you're right and that part of the condition
wants deleting from vmx_update_debug_state() (on top of deleting the
entire if() above).
> Furthermore, there's no CPU in practice that has VM Notify but lacks
> MTF, so the head of vmx_update_debug_state() looks like dead code...
"No CPU in practice" is not an applicable argument as long as the spec
doesn't spell out a connection. When running virtualized ourselves, any
valid feature combination may be found (seeing that we similarly
may ourselves surface feature combinations to guests which no real
hardware equivalent exists for).
Jan
Re: [Multiple reverts] [RFC PATCH] build: include/compat: figure out which other compat headers are needed
On 11.01.2023 23:29, Andrew Cooper wrote: > For posterity, > https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is > the issue in question. > > In file included from arch/x86/hvm/hvm.c:82: > ./include/compat/hvm/hvm_op.h:6:10: fatal error: ../trace.h: No such > file or directory > 6 | #include "../trace.h" > | ^~~~ > compilation terminated. > make[4]: *** [Rules.mk:246: arch/x86/hvm/hvm.o] Error 1 > make[3]: *** [Rules.mk:320: arch/x86/hvm] Error 2 > make[3]: *** Waiting for unfinished jobs > > > All public headers use "../" relative includes for traversing the > public/ hierarchy. This cannot feasibly change given our "copy this > into your project" stance, but it means the compat headers have the same > structure under compat/. > > This include is supposed to be including compat/trace.h but it was > actually picking up x86's asm/trace.h, hence the build failure now that > I've deleted the file. > > This demonstrates that trying to be clever with -iquote is a mistake. > Nothing good can possibly come of having the <> and "" include paths > being different. Therefore we must revert all uses of -iquote. I'm afraid I can't see the connection between use of -iquote and the bug here. > But, that isn't the only bug. > > The real hvm_op.h legitimately includes the real trace.h, therefore the > compat hvm_op.h legitimately includes the compat trace.h too. But > generation of compat trace.h was made asymmetric because of 2c8fabb223. > > In hindsight, that's a public ABI breakage. The current configuration > of this build of the hypervisor has no legitimate bearing on the headers > needing to be installed to /usr/include/xen. > > Or put another way, it is a breakage to require Xen to have > CONFIG_COMPAT+CONFIG_TRACEBUFFER enabled in the build simply to get the > public API headers generated properly. There are no public API headers which are generated. The compat headers are generate solely for Xen's internal purposes (and hence there's also no public ABI breakage). Since generation is slow, avoiding to generate ones not needed during the build is helpful. Jan
