On Mon, 18 Mar 2024, Jan Beulich wrote:
> The named reasons simply aren't convincing to me, at all. There's no
> loss towards the "end goals" when "unsigned int" is used instead of
> "uint32_t". Plus I recall Andrew putting under question use of
> "unsigned int" for various hypercall parameter
On Mon, 18 Mar 2024, Jan Beulich wrote:
> On 16.03.2024 01:07, Stefano Stabellini wrote:
> > On Fri, 15 Mar 2024, Jan Beulich wrote:
> >> On 14.03.2024 23:17, Stefano Stabellini wrote:
> >>> Xen makes assumptions about the size of integer types on the various
> >>> architectures. Document these
flight 185077 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185077/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185032
On Mon, 18 Mar 2024, Jan Beulich wrote:
> On 16.03.2024 01:43, Stefano Stabellini wrote:
> > On Fri, 15 Mar 2024, Jan Beulich wrote:
> >> On 14.03.2024 23:59, Stefano Stabellini wrote:
> >>> On Mon, 11 Mar 2024, Simone Ballarin wrote:
> On 11/03/24 14:56, Jan Beulich wrote:
> > On
On Mon, 18 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On Mon, 18 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On Mon, 18 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
flight 185075 linux-linus real [real]
flight 185086 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185075/
http://logs.test-lab.xenproject.org/osstest/logs/185086/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 2024-03-15 05:48, Jan Beulich wrote:
On 14.03.2024 20:19, Jason Andryuk wrote:
On 2024-03-14 09:31, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,108 @@ static paddr_t __init find_memory(
On 2024-03-14 10:19, Jan Beulich wrote:
On 14.03.2024 15:13, Jason Andryuk wrote:
On 2024-03-14 09:21, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -194,6 +194,17 @@
*/
#define
On 2/14/24 10:41, Jan Beulich wrote:
> On 02.02.2024 22:33, Stewart Hildebrand wrote:
>> @@ -836,9 +870,20 @@ static int cf_check init_header(struct pci_dev *pdev)
>> if ( pdev->ignore_bars )
>> return 0;
>>
>> -/* Disable memory decoding before sizing. */
>> cmd =
I sent a ping on this about 2 weeks ago. Since the plan is to move x86
IOMMU under general x86, the other x86 maintainers should be aware of
this:
On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > Apparently
All of these are informational and require no further logic changes in Xen to
support.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
name of FAST_REP_SCASB.
---
tools/misc/xen-cpuid.c
On Mon, Mar 18, 2024 at 11:04 AM Andrew Cooper
wrote:
>
> The start/stop1/etc linkage scheme predates struct virtual_region, and as
> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>
> Change the linker to provide explicit start/stop symbols for each bugframe
> type,
Still broken on arndale, serial stop working early, then the machine
timeout when working on creating a xen guest with xen-create-guest.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm
LVM in l0 doesn't let us run pvcreate on the host LV, `pvcreate
$outer_lvdev` fails with:
Cannot use /dev/$l0-vg/l1_gueststorage_outer_lv: device is an LV
Signed-off-by: Anthony PERARD
---
ts-nested-setup | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Signed-off-by: Anthony PERARD
---
make-hosts-flight | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/make-hosts-flight b/make-hosts-flight
index 63ac7b71..0177f605 100755
--- a/make-hosts-flight
+++ b/make-hosts-flight
@@ -26,7 +26,7 @@ blessing=$4
buildflight=$5
:
Xen 4.17 doesn't build with Debian Bookworm. It fails to build
IPXE/etherboot, on "amd64". So we keep using Debian Buster on Xen 4.18
and earlier branches. Xen 4.18 builds 4.17 via job "build-amd64-prev".
Xen 4.17 would needs 18a36b4a9b08 ("tools: ipxe: update for fixing
build with GCC12") which
This is a copy of the file installed, from grub-common package.
We are going to edit it shortly.
Signed-off-by: Anthony PERARD
---
overlay-bookworm/etc/grub.d/20_linux_xen | 379 +++
1 file changed, 379 insertions(+)
create mode 100755
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 68f1be60..3545f3fd 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1176,7 +1176,7 @@ END
logm("\$arch is $arch,
QEMU doesn't build on buster anymore.
This should be remove once bookworm is the default suite.
Signed-off-by: Anthony PERARD
---
make-flight | 5 +
1 file changed, 5 insertions(+)
diff --git a/make-flight b/make-flight
index d0c950bc..6e88cb13 100755
--- a/make-flight
+++ b/make-flight
`xen-create-image` doesn't create image for bookworm with a working
network, we need to fix the interface name.
For reference, there's a bug report upstream:
"UnPredictableNetworkInterfaceNames 'fun' with Bookworm domU: eth0 -> enX0"
https://github.com/xen-tools/xen-tools/issues/65
The file "/boot/grub/grub.cfg" on Debian Bookworm isn't accessible
from the "osstest" user, but target_editfile_root() tries to grab the
file as "osstest" then edit it as "root.
Change teditfileex() to use the same $user also to get the file. This
will fix ts-examine-serial-pre step.
udevd on Bookworm shows as "(udev-worker)" in the process list.
Suppress them.
Signed-off-by: Anthony PERARD
---
ts-leak-check | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-leak-check b/ts-leak-check
index f3cca8aa..023a945f 100755
--- a/ts-leak-check
+++ b/ts-leak-check
@@ -203,6
When starting the installation of the L2 guest, L0 kills L1. Switching
the L2 guest back to Debian Buster works fine, so do that to prevent
regression in the test.
Part of the logs from the host L0:
> domain_crash called from arch/x86/hvm/vmx/vvmx.c:2770
> Domain 3 (vcpu#0) crashed on cpu#4:
>
This ask to copy the MAC address from $physif on the bridge.
On Debian Bookworm, when running as a Xen guest for nested tests, the
bridge does get a random MAC address and a different IP address from
DHCP than before setting up the bridge, so the test fails.
Signed-off-by: Anthony PERARD
---
xen-tools commit 83c37b476a75 ("Start all Debian releases since
Stretch (9) with pygrub by default") started to use pygrub by default.
Revert this.
With "pygrub" setting, xen-create-guest fails on armhf, the
80-install-kernel hook fails because it doesn't know about "armhf".
On bookworm, "/boot/grub/grub.cfg" isn't accessible by user "osstest",
so read the file as user "root".
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 31d32d6f..57f31977 100644
Kernel in "debian-12.1.0-amd64-netinst.iso" prevent debian installer
from booting. Early on, it does `udevadm trigger --action=add`, which
fails, the same way as the following runes fails:
$ cat /sys/devices/virtual/input/input2/name
Xen Virtual Keyboard
$ echo add >
On 2024-03-18 17:49, Jan Beulich wrote:
On 18.03.2024 12:53, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that
all
768 MB for the guest isn't enough anymore for Debian Bookworm, at boot
it print this message:
Low memory
--
Entering low memory mode
This system has relatively little free memory, so it will enter low memory
mode. Among other things, this means that this program will
When running ./ts-debian-di-install, hostname on the command line is
interpreted by the debian installer. As the installer find it to be a
FQDN, it uses part of the hostname as the domain, thus overwriting the
value from the DHCP and from d-i netcfg/get_domain setting (maybe).
But the result is
20_linux_xen now uses "xen_hypervisor" and "xen_module" in place of
"multiboot2?" and "module2?" when generating a config file for
arm64-uefi.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Osstest/Debian.pm
On 15.03.2024 19:05, Oleksii Kurochko wrote:
> Currently, RISC-V requires two extensions: _zbb and _zihintpause.
Do we really require Zbb already?
> This patch introduces a compiler check to check if these extensions
> are supported.
> Additionally, it introduces the riscv/booting.txt file,
It turns out that setting $xen_version in linux_entry_xsm() override
$xen_version in the loop over $xen_list. This means that only one
entry per Xen version is going to enable XSM, but all further entries
are going to have "(XSM enabled)" in their titles without enabling
XSM.
When a
The default wait time of 3 seconds isn't always enough get an IP from
the DHCP, give more time to the installer to find a NIC that works.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index
On "italia?" machine, the two network interfaces are competing to have
"eno1", base on the "onboard" naming policy. So the name of the
network interface can change between "eno1" and "eth0".
Switching to "mac" should avoid the unpredictable name based on
"onboard" or "slot" policy.
The "mac"
ts-xtf-run does run ./xtf-runner, which run `python` in its shebang.
So install a `python` symlink to `python3`.
Signed-off-by: Anthony PERARD
---
ts-xtf-install | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ts-xtf-install b/ts-xtf-install
index a64fd329..fea737ff 100755
---
When there's more than one disk, like the "pinot?" machine, the name
assigned to e.g. "sda" may change after a reboot, at least when
installing Debian Bookworm, which is using Linux 6.1.
I believe Linux probes disk controller in parallel and assign "sda"
to the first controller to respond, or
Sometime, it can happen that the erase-other-disks script fails and
indicate that /dev/sda1 isn't a block device anymore. This happened
when /dev/sda was erased before /dev/sda1. So to avoid this, we will
zero the partitions of ${disk} first, and hopefully the error won't
happen again.
python-dev:
It doesn't exist on bookworm, and python2 shouldn't be needed
anymore.
libsdl-dev:
On buster this already select "libsdl1.2-dev", but to not change
buster installation we will only use the new package name on
Bookworm.
Signed-off-by: Anthony PERARD
---
libc6-xen packaged have been removed from Debian Bookworm.
Signed-off-by: Anthony PERARD
---
ts-xen-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-install b/ts-xen-install
index bf55d4e5..3a913fce 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -64,7
Signed-off-by: Anthony PERARD
---
mg-debian-installer-update | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index 4fb4bc21..31b8a192 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@
Newer version of Debian and thus git would use this automatically, no
need to force it.
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f0e087aa..0dded9b2 100644
This schema doesn't work. Even if the udev rule is there, the name of
the different NIC are different from one boot to the next. On a
machine (sabro*) with 3 different NIC, the name of each interface is
basically random and could take on of three name, "eth[0-2]".
net.ifnames=0 does still mean
Otherwise, the change to the config file isn't taken into account
until the next reboot.
Signed-off-by: Anthony PERARD
---
ts-host-install | 5 +
1 file changed, 5 insertions(+)
diff --git a/ts-host-install b/ts-host-install
index 00277485..43ed9285 100755
--- a/ts-host-install
+++
Signed-off-by: Anthony PERARD
---
production-config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/production-config b/production-config
index 2c44805c..6345c40c 100644
--- a/production-config
+++ b/production-config
@@ -101,6 +101,8 @@ DebianImageVersion_jessie 8.2.0
grub-installer on arndale-* machine fails with Debian Bookworm. It
tries to install "grub-pc" which doesn't exist. Skip installation.
Somehow, cubietruck-* installation works fine.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 8
1 file changed, 8 insertions(+)
diff --git
$@ expand to two or more words, but fail() only take one argument.
So if there's more than one argument left, fail() only shows the first
one, and don't event display "not found".
Signed-off-by: Anthony PERARD
---
mgi-common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Instead of "grub-installer/no-nvram" proposed in Debian bug #789798,
we have "grub-installer/update-nvram". Make use of it, and remove
workaround.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Osstest/Debian.pm
Signed-off-by: Anthony PERARD
---
ts-host-install | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ts-host-install b/ts-host-install
index f79a1beb..61433e64 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -151,7 +151,13 @@ END
my $ntpserver =
The Debian #778564 bug report is still open, the ntp.conf file doesn't
contain the setting from NtpServer after installation, so we still
need to edit ntp.conf on Bookworm.
Signed-off-by: Anthony PERARD
---
ts-host-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/osstest.git br.bookworm-v1
Hi,
I intend to push this series in two waves.
First, push up to commit "Temporally switch "qemu-mainline" branch to
Bookworm". This is to test that osstest still works fine if
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
With all users updated to the new API, drop the old API. This includes all of
asm/hvm/trace.h, which allows us to drop some includes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall
CC: Nicola Vetrini
CC:
(Almost) no functional change.
irq_move_cleanup_interrupt() changes two smp_processor_id() calls to the 'me'
local variable which manifests as a minor code improvement. All other
differences in the compiled binary are to do with line numbers changing.
Some conversion notes:
*
Most uses of bitfields and __packed are unnecessary. There is also no need to
cast 'd' to (unsigned char *) before passing it to a function taking void *.
Switch to new trace_time() API.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Dario Faggioli
---
CC: George Dunlap
CC:
trace() and trace_time(), in function form for struct arguments, and macro
form for simple uint32_t list arguments.
This will be used to clean up the mess of macros which exists throughout the
codebase, as well as eventually dropping __trace_var().
There is intentionally no macro to split a
This logically drops the cycles parameter, as it's now encoded directly in the
event code.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall
CC: Nicola Vetrini
CC: consult...@bugseng.com
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *. Switch to new trace_time() API.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by:
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *. Switch to new trace_time() API.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Dario Faggioli
---
CC:
Rework the trace API to unify it (remove the HVM specific obfuscation), and
remove MISRA violations.
v3:
* Delete TRACE_PARAM64()
Andrew Cooper (7):
xen/trace: Introduce new API
xen/credit2: Clean up trace handling
xen/rt: Clean up trace handling
xen/sched: Clean up trace handling
flight 185072 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185072/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat fail in 185061 pass
in 185072
flight 185081 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185081/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 18.03.24 17:08, Jan Beulich wrote:
On 18.03.2024 17:05, Jürgen Groß wrote:
On 18.03.24 16:59, Jan Beulich wrote:
On 18.03.2024 16:55, Jürgen Groß wrote:
On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
On 18.03.2024 17:05, Jürgen Groß wrote:
> On 18.03.24 16:59, Jan Beulich wrote:
>> On 18.03.2024 16:55, Jürgen Groß wrote:
>>> On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
> Instead of special casing rspin_lock_irqsave() and
>
On 18.03.24 17:05, Jan Beulich wrote:
On 18.03.2024 17:00, Jürgen Groß wrote:
On 18.03.24 16:39, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
@@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
static inline bool _is_write_locked_by_me(unsigned int cnts)
On 18.03.24 16:59, Jan Beulich wrote:
On 18.03.2024 16:55, Jürgen Groß wrote:
On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock
On 18.03.2024 17:00, Jürgen Groß wrote:
> On 18.03.24 16:39, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> @@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>>>
>>> static inline bool _is_write_locked_by_me(unsigned int cnts)
>>> {
>>> -
On 18.03.24 16:39, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
The rwlock handling is limiting the number of cpus to 4095 today. The
main reason is the use of the atomic_t data type for the main lock
handling, which needs 2 bits for the locking state (writer waiting or
write
On 18.03.2024 16:55, Jürgen Groß wrote:
> On 18.03.24 15:43, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> Instead of special casing rspin_lock_irqsave() and
>>> rspin_unlock_irqrestore() for the console lock, add those functions
>>> to spinlock handling and use them where
On 18.03.24 16:08, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -8,16 +8,16 @@
#include
#include
-#define SPINLOCK_CPU_BITS 12
+#define SPINLOCK_CPU_BITS 16
#ifdef CONFIG_DEBUG_LOCKS
union
On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
Reviewed-by:
On Mon, Mar 18, 2024 at 02:40:21PM +0100, Jan Beulich wrote:
> On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> > It will be useful for error reporting in a subsequent patch.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
>
> In principle
> Acked-by: Jan Beulich
> However, ...
>
>
On 18.03.24 16:44, Jan Beulich wrote:
On 18.03.2024 16:31, Jürgen Groß wrote:
On 18.03.24 15:57, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
On 18.03.2024 16:31, Jürgen Groß wrote:
> On 18.03.24 15:57, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> --- a/xen/common/spinlock.c
>>> +++ b/xen/common/spinlock.c
>>> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
>>> spinlock_tickets_t *t)
On 14.03.2024 08:20, Juergen Gross wrote:
> The rwlock handling is limiting the number of cpus to 4095 today. The
> main reason is the use of the atomic_t data type for the main lock
> handling, which needs 2 bits for the locking state (writer waiting or
> write locked), 12 bits for the id of a
On 18.03.24 15:57, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
spinlock_tickets_t *t)
int _spin_is_locked(const spinlock_t *lock)
{
-
On 14.03.2024 08:20, Juergen Gross wrote:
> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -8,16 +8,16 @@
> #include
> #include
>
> -#define SPINLOCK_CPU_BITS 12
> +#define SPINLOCK_CPU_BITS 16
>
> #ifdef CONFIG_DEBUG_LOCKS
> union lock_debug {
> -uint16_t
On 14.03.2024 08:20, Juergen Gross wrote:
> Switch the remaining trylock and is_locked variants to return bool.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 14.03.2024 08:20, Juergen Gross wrote:
> Recursive and normal spinlocks are sharing the same data structure for
> representation of the lock. This has two major disadvantages:
>
> - it is not clear from the definition of a lock, whether it is intended
> to be used recursive or not, while a
On 14.03.2024 08:20, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
> spinlock_tickets_t *t)
>
> int _spin_is_locked(const spinlock_t *lock)
> {
> -/*
> - * Recursive locks
On 14.03.2024 08:20, Juergen Gross wrote:
> Add another function level in spinlock.c hiding the spinlock_t layout
> from the low level locking code.
>
> This is done in preparation of introducing rspinlock_t for recursive
> locks without having to duplicate all of the locking code.
>
>
On 14.03.2024 08:20, Juergen Gross wrote:
> Instead of special casing rspin_lock_irqsave() and
> rspin_unlock_irqrestore() for the console lock, add those functions
> to spinlock handling and use them where needed.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with two remarks:
>
On Mon, 2024-03-18 at 08:54 +0100, Jan Beulich wrote:
> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/configs/tiny64_defconfig
> > +++ b/xen/arch/riscv/configs/tiny64_defconfig
> > @@ -7,6 +7,23 @@
> > # CONFIG_GRANT_TABLE is not set
> > # CONFIG_SPECULATIVE_HARDEN_ARRAY
On 14.03.2024 08:20, Juergen Gross wrote:
> Introduce a new type "rspinlock_t" to be used for recursive spinlocks.
>
> For now it is only an alias of spinlock_t, so both types can still be
> used for recursive spinlocks. This will be changed later, though.
>
> Switch all recursive spinlocks to
On 18.03.2024 14:54, Andrew Cooper wrote:
> On 18/03/2024 1:25 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> Given 3 statically initialised objects, its easy to link the list at build
>>> time. There's no need to do it during runtime at boot (and with IRQs-off,
>>>
On 18.03.2024 14:49, Andrew Cooper wrote:
> On 18/03/2024 1:29 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>>> {
On 13.03.2024 13:24, George Dunlap wrote:
> In order to make implementation and testing tractable, we will require
> specific host functionality. Add a nested_virt bit to hvm_funcs.caps,
> and return an error if a domain is created with nested virt and this
> bit isn't set. Create VMX and SVM
On 13.03.2024 13:24, George Dunlap wrote:
> The primary purpose of TSC scaling, from our perspective, is to
> maintain the fiction of an "invariant TSC" across migrates between
> platforms with different clock speeds.
>
> On AMD, the TscRateMSR CPUID bit is unconditionally enabled in the
> "host
On 13.03.2024 13:24, George Dunlap wrote:
> Currently (nested) SVM features we're willing to expose to the guest
> are defined in calculate_host_policy, and stored in host_cpu_policy.
> This is the wrong place for this; move it into
> calculate_hvm_max_policy(), and store it in hvm_max_cpu_policy.
On 18/03/2024 1:25 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> Given 3 statically initialised objects, its easy to link the list at build
>> time. There's no need to do it during runtime at boot (and with IRQs-off,
>> even).
> Hmm, technically that's correct, but isn't
On 18/03/2024 1:29 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> --- a/xen/common/virtual_region.c
>> +++ b/xen/common/virtual_region.c
>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>> { __start_bug_frames_2, __stop_bug_frames_2 },
>> {
On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
> map. This should be true for addresses coming from the firmware, but
> when extra pages used by Xen itself are included in the mapping, those
> are taken from usable RAM
On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> It will be useful for error reporting in a subsequent patch.
>
> Signed-off-by: Marek Marczykowski-Górecki
In principle
Acked-by: Jan Beulich
However, ...
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
>
1 - 100 of 142 matches
Mail list logo
