On Thu, 13 Feb 2025 at 11:11, Alexander Graf wrote:
>
>
> On 13.02.25 10:41, Ard Biesheuvel wrote:
> > On Tue, 11 Feb 2025 at 10:23, Gerd Hoffmann wrote:
> >> This patch adds a virtual device to qemu which the uefi firmware can use
> >> to store variabl
On Tue, 11 Feb 2025 at 10:23, Gerd Hoffmann wrote:
>
> This patch adds a virtual device to qemu which the uefi firmware can use
> to store variables. This moves the UEFI variable management from
> privileged guest code (managing vars in pflash) to the host. Main
> advantage is that the need to h
On Wed, 12 Feb 2025 at 22:26, Alexander Graf wrote:
>
>
> On 12.02.25 16:18, Gerd Hoffmann wrote:
> >Hi,
> >
> >>> Yes. Knowing both physical and virtual address works only for memory
> >>> you allocated yourself before ExitBootServices. So you can't pass on
> >>> pointers from the OS, you h
On Sun, 29 Sept 2024 at 20:07, Ard Biesheuvel wrote:
>
> Fix the handling of the ELF note that describes the PVH entrypoint
>
> v2: fix broken ELF note handling on big endian hosts
>
> Ard Biesheuvel (2):
> hw/elf_ops: Implement missing endian swabbing for ELF notes
>
Fix the handling of the ELF note that describes the PVH entrypoint
v2: fix broken ELF note handling on big endian hosts
Ard Biesheuvel (2):
hw/elf_ops: Implement missing endian swabbing for ELF notes
hw/x86: Always treat the PVH entrypoint as a 32-bit LE field
hw/i386/x86-common.c | 7
ELF notes have type and size fields in the elf_note header that need to
be swabbed before use if the host endianness differs from the endianness
of the ELF binary.
Signed-off-by: Ard Biesheuvel
---
include/hw/elf_ops.h.inc | 19 +--
1 file changed, 17 insertions(+), 2 deletions
citly, so things work
as expected on big endian hosts too.
Signed-off-by: Ard Biesheuvel
---
hw/i386/x86-common.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/i386/x86-common.c b/hw/i386/x86-common.c
index 992ea1f25e..44e5c365f1 100644
--- a/hw/i386/x86-common.c
On Fri, 27 Sept 2024 at 14:05, Paolo Bonzini wrote:
>
> On 9/27/24 09:19, Ard Biesheuvel wrote:
> > -
> > -pvh_start_addr = *(uint32_t *)elf_note_data_addr;
> > }
> >
> > +pvh_start_addr = *(uint32_t *)elf_note_data_addr;
>
> I thin
From: Ard Biesheuvel
The PVH entrypoint is entered in 32-bit mode, and is documented as being
a 32-bit field. Linux happens to widen the field in the ELF note to 64
bits so treating it as a 64-bit field works for booting the kernel.
However, Xen documents the ELF note with the following example
From: Ard Biesheuvel
target_ulong is typedef'ed as a 32-bit integer when building the
qemu-system-arm target, and this is smaller than the size of an
intermediate physical address when LPAE is being used.
Given that Linux may place leaf level user page tables in high memory
when built for
From: Ard Biesheuvel
target_ulong is typedef'ed as a 32-bit integer when building the
qemu-system-arm target, and this is smaller than the size of an
intermediate physical address when LPAE is being used.
Given that Linux may place leaf level user page tables in high memory
when built for
On Thu, 20 Jun 2024 at 12:20, Marcin Juszkiewicz
wrote:
>
> Update firmware to have graphics card memory fix from EDK2 commit
> c1d1910be6e04a8b1a73090cf2881fb698947a6e:
>
> OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C
>
> Some platforms (such as SBSA-QEMU on recent build
On Mon, 17 Jun 2024 at 10:37, Marcin Juszkiewicz
wrote:
>
> If we draw logo at odd coords then BootLogoLib goes into exception and
> boot process ends:
>
> Synchronous Exception at 0x0101FB943E48
> PC 0x0101FB943E48 (0x0101FB93F000+0x4E48) [ 0] QemuVideoDxe.dll
> PC 0x0101FB943314 (0x0101F
On Tue, 4 Jun 2024 at 20:08, Jean-Philippe Brucker
wrote:
>
> On Fri, May 31, 2024 at 05:24:44PM +0200, Ard Biesheuvel wrote:
> > > I'm able to reproduce this even without RME. This code was introduced
> > > recently by c98f7f755089 ("ArmVirtPkg: Use dynamic
On Fri, 31 May 2024 at 17:09, Jean-Philippe Brucker
wrote:
>
> Hi Gavin,
>
> On Fri, May 31, 2024 at 04:23:13PM +1000, Gavin Shan wrote:
> > I got a chance to try CCA software components, suggested by [1]. However,
> > the edk2
> > is stuck somewhere. I didn't reach to stage of loading guest kern
On Fri, 19 Apr 2024 at 18:36, Ard Biesheuvel wrote:
>
> On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io
> wrote:
> >
> > On Fri, 19 Apr 2024 13:52:07 +0200
> > Gerd Hoffmann wrote:
> >
> > > Hi,
> > >
> > > > G
ide of a requirement for strict alignment.
> So with out the errata
> DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
> is replaced with
> [BuildOptions]
> +!if $(CAVIUM_ERRATUM_27456) == TRUE^M
> + GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M
> +!else^M
>
On Thu, 15 Feb 2024 at 21:47, Richard Henderson
wrote:
>
> On 2/15/24 06:02, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > The Cortex-A53 r0p4 revision that QEMU emulates is affected by a CatA
> > erratum #843419 (i.e., the most severe), which requires wo
From: Ard Biesheuvel
The Cortex-A53 r0p4 revision that QEMU emulates is affected by a CatA
erratum #843419 (i.e., the most severe), which requires workarounds in
the toolchain as well as the OS.
Since the emulation is obviously not affected in the same way, we can
indicate this via REVIDR bit
rt on bootup
> * patch 2 commit message improved to give details of the EDK2 assert and
>state the options for dealing with it (this will also go into the
>QEMU release notes)
>
> thanks
> -- PMM
>
> Peter Maydell (3):
> tests/qtest/bios-tables-test: Allow changes to virt GTDT
> hw/arm/virt: Wire up non-secure EL2 virtual timer IRQ
> tests/qtest/bios-tables-tests: Update virt golden reference
>
Reviewed-by: Ard Biesheuvel
On Thu, 21 Sept 2023 at 10:50, Peter Maydell wrote:
>
> Hi; I've been looking again at a very long standing missing feature in
> the QEMU virt board, which is that we only have one UART. One of the
> things that has stalled this in the past has been the odd behaviour of
> EDK2 if the DTB that QEMU
\,arch_timer.yaml
> and the ACPI table entries are documented in the ACPI
> specification version 6.3 or later.
>
> Signed-off-by: Peter Maydell
As mentioned in reply to the cover letter, this needs the hunk below
to avoid using ACPI 6.3 features while claiming compatibility with
ACPI
Hi Peter,
On Tue, 19 Sept 2023 at 12:12, Peter Maydell wrote:
>
> This patchset is an RFC that wires up the NS EL2 virtual timer IRQ on
> the virt board, similarly to what
> https://patchew.org/QEMU/20230913140610.214893-1-marcin.juszkiew...@linaro.org/
> does for the sbsa-ref board.
>
> Patches
_16x2_even:
> + *
> + * Perform two 16x16->32 carry-less multiplies.
> + * The odd words of the inputs are ignored.
> + */
> +uint64_t clmul_16x2_even(uint64_t, uint64_t);
> +
> +/**
> + * clmul_16x2_odd:
> + *
> + * Perform two 16x16->32 carry-less multiplies.
&
On Mon, 21 Aug 2023 at 18:18, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Reviewed-by: Ard Biesheuvel
> ---
> include/crypto/clmul.h | 41 +
> crypto/clmul.c | 60 ++
> crypto/me
On Mon, 21 Aug 2023 at 18:19, Richard Henderson
wrote:
>
> Detect PCLMUL in cpuinfo; implement the accel hook.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Ard Biesheuvel
> ---
> host/include/i386/host/cpuinfo.h| 1 +
> host/include/i386/host/
On Mon, 21 Aug 2023 at 18:19, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Reviewed-by: Ard Biesheuvel
> ---
> host/include/generic/host/crypto/clmul.h | 15 +++
> include/crypto/clmul.h | 19 +++
&g
On Mon, 21 Aug 2023 at 18:19, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Replied to v2 by accident:
Reviewed-by: Ard Biesheuvel
> ---
> include/crypto/clmul.h | 7 +++
> crypto/clmul.c | 13 +
> 2 files changed, 20 insertions(+
On Sat, 19 Aug 2023 at 03:02, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Reviewed-by: Ard Biesheuvel
> ---
> include/crypto/clmul.h | 7 +++
> crypto/clmul.c | 13 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/
On Sat, 19 Aug 2023 at 03:02, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Reviewed-by: Ard Biesheuvel
> ---
> include/crypto/clmul.h | 16
> crypto/clmul.c | 21 +
> 2 files changed, 37 insertions(+)
>
&
On Sat, 19 Aug 2023 at 03:02, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Reviewed-by: Ard Biesheuvel
> ---
> include/crypto/clmul.h | 41 +
> crypto/clmul.c | 60 ++
> crypto/me
Mathieu-Daudé
Cc: Palmer Dabbelt
Cc: Alistair Francis
Signed-off-by: Ard Biesheuvel
---
v2: assign round constant to elements 0 and 1 only
target/riscv/crypto_helper.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/target/riscv/crypto_helper.c b/target
did the OpenSSL benchmark this time, using a x86_64 cross build
on arm64/ThunderX2, and the speedup is 7x (\o/)
Tested-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
Distro qemu (no acceleration):
$ qemu-x86_64 --version
qemu-x86_64 version 7.2.4 (Debian 1:7.2+dfsg-7+deb12u1)
$ apps/openssl sp
On Mon, 21 Aug 2023 at 17:15, Richard Henderson
wrote:
>
> On 8/21/23 07:57, Ard Biesheuvel wrote:
> >> Richard Henderson (18):
> >>crypto: Add generic 8-bit carry-less multiply routines
> >>target/arm: Use clmul_8* routines
> >>target/s390x
64
> target/s390x: Use clmul_64
> target/ppc: Use clmul_64
> host/include/i386: Implement clmul.h
> host/include/aarch64: Implement clmul.h
>
I didn't re-run the OpenSSL benchmark, but the x86 Linux kernel still
passes all its crypto selftests when running under TCG emulation on a
TX2 arm64 host, so
Tested-by: Ard Biesheuvel
for the series.
Thanks,
Ard.
(cc riscv maintainers)
On Mon, 31 Jul 2023 at 11:39, Ard Biesheuvel wrote:
>
> Use the accelerated SubBytes/ShiftRows/AddRoundKey AES helper to
> implement the first half of the key schedule derivation. This does not
> actually involve shifting rows, so clone the same uint32_t 4 time
On Thu, 13 Jul 2023 at 23:14, Richard Henderson
wrote:
>
> Inspired by Ard Biesheuvel's RFC patches [1] for accelerating
> carry-less multiply under emulation.
>
> This is less polished than the AES patch set:
>
> (1) Should I split HAVE_CLMUL_ACCEL into per-width HAVE_CLMUL{N}_ACCEL?
> The "_
-off-by: Ard Biesheuvel
---
target/riscv/crypto_helper.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/target/riscv/crypto_helper.c b/target/riscv/crypto_helper.c
index 4d65945429c6dcc4..257c5c4863fb160f 100644
--- a/target/riscv/crypto_helper.c
+++ b
: Junqiang Wang
Signed-off-by: Ard Biesheuvel
---
v2:
- ignore host endianness and use be32_to_cpu() unconditionally
crypto/aes.c | 4 +--
include/crypto/aes.h | 7
target/riscv/crypto_helper.c | 34 +++-
3 files changed, 13 insertions(+), 32 deletions
On Wed, 26 Jul 2023 at 17:01, Richard Henderson
wrote:
>
> On 7/26/23 01:17, Ard Biesheuvel wrote:
> > While working on some EFI boot changes for Linux/x86, I noticed that TCG
> > deviates from
> > bare metal when it comes to how it handles the value of the stack p
On Fri, 28 Jul 2023 at 02:17, Richard Henderson
wrote:
>
> On 7/27/23 14:36, Ard Biesheuvel wrote:
> > On Thu, 27 Jul 2023 at 19:56, Richard Henderson
> > wrote:
> >>
> >> On 7/26/23 08:01, Richard Henderson wrote:
> >>> On 7/26/23 01:17, Ard Bie
On Thu, 27 Jul 2023 at 19:56, Richard Henderson
wrote:
>
> On 7/26/23 08:01, Richard Henderson wrote:
> > On 7/26/23 01:17, Ard Biesheuvel wrote:
> >> Hints welcome on where the architectural behavior is specified, and in
> >> particular,
> >> whether or n
: Junqiang Wang
Signed-off-by: Ard Biesheuvel
---
crypto/aes.c | 5 ++--
include/crypto/aes.h | 7 +
target/riscv/crypto_helper.c | 30
3 files changed, 14 insertions(+), 28 deletions(-)
diff --git a/crypto/aes.c b/crypto/aes.c
index 836d7d5c0bf1b392
n RSP
retaining its value does not inadvertently work while bare metal does
not.
Observed on Intel Ice Lake cores.
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Link: https://lore.kernel.org/all/20230711091453.2543622-11-a...@kernel.org/
Signed-off-by: Ard Biesheuvel
---
I used this
On Fri, 9 Jun 2023 at 04:24, Richard Henderson
wrote:
>
> These symbols will avoid the indirection through memory
> when fully unrolling some new primitives.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Richard Henderson
> ---
> crypto/aes.c | 50
On Sat, 3 Jun 2023 at 15:23, Ard Biesheuvel wrote:
>
> On Sat, 3 Jun 2023 at 04:34, Richard Henderson
> wrote:
> >
> > Inspired by Ard Biesheuvel's RFC patches for accelerating AES
> > under emulation, provide a set of primitives that maps between
> > the g
On Sat, 3 Jun 2023 at 04:34, Richard Henderson
wrote:
>
> Inspired by Ard Biesheuvel's RFC patches for accelerating AES
> under emulation, provide a set of primitives that maps between
> the guest and host fragments.
>
> There is a small guest correctness test case.
>
> I think the end result is q
On Sat, 3 Jun 2023 at 04:34, Richard Henderson
wrote:
>
> Detect AES in cpuinfo; implement the accel hooks.
>
> Signed-off-by: Richard Henderson
> ---
> host/include/aarch64/host/aes-round.h | 204 ++
> host/include/aarch64/host/cpuinfo.h | 1 +
> util/cpuinfo-aarch64
On Sat, 3 Jun 2023 at 04:34, Richard Henderson
wrote:
>
> Start adding infrastructure for accelerating guest AES.
> Begin with a SubBytes + ShiftRows primitive.
>
> Signed-off-by: Richard Henderson
> ---
> host/include/generic/host/aes-round.h | 15 +
> include/crypto/aes-round.h
On Sat, 3 Jun 2023 at 04:34, Richard Henderson
wrote:
>
> We do not currently have a table in crypto/ for
> just MixColumns. Move both tables for consistency.
>
> Signed-off-by: Richard Henderson
> ---
> include/crypto/aes.h | 6 ++
> crypto/aes.c | 142 +++
On Thu, 1 Jun 2023 at 20:00, Leif Lindholm wrote:
>
> +Ard
>
> On Thu, Jun 01, 2023 at 16:01:43 +0100, Peter Maydell wrote:
> > > >> Also has EHCI never worked, or has it worked in some modes and so this
> > > >> change should be versioned?
> > > >
> > > > AIUI, EHCI has never worked and can never
On Thu, 1 Jun 2023 at 14:33, Ard Biesheuvel wrote:
>
> Use the AArch64 PMULL{2}.P64 instructions to implement PCLMULQDQ instead
> of emulating them in C code if the host supports this. This is used in
> the implementation of GCM, which is widely used in IPsec VPN and HTTPS.
On Thu, 1 Jun 2023 at 15:01, Peter Maydell wrote:
>
> On Thu, 1 Jun 2023 at 13:33, Ard Biesheuvel wrote:
> >
> > Signed-off-by: Ard Biesheuvel
> > ---
> > host/include/i386/host/cpuinfo.h | 1 +
> > target/arm/tcg/vec_helper.c | 26 +
Signed-off-by: Ard Biesheuvel
---
host/include/i386/host/cpuinfo.h | 1 +
target/arm/tcg/vec_helper.c | 26 +++-
util/cpuinfo-i386.c | 1 +
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/host/include/i386/host/cpuinfo.h b/host/include/i386/host
, 1420 byte blocks): 24372 operations in 1 seconds
(34608240 bytes)
Signed-off-by: Ard Biesheuvel
---
host/include/aarch64/host/cpuinfo.h | 1 +
target/i386/ops_sse.h | 24
util/cpuinfo-aarch64.c | 1 +
3 files changed, 26 insertions(+)
diff --git
c: Peter Maydell
Cc: Alex Bennée
Cc: Richard Henderson
Cc: Philippe Mathieu-Daudé
Ard Biesheuvel (2):
target/arm: Use x86 intrinsics to implement PMULL.P64
target/i386: Implement PCLMULQDQ using AArch64 PMULL instructions
host/include/aarch64/host/cpuinfo.h | 1 +
host/include/i386/host/c
On Wed, 31 May 2023 at 18:33, Richard Henderson
wrote:
>
> On 5/31/23 04:22, Ard Biesheuvel wrote:
> > Use the host native instructions to implement the AES instructions
> > exposed by the emulated target. The mapping is not 1:1, so it requires a
> > bit of fiddling
When available, use the AArch64 AES instructions to implement the x86
ones. These are not a 1:1 fit, but considerably more efficient, and
without data dependent timing.
For a typical benchmark (linux tcrypt mode=500), this gives a 2-3x
speedup when running on ThunderX2.
Signed-off-by: Ard
ends on whether there is a third host
architecture that could make use of this, and how its AES instructions
map onto the primitive AES ops above.
Cc: Peter Maydell
Cc: Alex Bennée
Cc: Richard Henderson
Cc: Philippe Mathieu-Daudé
Ard Biesheuvel (2):
target/arm: use x86 intrinsics t
an important property in crypto) and substantially more
efficient.
Signed-off-by: Ard Biesheuvel
---
host/include/i386/host/cpuinfo.h | 1 +
target/arm/tcg/crypto_helper.c | 37 ++--
util/cpuinfo-i386.c | 1 +
3 files changed, 36 insertions(+), 3 deletions
On Tue, 30 May 2023 at 18:45, Peter Maydell wrote:
>
> On Tue, 30 May 2023 at 14:52, Ard Biesheuvel wrote:
> >
> > ARM intrinsics for AES deviate from the x86 ones in the way they cover
> > the different stages of each round, and so mapping one to the other is
> >
On Tue, 30 May 2023 at 18:43, Richard Henderson
wrote:
>
> On 5/30/23 06:52, Ard Biesheuvel wrote:
> > +#ifdef __x86_64__
> > +if (have_aes()) {
> > +__m128i *d = (__m128i *)rd;
> > +
> > +*d = decrypt ? _mm_aesdec
an important property in crypto) and substantially more
efficient.
Cc: Peter Maydell
Cc: Alex Bennée
Cc: Richard Henderson
Cc: Philippe Mathieu-Daudé
Signed-off-by: Ard Biesheuvel
---
Suggestions welcome on how to make this more generic across targets and
compilers etc.
target/arm/tcg
hassle, by parsing the header and grabbing the payload from inside
the loaded zboot image.
Cc: Peter Maydell
Cc: Alex Bennée
Cc: Richard Henderson
Cc: Philippe Mathieu-Daudé
Signed-off-by: Ard Biesheuvel
---
v2:
- only attempt EFI zboot unpacking of raw images
- check MS-DOS magic as well
On Fri, 3 Mar 2023 at 15:25, Peter Maydell wrote:
>
> On Thu, 23 Feb 2023 at 10:53, Ard Biesheuvel wrote:
> >
> > Fedora 39 will ship its arm64 kernels in the new generic EFI zboot
> > format, using gzip compression for the payload.
> >
> > For doing
hassle, by parsing the header and grabbing the payload from inside
the loaded zboot image.
Cc: Peter Maydell
Cc: Alex Bennée
Cc: Richard Henderson
Cc: Philippe Mathieu-Daudé
Signed-off-by: Ard Biesheuvel
---
hw/arm/boot.c | 4 ++
hw/core/loader.c| 64
include
e been on KVM, and like they were on TCG
> before 5d971f9e6725 (v5.1.0).
>
> Tested with:
>
> - OVMF IA32 + qemu-system-i386, CPU hotplug/hot-unplug with SMM,
> intermixed with ACPI S3 suspend/resume, using KVM accel
> (regression-test);
>
> - OVMF IA32X64 + qemu-syst
On Mon, 2 Jan 2023 at 14:37, Borislav Petkov wrote:
>
> On Mon, Jan 02, 2023 at 10:32:03AM +0100, Ard Biesheuvel wrote:
> > So instead of appending data to the compressed image and assuming that
> > it will stay in place, create or extend a memory reservation
> > els
On Mon, 2 Jan 2023 at 07:17, Borislav Petkov wrote:
>
> On Mon, Jan 02, 2023 at 07:01:50AM +0100, Borislav Petkov wrote:
> > On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote:
> > > It would probably be a good idea to add a "maximum physical address for
> > > initrd/setup_data/cmdline
On Tue, 20 Dec 2022 at 16:33, Gerd Hoffmann wrote:
>
> On Tue, Dec 20, 2022 at 10:30:43AM +0100, Philippe Mathieu-Daudé wrote:
> > [Extending to people using UEFI VARStore on Virt machines]
> >
> > On 20/12/22 09:42, Gerd Hoffmann wrote:
> > > From: Xiang Zheng
> > >
> > > Currently we fill the V
On Fri, 2 Dec 2022 at 03:48, chenxiang (M) wrote:
>
> Hi Ard,
>
>
> 在 2022/12/1 19:07, Ard Biesheuvel 写道:
> > On Thu, 1 Dec 2022 at 09:07, Ard Biesheuvel wrote:
> >> On Thu, 1 Dec 2022 at 08:15, chenxiang (M)
> >> wrote:
> >>> Hi Ard,
>
On Thu, 1 Dec 2022 at 13:07, chenxiang (M) wrote:
>
>
>
> 在 2022/12/1 19:07, Ard Biesheuvel 写道:
> > On Thu, 1 Dec 2022 at 09:07, Ard Biesheuvel wrote:
> >> On Thu, 1 Dec 2022 at 08:15, chenxiang (M)
> >> wrote:
> >>> Hi Ard,
> >>>
On Thu, 1 Dec 2022 at 09:07, Ard Biesheuvel wrote:
>
> On Thu, 1 Dec 2022 at 08:15, chenxiang (M) wrote:
> >
> > Hi Ard,
> >
> >
> > 在 2022/11/30 16:18, Ard Biesheuvel 写道:
> > > On Wed, 30 Nov 2022 at 08:53, Marc Zyngier wrote:
> > >>
On Thu, 1 Dec 2022 at 08:15, chenxiang (M) wrote:
>
> Hi Ard,
>
>
> 在 2022/11/30 16:18, Ard Biesheuvel 写道:
> > On Wed, 30 Nov 2022 at 08:53, Marc Zyngier wrote:
> >> On Wed, 30 Nov 2022 02:52:35 +,
> >> "chenxiang (M)" wrote:
> >>
On Wed, 30 Nov 2022 at 08:53, Marc Zyngier wrote:
>
> On Wed, 30 Nov 2022 02:52:35 +,
> "chenxiang (M)" wrote:
> >
> > Hi,
> >
> > We boot the VM using following commands (with nvdimm on) (qemu
> > version 6.1.50, kernel 6.0-r4):
>
> How relevant is the presence of the nvdimm? Do you observe
d
be typed as such. So turn it from uint32_t into int32_t.
This avoids a level of -1 getting misinterpreted as being >= 3, and
terminating a page table walk prematurely with a bogus output address.
Cc: Peter Maydell
Cc: Philippe Mathieu-Daudé
Cc: Richard Henderson
Signed-off-by: A
On Tue, 22 Nov 2022 at 14:21, Peter Maydell wrote:
>
> On Mon, 21 Nov 2022 at 19:02, Ard Biesheuvel wrote:
> >
> > On Mon, 21 Nov 2022 at 19:51, Peter Maydell
> > wrote:
> > >
> > > On Mon, 21 Nov 2022 at 17:43, Ard Biesheuvel wrote:
> >
On Mon, 21 Nov 2022 at 19:51, Peter Maydell wrote:
>
> On Mon, 21 Nov 2022 at 17:43, Ard Biesheuvel wrote:
> >
> > The LPA2 extension implements 52-bit virtual addressing for 4k and 16k
> > translation granules, and for the former, this means an additional level
>
d
be typed as such. So turn it from uint32_t into int32_t.
Cc: Peter Maydell
Cc: Philippe Mathieu-Daudé
Cc: Richard Henderson
Signed-off-by: Ard Biesheuvel
---
target/arm/ptw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/ptw.c b/target/arm/ptw.c
index
architecture.
Cc: Peter Maydell
Cc: Philippe Mathieu-Daudé
Cc: Richard Henderson
Signed-off-by: Ard Biesheuvel
---
target/arm/ptw.c | 8
1 file changed, 8 insertions(+)
diff --git a/target/arm/ptw.c b/target/arm/ptw.c
index 3745ac9723474332..9a6277d862fac229 100644
--- a/target/arm/
so this makes that
> consistent.)
>
> Cc: Gerd Hoffmann
> Cc: Laurent Vivier
> Cc: Michael S. Tsirkin
> Cc: Paolo Bonzini
> Cc: Peter Maydell
> Cc: Philippe Mathieu-Daudé
> Cc: Richard Henderson
> Suggested-by: Ard Biesheuvel
> Signed-off-by: Jason A. Donenfeld
On Thu, 8 Sept 2022 at 13:30, Laszlo Ersek wrote:
>
> On 09/06/22 13:33, Daniel P. Berrangé wrote:
> > On Tue, Sep 06, 2022 at 01:14:50PM +0200, Ard Biesheuvel wrote:
> >> (cc Laszlo)
> >>
> >> On Tue, 6 Sept 2022 at 12:45, Michael S. Tsirkin wrote:
> &g
V
> > > > too.
> > > > This depends on the kernel commit linked below going upstream.
> > > >
> > > > Cc: Gerd Hoffmann
> > > > Cc: Laurent Vivier
> > > > Cc: Michael S. Tsirkin
> > > > Cc: Paolo Bonzini
> >
On Fri, 19 Aug 2022 at 08:41, Gerd Hoffmann wrote:
>
> On Thu, Aug 18, 2022 at 05:38:37PM +0200, Jason A. Donenfeld wrote:
> > Hey Gerd,
> >
> > > Joining the party late (and still catching up the thread). Given we
> > > don't need that anyway with EFI, only with legacy BIOS: Can't that just
> >
On Fri, 5 Aug 2022 at 19:29, Paolo Bonzini wrote:
>
> On 8/5/22 13:08, Ard Biesheuvel wrote:
> >>
> >> Does it work to place setup_data at the end of the cmdline file instead
> >> of having it at the end of the kernel file? This way the first item
>
On Fri, 5 Aug 2022 at 10:10, Paolo Bonzini wrote:
>
> On 8/5/22 01:04, Jason A. Donenfeld wrote:
> > +/* Nothing else uses this part of the hardware mapped region */
> > +setup_data_base = 0xf - 0x1000;
>
> Isn't this where the BIOS lives? I don't think this works.
>
> Does it work to
On Thu, 4 Aug 2022 at 14:11, Daniel P. Berrangé wrote:
>
> On Thu, Aug 04, 2022 at 02:03:29PM +0200, Jason A. Donenfeld wrote:
> > Hi Daniel,
> >
> > On Thu, Aug 04, 2022 at 10:25:36AM +0100, Daniel P. Berrangé wrote:
> > > Yep, and ultimately the inability to distinguish UEFI vs other firmware
>
ss.
> > >>
> > >> Fixes: 3cbeb52467 ("hw/i386: add device tree support")
> > >> Reported-by: Xiaoyao Li
> > >> Cc: Paolo Bonzini
> > >> Cc: Richard Henderson
> > >> Cc: Peter Maydell
> > >> Cc: Michael S.
On Fri, 25 Feb 2022 at 16:12, Alexander Graf wrote:
>
>
> On 25.02.22 15:33, Jason A. Donenfeld wrote:
> > On Fri, Feb 25, 2022 at 03:18:43PM +0100, Alexander Graf wrote:
> >>> I recall this part of the old thread. From what I understood, using
> >>> "VMGENID" + "QEMUVGID" worked /well enough/, ev
gt; > +}
> > +
> > +static void __exit vmgenid_exit(void)
> > +{
> > + acpi_bus_unregister_driver(&acpi_driver);
> > +}
> > +
> > +module_init(vmgenid_init);
> > +module_exit(vmgenid_exit);
>
> Nit, you could use module_acpi_driver() to make this even smaller if you
> want to.
>
With that suggestion adopted,
Reviewed-by: Ard Biesheuvel
ion-id-across-hypervisors.txt>,
> > so this driver simply treats these bytes as an opaque 128-bit binary
> > blob, as per the spec. This doesn't really make a difference anyway,
> > considering that's how it ends up when handed to the RNG in the end.
> >
On Fri, 25 Feb 2022 at 12:44, Jason A. Donenfeld wrote:
>
> On Fri, Feb 25, 2022 at 12:26 PM Ard Biesheuvel wrote:
> >
> > On Thu, 24 Feb 2022 at 14:39, Jason A. Donenfeld wrote:
> > >
> > > When a VM forks, we must immediately mix in additional information
ve already been used by a different fork, or generally gone
> stale -- does not contribute to the accounting of the next 256 bits.
>
> Cc: Dominik Brodowski
> Cc: Theodore Ts'o
> Cc: Jann Horn
> Cc: Eric Biggers
> Signed-off-by: Jason A. Donenfeld
Ac
nded to the RNG in the end.
>
> This driver builds on prior work from Adrian Catangiu at Amazon, and it
> is my hope that that team can resume maintenance of this driver.
>
> Cc: Adrian Catangiu
> Cc: Laszlo Ersek
> Cc: Daniel P. Berrangé
&
On Tue, 11 Jan 2022 at 15:11, Peter Maydell wrote:
>
> On Sat, 8 Jan 2022 at 15:10, Ard Biesheuvel wrote:
> >
> > When running under KVM, we may decide to run the CPU in 32-bit mode, by
> > setting the 'aarch64=off' CPU option. In this case, we need to switch to
and
errors out upon connecting to the target with a mysterious 'g' packet
length error.
Cc: Richard Henderson
Cc: Peter Maydell
Cc: Alex Bennee
Signed-off-by: Ard Biesheuvel
---
v2: refactor existing CPUClass::gdb_... member assignments for the
32-bit code so we can reuse it
and
errors out upon connecting to the target with a mysterious 'g' packet
length error.
Cc: Richard Henderson
Cc: Peter Maydell
Cc: Alex Bennee
Signed-off-by: Ard Biesheuvel
---
target/arm/cpu64.c | 12
1 file changed, 12 insertions(+)
diff --git a/target/arm/cpu64.c
On Wed, 22 Sept 2021 at 14:45, Peter Maydell wrote:
>
> On Wed, 22 Sept 2021 at 12:41, Ard Biesheuvel wrote:
> >
> > On Thu, 16 Sept 2021 at 18:17, Peter Maydell
> > wrote:
> > >
> > > On Thu, 16 Sept 2021 at 17:05, Ard Biesheuvel wrote:
> > >
On Thu, 16 Sept 2021 at 18:17, Peter Maydell wrote:
>
> On Thu, 16 Sept 2021 at 17:05, Ard Biesheuvel wrote:
> > I'd argue that compliance with the architecture means that the
> > software should not clear RES1 bits
>
> Architecturally, RES1 means that "soft
On Thu, 16 Sept 2021 at 17:56, Peter Maydell wrote:
>
> On Thu, 16 Sept 2021 at 16:30, Alexander Graf wrote:
> >
> >
> > On 16.09.21 14:24, Peter Maydell wrote:
> > > On Wed, 15 Sept 2021 at 19:10, Alexander Graf wrote:
> > >> Now that we have working system register sync, we push more target CP
1 - 100 of 355 matches
Mail list logo
