On 23.04.2025 00:11, [email protected] wrote:
> On Tue, Apr 22, 2025 at 09:56:00AM +0200, Jan Beulich wrote:
>> On 22.04.2025 03:15, [email protected] wrote:
>>> From: Denis Mukhin
>>>
>>> Current implementation of __vmread() returns the result via pointer argument
>>> which leads to having excess cod
On 23.04.2025 01:43, [email protected] wrote:
> From: Nicola Vetrini
>
> The unary minus operator applied to an unsigned quantity has
> a semantics (wrap around) that is well-known to all Xen developers.
> Thus, this operation is deemed safe.
Please, as you have it in the other two patches, c
On 23.04.2025 01:43, [email protected] wrote:
> From: Federico Serafini
>
> MISRA C Rule 5.5 states that:
> "Identifiers shall be distinct from macro names".
>
> A common pattern in Xen is to have a function-like macro that acts as a
> "wrapper" for the function to be called:
> before calling
On 23.04.2025 01:43, [email protected] wrote:
> From: Nicola Vetrini
>
> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
> reserved identifier or reserved macro name") and R21.2 ("A reserved
> identifier or reserved macro name shall not be declared") violations
> are not problem
On 23.04.2025 01:51, Stefano Stabellini wrote:
> On Tue, 22 Apr 2025, [email protected] wrote:
>> From: Nicola Vetrini
>>
>> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
>> reserved identifier or reserved macro name") and R21.2 ("A reserved
>> identifier or reserved macro name
SDM revision 087 points out that apparently as of quite some time ago on
Intel hardware BSF and BSR may alter all arithmetic flags, not just ZF.
Because of the inconsistency (and because documentation doesn't look to
be quite right about PF), best we can do is simply take the flag values
from what
On 2025/4/23 00:03, Jan Beulich wrote:
> On 21.04.2025 08:18, Jiqian Chen wrote:
>> Refactor REGISTER_VPCI_INIT to contain more capability specific
>> information, this is benifit for follow-on changes to hide capability
>> which initialization fails.
>>
>> What's more, change the definition of ini
On 2025/4/23 00:01, Jan Beulich wrote:
> On 21.04.2025 08:18, Jiqian Chen wrote:
>> @@ -759,10 +759,11 @@ static int vpci_init_capability_list(struct pci_dev
>> *pdev)
>> PCI_CAP_ID_MSI,
>> PCI_CAP_ID_MSIX,
>> };
>> +const unsigned int *caps = is_hwdom ?
On 2025/4/22 23:59, Jan Beulich wrote:
> On 21.04.2025 08:18, Jiqian Chen wrote:
>> Modify function pci_find_next_cap_ttl to support returning position
>> of next capability when size "n" is zero.
>>
>> That can help caller to get next capability offset if caller just
>> has a information of curren
We are going to need to reposition the call in a change with several moving
parts.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/alternative.c | 70 ++
1 file changed, 40 insertions(+), 30 deleti
Encoding altcalls as regular alternatives leads to an unreasonable amount of
complexity in _apply_alternatives().
Introduce apply_alt_calls(), and an .alt_call_sites section which simply
tracks the source address (relative, to save on space). That's literally all
that is needed in order to devirt
See patch 7 for details. This simplifies _apply_alternatives() specifically
by removing a special and quite complicated case, and encodes the metadata
about altcalls differently and more efficiently.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780872355
Andrew Cooper (8):
With altcall handled separately, the special case in _apply_alternatives() is
unused and can be dropped. The force parameter (used to signify the seal
pass) can be removed too.
In turn, nmi_apply_alternatives() no longer needs to call
_apply_alternatives() on the second pass.
No functional chang
With all the infrastructure in place, switch from using ALTERNATIVE() to
simply populating .alt_call_sites.
Before, _apply_alternatives() would devirtualise in two passes; the first
being opportunistic, and the second (signified by the force parameter) sealing
any call with a still-NULL function p
The alternatives APIs are not great; rename alternative_branches() to be more
precise. Centralise the declaration in xen/alternative-call.h, in the
expectation that x86 won't be the only user in the long term.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau
The new altcall scheme uses an .alt_call_sites section. Wire this up in very
much the same way as the .altinstructions section, although there is less
sanity checking necessary.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Ross Lagerwall
---
xen/arch/x86/alternati
... in preparation for changing how they're implemented.
Update the MISRA deviations with the new path.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: consult...@bug
nmi_apply_alternatives() is soon going to need to dispatch to multiple
functions, and a force parameter is not a good way of passing information.
Introduce ALT_INSNS and ALT_CALLS to pass in at the top level to select the
operation(s) desired. They represent what will happen when we've separated
On Tue, Apr 08, 2025 at 05:34:27PM +0200, Jan Beulich wrote:
> On 01.04.2025 02:52, [email protected] wrote:
> > From: Denis Mukhin
> >
> > Rewrite emulation_flags_ok() using XEN_X86_EMU_{OPTIONAL,BASELINE}
> > to simplify future modifications.
> >
> > Signed-off-by: Denis Mukhin
> > ---
> > Came i
On Tue, Apr 08, 2025 at 05:23:17PM +0200, Jan Beulich wrote:
> On 01.04.2025 02:52, [email protected] wrote:
> > From: Denis Mukhin
> >
> > Introduce XEN_X86_EMU_BASELINE and XEN_X86_EMU_OPTIONAL to simplify
> > d->arch.emulation_flags management in the code.
>
> If the simplification is limited to
On Tue, Apr 22, 2025 at 04:37:10PM +0100, Andrew Cooper wrote:
> On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
> > xen/include/xen/sha256.h | 12 ++
> > xen/lib/Makefile | 1 +
> > xen/lib/sha256.c | 238 +++
> > 3 files changed, 251 insertions
On Thu, Apr 17, 2025 at 11:47:07AM +0200, Jan Beulich wrote:
> On 16.04.2025 08:15, [email protected] wrote:
> > From: Denis Mukhin
> >
> > Unify the logic of domain ID allocation, so that both the initial domain
> > creation and the usage by domctl use the same helper function across
> > architectu
On Tue, Apr 22, 2025 at 05:36:22PM +0200, Jan Beulich wrote:
> On 22.04.2025 17:06, Sergii Dmytruk wrote:
> > From: Krystian Hebel
> >
> > The code comes from [1] and is licensed under GPL-2.0 license.
> > It's a combination of:
> > - include/crypto/sha1.h
> > - include/crypto/sha1_base.h
> > -
On Tue, Apr 22, 2025 at 09:56:00AM +0200, Jan Beulich wrote:
> On 22.04.2025 03:15, [email protected] wrote:
> > From: Denis Mukhin
> >
> > Current implementation of __vmread() returns the result via pointer argument
> > which leads to having excess code in some places.
> >
> > Update the signature
On Tue, Apr 22, 2025 at 01:54:06PM -0700, Stefano Stabellini wrote:
> On Tue, 22 Apr 2025, [email protected] wrote:
>
> > The series started from adding new argo XTF CI job and ended up with
> > updating
> > all XTF runners and related CI jobs.
> >
> > It unifies the XTF runner scripts so that it i
From: Denis Mukhin
Current implementation of __vmread() returns the result via pointer argument
which leads to having excess code in some places.
Update the signature of __vmread() to return `unsigned long` and drop the
pointer argument as per suggestion in [1].
Rename __vmread() to vmread() as
From: Denis Mukhin
Currently, hypervisor code has two different non-system domain ID allocation
algorithms:
(a) Arm port allocates IDs sequentially based on max_init_domid;
(b) x86 has another algorithm implementation embedded into
XEN_DOMCTL_createdomain; does not use max_init_domid,
On Tue, 22 Apr 2025, [email protected] wrote:
> The series started from adding new argo XTF CI job and ended up with updating
> all XTF runners and related CI jobs.
>
> It unifies the XTF runner scripts so that it is possible to use one script for
> executing any XTF test under QEMU. That simplifie
On 4/22/25 8:06 AM, Sergii Dmytruk wrote:
The file provides constants, structures and several helper functions for
parsing SLRT.
Signed-off-by: Sergii Dmytruk
---
xen/include/xen/slr_table.h | 274
1 file changed, 274 insertions(+)
create mode 100644 xe
On 2025-04-19 18:07, Daniel P. Smith wrote:
The domain configuration may request more vcpus than are present in the system.
For dom0, the function dom0_max_vcpus() was used to clamp down to physically
available vcpus. Here we are introducing a generalized version,
dom_max_vcpus(), that takes a bo
On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
> diff --git a/xen/include/xen/slr_table.h b/xen/include/xen/slr_table.h
> new file mode 100644
> index 00..e9dbac5d0a
> --- /dev/null
> +++ b/xen/include/xen/slr_table.h
> @@ -0,0 +1,274 @@
> +/* SPDX-License-Identifier: GPL-3.0-or-later */
I'm
On Tue, 22 Apr 2025, Nicola Vetrini wrote:
> On 2025-04-22 22:02, Stefano Stabellini wrote:
> > On Tue, 22 Apr 2025, Nicola Vetrini wrote:
> > > On 2025-04-22 21:58, Stefano Stabellini wrote:
> > > > On Tue, 22 Apr 2025, Andrew Cooper wrote:
> > > > > On 22/04/2025 8:46 pm, Stefano Stabellini wrote
On 2025-04-22 22:02, Stefano Stabellini wrote:
On Tue, 22 Apr 2025, Nicola Vetrini wrote:
On 2025-04-22 21:58, Stefano Stabellini wrote:
> On Tue, 22 Apr 2025, Andrew Cooper wrote:
> > On 22/04/2025 8:46 pm, Stefano Stabellini wrote:
> > > On Tue, 22 Apr 2025, Andrew Cooper wrote:
> > >> Compile
On 22/04/2025 8:58 pm, Stefano Stabellini wrote:
> On Tue, 22 Apr 2025, Andrew Cooper wrote:
>> On 22/04/2025 8:46 pm, Stefano Stabellini wrote:
>>> On Tue, 22 Apr 2025, Andrew Cooper wrote:
Compilers estimate the size of an asm() block for inlining purposes.
Constructs such as ALTER
On Tue, 22 Apr 2025, Nicola Vetrini wrote:
> On 2025-04-22 21:58, Stefano Stabellini wrote:
> > On Tue, 22 Apr 2025, Andrew Cooper wrote:
> > > On 22/04/2025 8:46 pm, Stefano Stabellini wrote:
> > > > On Tue, 22 Apr 2025, Andrew Cooper wrote:
> > > >> Compilers estimate the size of an asm() block f
On 2025-04-22 21:58, Stefano Stabellini wrote:
On Tue, 22 Apr 2025, Andrew Cooper wrote:
On 22/04/2025 8:46 pm, Stefano Stabellini wrote:
> On Tue, 22 Apr 2025, Andrew Cooper wrote:
>> Compilers estimate the size of an asm() block for inlining purposes.
>>
>> Constructs such as ALTERNATIVE appea
On Tue, 22 Apr 2025, Andrew Cooper wrote:
> On 22/04/2025 8:46 pm, Stefano Stabellini wrote:
> > On Tue, 22 Apr 2025, Andrew Cooper wrote:
> >> Compilers estimate the size of an asm() block for inlining purposes.
> >>
> >> Constructs such as ALTERNATIVE appear large due to the metadata, depsite
>
On 22/04/2025 8:46 pm, Stefano Stabellini wrote:
> On Tue, 22 Apr 2025, Andrew Cooper wrote:
>> Compilers estimate the size of an asm() block for inlining purposes.
>>
>> Constructs such as ALTERNATIVE appear large due to the metadata, depsite
>> often
>> only being a handful of instructions. asm
On Tue, Apr 22, 2025, Ingo Molnar wrote:
>
> * Luck, Tony wrote:
>
> > > >> base-commit: f30a0c0d2b08b355c01392538de8fc872387cb2b
> > > >
> > > > This commit doesn't exist in Linus' tree or the tip tree, and the
> > > > series doesn't
> > > > apply cleanly on any of the "obvious" choices. Revi
On Tue, 22 Apr 2025, Andrew Cooper wrote:
> Compilers estimate the size of an asm() block for inlining purposes.
>
> Constructs such as ALTERNATIVE appear large due to the metadata, depsite often
> only being a handful of instructions. asm inline() overrides the estimation
> to identify the block
* Luck, Tony wrote:
> > >> base-commit: f30a0c0d2b08b355c01392538de8fc872387cb2b
> > >
> > > This commit doesn't exist in Linus' tree or the tip tree, and the series
> > > doesn't
> > > apply cleanly on any of the "obvious" choices. Reviewing a 34 patches
> > > series
> > > without being abl
On Tue, 22 Apr 2025, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
> ---
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Volodymyr Babchuk
> CC: Bertrand Marquis
> CC: Michal Orzel
> ---
> xen/arch/arm/arm64/cache.S | 2 --
>
On 2025-04-22 19:14, Andrew Cooper wrote:
On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
- Intel TXT and AMD SKINIT on x86 CPUs
- legacy and UEFI boot
- TPM1.2 and TPM2
On Tue, Apr 22, 2025 at 05:23:30PM +0200, Jan Beulich wrote:
> Just one basic nit right here: In the names of new files you add, please
> prefer dashes over underscores.
I wasn't aware of this preference, will be updated in the next version.
> Jan
> >> base-commit: f30a0c0d2b08b355c01392538de8fc872387cb2b
> >
> > This commit doesn't exist in Linus' tree or the tip tree, and the series
> > doesn't
> > apply cleanly on any of the "obvious" choices. Reviewing a 34 patches
> > series
> > without being able to apply it is a wee bit difficult..
On 4/22/2025 8:03 AM, Sean Christopherson wrote:
On Tue, Apr 22, 2025, Xin Li (Intel) wrote:
base-commit: f30a0c0d2b08b355c01392538de8fc872387cb2b
This commit doesn't exist in Linus' tree or the tip tree, and the series doesn't
apply cleanly on any of the "obvious" choices. Reviewing a 34 pat
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/arm/arm64/cache.S | 2 --
xen/arch/arm/domain.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/xen/arch/arm/arm6
On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
> The aim of the [TrenchBoot] project is to provide an implementation of
> DRTM that is generic enough to cover various use cases:
> - Intel TXT and AMD SKINIT on x86 CPUs
> - legacy and UEFI boot
> - TPM1.2 and TPM2.0
> - (in the future) DRTM on Arm
On Mon, Apr 21, 2025 at 01:39:32PM -0700, Stefano Stabellini wrote:
> On Sat, 19 Apr 2025, [email protected] wrote:
> > From: Denis Mukhin
> >
> > Use qemu-xtf.sh for qemu-smoke-x86-64-gcc-efi job.
> >
> > Lead time is reduced a bit since not all XTF code base is built, just the
> > required test.
>
On Mon, Apr 21, 2025 at 01:39:21PM -0700, Stefano Stabellini wrote:
> On Sat, 19 Apr 2025, [email protected] wrote:
> > From: Denis Mukhin
> >
> > Add test runner script qemu-xtf.sh which is allows any XTF x86 test to be
> > easily executed. Test runner is invoked from the qemu-smoke* jobs with the
From: Denis Mukhin
Hook arm64 QEMU configuration to qemu-xtf.sh and use new script in arm64 CI
jobs.
Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
---
Changes v2->v3:
- .gitignore fixup
- Kept Stefano's R-b since the change was trivial
---
automation/gitlab-ci/test.yaml
From: Denis Mukhin
Introduce new CI job to run x86 XTF argo test under QEMU to smoke test argo
feature functionality in upstream CI.
The new job lead time is ~30s, limit max job duration to 60s.
Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
---
Changes v2->v3:
- Added Stefano's
From: Denis Mukhin
Use qemu-xtf.sh for qemu-smoke-x86-64-gcc-efi job.
Lead time is reduced a bit since not all XTF code base is built, just the
required test.
Signed-off-by: Denis Mukhin
---
Changes v2->v3:
- use pv64 variant for EFI job
---
automation/gitlab-ci/test.yaml| 2
The series started from adding new argo XTF CI job and ended up with updating
all XTF runners and related CI jobs.
It unifies the XTF runner scripts so that it is possible to use one script for
executing any XTF test under QEMU. That simplifies running XTFs locally and in
CI.
Patch 1 reworks x86
From: Denis Mukhin
Add test runner script qemu-xtf.sh which is allows any XTF x86 test to be
easily executed. Test runner is invoked from the qemu-smoke* jobs with the
hardcoded parameters.
Each x86 XTF job lead time is reduced a bit since only the test-related code
is built, not the entire XTF
On 21.04.2025 08:18, Jiqian Chen wrote:
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -449,6 +449,7 @@
> #define PCI_EXT_CAP_ID(header) ((header) & 0x)
> #define PCI_EXT_CAP_VER(header) (((header) >> 16) & 0xf)
> #define PCI_EXT_CAP
On 21.04.2025 08:18, Jiqian Chen wrote:
> Refactor REGISTER_VPCI_INIT to contain more capability specific
> information, this is benifit for follow-on changes to hide capability
> which initialization fails.
>
> What's more, change the definition of init_header() since it is
> not a capability and
On 21.04.2025 08:18, Jiqian Chen wrote:
> @@ -759,10 +759,11 @@ static int vpci_init_capability_list(struct pci_dev
> *pdev)
> PCI_CAP_ID_MSI,
> PCI_CAP_ID_MSIX,
> };
> +const unsigned int *caps = is_hwdom ? NULL : supported_caps;
> +const unsigne
On 21.04.2025 08:18, Jiqian Chen wrote:
> Modify function pci_find_next_cap_ttl to support returning position
> of next capability when size "n" is zero.
>
> That can help caller to get next capability offset if caller just
> has a information of current capability offset.
>
> That will be used i
On 22.04.2025 17:26, Oleksii Kurochko wrote:
>
> On 4/17/25 4:45 PM, Jan Beulich wrote:
>> On 14.04.2025 17:56, Oleksii Kurochko wrote:
>>> --- a/xen/include/xen/fdt-domain-build.h
>>> +++ b/xen/include/xen/fdt-domain-build.h
>>> @@ -5,6 +5,7 @@
>>> #include
>>> #include
>>> #include
>>>
On 22.04.2025 17:12, Oleksii Kurochko wrote:
> On 4/17/25 4:36 PM, Jan Beulich wrote:
>> On 14.04.2025 17:56, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/xen/fdt-domain-build.h
>>> @@ -0,0 +1,46 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __XEN_FDT_DOMAIN_BU
On 22.04.2025 17:06, Sergii Dmytruk wrote:
> The code comes from [1] and is licensed under GPL-2.0 or later version
> of the license. It's a combination of:
> - include/crypto/sha2.h
> - include/crypto/sha256_base.h
> - lib/crypto/sha256.c
> - crypto/sha256_generic.c
>
> Changes:
> - include
On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
> xen/include/xen/sha256.h | 12 ++
> xen/lib/Makefile | 1 +
> xen/lib/sha256.c | 238 +++
> 3 files changed, 251 insertions(+)
> create mode 100644 xen/include/xen/sha256.h
> create mode 100644
On 22.04.2025 17:06, Sergii Dmytruk wrote:
> From: Krystian Hebel
>
> The code comes from [1] and is licensed under GPL-2.0 license.
> It's a combination of:
> - include/crypto/sha1.h
> - include/crypto/sha1_base.h
> - lib/crypto/sha1.c
> - crypto/sha1_generic.c
>
> Changes:
> - includes
>
On 4/22/25 5:26 PM, Oleksii Kurochko wrote:
On 4/17/25 4:45 PM, Jan Beulich wrote:
On 14.04.2025 17:56, Oleksii Kurochko wrote:
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#i
On 4/17/25 4:45 PM, Jan Beulich wrote:
On 14.04.2025 17:56, Oleksii Kurochko wrote:
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#if __has_include()
@@ -32,7 +33,37 @@ int make_
On 4/17/25 4:36 PM, Jan Beulich wrote:
On 14.04.2025 17:56, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/include/xen/fdt-domain-build.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __XEN_FDT_DOMAIN_BUILD_H__
+#define __XEN_FDT_DOMAIN_BUILD_H__
+
+#include
+#include
On 22.04.2025 17:06, Sergii Dmytruk wrote:
> Kacper Stojek (2):
> x86/boot: add MLE header and new entry point
> xen/arch/x86: reserve TXT memory
>
> Krystian Hebel (7):
> x86/include/asm/intel_txt.h: constants and accessors for TXT registers
> and heap
> x86/boot/slaunch_early: early
The code comes from [1] and is licensed under GPL-2.0 or later version
of the license. It's a combination of:
- include/crypto/sha2.h
- include/crypto/sha256_base.h
- lib/crypto/sha256.c
- crypto/sha256_generic.c
Changes:
- includes
- formatting
- renames and splicing of some trivial funct
Use slr_entry_amd_info::boot_params_base on AMD with SKINIT to get MBI
location.
Another thing of interest is the location of SLRT which is bootloader's
data after SKL.
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/boot/head.S | 38
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/include/asm/intel_txt.h | 33 ++
xen/arch/x86/tpm.c | 169 ++-
2 files changed, 175 insertions(+), 27 deletions(-)
diff --git a/xen/arch/x86/include/asm/intel_txt.h
b/xen/arch/x86/include/asm/intel_txt
From: Michał Żygowski
Check whther IA32_FEATURE_CONTROL has the proper bits enabled to run
VMX in SMX when slaunch is active.
Signed-off-by: Michał Żygowski
---
xen/arch/x86/hvm/vmx/vmcs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/a
From: Krystian Hebel
In preparation for TXT SENTER call, GRUB had to modify MTRR settings
to be UC for everything except SINIT ACM. Old values are restored
from SLRT where they were saved by the bootloader.
Signed-off-by: Krystian Hebel
Signed-off-by: Michał Żygowski
Signed-off-by: Sergii Dmyt
When running on an EFI-enabled system, Xen needs to have access to Boot
Services in order to initialize itself properly and reach a state in
which a dom0 kernel can operate without issues.
This means that DRTM must be started in the middle of Xen's
initialization process. This effect is achieved
From: Krystian Hebel
This file is built twice: for early 32b mode without paging to measure
MBI and for 64b code to measure dom0 kernel and initramfs. Since MBI
is small, the first case uses TPM to do the hashing. Kernel and
initramfs on the other hand are too big, sending them to the TPM would
t
This mostly involves not running Intel-specific code when on AMD.
There are only a few new AMD-specific implementation details:
- finding SLB start and size and then mapping and reserving it in e820
- managing offset for adding the next TPM log entry (TXT-compatible
data prepared by SKL is st
On 4/17/25 10:08 AM, Orzel, Michal wrote:
I'm ok with making dom0less common in principle but I don't know if we should
keep using the word dom0less which we all know is confusing. In one of the
maintainers call we agreed on using "predefined domUs" to denote the concept of
starting domUs at boo
From: Krystian Hebel
This is made as the first step of making parallel AP bring-up possible.
It should be enough for pre-C code.
Parallel AP bring-up is necessary because TXT by design releases all APs
at once. In addition to that it reduces number of IPIs (and more
importantly, delays between t
Go through entires in the DRTM policy of SLRT to hash and extend data
that they describe into corresponding PCRs.
Addresses are being zeroed on measuring platform-specific data to
prevent measurements from changing when the only thing that has changed
is an address. Addresses can vary due to boot
SHA1 and SHA256 are hard-coded here, but their support by the TPM is
checked. Addition of event log for TPM2.0 will generalize the code
further.
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/tpm.c | 465 +++--
1 file changed, 453 insertions(+), 12 deleti
From: Krystian Hebel
On Intel TXT, APs are started in one of two ways, depending on ACM
which reports it in its information table. In both cases, all APs are
started simultaneously after BSP requests them to do so. Two possible
ways are:
- GETSEC[WAKEUP] instruction,
- MONITOR address.
GETSEC[WA
From: Michał Żygowski
Report TXT capabilities so that dom0 can query the Intel TXT or AMD
SKINIT support information using xl dmesg.
Signed-off-by: Michał Żygowski
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/cpu/amd.c | 14 +
xen/arch/x86/cpu/cpu.h | 1
On Tue, Apr 22, 2025, Xin Li (Intel) wrote:
> __rdmsr() is the lowest level primitive MSR read API, and its direct
> use is NOT preferred.
Doesn't mean it's wrong.
> Use its wrapper function native_rdmsrq() instead.
...
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 1547
From: Krystian Hebel
The code comes from [1] and is licensed under GPL-2.0 license.
It's a combination of:
- include/crypto/sha1.h
- include/crypto/sha1_base.h
- lib/crypto/sha1.c
- crypto/sha1_generic.c
Changes:
- includes
- formatting
- renames and splicing of some trivial functions tha
Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
platform-specific way. This is also the place to perform sanity checks
of DRTM.
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/Makefile| 1 +
xen/arch/x86/boot/Makefile
From: Kacper Stojek
TXT heap, SINIT and TXT private space are marked as reserved or unused
in e820 to protect from unintended uses.
Signed-off-by: Kacper Stojek
Signed-off-by: Krystian Hebel
Signed-off-by: Michał Żygowski
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/Makefile
The file provides constants, structures and several helper functions for
parsing SLRT.
Signed-off-by: Sergii Dmytruk
---
xen/include/xen/slr_table.h | 274
1 file changed, 274 insertions(+)
create mode 100644 xen/include/xen/slr_table.h
diff --git a/xen/inc
From: Krystian Hebel
The tests validate that important parts of memory are protected against
DMA attacks, including Xen and MBI. Modules can be tested later, when it
is possible to report issues to a user before invoking TXT reset.
TPM event log validation is temporarily disabled due to an issue
This allows the functionality to be reused by other units that need to
update MTRRs.
This also gets rid of a static variable.
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/cpu/mtrr/generic.c | 51 -
xen/arch/x86/include/asm/mtrr.h | 8 ++
2 files changed, 3
The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
- Intel TXT and AMD SKINIT on x86 CPUs
- legacy and UEFI boot
- TPM1.2 and TPM2.0
- (in the future) DRTM on Arm CPUs
DRTM is a version of a measured launch that starts
From: Kacper Stojek
Signed-off-by: Kacper Stojek
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
docs/hypervisor-guide/x86/how-xen-boots.rst | 5 ++
xen/arch/x86/boot/head.S| 53 +
2 files changed, 58 insertions(+)
diff --git a/docs/hy
From: Krystian Hebel
The file contains TXT register spaces base address, registers offsets,
error codes and inline functions for accessing structures stored on
TXT heap.
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/include/asm/intel_txt.h | 272
On Tue, Apr 22, 2025, Xin Li (Intel) wrote:
> base-commit: f30a0c0d2b08b355c01392538de8fc872387cb2b
This commit doesn't exist in Linus' tree or the tip tree, and the series doesn't
apply cleanly on any of the "obvious" choices. Reviewing a 34 patches series
without being able to apply it is a wee
On 4/10/25 03:45, Jan Beulich wrote:
With us now reading the full combined optional and NT headers, the
subsequent reading of (and seeking to) NT header fields is wrong. Since
PE32 and PE32+ NT headers are different anyway (beyond the image base
oddity extending across both headers), switch to
On 10.04.2025 09:45, Jan Beulich wrote:
> With us now reading the full combined optional and NT headers, the
> subsequent reading of (and seeking to) NT header fields is wrong. Since
> PE32 and PE32+ NT headers are different anyway (beyond the image base
> oddity extending across both headers), swi
On 22.04.2025 16:42, Andrew Cooper wrote:
> On 22/04/2025 1:13 pm, Jan Beulich wrote:
>> On 22.04.2025 13:32, Andrew Cooper wrote:
>>> --- a/xen/include/xen/xen.lds.h
>>> +++ b/xen/include/xen/xen.lds.h
>>> @@ -56,6 +56,7 @@
>>>DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
>>>DECL_DEBUG
On 22/04/2025 1:13 pm, Jan Beulich wrote:
> On 22.04.2025 13:32, Andrew Cooper wrote:
>> --- a/xen/include/xen/xen.lds.h
>> +++ b/xen/include/xen/xen.lds.h
>> @@ -56,6 +56,7 @@
>>DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
>>DECL_DEBUG(.debug_types, 1) \
>>DECL
On 22/04/2025 16:31, Oleksii Kurochko wrote:
>
> On 4/17/25 9:38 AM, Orzel, Michal wrote:
>> On 14/04/2025 17:56, Oleksii Kurochko wrote:
>>> There is no any users of handle_device_interrupts() thereby it
>>> could be dropped.
>> It reads as if you were dropping a definition. There is no defini
On 4/17/25 9:38 AM, Orzel, Michal wrote:
On 14/04/2025 17:56, Oleksii Kurochko wrote:
There is no any users of handle_device_interrupts() thereby it
could be dropped.
It reads as if you were dropping a definition. There is no definition, therefore
no users. Prototype was added by accident in:
On 22.04.2025 13:41, Andrew Cooper wrote:
> We have a mix of all 3 spellings in Xen, as well as having compatibility in
> compiler.h for older C standards.
>
> Remove the use of __alignof() and __alignof__(), which reduced code volume a
> little.
>
> No functional change.
>
> Signed-off-by: Andr
1 - 100 of 170 matches
Mail list logo
