On 03/01/2025 12:42 am, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jan 02, 2025 at 08:17:00PM +0100, Jürgen Groß wrote:
On 02.01.25 19
On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Jan 02, 2025 at 08:17:00PM +0100, Jürgen Groß wrote:
> > > On 02.01.25 19:54, Marek Marczykowski-Górecki wrote:
> > > > On Thu, Jan 0
On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 08:17:00PM +0100, Jürgen Groß wrote:
> > On 02.01.25 19:54, Marek Marczykowski-Górecki wrote:
> > > On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki
> > > wrote:
> > > > On Thu
Clang, of at least verion 17 complains:
arch/x86/pv/hypercall.c:30:10: error: variable 'eax' is used uninitialized
whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
30 | if ( !compat )
| ^~~
arch/x86/pv/hypercall.c:87:29: note: uninitialized u
On Thu, Jan 02, 2025 at 08:17:00PM +0100, Jürgen Groß wrote:
> On 02.01.25 19:54, Marek Marczykowski-Górecki wrote:
> > On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> > > > On 02.01.25 11:20, Jürgen
On Fri, 20 Dec 2024, Sergiy Kibrik wrote:
> Return false from arch_vcpu_ioreq_completion() when completion is not handled.
> According to coding-best-practices.pandoc an error should be propagated to
> caller, if caller is expecting to handle it, which seems to the case for
> callers of arch_vcpu_i
On Mon, 30 Dec 2024, Sergiy Kibrik wrote:
> From: Stefano Stabellini
>
> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> and monitoring support optional.
> This is to reduce code size on Arm when this option isn't enabled.
>
> Signed-off-by: Stefano Stabellini
> Si
---
xen/Kconfig.debug | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index c4a8d86912e0..9bc4eb2df353 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -60,18 +60,12 @@ config DEBUG_LOCKS
checks will be pe
* Strip trailing whitspace.
* Remove PRIperfc. It has never been used and isn't useful.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shaw
... and hook it up for RISC-V and PPC.
On RISC-V at least, no combination of headers pulls in errno.h, so include it
explicitly.
Guard the hypercalls array declaration based on NR_hypercalls existing. This
is sufficient to get PERF_COUNTERS fully working on RISC-V and PPC, so drop
the randconfig
This started as just patch 3 fixing a header tangle with FRED on x86, but grew
somewhat.
It's simple, straight forward, and gets perf counters working uniformly on all
architectures, and a net reduction in code.
It's low risk, and should be considered for 4.20 at this juncture.
https://gitlab.co
This is mostly for the removal of xen/lib.h and xen/smp.h from perfc.h. All
that is needed is xen/macros.h.
Trim and sort the includes for perfc.c too. There's no need for smp.h,
keyhandler.h or mm.h, but cpumask.h is needed.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monn
These were only ever used by the IA64 port, which was droped in commit
570c311ca2c7 ("remove ia64").
Remove them, and clean up the arm/x86 stub headers.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Ber
On 02.01.25 19:54, Marek Marczykowski-Górecki wrote:
On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
On 02.01.25 11:20, Jürgen Groß wrote:
On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
Hi,
It cr
On 02/01/2025 6:54 pm, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
>>> On 02.01.25 11:20, Jürgen Groß wrote:
On 19.12.24 17:14, Marek Marczykowski-Górecki wrote
On Thu, Jan 02, 2025 at 01:24:21PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> > On 02.01.25 11:20, Jürgen Groß wrote:
> > > On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > > >
> > > > It crashes on boot like belo
On Fri, 27 Dec 2024, Jan Beulich wrote:
> On 19.12.2024 10:29, Sergiy Kibrik wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -74,12 +74,12 @@ obj-y += hpet.o
> > obj-y += vm_event.o
> > obj-y += xstate.o
> >
> > -ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> > -obj-y +=
On Mon, 30 Dec 2024, Ayan Kumar Halder wrote:
> Hi Jason
>
> On 17/12/2024 21:19, Jason Andryuk wrote:
> > uboot-script-gen fails to process a zstd-compressed initramdisk, exiting
> > with:
> > Wrong file type initrd.img. It should be cpio archive, exiting.
> >
> > Extend the existing approach to
From: Petr Beneš
The EPT Paging-write feature (when enabled by the
TERTIARY_EXEC_EPT_PAGING_WRITE bit) uses bit 58 of the EPT entry to indicate
that guest paging may update the page, even if the W access is not set.
This patch is a preparation for the EPT Paging-write feature.
Signed-off-by:
From: Petr Beneš
This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is
similar to XENMEM_access_r, but for processors with
TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later),
it also permits the CPU to write to the page during guest page-table
From: Petr Beneš
Changes since v2:
- Reset entry->pw in all cases in p2m_set_entry, except for p2m_access_r_pw
Changes since v1:
- Added signed-off-by tags
This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is
similar to XENMEM_access_r, but for processors with
TERTIA
On Thu, 19 Dec 2024, Ariel Otilibili wrote:
> The if-statement tests `res` is non-zero; meaning the case zero is never
> reached.
>
> Coverity-ID: 1055253
> Fixes: e2b1ebf4de ("x86: Support booting a bzImage format domain 0 kernel.")
> Signed-off-by: Ariel Otilibili
Reviewed-by: Stefano Stabell
On Thu, 19 Dec 2024, Jan Beulich wrote:
> On 19.12.2024 09:58, Nicola Vetrini wrote:
> > On 2024-12-19 09:49, Jan Beulich wrote:
> >> On 18.12.2024 15:25, Alessandro Zucchelli wrote:
> >>> Rule 11.8 states as following: "A cast shall not remove any `const' or
> >>> `volatile' qualification from the
On 2024-12-24 08:54, Julien Grall wrote:
Hi,
Replying your last two replies in the same thread.
On 24/12/2024 03:41, Sergiy Kibrik wrote:
18.12.24 12:05, Julien Grall:
> yes, I had to assign devices to hardware domain manually.
I think it would be easier for the user to say "This is my ha
On 02/01/2025 4:30 pm, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 04:26:28PM +, Andrew Cooper wrote:
>> Hello,
>>
>> Forwarding a bug report from IRC from before Christmas:
>>
>> ---
>> bit of a random question, but: has anyone had any luck booting efi
>> builds of Xen? over th
On Thu, Jan 02, 2025 at 04:26:28PM +, Andrew Cooper wrote:
> Hello,
>
> Forwarding a bug report from IRC from before Christmas:
>
> ---
> bit of a random question, but: has anyone had any luck booting efi
> builds of Xen? over the last year or so I've tried 4.18 and 4.19, Alpine
> and Fedora
Hello,
Forwarding a bug report from IRC from before Christmas:
---
bit of a random question, but: has anyone had any luck booting efi
builds of Xen? over the last year or so I've tried 4.18 and 4.19, Alpine
and Fedora builds, and on a Dell PowerEdge R430 and an Optiplex 7010
Plus, and in every ca
On Fri, Dec 20, 2024 at 07:34:24PM +, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information. These
> features exist on AMD Zen5 CPUs and are necessary for Xen to use.
>
> The two features are in principle unrelated:
>
> * SRSO_U/S_NO is an enumeration sayin
On Thu, 2025-01-02 at 15:16 +0100, Jürgen Groß wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before you even know whether it's an Intel or AM
On 02.01.25 15:06, David Woodhouse wrote:
On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
Are you suggesting that you're able to enable the CPU-specific CFI
protections before you even know whether it's an Intel or AMD CPU?
Not before that, but maybe rather soon afterwards. And the hyper
On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > Are you suggesting that you're able to enable the CPU-specific CFI
> > protections before you even know whether it's an Intel or AMD CPU?
>
> Not before that, but maybe rather soon afterwards. And the hypercall page
> needs to be decommissi
On 02.01.25 14:40, David Woodhouse wrote:
On Thu, 2025-01-02 at 14:38 +0100, Jürgen Groß wrote:
On 02.01.25 13:53, David Woodhouse wrote:
On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
On 23.12.24 15:24, David Woodhouse wrote:
On Tue, 2024-12-17 at 12:18 +, Xen.org security team wr
On Thu, 2025-01-02 at 14:38 +0100, Jürgen Groß wrote:
> On 02.01.25 13:53, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
> > > On 23.12.24 15:24, David Woodhouse wrote:
> > > > On Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
> > > > >
On 02.01.25 13:53, David Woodhouse wrote:
On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
On 23.12.24 15:24, David Woodhouse wrote:
On Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
Xen Security Advisory CVE-2024-53241 / XSA-466
On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
> On 23.12.24 15:24, David Woodhouse wrote:
> > On Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
> > > Xen Security Advisory CVE-2024-53241 / XSA-466
> > > version 3
> > >
> > >
On Thu, Jan 02, 2025 at 12:30:10PM +0100, Juergen Gross wrote:
> On 02.01.25 11:20, Jürgen Groß wrote:
> > On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > >
> > > It crashes on boot like below, most of the times. But sometimes (rarely)
> > > it manages to stay alive. Below I'm p
On 23.12.24 15:24, David Woodhouse wrote:
On Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
Xen Security Advisory CVE-2024-53241 / XSA-466
version 3
Xen hypercall page unsafe against speculative attacks
UPDATES IN VERSION 3
On 02.01.25 11:20, Jürgen Groß wrote:
On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
Hi,
It crashes on boot like below, most of the times. But sometimes (rarely)
it manages to stay alive. Below I'm pasting few of the crashes that look
distinctly different, if you follow the links, you can
On 19.12.24 17:14, Marek Marczykowski-Górecki wrote:
Hi,
It crashes on boot like below, most of the times. But sometimes (rarely)
it manages to stay alive. Below I'm pasting few of the crashes that look
distinctly different, if you follow the links, you can find more of
them. IMHO it looks like
Signed-off-by: Tu Dinh
---
xen/arch/x86/include/asm/domain.h | 1 +
xen/arch/x86/xstate.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/xen/arch/x86/include/asm/domain.h
b/xen/arch/x86/include/asm/domain.h
index b79d6badd7..d3f2695c20 100644
--- a/xen/arch/x86/include/asm/dom
HVM vCPU state images are uncompressed and therefore can't contain XSS
states.
Signed-off-by: Tu Dinh
---
xen/arch/x86/hvm/hvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 922c9b3af6..c7b93c7d91 100644
--- a/xen/arc
Ensure that the arch LBR feature and its dependents are disabled if any
prerequisites are not available.
Signed-off-by: Tu Dinh
---
xen/arch/x86/cpu-policy.c | 28
xen/arch/x86/cpu/common.c | 7 +++
2 files changed, 35 insertions(+)
diff --git a/xen/arch/x86/cp
Add a new save code type CPU_XSAVES_CODE containing a compressed XSAVES
image.
Signed-off-by: Tu Dinh
---
xen/arch/x86/hvm/hvm.c | 67 +-
xen/arch/x86/xstate.c | 3 +-
xen/include/public/arch-x86/hvm/save.h | 4 +-
3 files changed, 60 in
Use guest LBR_CTL in VMCS to limit LBR operation per guest.
Use MSR bitmap to disable interception of arch LBR MSRs. Reconfigure
bitmap on each valid LBR depth write.
Signed-off-by: Tu Dinh
---
xen/arch/x86/domain.c | 7 +
xen/arch/x86/hvm/vmx/vmcs.c | 11 +-
xe
Signed-off-by: Tu Dinh
---
xen/arch/x86/include/asm/msr-index.h | 12
1 file changed, 12 insertions(+)
diff --git a/xen/arch/x86/include/asm/msr-index.h
b/xen/arch/x86/include/asm/msr-index.h
index 9cdb5b2625..97df740b04 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/a
Add a function get_xstate_component_comp() to allow fetching a specific
XSTATE component from a compressed image.
Also add LBR state declarations in xstate.h.
Signed-off-by: Tu Dinh
---
xen/arch/x86/include/asm/xstate.h | 22 -
xen/arch/x86/msr.c| 3 +-
xen/arch/x86/xst
Intel model-specific last branch records (LBRs) were replaced by
architectural LBRs (see Chapter 20 of Intel SDM volume 3B). This
patchset implements virtual LBRs for HVM guests using Intel's "load
guest IA32_LBR_CTL" and "clear IA32_LBR_CTL" VMX controls. It
dynamically intercepts accesses to LBR
Add three featureset words corresponding to the 3 CPUID words in leaf
0x1c.
Intel SDM states that CPUID may indicate a LBR depth of up to 64.
However, since XSAVE LBR state only goes up to 32 LBRs, don't expose the
other CPUID depth bits for now.
Signed-off-by: Tu Dinh
---
xen/arch/x86/include/
Signed-off-by: Tu Dinh
---
tools/libs/light/libxl_cpuid.c | 3 +++
tools/misc/xen-cpuid.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index 063fe86eb7..05be36f258 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/
Add new set_lbr_depth HVM function and emulate ops to support LBR
XSAVES/XRSTORS emulation.
Add the appropriate instruction hooks to 0fc7.c. Translate LBR registers
using cs.base within a large block emulator operation.
Signed-off-by: Tu Dinh
---
tools/tests/x86_emulator/x86-emulate.h | 2 +
50 matches
Mail list logo
