On 15.08.2024 18:34, Andrew Cooper wrote:
> On 15/08/2024 4:41 pm, Jan Beulich wrote:
>> On 15.08.2024 15:15, Andrew Cooper wrote:
>>> Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB is
>>> buggy. The architectural behaviour is to overwrite B{0..3} (rather than
>>> accumu
flight 187250 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187250/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187246
test-amd64-amd64-xl-qemuu-ws16-amd64
Hi Jason,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/x86/core]
[also build test ERROR on xen-tip/linux-next tip/master linus/master v6.11-rc3
next-20240815]
[cannot apply to tip/auto-latest]
[If your patch is applied to the wrong git tree, kindly drop us
Hi Jason,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tip/x86/core]
[also build test WARNING on xen-tip/linux-next tip/master linus/master
v6.11-rc3 next-20240815]
[cannot apply to tip/auto-latest]
[If your patch is applied to the wrong git tree, kindly
The expectation is that QEMU_TIMEOUT should be set as a Gitlab CI/CD
variable but if not we should be able to run the pipeline anyway.
Signed-off-by: Stefano Stabellini
---
automation/scripts/qemu-key.exp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/automation/scripts
Hi list!
Trying to apply patches to our xen aport I found issues building
tools/qemu-xen (qemu 8.0.4) with musl 1.2.5 and gcc 14 for the
alpinelinux rolling release branch "edge".
The insignificantly different build for our latest stable release,
3.20-stable with musl 1.2.5 but gcc 13.2.1_git2024
Hi Jason,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tip/x86/core]
[also build test WARNING on xen-tip/linux-next tip/master linus/master
v6.11-rc3 next-20240815]
[cannot apply to tip/auto-latest]
[If your patch is applied to the wrong git tree, kindly
flight 187248 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187248/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken in 187241
Tests which
On Thu, Aug 15, 2024 at 10:33:52AM +0200, Jürgen Groß wrote:
> On 14.08.24 22:26, Elliott Mitchell wrote:
> > On Wed, Aug 14, 2024 at 08:15:38AM +0200, Jürgen Groß wrote:
> > > On 14.08.24 00:36, Elliott Mitchell wrote:
> > > >
> > > > Drat. I haven't noticed much, which would match with simply e
flight 187247 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187247/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187238
test-amd64-amd64-libvirt 15 migrate-s
flight 187246 xen-unstable real [real]
flight 187249 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187246/
http://logs.test-lab.xenproject.org/osstest/logs/187249/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 15/08/2024 4:41 pm, Jan Beulich wrote:
> On 15.08.2024 15:15, Andrew Cooper wrote:
>> Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB is
>> buggy. The architectural behaviour is to overwrite B{0..3} (rather than
>> accumulate) and accumulate all other bits.
> Just to d
On 14.08.2024 17:52, Matthew Barnes wrote:
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -121,6 +121,7 @@ XEN_CPUFEATURE(SMX, 1*32+ 6) /* Safer Mode
> Extensions */
> XEN_CPUFEATURE(EIST, 1*32+ 7) /* Enhanced Sp
On 15.08.2024 15:16, Andrew Cooper wrote:
> Commit 08aacc392d86 ("x86/emul: Fix misaligned IO breakpoint behaviour in PV
> guests") caused a Coverity INTEGER_OVERFLOW complaint based on the reasoning
> that width could be 0.
>
> It can't, but digging into the code generation, GCC 8 and later (bise
On 15.08.2024 15:15, Andrew Cooper wrote:
> Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB is
> buggy. The architectural behaviour is to overwrite B{0..3} (rather than
> accumulate) and accumulate all other bits.
Just to double check (after 6 years I clearly don't recal
On 15.08.2024 15:34, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-08-15 at 14:16 +0200, Jan Beulich wrote:
>> On 15.08.2024 13:21, oleksii.kuroc...@gmail.com wrote:
>>> On Thu, 2024-08-15 at 10:09 +0200, Jan Beulich wrote:
On 14.08.2024 18:50, oleksii.kuroc...@gmail.com wrote:
> On Tue
On 15.08.2024 15:29, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-08-15 at 11:02 +0200, Jan Beulich wrote:
>> On 15.08.2024 10:55, oleksii.kuroc...@gmail.com wrote:
>>> On Wed, 2024-08-14 at 17:22 +0200, Jan Beulich wrote:
On 14.08.2024 16:45, oleksii.kuroc...@gmail.com wrote:
> On Tue
On 07.08.24 12:41, Juergen Gross wrote:
There have been reports of failed boots with Xen due to an overlap of
the kernel's memory with ACPI NVS reported in the E820 map of the host.
This series fixes this issue by moving the NVS area in dom0 to some
higher address.
Juergen Gross (5):
xen: us
On Thu, 2024-08-15 at 14:16 +0200, Jan Beulich wrote:
> On 15.08.2024 13:21, oleksii.kuroc...@gmail.com wrote:
> > On Thu, 2024-08-15 at 10:09 +0200, Jan Beulich wrote:
> > > On 14.08.2024 18:50, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
> > > >
On Thu, 2024-08-15 at 11:02 +0200, Jan Beulich wrote:
> On 15.08.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> > On Wed, 2024-08-14 at 17:22 +0200, Jan Beulich wrote:
> > > On 14.08.2024 16:45, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-08-13 at 10:54 +0200, Jan Beulich wrote:
> > > >
On 15/08/2024 2:16 pm, Andrew Cooper wrote:
> Commit 08aacc392d86 ("x86/emul: Fix misaligned IO breakpoint behaviour in PV
> guests") caused a Coverity INTEGER_OVERFLOW complaint based on the reasoning
> that width could be 0.
>
> It can't, but digging into the code generation, GCC 8 and later (bis
Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB is
buggy. The architectural behaviour is to overwrite B{0..3} (rather than
accumulate) and accumulate all other bits.
Introduce a new x86_merge_dr6() helper, and start fixing the mess by adjusting
the dr6 merge in do_debug(
Commit 08aacc392d86 ("x86/emul: Fix misaligned IO breakpoint behaviour in PV
guests") caused a Coverity INTEGER_OVERFLOW complaint based on the reasoning
that width could be 0.
It can't, but digging into the code generation, GCC 8 and later (bisected on
gotbolt) choose to emit a CSWITCH lookup tab
Patches 1 and 2 already reviewed, and split out of a larger series covering
HVM too. However, as it's been 6 years (yes really), I've reposed them just
in case.
Patch 3 fixes a Coverity complaint, highlighted by Matt's recent change to fix
IO breakpoint recognition.
Andrew Cooper (3):
x86/pv:
All #DB exceptions result in an update of %dr6, but this isn't captured in
Xen's handling, and is buggy everywhere.
To begin resolving this issue, add a new pending_dbg field to x86_event
(unioned with cr2 to avoid taking any extra space), and introduce
pv_inject_debug_exn() helpers to replace the
On 15.08.2024 13:21, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-08-15 at 10:09 +0200, Jan Beulich wrote:
>> On 14.08.2024 18:50, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
On 09.08.2024 18:19, Oleksii Kurochko wrote:
> RISC-V detects s
On Thu, 2024-08-15 at 10:09 +0200, Jan Beulich wrote:
> On 14.08.2024 18:50, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
> > > On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > > > Introduce internal macros starting with PTE_* for convenience.
> > > >
flight 187244 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187244/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187230
test-amd64-amd64-xl-qemut-win7-a
13.08.24 10:40, Jan Beulich:
I'm okay-ish with the simple stubbing out for update_mcu_opt_ctrl(), but
set_in_mcu_opt_ctrl() imo requires more work. The call sites in spec_ctrl.c
shouldn't give the wrong impression of having some effect. Imo in
init_speculation_mitigations() an #endif wants to mov
On 15.08.2024 12:00, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-08-14 at 17:53 +0200, Jan Beulich wrote:
>> On 14.08.2024 17:41, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-08-13 at 11:34 +0200, Jan Beulich wrote:
On 09.08.2024 18:19, Oleksii Kurochko wrote:
> +static unsigned
On 15/08/2024 10:37, Julien Grall wrote:
On 15/08/2024 09:58, Ayan Kumar Halder wrote:
Hi Julien,
Hi Ayan,
Hi Julien,
On 14/08/2024 22:00, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments,
13.08.24 10:50, Jan Beulich:
On 09.08.2024 12:11, Sergiy Kibrik wrote:
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -158,13 +158,21 @@
#define is_zen4_uarch() boot_cpu_has(X86_FEATURE_AUTO_IBRS)
struct cpuinfo_x86;
+#ifdef CONFIG_AMD
int cpu_has_amd_er
On Wed, 2024-08-14 at 17:53 +0200, Jan Beulich wrote:
> On 14.08.2024 17:41, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-13 at 11:34 +0200, Jan Beulich wrote:
> > > On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > > > +static unsigned long sbi_major_version(void)
> > > > +{
> > > > + r
On 15/08/2024 10:17 am, Jan Beulich wrote:
> avx512_vlen_check()'s argument was inverted, while the surrounding
> conditional wrongly forced the EVEX.L'L check for the scalar forms when
> embedded rounding was in effect.
>
> Fixes: d14c52cba0f5 ("x86emul: handle AVX512-FP16 complex multiplication
On 15/08/2024 09:58, Ayan Kumar Halder wrote:
Hi Julien,
Hi Ayan,
On 14/08/2024 22:00, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
Newer
avx512_vlen_check()'s argument was inverted, while the surrounding
conditional wrongly forced the EVEX.L'L check for the scalar forms when
embedded rounding was in effect.
Fixes: d14c52cba0f5 ("x86emul: handle AVX512-FP16 complex multiplication insns")
Signed-off-by: Jan Beulich
--- a/xen/arch/x
On 15.08.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-08-14 at 17:22 +0200, Jan Beulich wrote:
>> On 14.08.2024 16:45, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-08-13 at 10:54 +0200, Jan Beulich wrote:
On 09.08.2024 18:19, Oleksii Kurochko wrote:
> --- /dev/null
>>
Hi Julien,
On 14/08/2024 22:00, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
Newer hardware may support FEAT_SME. Xen doesn't have any knowledge
On Wed, 2024-08-14 at 17:22 +0200, Jan Beulich wrote:
> On 14.08.2024 16:45, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-13 at 10:54 +0200, Jan Beulich wrote:
> > > On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/smp.h
> > > > +++ b/xen/arch/riscv/inc
On 14.08.2024 23:31, Andrew Cooper wrote:
> On 14/08/2024 9:34 am, Frediano Ziglio wrote:
>> Testing this feature in preparation for UEFI CA memory mitigation
>> requirements I found some issues causing the loading to fail and
>> other minor issues.
>> Details in series commit messages.
>> This is
On 15.08.2024 03:28, Stewart Hildebrand wrote:
> On 8/13/24 10:01, Jan Beulich wrote:
>> On 12.08.2024 22:39, Stewart Hildebrand wrote:
>>> In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
>>> structure") a lock moved from allocate_and_map_msi_pirq() to the caller
>>> and chan
On 14.08.24 22:26, Elliott Mitchell wrote:
On Wed, Aug 14, 2024 at 08:15:38AM +0200, Jürgen Groß wrote:
On 14.08.24 00:36, Elliott Mitchell wrote:
On Tue, Aug 13, 2024 at 08:55:42PM +0200, Jürgen Groß wrote:
On 13.08.24 19:49, Elliott Mitchell wrote:
There is a possibility spurious interrupt
On 14.08.2024 18:46, Andrew Cooper wrote:
> On 14/08/2024 4:58 pm, Jan Beulich wrote:
>> On 14.08.2024 17:52, Matthew Barnes wrote:
>>> Upon running `xen-cpuid -d` on a host machine with Sapphire Rapids
>>> within Dom0, there exist unrecognised features.
>> Without looking at the particular bits ye
On Wed, 2024-08-14 at 17:08 +0200, Jan Beulich wrote:
> On 14.08.2024 16:21, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-13 at 10:22 +0200, Jan Beulich wrote:
> > > On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/page.h
> > > > +++ b/xen/arch/riscv/in
On 14.08.2024 18:50, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
>> On 09.08.2024 18:19, Oleksii Kurochko wrote:
>>> Introduce internal macros starting with PTE_* for convenience.
>>> These macros closely resemble PTE bits, with the exception of
>>> PTE
flight 187241 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-armhf-armhf-xl-credit2 5 host-install
On 14.08.24 21:50, Jason Andryuk wrote:
The PVH entry point will need an additional set of prebuild page tables.
Move the macros and defines to pgtable_64.h, so they can be re-used.
Signed-off-by: Jason Andryuk
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description
47 matches
Mail list logo
