Re: [PATCH v6 0/2] MTE support for KVM guest

On Thu, Dec 03, 2020 at 04:49:49PM +, Steven Price wrote: > On 03/12/2020 16:09, Mark Rutland wrote: > > On Fri, Nov 27, 2020 at 03:21:11PM +, Steven Price wrote: > > > It's been a week, and I think the comments on v5 made it clear that > > > enforcing PROT_

Re: [PATCH v6 0/2] MTE support for KVM guest

On Fri, Nov 27, 2020 at 03:21:11PM +, Steven Price wrote: > It's been a week, and I think the comments on v5 made it clear that > enforcing PROT_MTE requirements on the VMM was probably the wrong > approach. So since I've got swap working correctly without that I > thought I'd post a v6 which

Re: [PATCH v3 0/3] target/arm: Implement an IMPDEF pauth algorithm

so this all looks good to me, and it would be nice to see merged! Feel free to add: Tested-by: Mark Rutland Thanks, Mark.

Re: [PATCH 1/2] target/arm: Add cpu property to control pauth

On Thu, Aug 13, 2020 at 11:49:07AM +0200, Andrew Jones wrote: > On Thu, Aug 13, 2020 at 10:05:04AM +0100, Mark Rutland wrote: > > On Thu, Aug 13, 2020 at 08:03:21AM +0200, Andrew Jones wrote: > > > Thinking about this some more, maybe we don't need pauth-arch. > > > If w

Re: [PATCH 1/2] target/arm: Add cpu property to control pauth

On Thu, Aug 13, 2020 at 08:03:21AM +0200, Andrew Jones wrote: > Thinking about this some more, maybe we don't need pauth-arch. > If we don't, then it simplifies nicely to > > # Default (enabled with architected algorithm) > -cpu max[,pauth=on][,pauth-fast=off] > > # Select pauth-fast > -cpu

Re: [Qemu-devel] [PATCH for-4.1? 0/2] arm: further improve initrd positioning

all the previously-working images I had lying around. For both patches, feel free to take that as: Tested-by: Mark Rutland > Marked as 'maybe for 4.1' because it is a bug fix and to code which > is new in 4.1. OTOH cases that fail now would have failed with 4.0 > so it is not a regression

Re: [Qemu-devel] [PATCH v2 3/4] hw/arm/boot: Avoid placing the initrd on top of the kernel

On Mon, Jul 22, 2019 at 12:59:01PM +0100, Peter Maydell wrote: > On Fri, 19 Jul 2019 at 17:47, Mark Rutland wrote: > > > > Hi Peter, > > > > I've just been testing on QEMU v4.1.0-rc1, and found a case where the > > DTB overlapped the end of the kernel, and I thin

Re: [Qemu-devel] [PATCH v2 3/4] hw/arm/boot: Avoid placing the initrd on top of the kernel

Hi Peter, I've just been testing on QEMU v4.1.0-rc1, and found a case where the DTB overlapped the end of the kernel, and I think there's a bug in this patch -- explanation below. On Thu, May 16, 2019 at 03:47:32PM +0100, Peter Maydell wrote: > We currently put the initrd at the smaller of: > *

Re: [Qemu-devel] [RFC] Add virtual SDEI support in qemu

On Mon, Jul 15, 2019 at 03:26:39PM +0100, James Morse wrote: > On 15/07/2019 14:48, Mark Rutland wrote: > > On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote: > >> One option (suggested to me by James Morse) would be to allow userspace > >> to disable in the in

Re: [Qemu-devel] [RFC] Add virtual SDEI support in qemu

On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote: > On Sat, Jul 13, 2019 at 05:53:57PM +0800, Guoheyi wrote: > > Hi folks, > > > > Do it make sense to implement virtual SDEI in qemu? So that we can have the > > standard way for guest to handle NMI watchdog, RAS events and something

Re: [Qemu-devel] [PATCH v2 0/4] hw/arm/boot: handle large Images more gracefully

124M of RAM [mark@gravadlaks:~/repro]% ./vmboot.sh ~/Image.test-128M qemu-system-aarch64: kernel '/home/mark/Image.test-128M' is too large to fit in RAM (kernel size 155500544, RAM size 130023424) # 150M of RAM [mark@gravadlaks:~/repro]% ./vmboot.sh ~/Image.test-128M qemu-system-aarch64: Not

Re: [Qemu-devel] [PATCH 0/2] hw/arm/boot: handle large Images more gracefully

4386) both would silently fail to boot, and with these patches applied both all three begin booting and produce console output. The first two get to userspace, and the third crashes due to an unrelated Linux bug. So FWIW: Tested-by: Mark Rutland Thanks for putting this together! Thanks, Mark.

[Qemu-devel] [Bug 1823998] [NEW] qemu-system-aarch64: support kernels bigger than 128MiB

Public bug reported: Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd. This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size

Re: [Qemu-devel] Kernel boot regression with PAuth and aarch64-softmmu -cpu max and el2 enabled

On Tue, Jan 29, 2019 at 11:54:13AM +, Peter Maydell wrote: > On Tue, 29 Jan 2019 at 11:46, Mark Rutland wrote: > > On Tue, Jan 29, 2019 at 11:08:19AM +, Alex Bennée wrote: > > > The -cpu max enabled a cortex-a57 + whatever extra features we've > > > enabled in

Re: [Qemu-devel] Kernel boot regression with PAuth and aarch64-softmmu -cpu max and el2 enabled

nd as you would expect the system boots fine with -cpu cortex-a57 > > On the kernel side it breaks at: > > commit 04ca3204fa09f5f55c8f113b0072004a7b364ff4 > Author: Mark Rutland > Date: Fri Dec 7 18:39:30 2018 + > > arm64: enable pointer authentication &

Re: [Qemu-devel] [PATCH v1 0/2] Fix kvm guest debugging of AA32 guests on AA64

Hi Alex, On Thu, Dec 13, 2018 at 11:55:01AM +, Alex Bennée wrote: > Hi, > > This is an attempt to fix debugging of AArch32 binaries when running > under KVM on AArch64 hardware. There are two parts to this, the first is > a handling the possibility of AArch32 software breakpoints with a >

Re: [Qemu-devel] [PATCH v2 0/5] target/arm: KVM vs ARMISARegisters

On Sun, Nov 04, 2018 at 11:25:00AM +, Marc Zyngier wrote: > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 22fbbdbece3c..d50f912d3f4a 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -314,10 +314,15 @@ static bool trap_raz_wi(struct

Re: [Qemu-devel] [kvm-unit-tests PATCH v2 03/10] arm/arm64: smp: support more than 8 cpus

On Mon, Jun 06, 2016 at 05:22:49PM +0100, Alex Bennée wrote: > Andrew Jones writes: > > +#define MPIDR_LEVEL_SHIFT(level) \ > > + (((1 << level) >> 1) << 3) > > +#define MPIDR_AFFINITY_LEVEL(mpidr, level) \ > > + ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & 0xff) > > Doesn't

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

> > I'm not sure I follow what the difficulty with supporting DT in addition > > to ACPI is? It looks like all you need is a compatible string and a reg > > entry. > > Bearing in mind that I have almost no experience with arm: > > I started out by probing all possible port-io and mmio locations

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote: > > > On 05/10/2015 12:00, Mark Rutland wrote: > > Some of the keys in the example look like they'd come from other sources > > (e.g. the *-tables entries), while others look like kernel/bootloader > > conf

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Sat, Oct 03, 2015 at 07:28:05PM -0400, Gabriel L. Somlo wrote: > From: "Gabriel Somlo" > > Allow access to QEMU firmware blobs, passed into the guest VM via > the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, > size, and fw_cfg key), as well as the raw binary

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 08:43:46AM -0400, Gabriel L. Somlo wrote: > On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote: > > On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote: > > > > > > > > > On 05/10/2015 12:00, Mark Rutland wrote: >

Re: [Qemu-devel] [kernel PATCH] devicetree: document ARM bindings for QEMU's Firmware Config interface

Hi, On Fri, Nov 28, 2014 at 12:26:44PM +, Laszlo Ersek wrote: Peter Maydell suggested that we describe new devices / DTB nodes in the kernel Documentation tree that we expose to arm virt guests in QEMU. Although the kernel is not required to access the fw_cfg interface,

Re: [Qemu-devel] [kernel PATCH] devicetree: document ARM bindings for QEMU's Firmware Config interface

On Fri, Nov 28, 2014 at 01:22:29PM +, Laszlo Ersek wrote: On 11/28/14 13:59, Arnd Bergmann wrote: On Friday 28 November 2014 13:26:44 Laszlo Ersek wrote: +Example: + +/ { + #size-cells = 0x2; + #address-cells = 0x2; + + fw-cfg@902 { + reg

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Tue, Nov 11, 2014 at 09:33:12PM +, Christoffer Dall wrote: On Tue, Nov 11, 2014 at 04:48:07PM +, Mark Rutland wrote: Hi Christoffer, On Tue, Nov 11, 2014 at 04:31:01PM +, Christoffer Dall wrote: On Tue, Nov 11, 2014 at 03:29:33PM +, Mark Rutland wrote: Hi

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Wed, Nov 12, 2014 at 09:08:55AM +, Claudio Fontana wrote: On 11.11.2014 16:29, Mark Rutland wrote: Hi, On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote: On 6 November 2014 14:44, Peter Maydell peter.mayd...@linaro.org wrote: We need ACPI guest support

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[...] We are currently suggesting adding an RDSP property to the chosen node in the tiny DT, but a command-line arguement like kexec proposed could be another option I guess, albeit not a very pretty one. I'm not sure what an RDSP command line property would have to do

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote: On 12/11/2014 12:34, Christoffer Dall wrote: AFAIU ACPI already has a method for doing this It's not defined in the spec. QEMU defines a bunch of registers to do that, and provides AML that works with those registers. Huh?

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Wed, Nov 12, 2014 at 12:27:14PM +, Paolo Bonzini wrote: On 12/11/2014 13:18, Mark Rutland wrote: On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote: On 12/11/2014 12:34, Christoffer Dall wrote: AFAIU ACPI already has a method for doing this It's not defined

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Wed, Nov 12, 2014 at 01:59:30PM +, Paolo Bonzini wrote: On 12/11/2014 14:41, Mark Rutland wrote: Writing a binding for the partiuclar device might be trivial. How this would fit with the DT model is more complicated, and needs to be specified. As far as I can see, those documents

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

Hi, On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote: On 6 November 2014 14:44, Peter Maydell peter.mayd...@linaro.org wrote: We need ACPI guest support in QEMU for AArch64 over here, with all features (including the ability to run ACPI code and add specific

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Thu, Nov 06, 2014 at 06:53:03AM +, Hanjun Guo wrote: On 2014-10-31 2:02, Mark Rutland wrote: On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote: On 30 October 2014 17:43, Alexander Spyridakis a.spyrida...@virtualopensystems.com wrote: Currently, the virt machine model

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote: On 30 October 2014 17:43, Alexander Spyridakis a.spyrida...@virtualopensystems.com wrote: Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

On Fri, Mar 14, 2014 at 05:10:34PM +, Rob Herring wrote: On Fri, Mar 14, 2014 at 5:23 AM, Mark Rutland mark.rutl...@arm.com wrote: On Fri, Mar 14, 2014 at 06:53:53AM +, Pranavkumar Sawargaonkar wrote: Hi Christoffer, On 14 March 2014 09:19, Christoffer Dall christoffer.d

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

that we should add arm,psci-0.2 or something like that. Yes there was a discussion related to that by Mark Rutland and Rob Herring : http://www.spinics.net/lists/arm-kernel/msg298509.html But there is no dt binding added related to psci 0.2 in kernel (I am not sure about final conclusion