[RESEND][PATCH 0/2] acpi/nvdimm: support NVDIMM _LS{I,R,W} methods

2022-04-11 Thread Robert Hoo
The original NVDIMM _DSM functions (index 4~6) for label operations have
been deprecated by new ACPI methods _LS{I,R,W}[1][2].

Patch 1 implements the new _LS{I,R,W} methods, on top of old _DSM
implementation.

Patch 2 fixes some typo of logical and/or with bitwise and/or, though
functionally they haven't causing trouble.

[1] https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index.html, 6.5.10 NVDIMM 
Label Methods
[2] https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V2.0.pdf, 3.10 
Deprecated Functions

---
Resend for previous failed delivery to "qemu-devel@nongnu.org" due to
550-'Message headers fail syntax check'. 

Robert Hoo (2):
  acpi/nvdimm: Create _LS{I,R,W} method for NVDIMM device
  acpi/nvdimm: Fix aml_or() and aml_and() in if clause

 hw/acpi/nvdimm.c | 60 +++-
 1 file changed, 54 insertions(+), 6 deletions(-)


base-commit: 95a3fcc7487e5bef262e1f937ed8636986764c4e
-- 
2.31.1




[PATCH 0/2] acpi/nvdimm: support NVDIMM _LS{I,R,W} methods

2022-04-11 Thread Robert Hoo
The original NVDIMM _DSM functions (index 4~6) for label operations have
been deprecated by new ACPI methods _LS{I,R,W}[1][2].

Patch 1 implements the new _LS{I,R,W} methods, on top of old _DSM
implementation.

Patch 2 fixes some typo of logical and/or with bitwise and/or, though
functionally they haven't causing trouble.

[1] https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index.html, 6.5.10 NVDIMM 
Label Methods
[2] https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V2.0.pdf, 3.10 
Deprecated Functions

Robert Hoo (2):
  acpi/nvdimm: Create _LS{I,R,W} method for NVDIMM device
  acpi/nvdimm: Fix aml_or() and aml_and() in if clause

 hw/acpi/nvdimm.c | 60 +++-
 1 file changed, 54 insertions(+), 6 deletions(-)


base-commit: 95a3fcc7487e5bef262e1f937ed8636986764c4e
-- 
2.31.1




Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK

2022-04-11 Thread Hugh Dickins
On Mon, 11 Apr 2022, Kirill A. Shutemov wrote:
> On Fri, Apr 08, 2022 at 09:02:54PM +0800, Chao Peng wrote:
> > > I think the correct approach is to not do the locking automatically for 
> > > SHM_F_INACCESSIBLE,
> > > and instead require userspace to do shmctl(.., SHM_LOCK, ...) if 
> > > userspace knows the
> > > consumers don't support migrate/swap.  That'd require wrapping 
> > > migrate_page() and then
> > > wiring up notifier hooks for migrate/swap, but IMO that's a good thing to 
> > > get sorted
> > > out sooner than later.  KVM isn't planning on support migrate/swap for 
> > > TDX or SNP,
> > > but supporting at least migrate for a software-only implementation a la 
> > > pKVM should
> > > be relatively straightforward.  On the notifiee side, KVM can terminate 
> > > the VM if it
> > > gets an unexpected migrate/swap, e.g. so that TDX/SEV VMs don't die later 
> > > with
> > > exceptions and/or data corruption (pre-SNP SEV guests) in the guest.
> > 
> > SHM_LOCK sounds like a good match.
> 
> Emm, no. shmctl(2) and SHM_LOCK are SysV IPC thing. I don't see how they
> fit here.

I am still struggling to formulate a constructive response on
MFD_INACCESSIBLE in general: but before doing so, let me jump in here
to say that I'm firmly on the side of SHM_LOCK being the right model -
but admittedly not through userspace calling shmctl(2).

Please refer to our last year's posting "[PATCH 10/16] tmpfs: fcntl(fd,
F_MEM_LOCK) to memlock a tmpfs file" for the example of how Shakeel did
it then (though only a small part of that would be needed for this case):
https://lore.kernel.org/linux-mm/54e03798-d836-ae64-f41-4a1d46bc1...@google.com/

And until such time as swapping is enabled, this memlock accounting would
be necessarily entailed by "MFD_INACCESSIBLE", or however that turns out
to be implemented: not something that we could trust userspace to call
separately.

Hugh



Re: [PATCH v2] target/riscv: Fix incorrect PTE merge in walk_pte

2022-04-11 Thread Alistair Francis
On Tue, Apr 5, 2022 at 3:34 AM Ralf Ramsauer
 wrote:
>
> Two non-subsequent PTEs can be mapped to subsequent paddrs. In this
> case, walk_pte will erroneously merge them.
>
> Enforce the split up, by tracking the virtual base address.
>
> Let's say we have the mapping:
> 0x8120 -> 0x89623000 (4K)
> 0x8120f000 -> 0x89624000 (4K)
>
> Before, walk_pte would have shown:
>
> vaddrpaddrsize attr
>    ---
> 8120 89623000 2000 rwxu-ad
>
> as it only checks for subsequent paddrs. With this patch, it becomes:
>
> vaddrpaddrsize attr
>    ---
> 8120 89623000 1000 rwxu-ad
> 8120f000 89624000 1000 rwxu-ad
>
> Signed-off-by: Ralf Ramsauer 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/monitor.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
> index 7efb4b62c1..9dc4cb1156 100644
> --- a/target/riscv/monitor.c
> +++ b/target/riscv/monitor.c
> @@ -84,6 +84,7 @@ static void walk_pte(Monitor *mon, hwaddr base, 
> target_ulong start,
>  {
>  hwaddr pte_addr;
>  hwaddr paddr;
> +target_ulong last_start = -1;
>  target_ulong pgsize;
>  target_ulong pte;
>  int ptshift;
> @@ -116,7 +117,8 @@ static void walk_pte(Monitor *mon, hwaddr base, 
> target_ulong start,
>   * contiguous mapped block details.
>   */
>  if ((*last_attr != attr) ||
> -(*last_paddr + *last_size != paddr)) {
> +(*last_paddr + *last_size != paddr) ||
> +(last_start + *last_size != start)) {
>  print_pte(mon, va_bits, *vbase, *pbase,
>*last_paddr + *last_size - *pbase, *last_attr);
>
> @@ -125,6 +127,7 @@ static void walk_pte(Monitor *mon, hwaddr base, 
> target_ulong start,
>  *last_attr = attr;
>  }
>
> +last_start = start;
>  *last_paddr = paddr;
>  *last_size = pgsize;
>  } else {
> --
> 2.35.1
>
>



Re: [PATCH v3] hw/riscv: virt: Exit if the user provided -bios in combination with KVM

2022-04-11 Thread Alistair Francis
On Fri, Apr 1, 2022 at 10:18 PM Ralf Ramsauer
 wrote:
>
> The -bios option is silently ignored if used in combination with -enable-kvm.
> The reason is that the machine starts in S-Mode, and the bios typically runs 
> in
> M-Mode.
>
> Better exit in that case to not confuse the user.
>
> Signed-off-by: Ralf Ramsauer 

Thanks!

Applied to riscv-to-apply.next

Alistair

> ---
>  hw/riscv/virt.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index da50cbed43..09609c96e8 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1308,12 +1308,18 @@ static void virt_machine_init(MachineState *machine)
>
>  /*
>   * Only direct boot kernel is currently supported for KVM VM,
> - * so the "-bios" parameter is ignored and treated like "-bios none"
> - * when KVM is enabled.
> + * so the "-bios" parameter is not supported when KVM is enabled.
>   */
>  if (kvm_enabled()) {
> -g_free(machine->firmware);
> -machine->firmware = g_strdup("none");
> +if (machine->firmware) {
> +if (strcmp(machine->firmware, "none")) {
> +error_report("Machine mode firmware is not supported in "
> + "combination with KVM.");
> +exit(1);
> +}
> +} else {
> +machine->firmware = g_strdup("none");
> +}
>  }
>
>  if (riscv_is_32bit(&s->soc[0])) {
> --
> 2.32.0
>



Re: [libvirt] [PATCH RESEND v2 0/4] re-introduce

2022-04-11 Thread Ani Sinha
On Tue, Apr 12, 2022 at 9:50 AM Ani Sinha  wrote:
>
> On Tue, Mar 8, 2022 at 10:28 PM Michael S. Tsirkin  wrote:
> >
> > On Tue, Mar 08, 2022 at 10:15:49PM +0530, Ani Sinha wrote:
> > >
> > > Change log:
> > > v2: rebased the patchset. Laine's response is appended at the end.
> > >
> > > I am re-introducing the patchset for  which got
> > > reverted here few months back:
> > >
> > > https://www.spinics.net/linux/fedora/libvir/msg224089.html
> > >
> > > The reason for the reversal was that there seemed to be some
> > > instability/issues around the use of the qemu commandline which this
> > > patchset tries to support. In particular, some guest operating systems
> > > did not like the way QEMU was trying to disable native hotplug on pcie
> > > root ports. Subsequently, in QEMU 6.2, we have changed our mechanism
> > > using which we disable native hotplug. As I understand, we do not have
> > > any reported issues so far in 6.2 around this area. QEMU will enter a
> > > soft feature freeze in the first week of march in prep for 7.0 release.
> >
> > Right. But unfortunately we did not yet really work on
> > a sane interface for this.
> >
> > The way I see it, at high level we thinkably need two flags
> > - disable ACPI hotplug
> > - enable native hotplug (maybe separately for pci and pcie?)
>
> pci does not have native hotplug. so this would be applicable only for
> q35. For i440fx we have two separate flags already to disable acpi
> hotplug, one for root bus and another for bridges.
>
> >
> > and with both enabled guests actually can switch between
> > the two.
> >
> > This will at least reflect the hardware, so has a chance to be
> > stable.
> >
> > The big question however would be what is the actual use-case.
> > Without that this begs the question of why do we bother at all.
>
> To me the main motivation is as I have described here:
> https://listman.redhat.com/archives/libvir-list/2021-October/msg00068.html
>
> One concrete example of why one might still want to use native hotplug with
> pcie-root-port controller is the fact that we are still discovering issues 
> with
> acpi hotplug on PCIE. One such issue is:
> https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html
> Another reason is that users have been using native hotplug on pcie root ports
> up until now. They have built and tested their systems based on native 
> hotplug.
> They may not want to suddenly move to acpi based hotplug just because it is 
> now
> the default in qemu. Supporting the option to chose one or the other through
> libvirt makes things simpler for end users.

Essentially what I do not like is that we are imposing acpi hotplug on
q35 for the entire community without giving them a choice to revert
back to native hotplug though libvirt.

>
> > To allow hotplug of bridges? If it is really necessary for us then
> > we should think hard about questions that surround this:
> >
> > - how does one hotplug a pcie switch?
> > - any way to use e.g. dynamic ACPI to support hotplug of bridges?
> > - do we want to bite the bullet and create an option for management
> >   to fully control guest memory layout including all pci devices?
> >
> >
> >
> > > Libvirt is also entering a new release cycle phaze. Hence, I am
> > > introducing this patchset early enough in the release cycles so that if
> > > we do see any issues on the qemu side during the rc0, rc1 cycles and if
> > > reversal of this patchset is again required, it can be done in time
> > > before the next libvirt release end of March.
> > >
> > > All the patches in this series had been previously reviewed. Some
> > > subsequent fixes were made after my initial patches were pushed. I have
> > > squashed all those fixes and consolidated them into four patches. I have
> > > also updated the documentation to reflect the new changes from the QEMU
> > > side and rebased my changes fixing the tests in the process.
> > >
> > > What changed in QEMU post version 6.1 ?
> > > =
> > >
> > > We have made basically two major changes in QEMU. First is this change:
> > >
> > > (1) commit 211afe5c69b597acf85fdd577eb497f5be1ffbd8
> > > Author: Julia Suvorova 
> > > Date:   Fri Nov 12 06:08:56 2021 -0500
> > >
> > > hw/i386/acpi-build: Deny control on PCIe Native Hot-plug in _OSC
> > >
> > > There are two ways to enable ACPI PCI Hot-plug:
> > >
> > > * Disable the Hot-plug Capable bit on PCIe slots.
> > >
> > > This was the first approach which led to regression [1-2], as
> > > I/O space for a port is allocated only when it is hot-pluggable,
> > > which is determined by HPC bit.
> > >
> > > * Leave the HPC bit on and disable PCIe Native Hot-plug in 
> > > _OSC
> > >   method.
> > >
> > > This removes the (future) ability of hot-plugging switches with PCIe
> > > Native hotplug since ACPI PCI Hot-plug only works with cold-plugged
> > > bridges. If the user wants to explicitely use this fea

Re: [libvirt] [PATCH RESEND v2 0/4] re-introduce

2022-04-11 Thread Ani Sinha
On Tue, Mar 8, 2022 at 10:28 PM Michael S. Tsirkin  wrote:
>
> On Tue, Mar 08, 2022 at 10:15:49PM +0530, Ani Sinha wrote:
> >
> > Change log:
> > v2: rebased the patchset. Laine's response is appended at the end.
> >
> > I am re-introducing the patchset for  which got
> > reverted here few months back:
> >
> > https://www.spinics.net/linux/fedora/libvir/msg224089.html
> >
> > The reason for the reversal was that there seemed to be some
> > instability/issues around the use of the qemu commandline which this
> > patchset tries to support. In particular, some guest operating systems
> > did not like the way QEMU was trying to disable native hotplug on pcie
> > root ports. Subsequently, in QEMU 6.2, we have changed our mechanism
> > using which we disable native hotplug. As I understand, we do not have
> > any reported issues so far in 6.2 around this area. QEMU will enter a
> > soft feature freeze in the first week of march in prep for 7.0 release.
>
> Right. But unfortunately we did not yet really work on
> a sane interface for this.
>
> The way I see it, at high level we thinkably need two flags
> - disable ACPI hotplug
> - enable native hotplug (maybe separately for pci and pcie?)

pci does not have native hotplug. so this would be applicable only for
q35. For i440fx we have two separate flags already to disable acpi
hotplug, one for root bus and another for bridges.

>
> and with both enabled guests actually can switch between
> the two.
>
> This will at least reflect the hardware, so has a chance to be
> stable.
>
> The big question however would be what is the actual use-case.
> Without that this begs the question of why do we bother at all.

To me the main motivation is as I have described here:
https://listman.redhat.com/archives/libvir-list/2021-October/msg00068.html

One concrete example of why one might still want to use native hotplug with
pcie-root-port controller is the fact that we are still discovering issues with
acpi hotplug on PCIE. One such issue is:
https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html
Another reason is that users have been using native hotplug on pcie root ports
up until now. They have built and tested their systems based on native hotplug.
They may not want to suddenly move to acpi based hotplug just because it is now
the default in qemu. Supporting the option to chose one or the other through
libvirt makes things simpler for end users.

> To allow hotplug of bridges? If it is really necessary for us then
> we should think hard about questions that surround this:
>
> - how does one hotplug a pcie switch?
> - any way to use e.g. dynamic ACPI to support hotplug of bridges?
> - do we want to bite the bullet and create an option for management
>   to fully control guest memory layout including all pci devices?
>
>
>
> > Libvirt is also entering a new release cycle phaze. Hence, I am
> > introducing this patchset early enough in the release cycles so that if
> > we do see any issues on the qemu side during the rc0, rc1 cycles and if
> > reversal of this patchset is again required, it can be done in time
> > before the next libvirt release end of March.
> >
> > All the patches in this series had been previously reviewed. Some
> > subsequent fixes were made after my initial patches were pushed. I have
> > squashed all those fixes and consolidated them into four patches. I have
> > also updated the documentation to reflect the new changes from the QEMU
> > side and rebased my changes fixing the tests in the process.
> >
> > What changed in QEMU post version 6.1 ?
> > =
> >
> > We have made basically two major changes in QEMU. First is this change:
> >
> > (1) commit 211afe5c69b597acf85fdd577eb497f5be1ffbd8
> > Author: Julia Suvorova 
> > Date:   Fri Nov 12 06:08:56 2021 -0500
> >
> > hw/i386/acpi-build: Deny control on PCIe Native Hot-plug in _OSC
> >
> > There are two ways to enable ACPI PCI Hot-plug:
> >
> > * Disable the Hot-plug Capable bit on PCIe slots.
> >
> > This was the first approach which led to regression [1-2], as
> > I/O space for a port is allocated only when it is hot-pluggable,
> > which is determined by HPC bit.
> >
> > * Leave the HPC bit on and disable PCIe Native Hot-plug in _OSC
> >   method.
> >
> > This removes the (future) ability of hot-plugging switches with PCIe
> > Native hotplug since ACPI PCI Hot-plug only works with cold-plugged
> > bridges. If the user wants to explicitely use this feature, they can
> > disable ACPI PCI Hot-plug with:
> > --global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off
> >
> > Change the bit in _OSC method so that the OS selects ACPI PCI Hot-plug
> > instead of PCIe Native.
> >
> > [1] https://gitlab.com/qemu-project/qemu/-/issues/641
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006409
> >
> > Signed-off-by: Julia Suvorova 
> > Signed-off-by: Igor M

Re: [PATCH v2 9/9] target/ppc: Implemented vector module quadword

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)"

Implement the following PowerISA v3.1 instructions:
vmodsq: Vector Modulo Signed Quadword
vmoduq: Vector Modulo Unsigned Quadword

Signed-off-by: Lucas Mateus Castro (alqotel)
---
  target/ppc/helper.h |  2 ++
  target/ppc/insn32.decode|  2 ++
  target/ppc/int_helper.c | 21 +
  target/ppc/translate/vmx-impl.c.inc |  2 ++
  4 files changed, 27 insertions(+)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH v2 8/9] target/ppc: Implemented vector module word/doubleword

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)"

Implement the following PowerISA v3.1 instructions:
vmodsw: Vector Modulo Signed Word
vmoduw: Vector Modulo Unsigned Word
vmodsd: Vector Modulo Signed Doubleword
vmodud: Vector Modulo Unsigned Doubleword

Signed-off-by: Lucas Mateus Castro (alqotel)
---
  target/ppc/insn32.decode|  5 +
  target/ppc/translate/vmx-impl.c.inc | 10 ++
  2 files changed, 15 insertions(+)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH v2 7/9] target/ppc: Implemented remaining vector divide extended

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)"

Implement the following PowerISA v3.1 instructions:
vdivesd: Vector Divide Extended Signed Doubleword
vdiveud: Vector Divide Extended Unsigned Doubleword
vdivesq: Vector Divide Extended Signed Quadword
vdiveuq: Vector Divide Extended Unsigned Quadword

Signed-off-by: Lucas Mateus Castro (alqotel)
---
  target/ppc/helper.h |  4 ++
  target/ppc/insn32.decode|  4 ++
  target/ppc/int_helper.c | 64 +
  target/ppc/translate/vmx-impl.c.inc |  4 ++
  4 files changed, 76 insertions(+)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH v3] hw/riscv: virt: Exit if the user provided -bios in combination with KVM

2022-04-11 Thread Anup Patel
On Fri, Apr 1, 2022 at 5:48 PM Ralf Ramsauer
 wrote:
>
> The -bios option is silently ignored if used in combination with -enable-kvm.
> The reason is that the machine starts in S-Mode, and the bios typically runs 
> in
> M-Mode.
>
> Better exit in that case to not confuse the user.
>
> Signed-off-by: Ralf Ramsauer 

Looks good to me.

Reviewed-by: Anup Patel 

Regards,
Anup

> ---
>  hw/riscv/virt.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index da50cbed43..09609c96e8 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1308,12 +1308,18 @@ static void virt_machine_init(MachineState *machine)
>
>  /*
>   * Only direct boot kernel is currently supported for KVM VM,
> - * so the "-bios" parameter is ignored and treated like "-bios none"
> - * when KVM is enabled.
> + * so the "-bios" parameter is not supported when KVM is enabled.
>   */
>  if (kvm_enabled()) {
> -g_free(machine->firmware);
> -machine->firmware = g_strdup("none");
> +if (machine->firmware) {
> +if (strcmp(machine->firmware, "none")) {
> +error_report("Machine mode firmware is not supported in "
> + "combination with KVM.");
> +exit(1);
> +}
> +} else {
> +machine->firmware = g_strdup("none");
> +}
>  }
>
>  if (riscv_is_32bit(&s->soc[0])) {
> --
> 2.32.0
>



Re: [PATCH 1/2] hw/misc: Add Nuvoton's PCI Mailbox Module

2022-04-11 Thread Patrick Venture
On Thu, Jan 27, 2022 at 1:27 PM Patrick Venture  wrote:

>
>
> On Thu, Jan 27, 2022 at 10:37 AM Peter Maydell 
> wrote:
>
>> On Mon, 10 Jan 2022 at 17:56, Patrick Venture  wrote:
>> >
>> > From: Hao Wu 
>> >
>> > The PCI Mailbox Module is a high-bandwidth communcation module
>> > between a Nuvoton BMC and CPU. It features 16KB RAM that are both
>> > accessible by the BMC and core CPU. and supports interrupt for
>> > both sides.
>> >
>> > This patch implements the BMC side of the PCI mailbox module.
>> > Communication with the core CPU is emulated via a chardev and
>> > will be in a follow-up patch.
>> >
>> > Reviewed-by: Patrick Venture 
>> > Reviewed-by: Joe Komlodi 
>>
>> Hi; this mostly looks good, but I have a question about s->content.
>>
>> > +static void npcm7xx_pci_mbox_init(Object *obj)
>> > +{
>> > +NPCM7xxPCIMBoxState *s = NPCM7XX_PCI_MBOX(obj);
>> > +SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
>> > +
>> > +memory_region_init_ram_device_ptr(&s->ram, obj, "pci-mbox-ram",
>> > +  NPCM7XX_PCI_MBOX_RAM_SIZE,
>> s->content);
>>
>> What's s->content for? Nothing in the rest of the device emulation
>> touches it, which seems odd.
>>
>
> Hao informed me that we can drop the content bit here, since it's not used
> until a later patch that we'll be sending up with a bit more detail when we
> get a chance. I sent this series up to land some of the groundwork.
>
> I can send out a v2 with that bit removed.
>
>
>>
>> memory_region_init_ram_device_ptr() is intended primarily
>> for "create a MemoryRegion corresponding to something like
>> a bit of a host device (eg a host PCI MMIO BAR). That doesn't
>> seem like what you're doing here. In particular, using it
>> means that you take on responsibility for ensuring that the
>> underlying memory gets migrated, which you're not doing.
>>
>> If you just want a MemoryRegion that's backed by a bit of
>> host memory, use memory_region_init_ram().
>>
>
> I think this is what we use it for in the future patches, when we add it
> back, it'll come with the context.
>
>
>>
>> > +#define TYPE_NPCM7XX_PCI_MBOX "npcm7xx-pci-mbox"
>> > +#define NPCM7XX_PCI_MBOX(obj) \
>> > +OBJECT_CHECK(NPCM7xxPCIMBoxState, (obj), TYPE_NPCM7XX_PCI_MBOX)
>>
>> We prefer the OBJECT_DECLARE_SIMPLE_TYPE() macro rather than
>> hand-defining a cast macro these days.
>>
>
> Ack.
>
>
>>
>> thanks
>> -- PMM
>>
>
Peter, just an FYI, this fell off my radar, but I will be circling back
this week to revisit any patches I've sent that are in limbo or waiting on
me, etc.  Thanks for your patience.


>
> Thanks!
>


Re: [PATCH v2 5/9] host-utils: Implemented unsigned 256-by-128 division

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)" 

Based on already existing QEMU implementation, created an unsigned 256
bit by 128 bit division needed to implement the vector divide extended
unsigned instruction from PowerISA3.1

Signed-off-by: Lucas Mateus Castro (alqotel) 
---
  include/qemu/host-utils.h |  15 +
  include/qemu/int128.h |  20 ++
  util/host-utils.c | 128 ++
  3 files changed, 163 insertions(+)

diff --git a/include/qemu/host-utils.h b/include/qemu/host-utils.h
index ca979dc6cc..6da6a93f69 100644
--- a/include/qemu/host-utils.h
+++ b/include/qemu/host-utils.h
@@ -32,6 +32,7 @@
  
  #include "qemu/compiler.h"

  #include "qemu/bswap.h"
+#include "qemu/int128.h"
  
  #ifdef CONFIG_INT128

  static inline void mulu64(uint64_t *plow, uint64_t *phigh,
@@ -153,6 +154,19 @@ static inline int clo64(uint64_t val)
  return clz64(~val);
  }
  
+/*

+ * clz128 - count leading zeros in a 128-bit value.
+ * @val: The value to search
+ */
+static inline int clz128(Int128 a)
+{
+if (int128_gethi(a)) {
+return clz64(int128_gethi(a));
+} else {
+return clz64(int128_getlo(a)) + 64;
+}
+}


Should be in int128.h, like bswap128.


diff --git a/util/host-utils.c b/util/host-utils.c
index bcc772b8ec..c6a01638c7 100644
--- a/util/host-utils.c
+++ b/util/host-utils.c
@@ -266,3 +266,131 @@ void ulshift(uint64_t *plow, uint64_t *phigh, int32_t 
shift, bool *overflow)
  *plow = *plow << shift;
  }
  }
+/*


Watch your spacing.


+ * Unsigned 256-by-128 division.
+ * Returns the remainder via r.
+ * Returns lower 128 bit of quotient.
+ * Needs a normalized divisor (most significant bit set to 1).
+ *
+ * Adapted from include/qemu/host-utils.h udiv_qrnnd,
+ * from the GNU Multi Precision Library - longlong.h __udiv_qrnnd
+ * (https://gmplib.org/repo/gmp/file/tip/longlong.h)
+ *
+ * Licensed under the GPLv2/LGPLv3
+ */
+static Int128 udiv256_qrnnd(Int128 *r, Int128 n1, Int128 n0, Int128 d)
+{
+Int128 d0, d1, q0, q1, r1, r0, m;
+uint64_t mp0, mp1;
+
+d0 = int128_make64(int128_getlo(d));
+d1 = int128_make64(int128_gethi(d));
+
+r1 = int128_remu(n1, d1);
+q1 = int128_divu(n1, d1);
+mp0 = int128_getlo(q1);
+mp1 = int128_gethi(q1);
+mulu128(&mp0, &mp1, int128_getlo(d0));
+m = int128_make128(mp0, mp1);
+r1 = int128_make128(int128_gethi(n0), int128_getlo(r1));
+if (int128_ult(r1, m)) {
+q1 = int128_sub(q1, int128_one());
+r1 = int128_add(r1, d);
+if (int128_uge(r1, d)) {
+if (int128_ult(r1, m)) {
+q1 = int128_sub(q1, int128_one());
+r1 = int128_add(r1, d);
+}
+}
+}
+r1 = int128_sub(r1, m);
+
+r0 = int128_remu(r1, d1);
+q0 = int128_divu(r1, d1);
+mp0 = int128_getlo(q0);
+mp1 = int128_gethi(q0);
+mulu128(&mp0, &mp1, int128_getlo(d0));
+m = int128_make128(mp0, mp1);
+r0 = int128_make128(int128_getlo(n0), int128_getlo(r0));
+if (int128_ult(r0, m)) {
+q0 = int128_sub(q0, int128_one());
+r0 = int128_add(r0, d);
+if (int128_uge(r0, d)) {
+if (int128_ult(r0, m)) {
+q0 = int128_sub(q0, int128_one());
+r0 = int128_add(r0, d);
+}
+}
+}
+r0 = int128_sub(r0, m);
+
+*r = r0;
+return int128_or(int128_lshift(q1, 64), q0);
+}
+
+/*
+ * Unsigned 256-by-128 division.
+ * Returns the remainder.
+ * Returns quotient via plow and phigh.
+ * Also returns the remainder via the function return value.
+ */
+Int128 divu256(Int128 *plow, Int128 *phigh, Int128 divisor)
+{
+Int128 dhi = *phigh;
+Int128 dlo = *plow;
+Int128 rem, dhighest;
+int sh;
+
+if (!int128_nz(divisor) || !int128_nz(dhi)) {
+*plow  = int128_divu(dlo, divisor);
+*phigh = int128_zero();
+return int128_remu(dlo, divisor);
+} else {
+sh = clz128(divisor);
+
+if (int128_ult(dhi, divisor)) {
+if (sh != 0) {
+/* normalize the divisor, shifting the dividend accordingly */
+divisor = int128_lshift(divisor, sh);
+dhi = int128_or(int128_lshift(dhi, sh),
+int128_urshift(dlo, (128 - sh)));
+dlo = int128_lshift(dlo, sh);
+}
+
+*phigh = int128_zero();
+*plow = udiv256_qrnnd(&rem, dhi, dlo, divisor);
+} else {
+if (sh != 0) {
+/* normalize the divisor, shifting the dividend accordingly */
+divisor = int128_lshift(divisor, sh);
+dhighest = int128_rshift(dhi, (128 - sh));
+dhi = int128_or(int128_lshift(dhi, sh),
+int128_urshift(dlo, (128 - sh)));
+dlo = int128_lshift(dlo, sh);
+
+*phigh = udiv256_qrnnd(&dhi, dhighest, dhi, divisor);
+  

[RFC 2/3] hw/riscv: virt: Move common functions to a separate helper file

2022-04-11 Thread Atish Patra
The virt machine has many generic functions that can be used by
other machines. Move these functions to a helper file so that other
machines can use it in the future.

Signed-off-by: Atish Patra 
---
 hw/riscv/machine_helper.c | 417 ++
 hw/riscv/meson.build  |   1 +
 hw/riscv/virt.c   | 403 +++--
 include/hw/riscv/machine_helper.h |  87 +++
 include/hw/riscv/virt.h   |  13 -
 5 files changed, 541 insertions(+), 380 deletions(-)
 create mode 100644 hw/riscv/machine_helper.c
 create mode 100644 include/hw/riscv/machine_helper.h

diff --git a/hw/riscv/machine_helper.c b/hw/riscv/machine_helper.c
new file mode 100644
index ..d8e6b87f1a48
--- /dev/null
+++ b/hw/riscv/machine_helper.c
@@ -0,0 +1,417 @@
+/*
+ * QEMU machine helper
+ *
+ * Copyright (c) 2022 Rivos, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "hw/sysbus.h"
+#include "hw/qdev-properties.h"
+#include "target/riscv/cpu.h"
+#include "hw/riscv/riscv_hart.h"
+#include "hw/riscv/virt.h"
+#include "hw/riscv/boot.h"
+#include "hw/riscv/numa.h"
+#include "hw/riscv/machine_helper.h"
+#include "hw/intc/riscv_imsic.h"
+#include "chardev/char.h"
+#include "sysemu/device_tree.h"
+#include "sysemu/sysemu.h"
+#include "hw/pci/pci.h"
+#include "hw/pci-host/gpex.h"
+#include "hw/display/ramfb.h"
+
+static inline DeviceState *__gpex_pcie_common(MemoryRegion *sys_mem,
+  PcieInitData *data)
+{
+DeviceState *dev;
+MemoryRegion *ecam_alias, *ecam_reg;
+MemoryRegion *mmio_alias, *high_mmio_alias, *mmio_reg;
+
+dev = qdev_new(TYPE_GPEX_HOST);
+
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
+
+ecam_alias = g_new0(MemoryRegion, 1);
+ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0);
+memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam",
+ ecam_reg, 0, data->pcie_ecam.size);
+memory_region_add_subregion(get_system_memory(), data->pcie_ecam.base,
+ecam_alias);
+
+mmio_alias = g_new0(MemoryRegion, 1);
+mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1);
+memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio",
+ mmio_reg, data->pcie_mmio.base,
+ data->pcie_mmio.size);
+memory_region_add_subregion(get_system_memory(), data->pcie_mmio.base,
+mmio_alias);
+
+/* Map high MMIO space */
+high_mmio_alias = g_new0(MemoryRegion, 1);
+memory_region_init_alias(high_mmio_alias, OBJECT(dev), "pcie-mmio-high",
+ mmio_reg, data->pcie_high_mmio.base,
+ data->pcie_high_mmio.size);
+memory_region_add_subregion(get_system_memory(), data->pcie_high_mmio.base,
+high_mmio_alias);
+
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, data->pcie_pio.base);
+
+return dev;
+}
+
+DeviceState *riscv_gpex_pcie_msi_init(MemoryRegion *sys_mem,
+  PcieInitData *data)
+{
+return __gpex_pcie_common(sys_mem, data);
+}
+
+DeviceState *riscv_gpex_pcie_intx_init(MemoryRegion *sys_mem,
+   PcieInitData *data, DeviceState 
*irqchip)
+{
+qemu_irq irq;
+int i;
+DeviceState *dev;
+
+dev = __gpex_pcie_common(sys_mem, data);
+for (i = 0; i < GPEX_NUM_IRQS; i++) {
+irq = qdev_get_gpio_in(irqchip, PCIE_IRQ + i);
+
+sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, irq);
+gpex_set_irq_num(GPEX_HOST(dev), i, PCIE_IRQ + i);
+}
+
+return dev;
+}
+
+uint32_t riscv_imsic_num_bits(uint32_t count)
+{
+uint32_t ret = 0;
+
+while (BIT(ret) < count) {
+ret++;
+}
+
+return ret;
+}
+
+void riscv_create_fdt_imsic(MachineState *mc, RISCVHartArrayState *soc,
+uint32_t *phandle, uint32_t *intc_phandles,
+uint32_t *msi_m_phandle, uint32_t *msi_s_phandle,
+ImsicInitData *data)
+{
+int cpu, socket;
+char *imsic_name;
+uint32_t imsic_max_hart_per_socket, imsic_guest_bits;
+ui

[PATCH v2] hw/ppc: change indentation to spaces from TABs

2022-04-11 Thread Guo Zhi
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/374

There are still some files in the QEMU PPC code base that use TABs for 
indentation instead of using  spaces. The TABs should be replaced so that we 
have a consistent coding style.

Signed-off-by: Guo Zhi 
---
 hw/ppc/ppc440_bamboo.c |  6 +++---
 hw/ppc/spapr_rtas.c| 18 +-
 include/hw/ppc/ppc.h   | 10 +-
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 7fb620b9a0..5ec3a9a17f 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -3,9 +3,9 @@
  *
  * Copyright 2007 IBM Corporation.
  * Authors:
- * Jerone Young 
- * Christian Ehrhardt 
- * Hollis Blanchard 
+ *  Jerone Young 
+ *  Christian Ehrhardt 
+ *  Hollis Blanchard 
  *
  * This work is licensed under the GNU GPL license version 2 or later.
  *
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index d7c04237fe..d58b65e88f 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -474,16 +474,16 @@ static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
 
 if (spapr->fwnmi_machine_check_interlock != cpu->vcpu_id) {
 /*
-* The vCPU that hit the NMI should invoke "ibm,nmi-interlock"
+ * The vCPU that hit the NMI should invoke "ibm,nmi-interlock"
  * This should be PARAM_ERROR, but Linux calls "ibm,nmi-interlock"
-* for system reset interrupts, despite them not being interlocked.
-* PowerVM silently ignores this and returns success here. Returning
-* failure causes Linux to print the error "FWNMI: nmi-interlock
-* failed: -3", although no other apparent ill effects, this is a
-* regression for the user when enabling FWNMI. So for now, match
-* PowerVM. When most Linux clients are fixed, this could be
-* changed.
-*/
+ * for system reset interrupts, despite them not being interlocked.
+ * PowerVM silently ignores this and returns success here. Returning
+ * failure causes Linux to print the error "FWNMI: nmi-interlock
+ * failed: -3", although no other apparent ill effects, this is a
+ * regression for the user when enabling FWNMI. So for now, match
+ * PowerVM. When most Linux clients are fixed, this could be
+ * changed.
+ */
 rtas_st(rets, 0, RTAS_OUT_SUCCESS);
 return;
 }
diff --git a/include/hw/ppc/ppc.h b/include/hw/ppc/ppc.h
index 364f165b4b..02af03ada2 100644
--- a/include/hw/ppc/ppc.h
+++ b/include/hw/ppc/ppc.h
@@ -99,11 +99,11 @@ enum {
 ARCH_MAC99_U3,
 };
 
-#define FW_CFG_PPC_WIDTH   (FW_CFG_ARCH_LOCAL + 0x00)
-#define FW_CFG_PPC_HEIGHT  (FW_CFG_ARCH_LOCAL + 0x01)
-#define FW_CFG_PPC_DEPTH   (FW_CFG_ARCH_LOCAL + 0x02)
-#define FW_CFG_PPC_TBFREQ  (FW_CFG_ARCH_LOCAL + 0x03)
-#define FW_CFG_PPC_CLOCKFREQ   (FW_CFG_ARCH_LOCAL + 0x04)
+#define FW_CFG_PPC_WIDTH(FW_CFG_ARCH_LOCAL + 0x00)
+#define FW_CFG_PPC_HEIGHT   (FW_CFG_ARCH_LOCAL + 0x01)
+#define FW_CFG_PPC_DEPTH(FW_CFG_ARCH_LOCAL + 0x02)
+#define FW_CFG_PPC_TBFREQ   (FW_CFG_ARCH_LOCAL + 0x03)
+#define FW_CFG_PPC_CLOCKFREQ(FW_CFG_ARCH_LOCAL + 0x04)
 #define FW_CFG_PPC_IS_KVM   (FW_CFG_ARCH_LOCAL + 0x05)
 #define FW_CFG_PPC_KVM_HC   (FW_CFG_ARCH_LOCAL + 0x06)
 #define FW_CFG_PPC_KVM_PID  (FW_CFG_ARCH_LOCAL + 0x07)
-- 
2.35.1




[RFC 1/3] serial: Enable MSI capablity and option

2022-04-11 Thread Atish Patra
The seria-pci device doesn't support MSI. Enable the device to provide
MSI so that any platform with MSI support only can also use
this serial device. MSI can be enabled by enabling the newly introduced
device property. This will be disabled by default preserving the current
behavior of the seria-pci device.

Signed-off-by: Atish Patra 
---
 hw/char/serial-pci.c | 36 +---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/hw/char/serial-pci.c b/hw/char/serial-pci.c
index 93d6f9924425..ca93c2ce2776 100644
--- a/hw/char/serial-pci.c
+++ b/hw/char/serial-pci.c
@@ -31,6 +31,7 @@
 #include "hw/char/serial.h"
 #include "hw/irq.h"
 #include "hw/pci/pci.h"
+#include "hw/pci/msi.h"
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
 #include "qom/object.h"
@@ -39,26 +40,54 @@ struct PCISerialState {
 PCIDevice dev;
 SerialState state;
 uint8_t prog_if;
+bool msi_enabled;
 };
 
 #define TYPE_PCI_SERIAL "pci-serial"
 OBJECT_DECLARE_SIMPLE_TYPE(PCISerialState, PCI_SERIAL)
 
+
+static void msi_irq_handler(void *opaque, int irq_num, int level)
+{
+PCIDevice *pci_dev = opaque;
+
+assert(level == 0 || level == 1);
+
+if (msi_enabled(pci_dev)) {
+msi_notify(pci_dev, 0);
+}
+}
+
 static void serial_pci_realize(PCIDevice *dev, Error **errp)
 {
 PCISerialState *pci = DO_UPCAST(PCISerialState, dev, dev);
 SerialState *s = &pci->state;
+Error *err = NULL;
+int ret;
 
 if (!qdev_realize(DEVICE(s), NULL, errp)) {
 return;
 }
 
 pci->dev.config[PCI_CLASS_PROG] = pci->prog_if;
-pci->dev.config[PCI_INTERRUPT_PIN] = 0x01;
-s->irq = pci_allocate_irq(&pci->dev);
-
+if (pci->msi_enabled) {
+pci->dev.config[PCI_INTERRUPT_PIN] = 0x00;
+s->irq = qemu_allocate_irq(msi_irq_handler, &pci->dev, 100);
+} else {
+pci->dev.config[PCI_INTERRUPT_PIN] = 0x01;
+s->irq = pci_allocate_irq(&pci->dev);
+}
 memory_region_init_io(&s->io, OBJECT(pci), &serial_io_ops, s, "serial", 8);
 pci_register_bar(&pci->dev, 0, PCI_BASE_ADDRESS_SPACE_IO, &s->io);
+
+if (!pci->msi_enabled) {
+return;
+}
+
+ret = msi_init(&pci->dev, 0, 1, true, false, &err);
+if (ret == -ENOTSUP) {
+fprintf(stdout, "MSIX INIT FAILED\n");
+}
 }
 
 static void serial_pci_exit(PCIDevice *dev)
@@ -83,6 +112,7 @@ static const VMStateDescription vmstate_pci_serial = {
 
 static Property serial_pci_properties[] = {
 DEFINE_PROP_UINT8("prog_if",  PCISerialState, prog_if, 0x02),
+DEFINE_PROP_BOOL("msi",  PCISerialState, msi_enabled, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
2.25.1




[RFC 0/3] Introduce a new Qemu machine for RISC-V

2022-04-11 Thread Atish Patra


The RISC-V virt machine has helped RISC-V software eco system to evolve at a
rapid pace even in absense of the real hardware. It is definitely commendable.
However, the number of devices & commandline options keeps growing as a result
of that as well. That adds flexibility but will also become bit difficult
to manage in the future as more extension support will be added. As it is the
most commonly used qemu machine, it needs to support all kinds of device and
interrupts as well. Moreover, virt machine has limitations on the maximum
number of harts it can support because of all the MMIO devices it has to 
support.

The RISC-V IMSIC specification allows to develop machines completely relying
on MSI and don't care about the wired interrupts at all. It just requires
all the devices to be present behind a PCI bus or present themselves as platform
MSI device. The former is a more common scenario in x86 world where most
of the devices are behind PCI bus. As there is very limited MMIO device
support, it can also scale to very large number of harts.

That's why, this patch series introduces a minimalistic yet very extensible
forward looking machine called as "RISC-V Mini Computer" or "minic". The
idea is to build PC or server like systems with this machine. The machine can
work with or without virtio framework. The current implementation only
supports RV64. I am not sure if building a RV32 machine would be of interest
for such machines. The only mmio device it requires is clint to emulate
the mtimecmp.

"Naming is hard". I am not too attached with the name "minic". 
I just chose least bad one out of the few on my mind :). I am definitely
open to any other name as well. 

The other alternative to provide MSI only option to aia in the 
existing virt machine to build MSI only machines. This is certainly doable
and here is the patch that supports that kind of setup.

https://github.com/atishp04/qemu/tree/virt_imsic_only

However, it even complicates the virt machine even further with additional
command line option, branches in the code. I believe virt machine will become
very complex if we continue this path. I am interested to learn what everyone
else think.

It is needless to say that the current version of minic machine
is inspired from virt machine and tries to reuse as much as code possible.
The first patch in this series adds MSI support for serial-pci device so
console can work on such a machine. The 2nd patch moves some common functions
between minic and the virt machine to a helper file. The PATCH3 actually
implements the new minic machine.

I have not added the fw-cfg/flash support. We probably should add those
but I just wanted to start small and get the feedback first.
This is a work in progress and have few more TODO items before becoming the
new world order :)

1. OpenSBI doesn't have PCI support. Thus, no console support for OpenSBI
for now.
2. The ns16550 driver in OpenSBI also need to support MSI/MSI-X.
3. Add MSI-X support for serial-pci device.

This series can boot Linux distros with the minic machine with or without virtio
devices with out-of-tree Linux kernel patches[1]. Here is an example 
commandline 

Without virtio devices (nvme, serial-pci & e1000e):
=
/scratch/workspace/qemu/build/qemu-system-riscv64 -cpu rv64 -M minic -m 1G -smp 
4 -nographic -nodefaults \
-display none -bios 
/scratch/workspace/opensbi/build/platform/generic/firmware/fw_dynamic.elf \
-kernel /scratch/workspace/linux/arch/riscv/boot/Image \
-chardev stdio,mux=on,signal=off,id=charconsole0 \
-mon chardev=charconsole0,mode=readline \
-device pci-serial,msi=true,chardev=charconsole0 \
-drive 
id=disk3,file=/scratch/workspace/rootfs_images//fedora/Fedora-Developer-Rawhide-2020.n.0-sda.raw,format=raw,if=none,id=drive-system-disk,cache=none,format=raw
 \
-device nvme,serial=deadbeef,drive=disk3 \
-netdev user,id=usernet,hostfwd=tcp::1-:22 -device 
e1000e,netdev=usernet,bus=pcie.0 \
-append 'root=/dev/nvme0n1p2 rw loglevel=8 memblock=debug console=ttyS0 
earlycon' -d in_asm -D log.txt -s

With virtio devices (virtio-scsi-pci, serial-pci & virtio-net-pci)
==
/scratch/workspace/qemu/build/qemu-system-riscv64 -cpu rv64 -M minic -m 1G -smp 
4 -nographic -nodefaults \
-display none -bios 
/scratch/workspace/opensbi/build/platform/generic/firmware/fw_dynamic.elf \
-kernel /scratch/workspace/linux/arch/riscv/boot/Image \
-chardev stdio,mux=on,signal=off,id=charconsole0 \
-mon chardev=charconsole0,mode=readline \
-device pci-serial,msi=true,chardev=charconsole0 \
-drive 
file=/scratch/workspace/rootfs_images//fedora/Fedora-Developer-Rawhide-2020.n.0-sda.raw,format=raw,if=none,id=drive-system-disk,cache=none
 \
-device virtio-scsi-pci,id=scsi0 -device 
scsi-hd,bus=scsi0.0,drive=drive-system-disk,id=system-disk,bootindex=1 \
-netdev user,id=n1,hostfwd=tcp::1-:22 -device virtio-net-pci,netdev=n1 \
-append 'roo

[RFC 3/3] hw/riscv: Create a new qemu machine for RISC-V

2022-04-11 Thread Atish Patra
The RISC-V virt machine has been growing with many different commmandline
options. It has its limitations in terms of maximum number of harts that
it can support. The commandline options slowly will become bit difficult
to manage. Moreover, it always depends on the virtio framework and lot
of mmio devices.

The new MSI based interrupt controller (IMSIC) allows us to build a
minimalistic yet extensible machines without any wired interrupts. All
the devices can be behind PCI with MSI/MSI-X are only source of external
interrupts. This approach is highly scalable in terms of number of harts
and also mimics modern day PC/server machines more closely. As every device
must be behind PCI, we won't require a lot of addition to the machine.

Signed-off-by: Atish Patra 
---
 configs/devices/riscv64-softmmu/default.mak |   1 +
 hw/riscv/Kconfig|  11 +
 hw/riscv/meson.build|   1 +
 hw/riscv/minic.c| 438 
 include/hw/riscv/minic.h|  65 +++
 5 files changed, 516 insertions(+)
 create mode 100644 hw/riscv/minic.c
 create mode 100644 include/hw/riscv/minic.h

diff --git a/configs/devices/riscv64-softmmu/default.mak 
b/configs/devices/riscv64-softmmu/default.mak
index bc69301fa4a6..1407c4a9fe2f 100644
--- a/configs/devices/riscv64-softmmu/default.mak
+++ b/configs/devices/riscv64-softmmu/default.mak
@@ -14,3 +14,4 @@ CONFIG_SIFIVE_U=y
 CONFIG_RISCV_VIRT=y
 CONFIG_MICROCHIP_PFSOC=y
 CONFIG_SHAKTI_C=y
+CONFIG_MINIC=y
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index 91bb9d21c471..9eca1a6efa25 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -83,3 +83,14 @@ config SPIKE
 select MSI_NONBROKEN
 select RISCV_ACLINT
 select SIFIVE_PLIC
+
+config MINIC
+bool
+imply PCI_DEVICES
+select RISCV_NUMA
+select MSI_NONBROKEN
+select PCI
+select PCI_EXPRESS_GENERIC_BRIDGE
+select SERIAL
+select RISCV_ACLINT
+select RISCV_IMSIC
diff --git a/hw/riscv/meson.build b/hw/riscv/meson.build
index b3ae84ac0539..7b1c49466e62 100644
--- a/hw/riscv/meson.build
+++ b/hw/riscv/meson.build
@@ -10,5 +10,6 @@ riscv_ss.add(when: 'CONFIG_SIFIVE_E', if_true: 
files('sifive_e.c'))
 riscv_ss.add(when: 'CONFIG_SIFIVE_U', if_true: files('sifive_u.c'))
 riscv_ss.add(when: 'CONFIG_SPIKE', if_true: files('spike.c'))
 riscv_ss.add(when: 'CONFIG_MICROCHIP_PFSOC', if_true: 
files('microchip_pfsoc.c'))
+riscv_ss.add(when: 'CONFIG_MINIC', if_true: files('minic.c'))
 
 hw_arch += {'riscv': riscv_ss}
diff --git a/hw/riscv/minic.c b/hw/riscv/minic.c
new file mode 100644
index ..4ca707da1023
--- /dev/null
+++ b/hw/riscv/minic.c
@@ -0,0 +1,438 @@
+/*
+ * QEMU RISC-V Mini Computer
+ *
+ * Based on the minic machine implementation
+ *
+ * Copyright (c) 2022 Rivos, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "hw/sysbus.h"
+#include "hw/qdev-properties.h"
+#include "target/riscv/cpu.h"
+#include "hw/riscv/riscv_hart.h"
+#include "hw/riscv/minic.h"
+#include "hw/riscv/machine_helper.h"
+#include "hw/intc/riscv_aclint.h"
+#include "hw/intc/riscv_imsic.h"
+#include "hw/riscv/boot.h"
+#include "hw/riscv/numa.h"
+#include "chardev/char.h"
+#include "sysemu/device_tree.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/kvm.h"
+#include "hw/pci/pci.h"
+#include "hw/pci-host/gpex.h"
+#include "hw/display/ramfb.h"
+
+#define MINIC_IMSIC_GROUP_MAX_SIZE  (1U << IMSIC_MMIO_GROUP_MIN_SHIFT)
+#if MINIC_IMSIC_GROUP_MAX_SIZE < \
+IMSIC_GROUP_SIZE(MINIC_CPUS_MAX_BITS, MINIC_IRQCHIP_MAX_GUESTS_BITS)
+#error "Can't accomodate single IMSIC group in address space"
+#endif
+
+#define MINIC_IMSIC_MAX_SIZE(MINIC_SOCKETS_MAX * \
+MINIC_IMSIC_GROUP_MAX_SIZE)
+#if 0x400 < MINIC_IMSIC_MAX_SIZE
+#error "Can't accomodate all IMSIC groups in address space"
+#endif
+
+static const MemMapEntry minic_memmap[] = {
+[MINIC_MROM] ={ 0x1000,0xf000 },
+[MINIC_CLINT] =   {  0x200,   0x1 },
+[MINIC_PCIE_PIO] ={  0x300,   0x1 },
+[MINIC_IMSIC_M] = { 0x2400, MINIC_IMSIC_MAX_SIZE },
+[MINIC_IMSIC_S] = { 0x2800, MINIC_IMSIC_MAX_SIZE },
+[MINIC_PCIE_E

Re: [PATCH 0/5] target/arm: Support variable sized coprocessor registers

2022-04-11 Thread Gavin Shan

Hi Drew,

On 4/11/22 8:02 PM, Andrew Jones wrote:

On Mon, Apr 11, 2022 at 10:22:59AM +0100, Peter Maydell wrote:

On Mon, 11 Apr 2022 at 07:59, Gavin Shan  wrote:


There are two arrays for each CPU, to store the indexes and values of the
coprocessor registers. Currently, 8 bytes fixed storage space is reserved
for each coprocessor register. However, larger coprocessor registers have
been defined and exposed by KVM. Except SVE registers, no coprocessor
register exceeds 8 bytes in size. It doesn't mean large coprocessor registers
won't be exploited in future. For example, I'm looking into SDEI virtualization
support, which isn't merged into Linux upstream yet. I have plan to add
several coprocessor ("firmware pseudo") registers to assist the migration.


So, can you give an example of coprocessor registers which are
not 8 bytes in size? How are they accessed by the guest?
If we need to support them then we need to support them, but this
cover letter/series doesn't seem to me to provide enough detail
to make the case that they really are necessary.

Also, we support SVE today, and we don't have variable size
coprocessor registers. Is there a bug here that we would be
fixing ?


SVE registers are KVM_REG_SIZE_U2048 and KVM_REG_SIZE_U256 sized
registers. They work fine (just like the VFP registers which are
KVM_REG_SIZE_U128 sized). They work because they don't get stored in the
cpreg list. SVE and CORE (which includes VFP) registers are filtered
out by kvm_arm_reg_syncs_via_cpreg_list(). Since they're filtered
out they need to be handled specifically by kvm_arch_get/put_registers()

I asked Gavin to check if following the SVE pattern made sense for his
use case prior to sending this series, but I don't see the rationale for
not following the SVE pattern in this cover letter. Gavin, can you please
explain why following the SVE pattern doesn't work? Or, are you trying to
avoid adding an additional special case?



Yes, SVE registers are special case. They're not synchronized through
coprocessor register list as you mentioned. For SDEI, we mimic PSCI
because both of them are firmware interfaces.

PSCI's pseudo-registers are synchronized and migrated through the
coprocessor register list. Besides, treating SDEI as additional
special case should work, but more maintaining load will be introduced.
We need separate functions to get/set SDEI's pseudo registers, like
what we did for SVE.

Thanks,
Gavin




Re: [PATCH v2 4/9] target/ppc: Implemented vector divide extended word

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)" 

Implement the following PowerISA v3.1 instructions:
vdivesw: Vector Divide Extended Signed Word
vdiveuw: Vector Divide Extended Unsigned Word

Signed-off-by: Lucas Mateus Castro (alqotel) 
---
  target/ppc/insn32.decode|  3 ++
  target/ppc/translate/vmx-impl.c.inc | 48 +
  2 files changed, 51 insertions(+)

diff --git a/target/ppc/insn32.decode b/target/ppc/insn32.decode
index 3a88a0b5bc..8c115c9c60 100644
--- a/target/ppc/insn32.decode
+++ b/target/ppc/insn32.decode
@@ -712,3 +712,6 @@ VDIVSD  000100 . . . 00111001011@VX
  VDIVUD  000100 . . . 00011001011@VX
  VDIVSQ  000100 . . . 0011011@VX
  VDIVUQ  000100 . . . 0001011@VX
+
+VDIVESW 000100 . . . 01110001011@VX
+VDIVEUW 000100 . . . 01010001011@VX
diff --git a/target/ppc/translate/vmx-impl.c.inc 
b/target/ppc/translate/vmx-impl.c.inc
index bac0db7128..8799e945bd 100644
--- a/target/ppc/translate/vmx-impl.c.inc
+++ b/target/ppc/translate/vmx-impl.c.inc
@@ -3295,6 +3295,54 @@ TRANS_VDIV_VMOD(ISA310, VDIVUD, MO_64, NULL, do_divud)
  TRANS_FLAGS2(ISA310, VDIVSQ, do_vx_helper, gen_helper_VDIVSQ)
  TRANS_FLAGS2(ISA310, VDIVUQ, do_vx_helper, gen_helper_VDIVUQ)
  
+static void do_dives_i32(TCGv_i32 t, TCGv_i32 a, TCGv_i32 b)

+{
+TCGv_i64 val1, val2;
+
+val1 = tcg_temp_new_i64();
+val2 = tcg_temp_new_i64();
+
+tcg_gen_ext_i32_i64(val1, a);
+tcg_gen_ext_i32_i64(val2, b);
+
+/* (a << 32)/b */
+tcg_gen_shli_i64(val1, val1, 32);
+tcg_gen_div_i64(val1, val1, val2);
+
+/* if quotient doesn't fit in 32 bits the result is undefined */
+tcg_gen_extrl_i64_i32(t, val1);
+
+tcg_temp_free_i64(val1);
+tcg_temp_free_i64(val2);
+}
+
+static void do_diveu_i32(TCGv_i32 t, TCGv_i32 a, TCGv_i32 b)
+{
+TCGv_i64 val1, val2;
+
+val1 = tcg_temp_new_i64();
+val2 = tcg_temp_new_i64();
+
+tcg_gen_extu_i32_i64(val1, a);
+tcg_gen_extu_i32_i64(val2, b);
+
+/* (a << 32)/b */
+tcg_gen_shli_i64(val1, val1, 32);
+tcg_gen_divu_i64(val1, val1, val2);
+
+/* if quotient doesn't fit in 32 bits the result is undefined */
+tcg_gen_extrl_i64_i32(t, val1);
+
+tcg_temp_free_i64(val1);
+tcg_temp_free_i64(val2);
+}
+
+DO_VDIV_VMOD(do_divesw, 32, do_dives_i32, true)
+DO_VDIV_VMOD(do_diveuw, 32, do_diveu_i32, false)


Oh, I see, you do have one more use for the full min/-1 treatment.
It would still be nice if the macro were minimal and you use a callback.


r~



Re: [PATCH 0/5] target/arm: Support variable sized coprocessor registers

2022-04-11 Thread Gavin Shan

Hi Peter,

On 4/11/22 6:05 PM, Peter Maydell wrote:

On Mon, 11 Apr 2022 at 10:50, Gavin Shan  wrote:

On 4/11/22 5:22 PM, Peter Maydell wrote:

So, can you give an example of coprocessor registers which are
not 8 bytes in size? How are they accessed by the guest?
If we need to support them then we need to support them, but this
cover letter/series doesn't seem to me to provide enough detail
to make the case that they really are necessary.

Also, we support SVE today, and we don't have variable size
coprocessor registers. Is there a bug here that we would be
fixing ?



[Cc Oliver Upon]

Apart from SVE registers, I don't think we have any more large registers
whose sizes exceed 8 bytes for now, until SDEI virtualization needs more
large registers for migration.

I'm working the KVM series to support SDEI virtualization and last revision
is v6. One of the requirement is to migrate the SDEI events and states.
In v5, the migration is done by the dedicated ioctl commands and it was
suggested by Oliver to use {GET, SET}_ONE_REG. Note that the series isn't
merged yet. So I had the prototype to support SDEI's migration through
{GET, SET}_ONE_REG. Note that those newly added registers are inaccessible
from guest.

https://github.com/gwshan/linux/commit/c2e5de5e210de6b003d1e1330eeb0958cf7007f5
(branch: kvm/arm64_sdei)

https://lore.kernel.org/lkml/20220403153911.12332-13-gs...@redhat.com/T/   
(last revision: v6)
https://lore.kernel.org/kvmarm/yjtyuk+jx1dfp...@google.com/(v5)


Could you please describe what you're trying to do here rather
than asking me to wade through a big kernel patchset that's
adding support for a firmware interface I don't know?



I'm working on two serieses to support SDEI virtualization and asynchronous
page fault (Async PF) on arm64. When currently running thread is experiencing
stage-2 page fault, Async PF picks another thread for execution. After the
stage-2 page fault is resolved, that thread resumes. Async PF is driven by
notifications sent from host to guest. One of the notifications is delivered
by SDEI event. The SDEI event is something like NMI to some extent. When
the SDEI event is raised by host, it will be delivered to guest and the
previously registered (associated) event handler is invoked in guest.

One of the concerns for SDEI virtualization is how those SDEI events
and states can be migrated. Previously, I had dedicated ioctl commands
to read/write the SDEI events and states. Later, Oliver suggested to
use {GET,SET}_ONE_REG to do migration. I think it's much better than
the dedicated ioctl commands in terms of maintenance cost. In this case,
several 'firmware pseudo registers', like what PSCI is doing, will be
added and some of their sizes will exceed 8 bytes. On the other hand,
the SDEI events and states can be naturally treated as CPU's properties.
It's another reason why pseudo-registers fits the need to migrate
those SDEI events and states.

More information about SDEI can be found from its spec:

https://developer.arm.com/documentation/den0054/latest


There are large coprocessor register sizes, like U2048, exposed by KVM.
However, it seems we never support those large coprocessor registers.
I'm not sure if we have any challenges to support those large registers,
or we don't have the needs yet?


The general idea of the coprocessor register accessors for aarch64 KVM
is that we're giving the VMM access to the same registers that the guest
accesses via the msr/mrs instructions. Those instructions by definition
access 64 bit quantities. In a few places we've borrowed this mechanism
to define KVM-specific pseudo-registers, but that wasn't the primary
design intent. So maybe it makes sense to extend it to do what you're
trying to, or maybe that would be the tail wagging the dog. It's hard
to tell without more detail on what exactly you're trying to expose
to the VMM here.

(The ONE_REG API is used by more than just aarch64 and more than just
for coprocessor registers, which is why it supports lots of different
sizes.)



Yes, we're considering 'KVM specific pseudo-registers' for migrating
SDEI events and states. Those pseudo-registers shouldn't be accessed
from guest, meaning they're only accessed by VMM (QEMU). I think
pseudo-registers fits the need very well, to migrate SDEI events
and states.

Thanks,
Gavin




Re: [PATCH v2 3/9] target/ppc: Implemented vector divide quadword

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)"

Implement the following PowerISA v3.1 instructions:
vdivsq: Vector Divide Signed Quadword
vdivuq: Vector Divide Unsigned Quadword

Signed-off-by: Lucas Mateus Castro (alqotel)
---
  target/ppc/helper.h |  2 ++
  target/ppc/insn32.decode|  2 ++
  target/ppc/int_helper.c | 21 +
  target/ppc/translate/vmx-impl.c.inc |  2 ++
  4 files changed, 27 insertions(+)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH v2 2/9] target/ppc: Implemented vector divide instructions

2022-04-11 Thread Richard Henderson

On 4/5/22 12:55, Lucas Mateus Castro(alqotel) wrote:

From: "Lucas Mateus Castro (alqotel)" 

Implement the following PowerISA v3.1 instructions:
vdivsw: Vector Divide Signed Word
vdivuw: Vector Divide Unsigned Word
vdivsd: Vector Divide Signed Doubleword
vdivud: Vector Divide Unsigned Doubleword

Signed-off-by: Lucas Mateus Castro (alqotel) 
---
  target/ppc/insn32.decode|  7 
  target/ppc/translate/vmx-impl.c.inc | 59 +
  2 files changed, 66 insertions(+)

diff --git a/target/ppc/insn32.decode b/target/ppc/insn32.decode
index ac2d3da9a7..597768558b 100644
--- a/target/ppc/insn32.decode
+++ b/target/ppc/insn32.decode
@@ -703,3 +703,10 @@ XVTLSBB 00 ... -- 00010 . 111011011 . - 
@XX2_bf_xb
  &XL_s   s:uint8_t
  @XL_s   ..-- s:1 .. -   &XL_s
  RFEBB   010011-- .   0010010010 -   @XL_s
+
+## Vector Division Instructions
+
+VDIVSW  000100 . . . 00110001011@VX
+VDIVUW  000100 . . . 00010001011@VX
+VDIVSD  000100 . . . 00111001011@VX
+VDIVUD  000100 . . . 00011001011@VX
diff --git a/target/ppc/translate/vmx-impl.c.inc 
b/target/ppc/translate/vmx-impl.c.inc
index 6101bca3fd..be35d6fdf3 100644
--- a/target/ppc/translate/vmx-impl.c.inc
+++ b/target/ppc/translate/vmx-impl.c.inc
@@ -3236,6 +3236,65 @@ TRANS(VMULHSD, do_vx_mulh, true , do_vx_vmulhd_i64)
  TRANS(VMULHUW, do_vx_mulh, false, do_vx_vmulhw_i64)
  TRANS(VMULHUD, do_vx_mulh, false, do_vx_vmulhd_i64)
  
+#define TRANS_VDIV_VMOD(FLAGS, NAME, VECE, FNI4_FUNC, FNI8_FUNC)\

+static bool trans_##NAME(DisasContext *ctx, arg_VX *a)  \
+{   \
+static const GVecGen3 op = {\
+.fni4 = FNI4_FUNC,  \
+.fni8 = FNI8_FUNC,  \
+.vece = VECE\
+};  \
+\
+REQUIRE_VECTOR(ctx);\
+REQUIRE_INSNS_FLAGS2(ctx, FLAGS);   \
+\
+tcg_gen_gvec_3(avr_full_offset(a->vrt), avr_full_offset(a->vra),\
+   avr_full_offset(a->vrb), 16, 16, &op);   \
+\
+return true;\
+}


Better to use a standalone helper and TRANS() -- the op structure doesn't *need* to be 
static const.



+
+#define DO_VDIV_VMOD(NAME, SZ, DIV, SIGNED) \
+static void NAME(TCGv_i##SZ t, TCGv_i##SZ a, TCGv_i##SZ b)  \
+{   \
+/*  \
+ *  If N/0 the instruction used by the backend might deliver\
+ *  an invalid division signal to the process, so if b = 0 return   \
+ *  N/1 and if signed instruction, the same for a = int_min, b = -1 \
+ */ \
+if (SIGNED) {   \
+TCGv_i##SZ t0 = tcg_temp_new_i##SZ();   \
+TCGv_i##SZ t1 = tcg_temp_new_i##SZ();   \
+tcg_gen_setcondi_i##SZ(TCG_COND_EQ, t0, a, INT##SZ##_MIN);  \
+tcg_gen_setcondi_i##SZ(TCG_COND_EQ, t1, b, -1); \
+tcg_gen_and_i##SZ(t0, t0, t1);  \
+tcg_gen_setcondi_i##SZ(TCG_COND_EQ, t1, b, 0);  \
+tcg_gen_or_i##SZ(t0, t0, t1);   \
+tcg_gen_movi_i##SZ(t1, 0);  \
+tcg_gen_movcond_i##SZ(TCG_COND_NE, b, t0, t1, t0, b);   \
+DIV(t, a, b);   \
+tcg_temp_free_i##SZ(t0);\
+tcg_temp_free_i##SZ(t1);\
+} else {\
+TCGv_i##SZ zero = tcg_constant_i##SZ(0);\
+TCGv_i##SZ one = tcg_constant_i##SZ(1); \
+tcg_gen_movcond_i##SZ(TCG_COND_EQ, b, b, zero, one, b); \
+DIV(t, a, b);   \
+}   \
+}


This is overkill.  Even if you keep some macros, passing in SIGNE

Re: [PATCH v2 1/2] hw/core: Sync uboot_image.h from U-Boot v2022.01

2022-04-11 Thread Bin Meng
On Thu, Mar 24, 2022 at 9:48 PM Bin Meng  wrote:
>
> From: Bin Meng 
>
> Sync uboot_image.h from upstream U-Boot v2022.01 release [1].
>
> [1] https://source.denx.de/u-boot/u-boot/-/blob/v2022.01/include/image.h
>
> Signed-off-by: Bin Meng 
> ---
>
> (no changes since v1)
>
>  hw/core/uboot_image.h | 213 --
>  1 file changed, 142 insertions(+), 71 deletions(-)
>

Ping?



Re: [PATCH v3] hw/riscv: virt: Exit if the user provided -bios in combination with KVM

2022-04-11 Thread Bin Meng
On Fri, Apr 1, 2022 at 8:19 PM Ralf Ramsauer
 wrote:
>
> The -bios option is silently ignored if used in combination with -enable-kvm.
> The reason is that the machine starts in S-Mode, and the bios typically runs 
> in
> M-Mode.
>
> Better exit in that case to not confuse the user.
>
> Signed-off-by: Ralf Ramsauer 
> ---
>  hw/riscv/virt.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 



[PATCH v2 24/24] target/arm: Define neoverse-n1

2022-04-11 Thread Richard Henderson
Enable the n1 for virt and sbsa board use.

Signed-off-by: Richard Henderson 
---
 docs/system/arm/virt.rst |  1 +
 hw/arm/sbsa-ref.c|  1 +
 hw/arm/virt.c|  1 +
 target/arm/cpu64.c   | 66 
 4 files changed, 69 insertions(+)

diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index e9ff81aa21..e8e851a15b 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -58,6 +58,7 @@ Supported guest CPU types:
 - ``cortex-a76`` (64-bit)
 - ``a64fx`` (64-bit)
 - ``host`` (with KVM only)
+- ``neoverse-n1`` (64-bit)
 - ``max`` (same as ``host`` for KVM; best possible emulation with TCG)
 
 Note that the default is ``cortex-a15``, so for an AArch64 guest you must
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 2ddde88f5e..dac8860f2d 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -146,6 +146,7 @@ static const char * const valid_cpus[] = {
 ARM_CPU_TYPE_NAME("cortex-a57"),
 ARM_CPU_TYPE_NAME("cortex-a72"),
 ARM_CPU_TYPE_NAME("cortex-a76"),
+ARM_CPU_TYPE_NAME("neoverse-n1"),
 ARM_CPU_TYPE_NAME("max"),
 };
 
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ce15c36a7f..82dd934de6 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -204,6 +204,7 @@ static const char *valid_cpus[] = {
 ARM_CPU_TYPE_NAME("cortex-a72"),
 ARM_CPU_TYPE_NAME("cortex-a76"),
 ARM_CPU_TYPE_NAME("a64fx"),
+ARM_CPU_TYPE_NAME("neoverse-n1"),
 ARM_CPU_TYPE_NAME("host"),
 ARM_CPU_TYPE_NAME("max"),
 };
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 7dbd649b0c..4bfa8af833 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -259,6 +259,71 @@ static void aarch64_a76_initfn(Object *obj)
 cpu->isar.mvfr2 = 0x0043;
 }
 
+static void aarch64_neoverse_n1_initfn(Object *obj)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+cpu->dtb_compatible = "arm,neoverse-n1";
+set_feature(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
+set_feature(&cpu->env, ARM_FEATURE_AARCH64);
+set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
+set_feature(&cpu->env, ARM_FEATURE_EL2);
+set_feature(&cpu->env, ARM_FEATURE_EL3);
+set_feature(&cpu->env, ARM_FEATURE_PMU);
+
+/* Ordered by B2.4 AArch64 registers by functional group */
+cpu->clidr = 0x8223;
+cpu->ctr = 0x8444c004;
+cpu->dcz_blocksize = 4;
+cpu->isar.id_aa64dfr0  = 0x000110305408ull;
+cpu->isar.id_aa64isar0 = 0x100010211120ull;
+cpu->isar.id_aa64isar1 = 0x0011ull;
+cpu->isar.id_aa64mmfr0 = 0x00101125ull;
+cpu->isar.id_aa64mmfr1 = 0x10212122ull;
+cpu->isar.id_aa64mmfr2 = 0x1011ull;
+cpu->isar.id_aa64pfr0  = 0x11001012ull; /* GIC filled in later */
+cpu->isar.id_aa64pfr1  = 0x0020ull;
+cpu->id_afr0   = 0x;
+cpu->isar.id_dfr0  = 0x04010088;
+cpu->isar.id_isar0 = 0x02101110;
+cpu->isar.id_isar1 = 0x13112111;
+cpu->isar.id_isar2 = 0x21232042;
+cpu->isar.id_isar3 = 0x01112131;
+cpu->isar.id_isar4 = 0x00010142;
+cpu->isar.id_isar5 = 0x01011121;
+cpu->isar.id_isar6 = 0x0010;
+cpu->isar.id_mmfr0 = 0x10201105;
+cpu->isar.id_mmfr1 = 0x4000;
+cpu->isar.id_mmfr2 = 0x0126;
+cpu->isar.id_mmfr3 = 0x02122211;
+cpu->isar.id_mmfr4 = 0x00021110;
+cpu->isar.id_pfr0  = 0x10010131;
+cpu->isar.id_pfr1  = 0x0001; /* GIC filled in later */
+cpu->isar.id_pfr2  = 0x0011;
+cpu->midr = 0x414fd0c1;  /* r4p1 */
+cpu->revidr = 0;
+
+/* From B2.23 CCSIDR_EL1 */
+cpu->ccsidr[0] = 0x701fe01a; /* 64KB L1 dcache */
+cpu->ccsidr[1] = 0x201fe01a; /* 64KB L1 icache */
+cpu->ccsidr[2] = 0x70ffe03a; /* 1MB L2 cache */
+
+/* From B2.98 SCTLR_EL3 */
+cpu->reset_sctlr = 0x30c50838;
+
+/* From B4.23 ICH_VTR_EL2 */
+cpu->gic_num_lrs = 4;
+cpu->gic_vpribits = 5;
+cpu->gic_vprebits = 5;
+
+/* From B5.1 AdvSIMD AArch64 register summary */
+cpu->isar.mvfr0 = 0x10110222;
+cpu->isar.mvfr1 = 0x1321;
+cpu->isar.mvfr2 = 0x0043;
+}
+
 void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp)
 {
 /*
@@ -946,6 +1011,7 @@ static const ARMCPUInfo aarch64_cpus[] = {
 { .name = "cortex-a72", .initfn = aarch64_a72_initfn },
 { .name = "cortex-a76", .initfn = aarch64_a76_initfn },
 { .name = "a64fx",  .initfn = aarch64_a64fx_initfn },
+{ .name = "neoverse-n1",.initfn = aarch64_neoverse_n1_initfn },
 { .name = "max",.initfn = aarch64_max_initfn },
 #if defined(CONFIG_KVM) || defined(CONFIG_HVF)
 { .name = "host",   .initfn = aarch64_host_initfn },
-- 
2.25.1




[PATCH v2 21/24] target/arm: Enable FEAT_CSV3 for -cpu max

2022-04-11 Thread Richard Henderson
This extension concerns cache speculation, which TCG does
not implement.  Thus we can trivially enable this feature.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c| 1 +
 target/arm/cpu_tcg.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index aebe3be1ba..f75f0fc110 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -15,6 +15,7 @@ the following architecture extensions:
 - FEAT_CSV2_1p1 (Cache speculation variant 2, version 1.1)
 - FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2)
 - FEAT_CSV2_2 (Cache speculation variant 2, version 2)
+- FEAT_CSV3 (Cache speculation variant 3)
 - FEAT_DIT (Data Independent Timing instructions)
 - FEAT_DPB (DC CVAP instruction)
 - FEAT_Debugv8p2 (Debug changes for v8.2)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 98fc3ace1f..2b6b9afd76 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -749,6 +749,7 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);  /* FEAT_SEL2 */
 t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);   /* FEAT_DIT */
 t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 2);  /* FEAT_CSV2_2 */
+t = FIELD_DP64(t, ID_AA64PFR0, CSV3, 1);  /* FEAT_CSV3 */
 cpu->isar.id_aa64pfr0 = t;
 
 t = cpu->isar.id_aa64pfr1;
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 7775a84575..2592d7008a 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -73,6 +73,7 @@ void arm32_max_features(ARMCPU *cpu)
 cpu->isar.id_pfr0 = t;
 
 t = cpu->isar.id_pfr2;
+t = FIELD_DP32(t, ID_PFR2, CSV3, 1);  /* FEAT_CSV3 */
 t = FIELD_DP32(t, ID_PFR2, SSBS, 1);  /* FEAT_SSBS */
 cpu->isar.id_pfr2 = t;
 
-- 
2.25.1




[PATCH v2 18/24] target/arm: Enable FEAT_CSV2 for -cpu max

2022-04-11 Thread Richard Henderson
This extension concerns branch speculation, which TCG does
not implement.  Thus we can trivially enable this feature.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c| 1 +
 target/arm/cpu_tcg.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index ebd9e418cc..91fb06c579 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -11,6 +11,7 @@ the following architecture extensions:
 - FEAT_AES (AESD and AESE instructions)
 - FEAT_BF16 (AArch64 BFloat16 instructions)
 - FEAT_BTI (Branch Target Identification)
+- FEAT_CSV2 (Cache speculation variant 2)
 - FEAT_DIT (Data Independent Timing instructions)
 - FEAT_DPB (DC CVAP instruction)
 - FEAT_Debugv8p2 (Debug changes for v8.2)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index c91528a12e..eb4bcd8e80 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -748,6 +748,7 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
 t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);  /* FEAT_SEL2 */
 t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);   /* FEAT_DIT */
+t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 1);  /* FEAT_CSV2 */
 cpu->isar.id_aa64pfr0 = t;
 
 t = cpu->isar.id_aa64pfr1;
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 4aa2eb0841..7775a84575 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -67,6 +67,7 @@ void arm32_max_features(ARMCPU *cpu)
 cpu->isar.id_mmfr4 = t;
 
 t = cpu->isar.id_pfr0;
+t = FIELD_DP32(t, ID_PFR0, CSV2, 2);  /* FEAT_CVS2 */
 t = FIELD_DP32(t, ID_PFR0, DIT, 1);   /* FEAT_DIT */
 t = FIELD_DP32(t, ID_PFR0, RAS, 1);   /* FEAT_RAS */
 cpu->isar.id_pfr0 = t;
-- 
2.25.1




[PATCH v2 20/24] target/arm: Enable FEAT_CSV2_2 for -cpu max

2022-04-11 Thread Richard Henderson
There is no branch prediction in TCG, therefore there is no
need to actually include the context number into the predictor.
Therefore all we need to do is add the state for SCXTNUM_ELx.

Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst; clear CSV2_FRAC; use decimal; tidy access_scxtnum.
---
 docs/system/arm/emulation.rst |  3 ++
 target/arm/cpu.h  | 16 +
 target/arm/cpu64.c|  3 +-
 target/arm/helper.c   | 67 ++-
 4 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 91fb06c579..aebe3be1ba 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -12,6 +12,9 @@ the following architecture extensions:
 - FEAT_BF16 (AArch64 BFloat16 instructions)
 - FEAT_BTI (Branch Target Identification)
 - FEAT_CSV2 (Cache speculation variant 2)
+- FEAT_CSV2_1p1 (Cache speculation variant 2, version 1.1)
+- FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2)
+- FEAT_CSV2_2 (Cache speculation variant 2, version 2)
 - FEAT_DIT (Data Independent Timing instructions)
 - FEAT_DPB (DC CVAP instruction)
 - FEAT_Debugv8p2 (Debug changes for v8.2)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 6793336b5e..4b3b537fff 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -687,6 +687,8 @@ typedef struct CPUArchState {
 ARMPACKey apdb;
 ARMPACKey apga;
 } keys;
+
+uint64_t scxtnum_el[4];
 #endif
 
 #if defined(CONFIG_USER_ONLY)
@@ -1210,6 +1212,7 @@ void pmu_init(ARMCPU *cpu);
 #define SCTLR_WXN (1U << 19)
 #define SCTLR_ST  (1U << 20) /* up to ??, RAZ in v6 */
 #define SCTLR_UWXN(1U << 20) /* v7 onward, AArch32 only */
+#define SCTLR_TSCXT   (1U << 20) /* FEAT_CSV2_1p2, AArch64 only */
 #define SCTLR_FI  (1U << 21) /* up to v7, v8 RES0 */
 #define SCTLR_IESB(1U << 21) /* v8.2-IESB, AArch64 only */
 #define SCTLR_U   (1U << 22) /* up to v6, RAO in v7 */
@@ -4368,6 +4371,19 @@ static inline bool isar_feature_aa64_dit(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, DIT) != 0;
 }
 
+static inline bool isar_feature_aa64_scxtnum(const ARMISARegisters *id)
+{
+int key = FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, CSV2);
+if (key >= 2) {
+return true;  /* FEAT_CSV2_2 */
+}
+if (key == 1) {
+key = FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, CSV2_FRAC);
+return key >= 2;  /* FEAT_CSV2_1p2 */
+}
+return false;
+}
+
 static inline bool isar_feature_aa64_ssbs(const ARMISARegisters *id)
 {
 return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, SSBS) != 0;
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index eb4bcd8e80..98fc3ace1f 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -748,7 +748,7 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
 t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);  /* FEAT_SEL2 */
 t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);   /* FEAT_DIT */
-t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 1);  /* FEAT_CSV2 */
+t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 2);  /* FEAT_CSV2_2 */
 cpu->isar.id_aa64pfr0 = t;
 
 t = cpu->isar.id_aa64pfr1;
@@ -760,6 +760,7 @@ static void aarch64_max_initfn(Object *obj)
  * we do for EL2 with the virtualization=on property.
  */
 t = FIELD_DP64(t, ID_AA64PFR1, MTE, 3);   /* FEAT_MTE3 */
+t = FIELD_DP64(t, ID_AA64PFR1, CSV2_FRAC, 0); /* FEAT_CSV2_2 */
 cpu->isar.id_aa64pfr1 = t;
 
 t = cpu->isar.id_aa64mmfr0;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index c29409f060..0291666c03 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1780,6 +1780,9 @@ static void scr_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 if (cpu_isar_feature(aa64_mte, cpu)) {
 valid_mask |= SCR_ATA;
 }
+if (cpu_isar_feature(aa64_scxtnum, cpu)) {
+valid_mask |= SCR_ENSCXT;
+}
 } else {
 valid_mask &= ~(SCR_RW | SCR_ST);
 if (cpu_isar_feature(aa32_ras, cpu)) {
@@ -5312,6 +5315,9 @@ static void do_hcr_write(CPUARMState *env, uint64_t 
value, uint64_t valid_mask)
 if (cpu_isar_feature(aa64_mte, cpu)) {
 valid_mask |= HCR_ATA | HCR_DCT | HCR_TID5;
 }
+if (cpu_isar_feature(aa64_scxtnum, cpu)) {
+valid_mask |= HCR_ENSCXT;
+}
 }
 
 /* Clear RES0 bits.  */
@@ -5965,6 +5971,10 @@ static void define_arm_vh_e2h_redirects_aliases(ARMCPU 
*cpu)
 { K(3, 0,  5, 6, 0), K(3, 4,  5, 6, 0), K(3, 5, 5, 6, 0),
   "TFSR_EL1", "TFSR_EL2", "TFSR_EL12", isar_feature_aa64_mte },
 
+{ K(3, 0, 13, 0, 7), K(3, 4, 13, 0, 7), K(3, 5, 13, 0, 7),
+  "SCXTNUM_EL1", "SCXTNUM_EL2", "SCXTNUM_EL12",
+  isar_feature_aa64_scxtnum },
+
 /* TODO: ARMv8.2-SPE -- PMSCR_EL2 */
 /* TODO: ARMv8.4-Trace -- TRFCR_EL2 */
 

[PATCH v2 19/24] target/arm: Update ISAR fields for ARMv8.8

2022-04-11 Thread Richard Henderson
Update isar fields per ARM DDI0487 H.a.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Add ID_AA64DFR0.HPMN0
---
 target/arm/cpu.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 7ca2463e17..6793336b5e 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1940,6 +1940,7 @@ FIELD(ID_MMFR4, CCIDX, 24, 4)
 FIELD(ID_MMFR4, EVT, 28, 4)
 
 FIELD(ID_MMFR5, ETS, 0, 4)
+FIELD(ID_MMFR5, NTLBPA, 4, 4)
 
 FIELD(ID_PFR0, STATE0, 0, 4)
 FIELD(ID_PFR0, STATE1, 4, 4)
@@ -1992,6 +1993,16 @@ FIELD(ID_AA64ISAR1, SPECRES, 40, 4)
 FIELD(ID_AA64ISAR1, BF16, 44, 4)
 FIELD(ID_AA64ISAR1, DGH, 48, 4)
 FIELD(ID_AA64ISAR1, I8MM, 52, 4)
+FIELD(ID_AA64ISAR1, XS, 56, 4)
+FIELD(ID_AA64ISAR1, LS64, 60, 4)
+
+FIELD(ID_AA64ISAR2, WFXT, 0, 4)
+FIELD(ID_AA64ISAR2, RPRES, 4, 4)
+FIELD(ID_AA64ISAR2, GPA3, 8, 4)
+FIELD(ID_AA64ISAR2, APA3, 12, 4)
+FIELD(ID_AA64ISAR2, MOPS, 16, 4)
+FIELD(ID_AA64ISAR2, BC, 20, 4)
+FIELD(ID_AA64ISAR2, PAC_FRAC, 24, 4)
 
 FIELD(ID_AA64PFR0, EL0, 0, 4)
 FIELD(ID_AA64PFR0, EL1, 4, 4)
@@ -2014,6 +2025,10 @@ FIELD(ID_AA64PFR1, SSBS, 4, 4)
 FIELD(ID_AA64PFR1, MTE, 8, 4)
 FIELD(ID_AA64PFR1, RAS_FRAC, 12, 4)
 FIELD(ID_AA64PFR1, MPAM_FRAC, 16, 4)
+FIELD(ID_AA64PFR1, SME, 24, 4)
+FIELD(ID_AA64PFR1, RNDR_TRAP, 28, 4)
+FIELD(ID_AA64PFR1, CSV2_FRAC, 32, 4)
+FIELD(ID_AA64PFR1, NMI, 36, 4)
 
 FIELD(ID_AA64MMFR0, PARANGE, 0, 4)
 FIELD(ID_AA64MMFR0, ASIDBITS, 4, 4)
@@ -2040,6 +2055,11 @@ FIELD(ID_AA64MMFR1, SPECSEI, 24, 4)
 FIELD(ID_AA64MMFR1, XNX, 28, 4)
 FIELD(ID_AA64MMFR1, TWED, 32, 4)
 FIELD(ID_AA64MMFR1, ETS, 36, 4)
+FIELD(ID_AA64MMFR1, HCX, 40, 4)
+FIELD(ID_AA64MMFR1, AFP, 44, 4)
+FIELD(ID_AA64MMFR1, NTLBPA, 48, 4)
+FIELD(ID_AA64MMFR1, TIDCP1, 52, 4)
+FIELD(ID_AA64MMFR1, CMOW, 56, 4)
 
 FIELD(ID_AA64MMFR2, CNP, 0, 4)
 FIELD(ID_AA64MMFR2, UAO, 4, 4)
@@ -2066,7 +2086,10 @@ FIELD(ID_AA64DFR0, CTX_CMPS, 28, 4)
 FIELD(ID_AA64DFR0, PMSVER, 32, 4)
 FIELD(ID_AA64DFR0, DOUBLELOCK, 36, 4)
 FIELD(ID_AA64DFR0, TRACEFILT, 40, 4)
+FIELD(ID_AA64DFR0, TRACEBUFFER, 44, 4)
 FIELD(ID_AA64DFR0, MTPMU, 48, 4)
+FIELD(ID_AA64DFR0, BRBE, 52, 4)
+FIELD(ID_AA64DFR0, HPMN0, 60, 4)
 
 FIELD(ID_AA64ZFR0, SVEVER, 0, 4)
 FIELD(ID_AA64ZFR0, AES, 4, 4)
@@ -2088,6 +2111,7 @@ FIELD(ID_DFR0, PERFMON, 24, 4)
 FIELD(ID_DFR0, TRACEFILT, 28, 4)
 
 FIELD(ID_DFR1, MTPMU, 0, 4)
+FIELD(ID_DFR1, HPMN0, 4, 4)
 
 FIELD(DBGDIDR, SE_IMP, 12, 1)
 FIELD(DBGDIDR, NSUHD_IMP, 14, 1)
-- 
2.25.1




[PATCH v2 15/24] target/arm: Implement ESB instruction

2022-04-11 Thread Richard Henderson
Check for and defer any pending virtual SError.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Retain m-profile check; improve comments.
---
 target/arm/helper.h|  1 +
 target/arm/a32.decode  | 16 --
 target/arm/t32.decode  | 18 
 target/arm/op_helper.c | 43 ++
 target/arm/translate-a64.c | 17 +++
 target/arm/translate.c | 23 
 6 files changed, 103 insertions(+), 15 deletions(-)

diff --git a/target/arm/helper.h b/target/arm/helper.h
index b463d9343b..b1334e0c42 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -54,6 +54,7 @@ DEF_HELPER_1(wfe, void, env)
 DEF_HELPER_1(yield, void, env)
 DEF_HELPER_1(pre_hvc, void, env)
 DEF_HELPER_2(pre_smc, void, env, i32)
+DEF_HELPER_1(vesb, void, env)
 
 DEF_HELPER_3(cpsr_write, void, env, i32, i32)
 DEF_HELPER_2(cpsr_write_eret, void, env, i32)
diff --git a/target/arm/a32.decode b/target/arm/a32.decode
index fcd8cd4f7d..f2ca480949 100644
--- a/target/arm/a32.decode
+++ b/target/arm/a32.decode
@@ -187,13 +187,17 @@ SMULTT    0001 0110    1110   
@rd0mn
 
 {
   {
-YIELD 0011 0010     0001
-WFE   0011 0010     0010
-WFI   0011 0010     0011
+[
+  YIELD   0011 0010     0001
+  WFE 0011 0010     0010
+  WFI 0011 0010     0011
 
-# TODO: Implement SEV, SEVL; may help SMP performance.
-# SEV 0011 0010     0100
-# SEVL    0011 0010     0101
+  # TODO: Implement SEV, SEVL; may help SMP performance.
+  # SEV   0011 0010     0100
+  # SEVL  0011 0010     0101
+
+  ESB 0011 0010    0001 
+]
 
 # The canonical nop ends in , but the whole of the
 # rest of the space executes as nop if otherwise unsupported.
diff --git a/target/arm/t32.decode b/target/arm/t32.decode
index 78fadef9d6..f21ad0167a 100644
--- a/target/arm/t32.decode
+++ b/target/arm/t32.decode
@@ -364,17 +364,17 @@ CLZ   1010 1011    1000   
@rdm
   [
 # Hints, and CPS
 {
-  YIELD   0011 1010  1000   0001
-  WFE 0011 1010  1000   0010
-  WFI 0011 1010  1000   0011
+  [
+YIELD 0011 1010  1000   0001
+WFE   0011 1010  1000   0010
+WFI   0011 1010  1000   0011
 
-  # TODO: Implement SEV, SEVL; may help SMP performance.
-  # SEV   0011 1010  1000   0100
-  # SEVL  0011 1010  1000   0101
+# TODO: Implement SEV, SEVL; may help SMP performance.
+# SEV 0011 1010  1000   0100
+# SEVL    0011 1010  1000   0101
 
-  # For M-profile minimal-RAS ESB can be a NOP, which is the
-  # default behaviour since it is in the hint space.
-  # ESB   0011 1010  1000  0001 
+ESB   0011 1010  1000  0001 
+  ]
 
   # The canonical nop ends in  , but the whole rest
   # of the space is "reserved hint, behaves as nop".
diff --git a/target/arm/op_helper.c b/target/arm/op_helper.c
index 70b42b55fd..13076ee885 100644
--- a/target/arm/op_helper.c
+++ b/target/arm/op_helper.c
@@ -972,3 +972,46 @@ void HELPER(probe_access)(CPUARMState *env, target_ulong 
ptr,
  access_type, mmu_idx, ra);
 }
 }
+
+/*
+ * This function corresponds to AArch64.vESBOperation().
+ * Note that the AArch32 version is not functionally different.
+ */
+void HELPER(vesb)(CPUARMState *env)
+{
+/*
+ * The EL2Enabled() check is done inside arm_hcr_el2_eff,
+ * and will return HCR_EL2.VSE == 0, so nothing happens.
+ */
+uint64_t hcr = arm_hcr_el2_eff(env);
+bool enabled = !(hcr & HCR_TGE) && (hcr & HCR_AMO);
+bool pending = enabled && (hcr & HCR_VSE);
+bool masked  = (env->daif & PSTATE_A);
+
+/* If VSE pending and masked, defer the exception.  */
+if (pending && masked) {
+uint32_t syndrome;
+
+if (arm_el_is_aa64(env, 1)) {
+/* Copy across IDS and ISS from VSESR. */
+syndrome = env->cp15.vsesr_el2 & 0x1ff;
+} else {
+ARMMMUFaultInfo fi = { .type = ARMFault_AsyncExternal };
+
+if (extended_addresses_enabled(env)) {
+syndrome = arm_fi_to_lfsc(&fi);
+} else {
+syndrome = arm_fi_to_sfsc(&fi);
+}
+/* Copy across AET and ExT from VSESR. */
+syndrome |= env->cp15.vsesr_el2 & 0xd000;
+}
+
+/* Set VDISR_EL2.A along with t

[PATCH v2 23/24] target/arm: Define cortex-a76

2022-04-11 Thread Richard Henderson
Enable the a76 for virt and sbsa board use.

Signed-off-by: Richard Henderson 
---
 docs/system/arm/virt.rst |  1 +
 hw/arm/sbsa-ref.c|  1 +
 hw/arm/virt.c|  1 +
 target/arm/cpu64.c   | 66 
 4 files changed, 69 insertions(+)

diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 1544632b67..e9ff81aa21 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -55,6 +55,7 @@ Supported guest CPU types:
 - ``cortex-a53`` (64-bit)
 - ``cortex-a57`` (64-bit)
 - ``cortex-a72`` (64-bit)
+- ``cortex-a76`` (64-bit)
 - ``a64fx`` (64-bit)
 - ``host`` (with KVM only)
 - ``max`` (same as ``host`` for KVM; best possible emulation with TCG)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 2387401963..2ddde88f5e 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -145,6 +145,7 @@ static const int sbsa_ref_irqmap[] = {
 static const char * const valid_cpus[] = {
 ARM_CPU_TYPE_NAME("cortex-a57"),
 ARM_CPU_TYPE_NAME("cortex-a72"),
+ARM_CPU_TYPE_NAME("cortex-a76"),
 ARM_CPU_TYPE_NAME("max"),
 };
 
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index d2e5ecd234..ce15c36a7f 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -202,6 +202,7 @@ static const char *valid_cpus[] = {
 ARM_CPU_TYPE_NAME("cortex-a53"),
 ARM_CPU_TYPE_NAME("cortex-a57"),
 ARM_CPU_TYPE_NAME("cortex-a72"),
+ARM_CPU_TYPE_NAME("cortex-a76"),
 ARM_CPU_TYPE_NAME("a64fx"),
 ARM_CPU_TYPE_NAME("host"),
 ARM_CPU_TYPE_NAME("max"),
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 8934ced19a..7dbd649b0c 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -194,6 +194,71 @@ static void aarch64_a72_initfn(Object *obj)
 define_cortex_a72_a57_a53_cp_reginfo(cpu);
 }
 
+static void aarch64_a76_initfn(Object *obj)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+cpu->dtb_compatible = "arm,cortex-a76";
+set_feature(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
+set_feature(&cpu->env, ARM_FEATURE_AARCH64);
+set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
+set_feature(&cpu->env, ARM_FEATURE_EL2);
+set_feature(&cpu->env, ARM_FEATURE_EL3);
+set_feature(&cpu->env, ARM_FEATURE_PMU);
+
+/* Ordered by B2.4 AArch64 registers by functional group */
+cpu->clidr = 0x8223;
+cpu->ctr = 0x8444C004;
+cpu->dcz_blocksize = 4;
+cpu->isar.id_aa64dfr0  = 0x10305408ull;
+cpu->isar.id_aa64isar0 = 0x100010211120ull;
+cpu->isar.id_aa64isar1 = 0x0011ull;
+cpu->isar.id_aa64mmfr0 = 0x00101122ull;
+cpu->isar.id_aa64mmfr1 = 0x10212122ull;
+cpu->isar.id_aa64mmfr2 = 0x1011ull;
+cpu->isar.id_aa64pfr0  = 0x11001012ull; /* GIC filled in later */
+cpu->isar.id_aa64pfr1  = 0x0010ull;
+cpu->id_afr0   = 0x;
+cpu->isar.id_dfr0  = 0x04010088;
+cpu->isar.id_isar0 = 0x02101110;
+cpu->isar.id_isar1 = 0x13112111;
+cpu->isar.id_isar2 = 0x21232042;
+cpu->isar.id_isar3 = 0x01112131;
+cpu->isar.id_isar4 = 0x00010142;
+cpu->isar.id_isar5 = 0x01011121;
+cpu->isar.id_isar6 = 0x0010;
+cpu->isar.id_mmfr0 = 0x10201105;
+cpu->isar.id_mmfr1 = 0x4000;
+cpu->isar.id_mmfr2 = 0x0126;
+cpu->isar.id_mmfr3 = 0x02122211;
+cpu->isar.id_mmfr4 = 0x00021110;
+cpu->isar.id_pfr0  = 0x10010131;
+cpu->isar.id_pfr1  = 0x0001; /* GIC filled in later */
+cpu->isar.id_pfr2  = 0x0011;
+cpu->midr = 0x414fd0b1;  /* r4p1 */
+cpu->revidr = 0;
+
+/* From B2.18 CCSIDR_EL1 */
+cpu->ccsidr[0] = 0x701fe01a; /* 64KB L1 dcache */
+cpu->ccsidr[1] = 0x201fe01a; /* 64KB L1 icache */
+cpu->ccsidr[2] = 0x707fe03a; /* 512KB L2 cache */
+
+/* From B2.93 SCTLR_EL3 */
+cpu->reset_sctlr = 0x30c50838;
+
+/* From B4.23 ICH_VTR_EL2 */
+cpu->gic_num_lrs = 4;
+cpu->gic_vpribits = 5;
+cpu->gic_vprebits = 5;
+
+/* From B5.1 AdvSIMD AArch64 register summary */
+cpu->isar.mvfr0 = 0x10110222;
+cpu->isar.mvfr1 = 0x1321;
+cpu->isar.mvfr2 = 0x0043;
+}
+
 void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp)
 {
 /*
@@ -879,6 +944,7 @@ static const ARMCPUInfo aarch64_cpus[] = {
 { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
 { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
 { .name = "cortex-a72", .initfn = aarch64_a72_initfn },
+{ .name = "cortex-a76", .initfn = aarch64_a76_initfn },
 { .name = "a64fx",  .initfn = aarch64_a64fx_initfn },
 { .name = "max",.initfn = aarch64_max_initfn },
 #if defined(CONFIG_KVM) || defined(CONFIG_HVF)
-- 
2.25.1




[PATCH v2 16/24] target/arm: Enable FEAT_RAS for -cpu max

2022-04-11 Thread Richard Henderson
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c| 1 +
 target/arm/cpu_tcg.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index c89c344de1..35b6f7d4de 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -41,6 +41,7 @@ the following architecture extensions:
 - FEAT_PMULL (PMULL, PMULL2 instructions)
 - FEAT_PMUv3p1 (PMU Extensions v3.1)
 - FEAT_PMUv3p4 (PMU Extensions v3.4)
+- FEAT_RAS (Reliability, availability, and serviceability)
 - FEAT_RDM (Advanced SIMD rounding double multiply accumulate instructions)
 - FEAT_RNG (Random number generator)
 - FEAT_SB (Speculation Barrier)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 9bed76342f..3525aba610 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -744,6 +744,7 @@ static void aarch64_max_initfn(Object *obj)
 t = cpu->isar.id_aa64pfr0;
 t = FIELD_DP64(t, ID_AA64PFR0, FP, 1);/* FEAT_FP16 */
 t = FIELD_DP64(t, ID_AA64PFR0, ADVSIMD, 1);   /* FEAT_FP16 */
+t = FIELD_DP64(t, ID_AA64PFR0, RAS, 1);   /* FEAT_RAS */
 t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
 t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);  /* FEAT_SEL2 */
 t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);   /* FEAT_DIT */
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 4ff4f30e89..4aa2eb0841 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -68,6 +68,7 @@ void arm32_max_features(ARMCPU *cpu)
 
 t = cpu->isar.id_pfr0;
 t = FIELD_DP32(t, ID_PFR0, DIT, 1);   /* FEAT_DIT */
+t = FIELD_DP32(t, ID_PFR0, RAS, 1);   /* FEAT_RAS */
 cpu->isar.id_pfr0 = t;
 
 t = cpu->isar.id_pfr2;
-- 
2.25.1




[PATCH v2 13/24] target/arm: Enable SCR and HCR bits for RAS

2022-04-11 Thread Richard Henderson
Enable writes to the TERR and TEA bits when RAS is enabled.
These bits are otherwise RES0.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index b066a86f04..aa05a15e5c 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1765,6 +1765,9 @@ static void scr_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 }
 valid_mask &= ~SCR_NET;
 
+if (cpu_isar_feature(aa64_ras, cpu)) {
+valid_mask |= SCR_TERR;
+}
 if (cpu_isar_feature(aa64_lor, cpu)) {
 valid_mask |= SCR_TLOR;
 }
@@ -1779,6 +1782,9 @@ static void scr_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 }
 } else {
 valid_mask &= ~(SCR_RW | SCR_ST);
+if (cpu_isar_feature(aa32_ras, cpu)) {
+valid_mask |= SCR_TERR;
+}
 }
 
 if (!arm_feature(env, ARM_FEATURE_EL2)) {
@@ -5289,6 +5295,9 @@ static void do_hcr_write(CPUARMState *env, uint64_t 
value, uint64_t valid_mask)
 if (cpu_isar_feature(aa64_vh, cpu)) {
 valid_mask |= HCR_E2H;
 }
+if (cpu_isar_feature(aa64_ras, cpu)) {
+valid_mask |= HCR_TERR | HCR_TEA;
+}
 if (cpu_isar_feature(aa64_lor, cpu)) {
 valid_mask |= HCR_TLOR;
 }
-- 
2.25.1




[PATCH v2 09/24] target/arm: Enable FEAT_Debugv8p2 for -cpu max

2022-04-11 Thread Richard Henderson
The only portion of FEAT_Debugv8p2 that is relevant to QEMU
is CONTEXTIDR_EL2, which is also conditionally implemented
with FEAT_VHE.  The rest of the debug extension concerns the
External debug interface, which is outside the scope of QEMU.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu.c  | 1 +
 target/arm/cpu64.c| 1 +
 target/arm/cpu_tcg.c  | 2 ++
 4 files changed, 5 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 520fd39071..035f7cf9d0 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -13,6 +13,7 @@ the following architecture extensions:
 - FEAT_BTI (Branch Target Identification)
 - FEAT_DIT (Data Independent Timing instructions)
 - FEAT_DPB (DC CVAP instruction)
+- FEAT_Debugv8p2 (Debug changes for v8.2)
 - FEAT_DotProd (Advanced SIMD dot product instructions)
 - FEAT_FCMA (Floating-point complex number instructions)
 - FEAT_FHM (Floating-point half-precision multiplication instructions)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6521f350f9..d815d3a397 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1800,6 +1800,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
  * feature registers as well.
  */
 cpu->isar.id_pfr1 = FIELD_DP32(cpu->isar.id_pfr1, ID_PFR1, SECURITY, 
0);
+cpu->isar.id_dfr0 = FIELD_DP32(cpu->isar.id_dfr0, ID_DFR0, COPSDBG, 0);
 cpu->isar.id_aa64pfr0 = FIELD_DP64(cpu->isar.id_aa64pfr0,
ID_AA64PFR0, EL3, 0);
 }
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index e4f630d83f..33570c3b6d 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -797,6 +797,7 @@ static void aarch64_max_initfn(Object *obj)
 cpu->isar.id_aa64zfr0 = t;
 
 t = cpu->isar.id_aa64dfr0;
+t = FIELD_DP64(t, ID_AA64DFR0, DEBUGVER, 8);  /* FEAT_Debugv8p2 */
 t = FIELD_DP64(t, ID_AA64DFR0, PMUVER, 5);/* FEAT_PMUv3p4 */
 cpu->isar.id_aa64dfr0 = t;
 
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 075c187286..e719696412 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -75,6 +75,8 @@ void arm32_max_features(ARMCPU *cpu)
 cpu->isar.id_pfr2 = t;
 
 t = cpu->isar.id_dfr0;
+t = FIELD_DP32(t, ID_DFR0, COPDBG, 8);/* FEAT_Debugv8p2 */
+t = FIELD_DP32(t, ID_DFR0, COPSDBG, 8);   /* FEAT_Debugv8p2 */
 t = FIELD_DP32(t, ID_DFR0, PERFMON, 5);   /* FEAT_PMUv3p4 */
 cpu->isar.id_dfr0 = t;
 }
-- 
2.25.1




[PATCH v2 14/24] target/arm: Implement virtual SError exceptions

2022-04-11 Thread Richard Henderson
Virtual SError exceptions are raised by setting HCR_EL2.VSE,
and are routed to EL1 just like other virtual exceptions.

Signed-off-by: Richard Henderson 
---
v2: Honor EAE for reporting VSERR to aa32.
---
 target/arm/cpu.h   |  2 ++
 target/arm/internals.h |  8 
 target/arm/syndrome.h  |  5 +
 target/arm/cpu.c   | 38 +-
 target/arm/helper.c| 40 +++-
 5 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 1f248b..7ca2463e17 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -55,6 +55,7 @@
 #define EXCP_LSERR  21   /* v8M LSERR SecureFault */
 #define EXCP_UNALIGNED  22   /* v7M UNALIGNED UsageFault */
 #define EXCP_DIVBYZERO  23   /* v7M DIVBYZERO UsageFault */
+#define EXCP_VSERR  24
 /* NB: add new EXCP_ defines to the array in arm_log_exception() too */
 
 #define ARMV7M_EXCP_RESET   1
@@ -88,6 +89,7 @@ enum {
 #define CPU_INTERRUPT_FIQ   CPU_INTERRUPT_TGT_EXT_1
 #define CPU_INTERRUPT_VIRQ  CPU_INTERRUPT_TGT_EXT_2
 #define CPU_INTERRUPT_VFIQ  CPU_INTERRUPT_TGT_EXT_3
+#define CPU_INTERRUPT_VSERR CPU_INTERRUPT_TGT_INT_0
 
 /* The usual mapping for an AArch64 system register to its AArch32
  * counterpart is for the 32 bit world to have access to the lower
diff --git a/target/arm/internals.h b/target/arm/internals.h
index ca9782b9f0..5fdccb38d4 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -935,6 +935,14 @@ void arm_cpu_update_virq(ARMCPU *cpu);
  */
 void arm_cpu_update_vfiq(ARMCPU *cpu);
 
+/**
+ * arm_cpu_update_vserr: Update CPU_INTERRUPT_VSERR bit
+ *
+ * Update the CPU_INTERRUPT_VSERR bit in cs->interrupt_request,
+ * following a change to the HCR_EL2.VSE bit.
+ */
+void arm_cpu_update_vserr(ARMCPU *cpu);
+
 /**
  * arm_mmu_idx_el:
  * @env: The cpu environment
diff --git a/target/arm/syndrome.h b/target/arm/syndrome.h
index 8cde8e7243..0cb26dde7d 100644
--- a/target/arm/syndrome.h
+++ b/target/arm/syndrome.h
@@ -287,4 +287,9 @@ static inline uint32_t syn_pcalignment(void)
 return (EC_PCALIGNMENT << ARM_EL_EC_SHIFT) | ARM_EL_IL;
 }
 
+static inline uint32_t syn_serror(uint32_t extra)
+{
+return (EC_SERROR << ARM_EL_EC_SHIFT) | ARM_EL_IL | extra;
+}
+
 #endif /* TARGET_ARM_SYNDROME_H */
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index d815d3a397..1a1b1612a8 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -84,7 +84,7 @@ static bool arm_cpu_has_work(CPUState *cs)
 return (cpu->power_state != PSCI_OFF)
 && cs->interrupt_request &
 (CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD
- | CPU_INTERRUPT_VFIQ | CPU_INTERRUPT_VIRQ
+ | CPU_INTERRUPT_VFIQ | CPU_INTERRUPT_VIRQ | CPU_INTERRUPT_VSERR
  | CPU_INTERRUPT_EXITTB);
 }
 
@@ -508,6 +508,12 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
unsigned int excp_idx,
 return false;
 }
 return !(env->daif & PSTATE_I);
+case EXCP_VSERR:
+if (!(hcr_el2 & HCR_AMO) || (hcr_el2 & HCR_TGE)) {
+/* VIRQs are only taken when hypervized.  */
+return false;
+}
+return !(env->daif & PSTATE_A);
 default:
 g_assert_not_reached();
 }
@@ -629,6 +635,17 @@ static bool arm_cpu_exec_interrupt(CPUState *cs, int 
interrupt_request)
 goto found;
 }
 }
+if (interrupt_request & CPU_INTERRUPT_VSERR) {
+excp_idx = EXCP_VSERR;
+target_el = 1;
+if (arm_excp_unmasked(cs, excp_idx, target_el,
+  cur_el, secure, hcr_el2)) {
+/* Taking a virtual abort clears HCR_EL2.VSE */
+env->cp15.hcr_el2 &= ~HCR_VSE;
+cpu_reset_interrupt(cs, CPU_INTERRUPT_VSERR);
+goto found;
+}
+}
 return false;
 
  found:
@@ -681,6 +698,25 @@ void arm_cpu_update_vfiq(ARMCPU *cpu)
 }
 }
 
+void arm_cpu_update_vserr(ARMCPU *cpu)
+{
+/*
+ * Update the interrupt level for VSERR, which is the HCR_EL2.VSE bit.
+ */
+CPUARMState *env = &cpu->env;
+CPUState *cs = CPU(cpu);
+
+bool new_state = env->cp15.hcr_el2 & HCR_VSE;
+
+if (new_state != ((cs->interrupt_request & CPU_INTERRUPT_VSERR) != 0)) {
+if (new_state) {
+cpu_interrupt(cs, CPU_INTERRUPT_VSERR);
+} else {
+cpu_reset_interrupt(cs, CPU_INTERRUPT_VSERR);
+}
+}
+}
+
 #ifndef CONFIG_USER_ONLY
 static void arm_cpu_set_irq(void *opaque, int irq, int level)
 {
diff --git a/target/arm/helper.c b/target/arm/helper.c
index aa05a15e5c..c29409f060 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1873,7 +1873,12 @@ static uint64_t isr_read(CPUARMState *env, const 
ARMCPRegInfo *ri)
 }
 }
 
-/* External aborts are not possible in QEMU so A bit is always clear */
+if (hcr_el2 & HCR_AMO) {
+if (cs->interrupt_request & CPU_INTERRUPT_VSERR) {
+ret |= CPSR_A;
+

[PATCH v2 22/24] target/arm: Enable FEAT_DGH for -cpu max

2022-04-11 Thread Richard Henderson
This extension concerns not merging memory access, which TCG does
not implement.  Thus we can trivially enable this feature.
Add a comment to handle_hint for the DGH instruction, but no code.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c| 1 +
 target/arm/translate-a64.c| 1 +
 3 files changed, 3 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index f75f0fc110..bc9cdda75a 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -16,6 +16,7 @@ the following architecture extensions:
 - FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2)
 - FEAT_CSV2_2 (Cache speculation variant 2, version 2)
 - FEAT_CSV3 (Cache speculation variant 3)
+- FEAT_DGH (Data gathering hint)
 - FEAT_DIT (Data Independent Timing instructions)
 - FEAT_DPB (DC CVAP instruction)
 - FEAT_Debugv8p2 (Debug changes for v8.2)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 2b6b9afd76..8934ced19a 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -738,6 +738,7 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64ISAR1, SB, 1);   /* FEAT_SB */
 t = FIELD_DP64(t, ID_AA64ISAR1, SPECRES, 1);  /* FEAT_SPECRES */
 t = FIELD_DP64(t, ID_AA64ISAR1, BF16, 1); /* FEAT_BF16 */
+t = FIELD_DP64(t, ID_AA64ISAR1, DGH, 1);  /* FEAT_DGH */
 t = FIELD_DP64(t, ID_AA64ISAR1, I8MM, 1); /* FEAT_I8MM */
 cpu->isar.id_aa64isar1 = t;
 
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 4fc31807ff..0adfa1d22c 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -1442,6 +1442,7 @@ static void handle_hint(DisasContext *s, uint32_t insn,
 break;
 case 0b00100: /* SEV */
 case 0b00101: /* SEVL */
+case 0b00110: /* DGH */
 /* we treat all as NOP at least for now */
 break;
 case 0b00111: /* XPACLRI */
-- 
2.25.1




[PATCH v2 17/24] target/arm: Enable FEAT_IESB for -cpu max

2022-04-11 Thread Richard Henderson
This feature is AArch64 only, and applies to physical SErrors,
which QEMU does not implement, thus the feature is a nop.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c| 1 +
 2 files changed, 2 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 35b6f7d4de..ebd9e418cc 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -24,6 +24,7 @@ the following architecture extensions:
 - FEAT_FlagM2 (Enhancements to flag manipulation instructions)
 - FEAT_HPDS (Hierarchical permission disables)
 - FEAT_I8MM (AArch64 Int8 matrix multiplication instructions)
+- FEAT_IESB (Implicit error synchronization event)
 - FEAT_JSCVT (JavaScript conversion instructions)
 - FEAT_LOR (Limited ordering regions)
 - FEAT_LPA (Large Physical Address space)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 3525aba610..c91528a12e 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -781,6 +781,7 @@ static void aarch64_max_initfn(Object *obj)
 t = cpu->isar.id_aa64mmfr2;
 t = FIELD_DP64(t, ID_AA64MMFR2, CNP, 1);  /* FEAT_TTCNP */
 t = FIELD_DP64(t, ID_AA64MMFR2, UAO, 1);  /* FEAT_UAO */
+t = FIELD_DP64(t, ID_AA64MMFR2, IESB, 1); /* FEAT_IESB */
 t = FIELD_DP64(t, ID_AA64MMFR2, VARANGE, 1);  /* FEAT_LVA */
 t = FIELD_DP64(t, ID_AA64MMFR2, ST, 1);   /* FEAT_TTST */
 cpu->isar.id_aa64mmfr2 = t;
-- 
2.25.1




[PATCH v2 12/24] target/arm: Add minimal RAS registers

2022-04-11 Thread Richard Henderson
Add only the system registers required to implement zero error
records.  This means we need to save state for ERRSELR, but all
values are out of range, so none of the indexed error record
registers need be implemented.

Add the EL2 registers required for injecting virtual SError.

Signed-off-by: Richard Henderson 
---
v2: Leave ERRSELR_EL1 undefined.
---
 target/arm/cpu.h|   5 +++
 target/arm/helper.c | 105 
 2 files changed, 110 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 890001f26b..1f248b 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -524,6 +524,11 @@ typedef struct CPUArchState {
 uint64_t tfsr_el[4]; /* tfsre0_el1 is index 0.  */
 uint64_t gcr_el1;
 uint64_t rgsr_el1;
+
+/* Minimal RAS registers */
+uint64_t disr_el1;
+uint64_t vdisr_el2;
+uint64_t vsesr_el2;
 } cp15;
 
 struct {
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 210c139818..b066a86f04 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6147,6 +6147,102 @@ static const ARMCPRegInfo debug_lpae_cp_reginfo[] = {
 REGINFO_SENTINEL
 };
 
+/*
+ * Check for traps to RAS registers, which are controlled
+ * by HCR_EL2.TERR and SCR_EL3.TERR.
+ */
+static CPAccessResult access_terr(CPUARMState *env, const ARMCPRegInfo *ri,
+  bool isread)
+{
+int el = arm_current_el(env);
+
+if (el < 2 && (arm_hcr_el2_eff(env) & HCR_TERR)) {
+return CP_ACCESS_TRAP_EL2;
+}
+if (el < 3 && (env->cp15.scr_el3 & SCR_TERR)) {
+return CP_ACCESS_TRAP_EL3;
+}
+return CP_ACCESS_OK;
+}
+
+static uint64_t disr_read(CPUARMState *env, const ARMCPRegInfo *ri)
+{
+int el = arm_current_el(env);
+
+if (el < 2 && (arm_hcr_el2_eff(env) & HCR_AMO)) {
+return env->cp15.vdisr_el2;
+}
+if (el < 3 && (env->cp15.scr_el3 & SCR_EA)) {
+return 0; /* RAZ/WI */
+}
+return env->cp15.disr_el1;
+}
+
+static void disr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t val)
+{
+int el = arm_current_el(env);
+
+if (el < 2 && (arm_hcr_el2_eff(env) & HCR_AMO)) {
+env->cp15.vdisr_el2 = val;
+return;
+}
+if (el < 3 && (env->cp15.scr_el3 & SCR_EA)) {
+return; /* RAZ/WI */
+}
+env->cp15.disr_el1 = val;
+}
+
+/*
+ * Minimal RAS implementation with no Error Records.
+ * Which means that all of the Error Record registers:
+ *   ERXADDR_EL1
+ *   ERXCTLR_EL1
+ *   ERXFR_EL1
+ *   ERXMISC0_EL1
+ *   ERXMISC1_EL1
+ *   ERXMISC2_EL1
+ *   ERXMISC3_EL1
+ *   ERXPFGCDN_EL1  (RASv1p1)
+ *   ERXPFGCTL_EL1  (RASv1p1)
+ *   ERXPFGF_EL1(RASv1p1)
+ *   ERXSTATUS_EL1
+ * and
+ *   ERRSELR_EL1
+ * may generate UNDEFINED, which is the effect we get by not
+ * listing them at all.
+ */
+static const ARMCPRegInfo minimal_ras_reginfo_el1[] = {
+{ .name = "DISR_EL1", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 0, .crn = 12, .crm = 1, .opc2 = 1,
+  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.disr_el1),
+  .readfn = disr_read, .writefn = disr_write, .raw_writefn = raw_write },
+{ .name = "ERRIDR_EL1", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 3, .opc2 = 0,
+  .access = PL1_R, .accessfn = access_terr,
+  .type = ARM_CP_CONST, .resetvalue = 0 },
+REGINFO_SENTINEL
+};
+
+static const ARMCPRegInfo minimal_ras_reginfo_el2[] = {
+{ .name = "VDISR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 12, .crm = 1, .opc2 = 1,
+  .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.vdisr_el2) },
+{ .name = "VSESR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 2, .opc2 = 3,
+  .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.vsesr_el2) },
+REGINFO_SENTINEL
+};
+
+static const ARMCPRegInfo minimal_ras_reginfo_no_el2[] = {
+{ .name = "VDISR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 12, .crm = 1, .opc2 = 1,
+  .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+{ .name = "VSESR_EL2", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 2, .opc2 = 3,
+  .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+REGINFO_SENTINEL
+};
+
 /* Return the exception level to which exceptions should be taken
  * via SVEAccessTrap.  If an exception should be routed through
  * AArch64.AdvSIMDFPAccessTrap, return 0; fp_exception_el should
@@ -8452,6 +8548,15 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 define_one_arm_cp_reg(cpu, &ssbs_reginfo);
 }
 
+if (cpu_isar_feature(any_ras, cpu)) {
+define_arm_cp_regs(cpu, minimal_ras_reginfo_el1);
+if (arm_feature(env, ARM_FEATURE_EL2)) {
+define_arm_cp_regs(cpu, minimal_ras_reginfo_el2);
+} else {
+define_arm_cp_regs(cpu, minimal_ras_reginfo_no_el2);
+   

[PATCH v2 10/24] target/arm: Enable FEAT_Debugv8p4 for -cpu max

2022-04-11 Thread Richard Henderson
This extension concerns changes to the External Debug interface,
with Secure and Non-secure access to the debug registers, and all
of it is outside the scope of QEMU.  Indicating support for this
is mandatory with FEAT_SEL2, which we do implement.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Update emulation.rst
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu64.c| 2 +-
 target/arm/cpu_tcg.c  | 4 ++--
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 035f7cf9d0..c89c344de1 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -14,6 +14,7 @@ the following architecture extensions:
 - FEAT_DIT (Data Independent Timing instructions)
 - FEAT_DPB (DC CVAP instruction)
 - FEAT_Debugv8p2 (Debug changes for v8.2)
+- FEAT_Debugv8p4 (Debug changes for v8.4)
 - FEAT_DotProd (Advanced SIMD dot product instructions)
 - FEAT_FCMA (Floating-point complex number instructions)
 - FEAT_FHM (Floating-point half-precision multiplication instructions)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 33570c3b6d..9bed76342f 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -797,7 +797,7 @@ static void aarch64_max_initfn(Object *obj)
 cpu->isar.id_aa64zfr0 = t;
 
 t = cpu->isar.id_aa64dfr0;
-t = FIELD_DP64(t, ID_AA64DFR0, DEBUGVER, 8);  /* FEAT_Debugv8p2 */
+t = FIELD_DP64(t, ID_AA64DFR0, DEBUGVER, 9);  /* FEAT_Debugv8p4 */
 t = FIELD_DP64(t, ID_AA64DFR0, PMUVER, 5);/* FEAT_PMUv3p4 */
 cpu->isar.id_aa64dfr0 = t;
 
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index e719696412..4ff4f30e89 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -75,8 +75,8 @@ void arm32_max_features(ARMCPU *cpu)
 cpu->isar.id_pfr2 = t;
 
 t = cpu->isar.id_dfr0;
-t = FIELD_DP32(t, ID_DFR0, COPDBG, 8);/* FEAT_Debugv8p2 */
-t = FIELD_DP32(t, ID_DFR0, COPSDBG, 8);   /* FEAT_Debugv8p2 */
+t = FIELD_DP32(t, ID_DFR0, COPDBG, 9);/* FEAT_Debugv8p4 */
+t = FIELD_DP32(t, ID_DFR0, COPSDBG, 9);   /* FEAT_Debugv8p4 */
 t = FIELD_DP32(t, ID_DFR0, PERFMON, 5);   /* FEAT_PMUv3p4 */
 cpu->isar.id_dfr0 = t;
 }
-- 
2.25.1




[PATCH v2 11/24] target/arm: Add isar_feature_{aa64,any}_ras

2022-04-11 Thread Richard Henderson
Add the aa64 predicate for detecting RAS support from id registers.
We already have the aa32 version from the M-profile work.
Add the 'any' predicate for testing both aa64 and aa32.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 9c456ff23a..890001f26b 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -4208,6 +4208,11 @@ static inline bool isar_feature_aa64_aa32_el1(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, EL1) >= 2;
 }
 
+static inline bool isar_feature_aa64_ras(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, RAS) != 0;
+}
+
 static inline bool isar_feature_aa64_sve(const ARMISARegisters *id)
 {
 return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, SVE) != 0;
@@ -4430,6 +4435,11 @@ static inline bool isar_feature_any_debugv8p2(const 
ARMISARegisters *id)
 return isar_feature_aa64_debugv8p2(id) || isar_feature_aa32_debugv8p2(id);
 }
 
+static inline bool isar_feature_any_ras(const ARMISARegisters *id)
+{
+return isar_feature_aa64_ras(id) || isar_feature_aa32_ras(id);
+}
+
 /*
  * Forward to the above feature tests given an ARMCPU pointer.
  */
-- 
2.25.1




[PATCH v2 08/24] target/arm: Use field names for manipulating EL2 and EL3 modes

2022-04-11 Thread Richard Henderson
Use FIELD_DP{32,64} to manipulate id_pfr1 and id_aa64pfr0
during arm_cpu_realizefn.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/cpu.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 5d4ca7a227..6521f350f9 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1795,11 +1795,13 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
  */
 unset_feature(env, ARM_FEATURE_EL3);
 
-/* Disable the security extension feature bits in the processor feature
- * registers as well. These are id_pfr1[7:4] and id_aa64pfr0[15:12].
+/*
+ * Disable the security extension feature bits in the processor
+ * feature registers as well.
  */
-cpu->isar.id_pfr1 &= ~0xf0;
-cpu->isar.id_aa64pfr0 &= ~0xf000;
+cpu->isar.id_pfr1 = FIELD_DP32(cpu->isar.id_pfr1, ID_PFR1, SECURITY, 
0);
+cpu->isar.id_aa64pfr0 = FIELD_DP64(cpu->isar.id_aa64pfr0,
+   ID_AA64PFR0, EL3, 0);
 }
 
 if (!cpu->has_el2) {
@@ -1830,12 +1832,14 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 }
 
 if (!arm_feature(env, ARM_FEATURE_EL2)) {
-/* Disable the hypervisor feature bits in the processor feature
- * registers if we don't have EL2. These are id_pfr1[15:12] and
- * id_aa64pfr0_el1[11:8].
+/*
+ * Disable the hypervisor feature bits in the processor feature
+ * registers if we don't have EL2.
  */
-cpu->isar.id_aa64pfr0 &= ~0xf00;
-cpu->isar.id_pfr1 &= ~0xf000;
+cpu->isar.id_aa64pfr0 = FIELD_DP64(cpu->isar.id_aa64pfr0,
+   ID_AA64PFR0, EL2, 0);
+cpu->isar.id_pfr1 = FIELD_DP32(cpu->isar.id_pfr1,
+   ID_PFR1, VIRTUALIZATION, 0);
 }
 
 #ifndef CONFIG_USER_ONLY
-- 
2.25.1




[PATCH v2 07/24] target/arm: Annotate arm_max_initfn with FEAT identifiers

2022-04-11 Thread Richard Henderson
Update the legacy feature names to the current names.
Provide feature names for id changes that were not marked.
Sort the field updates into increasing bitfield order.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/cpu64.c   | 96 ++--
 target/arm/cpu_tcg.c | 48 +++---
 2 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 528b0f5e64..e4f630d83f 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -713,51 +713,51 @@ static void aarch64_max_initfn(Object *obj)
 cpu->midr = t;
 
 t = cpu->isar.id_aa64isar0;
-t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2); /* AES + PMULL */
-t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 2); /* SHA512 */
+t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2);  /* FEAT_PMULL */
+t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1); /* FEAT_SHA1 */
+t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 2); /* FEAT_SHA512 */
 t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2);
-t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, SHA3, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, SM3, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, SM4, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, FHM, 1);
-t = FIELD_DP64(t, ID_AA64ISAR0, TS, 2); /* v8.5-CondM */
-t = FIELD_DP64(t, ID_AA64ISAR0, TLB, 2); /* FEAT_TLBIRANGE */
-t = FIELD_DP64(t, ID_AA64ISAR0, RNDR, 1);
+t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2);   /* FEAT_LSE */
+t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1);  /* FEAT_RDM */
+t = FIELD_DP64(t, ID_AA64ISAR0, SHA3, 1); /* FEAT_SHA3 */
+t = FIELD_DP64(t, ID_AA64ISAR0, SM3, 1);  /* FEAT_SM3 */
+t = FIELD_DP64(t, ID_AA64ISAR0, SM4, 1);  /* FEAT_SM4 */
+t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);   /* FEAT_DotProd */
+t = FIELD_DP64(t, ID_AA64ISAR0, FHM, 1);  /* FEAT_FHM */
+t = FIELD_DP64(t, ID_AA64ISAR0, TS, 2);   /* FEAT_FlagM2 */
+t = FIELD_DP64(t, ID_AA64ISAR0, TLB, 2);  /* FEAT_TLBIRANGE */
+t = FIELD_DP64(t, ID_AA64ISAR0, RNDR, 1); /* FEAT_RNG */
 cpu->isar.id_aa64isar0 = t;
 
 t = cpu->isar.id_aa64isar1;
-t = FIELD_DP64(t, ID_AA64ISAR1, DPB, 2);
-t = FIELD_DP64(t, ID_AA64ISAR1, JSCVT, 1);
-t = FIELD_DP64(t, ID_AA64ISAR1, FCMA, 1);
-t = FIELD_DP64(t, ID_AA64ISAR1, SB, 1);
-t = FIELD_DP64(t, ID_AA64ISAR1, SPECRES, 1);
-t = FIELD_DP64(t, ID_AA64ISAR1, BF16, 1);
-t = FIELD_DP64(t, ID_AA64ISAR1, FRINTTS, 1);
-t = FIELD_DP64(t, ID_AA64ISAR1, LRCPC, 2); /* ARMv8.4-RCPC */
-t = FIELD_DP64(t, ID_AA64ISAR1, I8MM, 1);
+t = FIELD_DP64(t, ID_AA64ISAR1, DPB, 2);  /* FEAT_DPB2 */
+t = FIELD_DP64(t, ID_AA64ISAR1, JSCVT, 1);/* FEAT_JSCVT */
+t = FIELD_DP64(t, ID_AA64ISAR1, FCMA, 1); /* FEAT_FCMA */
+t = FIELD_DP64(t, ID_AA64ISAR1, LRCPC, 2);/* FEAT_LRCPC2 */
+t = FIELD_DP64(t, ID_AA64ISAR1, FRINTTS, 1);  /* FEAT_FRINTTS */
+t = FIELD_DP64(t, ID_AA64ISAR1, SB, 1);   /* FEAT_SB */
+t = FIELD_DP64(t, ID_AA64ISAR1, SPECRES, 1);  /* FEAT_SPECRES */
+t = FIELD_DP64(t, ID_AA64ISAR1, BF16, 1); /* FEAT_BF16 */
+t = FIELD_DP64(t, ID_AA64ISAR1, I8MM, 1); /* FEAT_I8MM */
 cpu->isar.id_aa64isar1 = t;
 
 t = cpu->isar.id_aa64pfr0;
+t = FIELD_DP64(t, ID_AA64PFR0, FP, 1);/* FEAT_FP16 */
+t = FIELD_DP64(t, ID_AA64PFR0, ADVSIMD, 1);   /* FEAT_FP16 */
 t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
-t = FIELD_DP64(t, ID_AA64PFR0, FP, 1);
-t = FIELD_DP64(t, ID_AA64PFR0, ADVSIMD, 1);
-t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);
-t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);
+t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);  /* FEAT_SEL2 */
+t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);   /* FEAT_DIT */
 cpu->isar.id_aa64pfr0 = t;
 
 t = cpu->isar.id_aa64pfr1;
-t = FIELD_DP64(t, ID_AA64PFR1, BT, 1);
-t = FIELD_DP64(t, ID_AA64PFR1, SSBS, 2);
+t = FIELD_DP64(t, ID_AA64PFR1, BT, 1);/* FEAT_BTI */
+t = FIELD_DP64(t, ID_AA64PFR1, SSBS, 2);  /* FEAT_SSBS2 */
 /*
  * Begin with full support for MTE. This will be downgraded to MTE=0
  * during realize if the board provides no tag memory, much like
  * we do for EL2 with the virtualization=on property.
  */
-t = FIELD_DP64(t, ID_AA64PFR1, MTE, 3);
+t = FIELD_DP64(t, ID_AA64PFR1, MTE, 3);   /* FEAT_MTE3 */
 cpu->isar.id_aa64pfr1 = t;
 
 t = cpu->isar.id_aa64mmfr0;
@@ -769,35 +769,35 @@ static void aarch64_max_initfn(Object *obj)
 cpu->isar.id_aa64mmfr0 = t;
 
 t = cpu->isar.id_aa64mmfr1;
-t = FIELD_DP64(t, ID_AA64MMFR1, HPDS, 1); /* HPD */
-t = FIELD_DP64(t, ID_AA64MMFR1, LO, 1);
-t = FIELD_DP64(t, ID_AA64MMFR1, VH, 1);
-t = FIELD_DP64(t, ID_AA64MMFR1, PAN, 2); /* ATS1E1 */
-t = FIELD

[PATCH v2 06/24] target/arm: Split out arm32_max_features

2022-04-11 Thread Richard Henderson
Share the code to set AArch32 max features so that we no
longer have code drift between qemu{-system,}-{arm,aarch64}.

Signed-off-by: Richard Henderson 
---
 target/arm/internals.h |   2 +
 target/arm/cpu64.c |  50 +-
 target/arm/cpu_tcg.c   | 114 ++---
 3 files changed, 65 insertions(+), 101 deletions(-)

diff --git a/target/arm/internals.h b/target/arm/internals.h
index 96a57ee68f..ca9782b9f0 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1301,4 +1301,6 @@ static inline void 
define_cortex_a72_a57_a53_cp_reginfo(ARMCPU *cpu) { }
 void define_cortex_a72_a57_a53_cp_reginfo(ARMCPU *cpu);
 #endif
 
+void arm32_max_features(ARMCPU *cpu);
+
 #endif
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 67d628c0af..528b0f5e64 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -682,7 +682,6 @@ static void aarch64_max_initfn(Object *obj)
 {
 ARMCPU *cpu = ARM_CPU(obj);
 uint64_t t;
-uint32_t u;
 
 if (kvm_enabled() || hvf_enabled()) {
 /* With KVM or HVF, '-cpu max' is identical to '-cpu host' */
@@ -797,57 +796,12 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64ZFR0, F64MM, 1);
 cpu->isar.id_aa64zfr0 = t;
 
-/* Replicate the same data to the 32-bit id registers.  */
-u = cpu->isar.id_isar5;
-u = FIELD_DP32(u, ID_ISAR5, AES, 2); /* AES + PMULL */
-u = FIELD_DP32(u, ID_ISAR5, SHA1, 1);
-u = FIELD_DP32(u, ID_ISAR5, SHA2, 1);
-u = FIELD_DP32(u, ID_ISAR5, CRC32, 1);
-u = FIELD_DP32(u, ID_ISAR5, RDM, 1);
-u = FIELD_DP32(u, ID_ISAR5, VCMA, 1);
-cpu->isar.id_isar5 = u;
-
-u = cpu->isar.id_isar6;
-u = FIELD_DP32(u, ID_ISAR6, JSCVT, 1);
-u = FIELD_DP32(u, ID_ISAR6, DP, 1);
-u = FIELD_DP32(u, ID_ISAR6, FHM, 1);
-u = FIELD_DP32(u, ID_ISAR6, SB, 1);
-u = FIELD_DP32(u, ID_ISAR6, SPECRES, 1);
-u = FIELD_DP32(u, ID_ISAR6, BF16, 1);
-u = FIELD_DP32(u, ID_ISAR6, I8MM, 1);
-cpu->isar.id_isar6 = u;
-
-u = cpu->isar.id_pfr0;
-u = FIELD_DP32(u, ID_PFR0, DIT, 1);
-cpu->isar.id_pfr0 = u;
-
-u = cpu->isar.id_pfr2;
-u = FIELD_DP32(u, ID_PFR2, SSBS, 1);
-cpu->isar.id_pfr2 = u;
-
-u = cpu->isar.id_mmfr3;
-u = FIELD_DP32(u, ID_MMFR3, PAN, 2); /* ATS1E1 */
-cpu->isar.id_mmfr3 = u;
-
-u = cpu->isar.id_mmfr4;
-u = FIELD_DP32(u, ID_MMFR4, HPDS, 1); /* AA32HPD */
-u = FIELD_DP32(u, ID_MMFR4, AC2, 1); /* ACTLR2, HACTLR2 */
-u = FIELD_DP32(u, ID_MMFR4, CNP, 1); /* TTCNP */
-u = FIELD_DP32(u, ID_MMFR4, XNX, 1); /* TTS2UXN */
-cpu->isar.id_mmfr4 = u;
-
 t = cpu->isar.id_aa64dfr0;
 t = FIELD_DP64(t, ID_AA64DFR0, PMUVER, 5); /* v8.4-PMU */
 cpu->isar.id_aa64dfr0 = t;
 
-u = cpu->isar.id_dfr0;
-u = FIELD_DP32(u, ID_DFR0, PERFMON, 5); /* v8.4-PMU */
-cpu->isar.id_dfr0 = u;
-
-u = cpu->isar.mvfr1;
-u = FIELD_DP32(u, MVFR1, FPHP, 3);  /* v8.2-FP16 */
-u = FIELD_DP32(u, MVFR1, SIMDHP, 2);/* v8.2-FP16 */
-cpu->isar.mvfr1 = u;
+/* Replicate the same data to the 32-bit id registers.  */
+arm32_max_features(cpu);
 
 #ifdef CONFIG_USER_ONLY
 /*
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index ac782531a7..94af0c3bda 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -19,6 +19,66 @@
 #include "hw/boards.h"
 #endif
 
+
+/* Share AArch32 -cpu max features with AArch64. */
+void arm32_max_features(ARMCPU *cpu)
+{
+uint32_t t;
+
+/* Add additional features supported by QEMU */
+t = cpu->isar.id_isar5;
+t = FIELD_DP32(t, ID_ISAR5, AES, 2);
+t = FIELD_DP32(t, ID_ISAR5, SHA1, 1);
+t = FIELD_DP32(t, ID_ISAR5, SHA2, 1);
+t = FIELD_DP32(t, ID_ISAR5, CRC32, 1);
+t = FIELD_DP32(t, ID_ISAR5, RDM, 1);
+t = FIELD_DP32(t, ID_ISAR5, VCMA, 1);
+cpu->isar.id_isar5 = t;
+
+t = cpu->isar.id_isar6;
+t = FIELD_DP32(t, ID_ISAR6, JSCVT, 1);
+t = FIELD_DP32(t, ID_ISAR6, DP, 1);
+t = FIELD_DP32(t, ID_ISAR6, FHM, 1);
+t = FIELD_DP32(t, ID_ISAR6, SB, 1);
+t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
+t = FIELD_DP32(t, ID_ISAR6, BF16, 1);
+t = FIELD_DP32(t, ID_ISAR6, I8MM, 1);
+cpu->isar.id_isar6 = t;
+
+t = cpu->isar.mvfr1;
+t = FIELD_DP32(t, MVFR1, FPHP, 3); /* v8.2-FP16 */
+t = FIELD_DP32(t, MVFR1, SIMDHP, 2);   /* v8.2-FP16 */
+cpu->isar.mvfr1 = t;
+
+t = cpu->isar.mvfr2;
+t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
+t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
+cpu->isar.mvfr2 = t;
+
+t = cpu->isar.id_mmfr3;
+t = FIELD_DP32(t, ID_MMFR3, PAN, 2); /* ATS1E1 */
+cpu->isar.id_mmfr3 = t;
+
+t = cpu->isar.id_mmfr4;
+t = FIELD_DP32(t, ID_MMFR4, HPDS, 1); /* AA32HPD */
+t = FIELD_DP32(t, ID_MMFR4, AC2, 1); /* ACTLR2, HACTLR2 */
+t = FIELD_DP32(t, ID_MMFR4, CNP, 1); /* TTCNP */
+t = FIELD_DP32(t, ID_MMFR4, XNX, 1); /* TTS2UXN */
+cpu->isar.id_mmfr4 = t;
+
+t = cpu->isa

[PATCH v2 03/24] target/arm: Move cortex impdef sysregs to cpu_tcg.c

2022-04-11 Thread Richard Henderson
Previously we were defining some of these in user-only mode,
but none of them are accessible from user-only, therefore
define them only in system mode.

This will shortly be used from cpu_tcg.c also.

Signed-off-by: Richard Henderson 
---
v2: New patch.
---
 target/arm/internals.h |  6 
 target/arm/cpu64.c | 64 +++---
 target/arm/cpu_tcg.c   | 60 +++
 3 files changed, 70 insertions(+), 60 deletions(-)

diff --git a/target/arm/internals.h b/target/arm/internals.h
index 7f696cd36a..96a57ee68f 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1295,4 +1295,10 @@ int aarch64_fpu_gdb_get_reg(CPUARMState *env, GByteArray 
*buf, int reg);
 int aarch64_fpu_gdb_set_reg(CPUARMState *env, uint8_t *buf, int reg);
 #endif
 
+#ifdef CONFIG_USER_ONLY
+static inline void define_cortex_a72_a57_a53_cp_reginfo(ARMCPU *cpu) { }
+#else
+void define_cortex_a72_a57_a53_cp_reginfo(ARMCPU *cpu);
+#endif
+
 #endif
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index eb44c05822..67d628c0af 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -34,65 +34,9 @@
 #include "hvf_arm.h"
 #include "qapi/visitor.h"
 #include "hw/qdev-properties.h"
+#include "internals.h"
 
 
-#ifndef CONFIG_USER_ONLY
-static uint64_t a57_a53_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri)
-{
-ARMCPU *cpu = env_archcpu(env);
-
-/* Number of cores is in [25:24]; otherwise we RAZ */
-return (cpu->core_count - 1) << 24;
-}
-#endif
-
-static const ARMCPRegInfo cortex_a72_a57_a53_cp_reginfo[] = {
-#ifndef CONFIG_USER_ONLY
-{ .name = "L2CTLR_EL1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 1, .crn = 11, .crm = 0, .opc2 = 2,
-  .access = PL1_RW, .readfn = a57_a53_l2ctlr_read,
-  .writefn = arm_cp_write_ignore },
-{ .name = "L2CTLR",
-  .cp = 15, .opc1 = 1, .crn = 9, .crm = 0, .opc2 = 2,
-  .access = PL1_RW, .readfn = a57_a53_l2ctlr_read,
-  .writefn = arm_cp_write_ignore },
-#endif
-{ .name = "L2ECTLR_EL1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 1, .crn = 11, .crm = 0, .opc2 = 3,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "L2ECTLR",
-  .cp = 15, .opc1 = 1, .crn = 9, .crm = 0, .opc2 = 3,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "L2ACTLR", .state = ARM_CP_STATE_BOTH,
-  .opc0 = 3, .opc1 = 1, .crn = 15, .crm = 0, .opc2 = 0,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "CPUACTLR_EL1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 1, .crn = 15, .crm = 2, .opc2 = 0,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "CPUACTLR",
-  .cp = 15, .opc1 = 0, .crm = 15,
-  .access = PL1_RW, .type = ARM_CP_CONST | ARM_CP_64BIT, .resetvalue = 0 },
-{ .name = "CPUECTLR_EL1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 1, .crn = 15, .crm = 2, .opc2 = 1,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "CPUECTLR",
-  .cp = 15, .opc1 = 1, .crm = 15,
-  .access = PL1_RW, .type = ARM_CP_CONST | ARM_CP_64BIT, .resetvalue = 0 },
-{ .name = "CPUMERRSR_EL1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 1, .crn = 15, .crm = 2, .opc2 = 2,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "CPUMERRSR",
-  .cp = 15, .opc1 = 2, .crm = 15,
-  .access = PL1_RW, .type = ARM_CP_CONST | ARM_CP_64BIT, .resetvalue = 0 },
-{ .name = "L2MERRSR_EL1", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 1, .crn = 15, .crm = 2, .opc2 = 3,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "L2MERRSR",
-  .cp = 15, .opc1 = 3, .crm = 15,
-  .access = PL1_RW, .type = ARM_CP_CONST | ARM_CP_64BIT, .resetvalue = 0 },
-REGINFO_SENTINEL
-};
-
 static void aarch64_a57_initfn(Object *obj)
 {
 ARMCPU *cpu = ARM_CPU(obj);
@@ -143,7 +87,7 @@ static void aarch64_a57_initfn(Object *obj)
 cpu->gic_num_lrs = 4;
 cpu->gic_vpribits = 5;
 cpu->gic_vprebits = 5;
-define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
+define_cortex_a72_a57_a53_cp_reginfo(cpu);
 }
 
 static void aarch64_a53_initfn(Object *obj)
@@ -196,7 +140,7 @@ static void aarch64_a53_initfn(Object *obj)
 cpu->gic_num_lrs = 4;
 cpu->gic_vpribits = 5;
 cpu->gic_vprebits = 5;
-define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
+define_cortex_a72_a57_a53_cp_reginfo(cpu);
 }
 
 static void aarch64_a72_initfn(Object *obj)
@@ -247,7 +191,7 @@ static void aarch64_a72_initfn(Object *obj)
 cpu->gic_num_lrs = 4;
 cpu->gic_vpribits = 5;
 cpu->gic_vprebits = 5;
-define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
+define_cortex_a72_a57_a53_cp_reginfo(cpu);
 }
 
 void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp)
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 13d0e9b195..17bb5e5d76 100644

[PATCH v2 05/24] target/arm: Set ID_DFR0.PerfMon for qemu-system-arm -cpu max

2022-04-11 Thread Richard Henderson
We set this for qemu-system-aarch64, but failed to do so
for the strictly 32-bit emulation.

Fixes: 3bec78447a9 ("target/arm: Provide ARMv8.4-PMU in '-cpu max'")
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/cpu_tcg.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index b7cb3a6cb3..ac782531a7 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -1088,6 +1088,10 @@ static void arm_max_initfn(Object *obj)
 t = FIELD_DP32(t, ID_PFR2, SSBS, 1);
 cpu->isar.id_pfr2 = t;
 
+t = cpu->isar.id_dfr0;
+t = FIELD_DP32(t, ID_DFR0, PERFMON, 5); /* v8.4-PMU */
+cpu->isar.id_dfr0 = t;
+
 #ifdef CONFIG_USER_ONLY
 /*
  * Break with true ARMv8 and add back old-style VFP short-vector support.
-- 
2.25.1




[PATCH v2 04/24] target/arm: Update qemu-system-arm -cpu max to cortex-a57

2022-04-11 Thread Richard Henderson
Instead of starting with cortex-a15 and adding v8 features to
a v7 cpu, begin with a v8 cpu stripped of its aarch64 features.
This fixes the long-standing to-do where we only enabled v8
features for user-only.

Signed-off-by: Richard Henderson 
---
v2: Create impdef sysregs; only enable short-vector support for user-only.
---
 target/arm/cpu_tcg.c | 151 ++-
 1 file changed, 92 insertions(+), 59 deletions(-)

diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 17bb5e5d76..b7cb3a6cb3 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -998,71 +998,104 @@ static void arm_v7m_class_init(ObjectClass *oc, void 
*data)
 static void arm_max_initfn(Object *obj)
 {
 ARMCPU *cpu = ARM_CPU(obj);
+uint32_t t;
 
-cortex_a15_initfn(obj);
+/* aarch64_a57_initfn, advertising none of the aarch64 features */
+cpu->dtb_compatible = "arm,cortex-a57";
+set_feature(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
+set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
+set_feature(&cpu->env, ARM_FEATURE_EL2);
+set_feature(&cpu->env, ARM_FEATURE_EL3);
+set_feature(&cpu->env, ARM_FEATURE_PMU);
+cpu->midr = 0x411fd070;
+cpu->revidr = 0x;
+cpu->reset_fpsid = 0x41034070;
+cpu->isar.mvfr0 = 0x10110222;
+cpu->isar.mvfr1 = 0x1211;
+cpu->isar.mvfr2 = 0x0043;
+cpu->ctr = 0x8444c004;
+cpu->reset_sctlr = 0x00c50838;
+cpu->isar.id_pfr0 = 0x0131;
+cpu->isar.id_pfr1 = 0x00011011;
+cpu->isar.id_dfr0 = 0x03010066;
+cpu->id_afr0 = 0x;
+cpu->isar.id_mmfr0 = 0x10101105;
+cpu->isar.id_mmfr1 = 0x4000;
+cpu->isar.id_mmfr2 = 0x0126;
+cpu->isar.id_mmfr3 = 0x02102211;
+cpu->isar.id_isar0 = 0x02101110;
+cpu->isar.id_isar1 = 0x13112111;
+cpu->isar.id_isar2 = 0x21232042;
+cpu->isar.id_isar3 = 0x01112131;
+cpu->isar.id_isar4 = 0x00011142;
+cpu->isar.id_isar5 = 0x00011121;
+cpu->isar.id_isar6 = 0;
+cpu->isar.dbgdidr = 0x3516d000;
+cpu->clidr = 0x0a200023;
+cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
+cpu->ccsidr[1] = 0x201fe012; /* 48KB L1 icache */
+cpu->ccsidr[2] = 0x70ffe07a; /* 2048KB L2 cache */
+define_cortex_a72_a57_a53_cp_reginfo(cpu);
 
-/* old-style VFP short-vector support */
-cpu->isar.mvfr0 = FIELD_DP32(cpu->isar.mvfr0, MVFR0, FPSHVEC, 1);
+/* Add additional features supported by QEMU */
+t = cpu->isar.id_isar5;
+t = FIELD_DP32(t, ID_ISAR5, AES, 2);
+t = FIELD_DP32(t, ID_ISAR5, SHA1, 1);
+t = FIELD_DP32(t, ID_ISAR5, SHA2, 1);
+t = FIELD_DP32(t, ID_ISAR5, CRC32, 1);
+t = FIELD_DP32(t, ID_ISAR5, RDM, 1);
+t = FIELD_DP32(t, ID_ISAR5, VCMA, 1);
+cpu->isar.id_isar5 = t;
+
+t = cpu->isar.id_isar6;
+t = FIELD_DP32(t, ID_ISAR6, JSCVT, 1);
+t = FIELD_DP32(t, ID_ISAR6, DP, 1);
+t = FIELD_DP32(t, ID_ISAR6, FHM, 1);
+t = FIELD_DP32(t, ID_ISAR6, SB, 1);
+t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
+t = FIELD_DP32(t, ID_ISAR6, BF16, 1);
+t = FIELD_DP32(t, ID_ISAR6, I8MM, 1);
+cpu->isar.id_isar6 = t;
+
+t = cpu->isar.mvfr1;
+t = FIELD_DP32(t, MVFR1, FPHP, 3); /* v8.2-FP16 */
+t = FIELD_DP32(t, MVFR1, SIMDHP, 2);   /* v8.2-FP16 */
+cpu->isar.mvfr1 = t;
+
+t = cpu->isar.mvfr2;
+t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
+t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
+cpu->isar.mvfr2 = t;
+
+t = cpu->isar.id_mmfr3;
+t = FIELD_DP32(t, ID_MMFR3, PAN, 2); /* ATS1E1 */
+cpu->isar.id_mmfr3 = t;
+
+t = cpu->isar.id_mmfr4;
+t = FIELD_DP32(t, ID_MMFR4, HPDS, 1); /* AA32HPD */
+t = FIELD_DP32(t, ID_MMFR4, AC2, 1); /* ACTLR2, HACTLR2 */
+t = FIELD_DP32(t, ID_MMFR4, CNP, 1); /* TTCNP */
+t = FIELD_DP32(t, ID_MMFR4, XNX, 1); /* TTS2UXN */
+cpu->isar.id_mmfr4 = t;
+
+t = cpu->isar.id_pfr0;
+t = FIELD_DP32(t, ID_PFR0, DIT, 1);
+cpu->isar.id_pfr0 = t;
+
+t = cpu->isar.id_pfr2;
+t = FIELD_DP32(t, ID_PFR2, SSBS, 1);
+cpu->isar.id_pfr2 = t;
 
 #ifdef CONFIG_USER_ONLY
 /*
- * We don't set these in system emulation mode for the moment,
- * since we don't correctly set (all of) the ID registers to
- * advertise them.
+ * Break with true ARMv8 and add back old-style VFP short-vector support.
+ * Only do this for user-mode, where -cpu max is the default, so that
+ * older v6 and v7 programs are more likely to work without adjustment.
  */
-set_feature(&cpu->env, ARM_FEATURE_V8);
-{
-uint32_t t;
-
-t = cpu->isar.id_isar5;
-t = FIELD_DP32(t, ID_ISAR5, AES, 2);
-t = FIELD_DP32(t, ID_ISAR5, SHA1, 1);
-t = FIELD_DP32(t, ID_ISAR5, SHA2, 1);
-t = FIELD_DP32(t, ID_ISAR5, CRC32, 1);
-t = FIELD_DP32(t, ID_ISAR5, RDM, 1);
-t = FIELD_DP32(t, ID_ISAR5, VCMA, 1);
-cpu->is

[PATCH v2 01/24] target/arm: Add isar predicates for FEAT_Debugv8p2

2022-04-11 Thread Richard Henderson
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 23879de5fa..9c456ff23a 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -4026,6 +4026,11 @@ static inline bool isar_feature_aa32_ssbs(const 
ARMISARegisters *id)
 return FIELD_EX32(id->id_pfr2, ID_PFR2, SSBS) != 0;
 }
 
+static inline bool isar_feature_aa32_debugv8p2(const ARMISARegisters *id)
+{
+return FIELD_EX32(id->id_dfr0, ID_DFR0, COPDBG) >= 8;
+}
+
 /*
  * 64-bit feature tests via id registers.
  */
@@ -4332,6 +4337,11 @@ static inline bool isar_feature_aa64_ssbs(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, SSBS) != 0;
 }
 
+static inline bool isar_feature_aa64_debugv8p2(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->id_aa64dfr0, ID_AA64DFR0, DEBUGVER) >= 8;
+}
+
 static inline bool isar_feature_aa64_sve2(const ARMISARegisters *id)
 {
 return FIELD_EX64(id->id_aa64zfr0, ID_AA64ZFR0, SVEVER) != 0;
@@ -4415,6 +4425,11 @@ static inline bool isar_feature_any_tts2uxn(const 
ARMISARegisters *id)
 return isar_feature_aa64_tts2uxn(id) || isar_feature_aa32_tts2uxn(id);
 }
 
+static inline bool isar_feature_any_debugv8p2(const ARMISARegisters *id)
+{
+return isar_feature_aa64_debugv8p2(id) || isar_feature_aa32_debugv8p2(id);
+}
+
 /*
  * Forward to the above feature tests given an ARMCPU pointer.
  */
-- 
2.25.1




[PATCH v2 02/24] target/arm: Adjust definition of CONTEXTIDR_EL2

2022-04-11 Thread Richard Henderson
This register is present for either VHE or Debugv8p2, and is
RES0 from EL3 when EL2 is not present.  Move the definition
out of vhe_reginfo and provide a fallback for missing EL2.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 7d14650615..210c139818 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7443,11 +7443,20 @@ static const ARMCPRegInfo jazelle_regs[] = {
 REGINFO_SENTINEL
 };
 
+static const ARMCPRegInfo contextidr_el2 = {
+.name = "CONTEXTIDR_EL2", .state = ARM_CP_STATE_AA64,
+.opc0 = 3, .opc1 = 4, .crn = 13, .crm = 0, .opc2 = 1,
+.access = PL2_RW,
+.fieldoffset = offsetof(CPUARMState, cp15.contextidr_el[2])
+};
+
+static const ARMCPRegInfo contextidr_no_el2 = {
+.name = "CONTEXTIDR_EL2", .state = ARM_CP_STATE_AA64,
+.opc0 = 3, .opc1 = 4, .crn = 13, .crm = 0, .opc2 = 1,
+.access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0
+};
+
 static const ARMCPRegInfo vhe_reginfo[] = {
-{ .name = "CONTEXTIDR_EL2", .state = ARM_CP_STATE_AA64,
-  .opc0 = 3, .opc1 = 4, .crn = 13, .crm = 0, .opc2 = 1,
-  .access = PL2_RW,
-  .fieldoffset = offsetof(CPUARMState, cp15.contextidr_el[2]) },
 { .name = "TTBR1_EL2", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 4, .crn = 2, .crm = 0, .opc2 = 1,
   .access = PL2_RW, .writefn = vmsa_tcr_ttbr_el2_write,
@@ -8443,6 +8452,14 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 define_one_arm_cp_reg(cpu, &ssbs_reginfo);
 }
 
+if (cpu_isar_feature(aa64_vh, cpu) ||
+cpu_isar_feature(aa64_debugv8p2, cpu)) {
+if (arm_feature(env, ARM_FEATURE_EL2)) {
+define_one_arm_cp_reg(cpu, &contextidr_el2);
+} else {
+define_one_arm_cp_reg(cpu, &contextidr_no_el2);
+}
+}
 if (arm_feature(env, ARM_FEATURE_EL2) && cpu_isar_feature(aa64_vh, cpu)) {
 define_arm_cp_regs(cpu, vhe_reginfo);
 }
-- 
2.25.1




[PATCH v2 00/24] target/arm: 8 new features, A76 and N1

2022-04-11 Thread Richard Henderson
For v2, combine two previous patch sets and address comments.

Patches lacking review:
  03-target-arm-Move-cortex-impdef-sysregs-to-cpu_tcg..patch
  04-target-arm-Update-qemu-system-arm-cpu-max-to-cort.patch
  06-target-arm-Split-out-arm32_max_features.patch
  12-target-arm-Add-minimal-RAS-registers.patch
  14-target-arm-Implement-virtual-SError-exceptions.patch
  20-target-arm-Enable-FEAT_CSV2_2-for-cpu-max.patch
  23-target-arm-Define-cortex-a76.patch
  24-target-arm-Define-neoverse-n1.patch


r~


Richard Henderson (24):
  target/arm: Add isar predicates for FEAT_Debugv8p2
  target/arm: Adjust definition of CONTEXTIDR_EL2
  target/arm: Move cortex impdef sysregs to cpu_tcg.c
  target/arm: Update qemu-system-arm -cpu max to cortex-a57
  target/arm: Set ID_DFR0.PerfMon for qemu-system-arm -cpu max
  target/arm: Split out arm32_max_features
  target/arm: Annotate arm_max_initfn with FEAT identifiers
  target/arm: Use field names for manipulating EL2 and EL3 modes
  target/arm: Enable FEAT_Debugv8p2 for -cpu max
  target/arm: Enable FEAT_Debugv8p4 for -cpu max
  target/arm: Add isar_feature_{aa64,any}_ras
  target/arm: Add minimal RAS registers
  target/arm: Enable SCR and HCR bits for RAS
  target/arm: Implement virtual SError exceptions
  target/arm: Implement ESB instruction
  target/arm: Enable FEAT_RAS for -cpu max
  target/arm: Enable FEAT_IESB for -cpu max
  target/arm: Enable FEAT_CSV2 for -cpu max
  target/arm: Update ISAR fields for ARMv8.8
  target/arm: Enable FEAT_CSV2_2 for -cpu max
  target/arm: Enable FEAT_CSV3 for -cpu max
  target/arm: Enable FEAT_DGH for -cpu max
  target/arm: Define cortex-a76
  target/arm: Define neoverse-n1

 docs/system/arm/emulation.rst |  10 +
 docs/system/arm/virt.rst  |   2 +
 target/arm/cpu.h  |  72 +++
 target/arm/helper.h   |   1 +
 target/arm/internals.h|  16 ++
 target/arm/syndrome.h |   5 +
 target/arm/a32.decode |  16 +-
 target/arm/t32.decode |  18 +-
 hw/arm/sbsa-ref.c |   2 +
 hw/arm/virt.c |   2 +
 target/arm/cpu.c  |  61 +-
 target/arm/cpu64.c| 349 +++---
 target/arm/cpu_tcg.c  | 228 --
 target/arm/helper.c   | 246 +++-
 target/arm/op_helper.c|  43 +
 target/arm/translate-a64.c|  18 ++
 target/arm/translate.c|  23 +++
 17 files changed, 866 insertions(+), 246 deletions(-)

-- 
2.25.1




Re: [PATCH 0/2] target/riscv: Annotate atomic operations

2022-04-11 Thread Alistair Francis
On Fri, Apr 1, 2022 at 11:00 PM Richard Henderson
 wrote:
>
> If an atomic operation fails on RISC-V, we want to generate
> a store/amo fault and not a load fault.
>
> Annotate amo insns, so that we can recognize them after unwinding.
> Transform the implementation access type to store/amo for reporting.
>
>
> r~
>
>
> Richard Henderson (2):
>   target/riscv: Use cpu_loop_exit_restore directly from mmu faults
>   target/riscv: Mark amo insns during translation
>
>  target/riscv/cpu.h  | 15 ++
>  target/riscv/cpu.c  |  3 ++
>  target/riscv/cpu_helper.c   | 62 +
>  target/riscv/translate.c|  9 
>  target/riscv/insn_trans/trans_rva.c.inc | 11 -
>  5 files changed, 79 insertions(+), 21 deletions(-)

Thanks!

Applied to riscv-to-apply.next

Alistair

>
> --
> 2.25.1
>
>



Re: [PATCH v3] hw/riscv: virt: Exit if the user provided -bios in combination with KVM

2022-04-11 Thread Alistair Francis
On Fri, Apr 1, 2022 at 10:18 PM Ralf Ramsauer
 wrote:
>
> The -bios option is silently ignored if used in combination with -enable-kvm.
> The reason is that the machine starts in S-Mode, and the bios typically runs 
> in
> M-Mode.
>
> Better exit in that case to not confuse the user.
>
> Signed-off-by: Ralf Ramsauer 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/riscv/virt.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index da50cbed43..09609c96e8 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1308,12 +1308,18 @@ static void virt_machine_init(MachineState *machine)
>
>  /*
>   * Only direct boot kernel is currently supported for KVM VM,
> - * so the "-bios" parameter is ignored and treated like "-bios none"
> - * when KVM is enabled.
> + * so the "-bios" parameter is not supported when KVM is enabled.
>   */
>  if (kvm_enabled()) {
> -g_free(machine->firmware);
> -machine->firmware = g_strdup("none");
> +if (machine->firmware) {
> +if (strcmp(machine->firmware, "none")) {
> +error_report("Machine mode firmware is not supported in "
> + "combination with KVM.");
> +exit(1);
> +}
> +} else {
> +machine->firmware = g_strdup("none");
> +}
>  }
>
>  if (riscv_is_32bit(&s->soc[0])) {
> --
> 2.32.0
>



Re: [PATCH 6/7] target/arm: Define cortex-a76

2022-04-11 Thread Richard Henderson

On 4/11/22 11:30, Richard Henderson wrote:

   cpu->isar.dbgdidr


"If EL1 cannot use AArch32 then the implementation of this register is OPTIONAL and 
deprecated."


Which we already handle in define_debug_regs by not defining DBGDIDR if this 
value is 0.


r~



[PATCH v2 2/2] include/hw/pci/pcie_host: Correct PCIE_MMCFG_SIZE_MAX

2022-04-11 Thread Francisco Iglesias
According to 7.2.2 in [1] bit 27 is the last bit that can be part of the
bus number, this makes the ECAM max size equal to '1 << 28'. This patch
restores back this value into the PCIE_MMCFG_SIZE_MAX define (which was
changed in commit 58d5b22bbd5 ("ppc4xx: Add device models found in PPC440
core SoCs")).

[1] PCI Express® Base Specification Revision 5.0 Version 1.0

Signed-off-by: Francisco Iglesias 
---
 include/hw/pci/pcie_host.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/pci/pcie_host.h b/include/hw/pci/pcie_host.h
index b3c8ce973c..82d92177da 100644
--- a/include/hw/pci/pcie_host.h
+++ b/include/hw/pci/pcie_host.h
@@ -65,7 +65,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
  * bit 12 - 14: function number
  * bit  0 - 11: offset in configuration space of a given device
  */
-#define PCIE_MMCFG_SIZE_MAX (1ULL << 29)
+#define PCIE_MMCFG_SIZE_MAX (1ULL << 28)
 #define PCIE_MMCFG_SIZE_MIN (1ULL << 20)
 #define PCIE_MMCFG_BUS_BIT  20
 #define PCIE_MMCFG_BUS_MASK 0xff
-- 
2.20.1




[PATCH v2 1/2] include/hw/pci/pcie_host: Correct PCIE_MMCFG_BUS_MASK

2022-04-11 Thread Francisco Iglesias
According to [1] address bits 27 - 20 are mapped to the bus number (the
TLPs bus number field is 8 bits). Below is the formula taken from Table
7-1 in [1].

"
Memory Address | PCI Express Configuration Space
A[(20+n-1):20] | Bus Number, 1 ≤ n ≤ 8
"

[1] PCI Express® Base Specification Revision 5.0 Version 1.0

Signed-off-by: Francisco Iglesias 
---
 include/hw/pci/pcie_host.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/hw/pci/pcie_host.h b/include/hw/pci/pcie_host.h
index 076457b270..b3c8ce973c 100644
--- a/include/hw/pci/pcie_host.h
+++ b/include/hw/pci/pcie_host.h
@@ -60,7 +60,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
 /*
  * PCI express ECAM (Enhanced Configuration Address Mapping) format.
  * AKA mmcfg address
- * bit 20 - 28: bus number
+ * bit 20 - 27: bus number
  * bit 15 - 19: device number
  * bit 12 - 14: function number
  * bit  0 - 11: offset in configuration space of a given device
@@ -68,7 +68,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
 #define PCIE_MMCFG_SIZE_MAX (1ULL << 29)
 #define PCIE_MMCFG_SIZE_MIN (1ULL << 20)
 #define PCIE_MMCFG_BUS_BIT  20
-#define PCIE_MMCFG_BUS_MASK 0x1ff
+#define PCIE_MMCFG_BUS_MASK 0xff
 #define PCIE_MMCFG_DEVFN_BIT12
 #define PCIE_MMCFG_DEVFN_MASK   0xff
 #define PCIE_MMCFG_CONFOFFSET_MASK  0xfff
-- 
2.20.1




[PATCH v2 0/2] Correct a couple of defines in pcie_host.h

2022-04-11 Thread Francisco Iglesias
Hi,

This series attempts to correct a couple of defines inside pcie_host.h.

Best regards,
Francisco Iglesias

Changelog:
v1->v2:
 * Went from RFC to patch proposal
 * Added more meat on the commit message of patch 1


Francisco Iglesias (2):
  include/hw/pci/pcie_host: Correct PCIE_MMCFG_BUS_MASK
  include/hw/pci/pcie_host: Correct PCIE_MMCFG_SIZE_MAX

 include/hw/pci/pcie_host.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.20.1




Re: [RFC PATCH v1 1/1] include/hw/pci/pcie_host: Correct PCIE_MMCFG_BUS_MASK

2022-04-11 Thread Francisco Iglesias
Hi Michael,

On [2022 Apr 11] Mon 17:12:47, Michael S. Tsirkin wrote:
> On Mon, Apr 11, 2022 at 09:38:18PM +0200, Francisco Iglesias wrote:
> > According to [1] address bits 27 - 20 are mapped to the bus number (the
> > TLPs bus number field is 8 bits).
> > 
> > [1] PCI Express® Base Specification Revision 5.0 Version 1.0
> > 
> > Signed-off-by: Francisco Iglesias 
> > ---
> >  include/hw/pci/pcie_host.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/hw/pci/pcie_host.h b/include/hw/pci/pcie_host.h
> > index 076457b270..b3c8ce973c 100644
> > --- a/include/hw/pci/pcie_host.h
> > +++ b/include/hw/pci/pcie_host.h
> > @@ -60,7 +60,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
> >  /*
> >   * PCI express ECAM (Enhanced Configuration Address Mapping) format.
> >   * AKA mmcfg address
> > - * bit 20 - 28: bus number
> > + * bit 20 - 27: bus number
> >   * bit 15 - 19: device number
> >   * bit 12 - 14: function number
> >   * bit  0 - 11: offset in configuration space of a given device
> 
> this is correct, or to be more precise:
> A[(20 + n – 1):20] and 1 <= n <= 8

Thank you for having a look! I'll create a patch for this and also a
second proposing a correction for PCIE_MMCFG_SIZE_MAX and repost!

Best regards,
Francisco

> 
> 
> > @@ -68,7 +68,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
> >  #define PCIE_MMCFG_SIZE_MAX (1ULL << 29)
> >  #define PCIE_MMCFG_SIZE_MIN (1ULL << 20)
> >  #define PCIE_MMCFG_BUS_BIT  20
> > -#define PCIE_MMCFG_BUS_MASK 0x1ff
> > +#define PCIE_MMCFG_BUS_MASK 0xff
> >  #define PCIE_MMCFG_DEVFN_BIT12
> >  #define PCIE_MMCFG_DEVFN_MASK   0xff
> >  #define PCIE_MMCFG_CONFOFFSET_MASK  0xfff
> > -- 
> > 2.20.1
> 



Re: [PATCH 14/16] target/arm: Implement ESB instruction

2022-04-11 Thread Richard Henderson

On 4/11/22 09:18, Peter Maydell wrote:

+  ESB 0011 0010    0001 
+]


Why don't we decode bits [11:8] here? I see it's the same
as YIELD/WFE/WFI, but I'm not sure why we're not decoding
those bits in those insns either...


See page F4-7074 in H.a, where bits [11:8] of the imm12 field are described 
with ''.


+static bool trans_ESB(DisasContext *s, arg_ESB *a)
+{
+if (dc_isar_feature(aa32_ras, s) &&
+arm_dc_feature(s, ARM_FEATURE_EL2) &&
+s->current_el <= 1) {


This is doing the right thing for M-profile but only rather
indirectly because it happens to get caught by the FEATURE_EL2
check.


Yes, I had though that a feature, reducing the number of checks, but...



I think it would be safer to explicitly check for
not-M-profile (which then gives you a place to put the
"For M-profile minimal-RAS ESB can be a NOP" comment that got
removed above).


... fair enough.


I think a comment noting that without RAS we must NOP would
be useful here.


Ok.


r~



Re: [PATCH] migration/dirtyrate: Replace malloc with g_new

2022-04-11 Thread Philippe Mathieu-Daudé

On 11/4/22 11:47, jianchunfu wrote:

Using macro g_new() to handling potential memory allocation failures
in dirtyrate.

Signed-off-by: jianchunfu 
---
  migration/dirtyrate.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index aace12a787..0e59aacbb0 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -522,10 +522,10 @@ static void calculate_dirtyrate_dirty_ring(struct 
DirtyRateConfig config)
  nvcpu++;
  }
  
-dirty_pages = malloc(sizeof(*dirty_pages) * nvcpu);

+dirty_pages = g_new(DirtyPageRecord, nvcpu);
  
  DirtyStat.dirty_ring.nvcpu = nvcpu;

-DirtyStat.dirty_ring.rates = malloc(sizeof(DirtyRateVcpu) * nvcpu);
+DirtyStat.dirty_ring.rates = g_new(DirtyRateVcpu, nvcpu);
  
  dirtyrate_global_dirty_log_start();
  


While malloc() resources are released with free(), g_malloc/g_new()
ones with g_free().

So to match the API, this hunk is missing:

-- >8 --
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index aace12a787..e49db7ca4c 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -159,3 +159,3 @@ static void cleanup_dirtyrate_stat(struct 
DirtyRateConfig config)

 if (dirtyrate_mode == DIRTY_RATE_MEASURE_MODE_DIRTY_RING) {
-free(DirtyStat.dirty_ring.rates);
+g_free(DirtyStat.dirty_ring.rates);
 DirtyStat.dirty_ring.rates = NULL;
@@ -558,3 +558,3 @@ static void calculate_dirtyrate_dirty_ring(struct 
DirtyRateConfig config)

 DirtyStat.dirty_rate = dirtyrate_sum;
-free(dirty_pages);
+g_free(dirty_pages);
 }
---



Re: [PATCH 13/16] target/arm: Implement virtual SError exceptions

2022-04-11 Thread Richard Henderson

On 4/11/22 09:32, Peter Maydell wrote:

On Sat, 9 Apr 2022 at 01:11, Richard Henderson
 wrote:


Virtual SError exceptions are raised by setting HCR_EL2.VSE,
and are routed to EL1 just like other virtual exceptions.

Signed-off-by: Richard Henderson 



@@ -10041,6 +10048,20 @@ static void arm_cpu_do_interrupt_aarch32(CPUState *cs)
  mask = CPSR_A | CPSR_I | CPSR_F;
  offset = 4;
  break;
+case EXCP_VSERR:
+{
+/* Construct the SError syndrome from AET and ExT fields. */
+ARMMMUFaultInfo fi = { .type = ARMFault_AsyncExternal, };
+env->exception.fsr = arm_fi_to_sfsc(&fi);
+env->exception.fsr |= env->cp15.vsesr_el2 & 0xd000;
+A32_BANKED_CURRENT_REG_SET(env, dfsr, env->exception.fsr);
+
+new_mode = ARM_CPU_MODE_ABT;
+addr = 0x10;
+mask = CPSR_A | CPSR_I;
+offset = 8;
+}
+break;
  case EXCP_SMC:


Having looked at the following patch I came back to the AArch32 handling
of taking an SError in this patch...

(1) I think you need to look at TTBCR.EAE in the usual way to
decide whether to report the FSR in long-descriptor or
short-descriptor format


Yes, I've reread AArch32.TakeVirtualSErrorException() and you're right -- 
AArch32.ReportDataAbort() examines EAE.



(2) maybe log the FSR value, the way we do for prefetch and
data aborts ?
(3) maybe mention that this is reported like a data abort but that
the DFAR has an unknown value ?


Yes to all.


r~



Re: [PATCH 11/16] target/arm: Add minimal RAS registers

2022-04-11 Thread Richard Henderson

On 4/11/22 08:49, Peter Maydell wrote:

+{ .name = "ERRSELR_EL1", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 3, .opc2 = 1,
+  .access = PL1_RW, .accessfn = access_terr,
+  .fieldoffset = offsetof(CPUARMState, cp15.errselr_el1) },


By my reading of the spec we could make ERRSELR_EL1 RAZ/WI, because
writing an over-large number has a number of behaviours including
that the value the guest can read back is UNKNOWN. That would save
having the CPU state struct field.


Good point, I should have read the fine print myself:

If ERRIDR_EL1 indicates that zero error records are implemented, then it is IMPLEMENTATION 
DEFINED whether ERRSELR_EL1 is UNDEFINED or RES 0.


so perhaps it's better to leave it UNDEFINED.


r~



Re: [RFC PATCH v1 1/1] include/hw/pci/pcie_host: Correct PCIE_MMCFG_BUS_MASK

2022-04-11 Thread Michael S. Tsirkin
On Mon, Apr 11, 2022 at 09:38:18PM +0200, Francisco Iglesias wrote:
> According to [1] address bits 27 - 20 are mapped to the bus number (the
> TLPs bus number field is 8 bits).
> 
> [1] PCI Express® Base Specification Revision 5.0 Version 1.0
> 
> Signed-off-by: Francisco Iglesias 
> ---
>  include/hw/pci/pcie_host.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/hw/pci/pcie_host.h b/include/hw/pci/pcie_host.h
> index 076457b270..b3c8ce973c 100644
> --- a/include/hw/pci/pcie_host.h
> +++ b/include/hw/pci/pcie_host.h
> @@ -60,7 +60,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
>  /*
>   * PCI express ECAM (Enhanced Configuration Address Mapping) format.
>   * AKA mmcfg address
> - * bit 20 - 28: bus number
> + * bit 20 - 27: bus number
>   * bit 15 - 19: device number
>   * bit 12 - 14: function number
>   * bit  0 - 11: offset in configuration space of a given device

this is correct, or to be more precise:
A[(20 + n – 1):20] and 1 <= n <= 8


> @@ -68,7 +68,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
>  #define PCIE_MMCFG_SIZE_MAX (1ULL << 29)
>  #define PCIE_MMCFG_SIZE_MIN (1ULL << 20)
>  #define PCIE_MMCFG_BUS_BIT  20
> -#define PCIE_MMCFG_BUS_MASK 0x1ff
> +#define PCIE_MMCFG_BUS_MASK 0xff
>  #define PCIE_MMCFG_DEVFN_BIT12
>  #define PCIE_MMCFG_DEVFN_MASK   0xff
>  #define PCIE_MMCFG_CONFOFFSET_MASK  0xfff
> -- 
> 2.20.1




[RFC PATCH v1 1/1] include/hw/pci/pcie_host: Correct PCIE_MMCFG_BUS_MASK

2022-04-11 Thread Francisco Iglesias
According to [1] address bits 27 - 20 are mapped to the bus number (the
TLPs bus number field is 8 bits).

[1] PCI Express® Base Specification Revision 5.0 Version 1.0

Signed-off-by: Francisco Iglesias 
---
 include/hw/pci/pcie_host.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/hw/pci/pcie_host.h b/include/hw/pci/pcie_host.h
index 076457b270..b3c8ce973c 100644
--- a/include/hw/pci/pcie_host.h
+++ b/include/hw/pci/pcie_host.h
@@ -60,7 +60,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
 /*
  * PCI express ECAM (Enhanced Configuration Address Mapping) format.
  * AKA mmcfg address
- * bit 20 - 28: bus number
+ * bit 20 - 27: bus number
  * bit 15 - 19: device number
  * bit 12 - 14: function number
  * bit  0 - 11: offset in configuration space of a given device
@@ -68,7 +68,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
 #define PCIE_MMCFG_SIZE_MAX (1ULL << 29)
 #define PCIE_MMCFG_SIZE_MIN (1ULL << 20)
 #define PCIE_MMCFG_BUS_BIT  20
-#define PCIE_MMCFG_BUS_MASK 0x1ff
+#define PCIE_MMCFG_BUS_MASK 0xff
 #define PCIE_MMCFG_DEVFN_BIT12
 #define PCIE_MMCFG_DEVFN_MASK   0xff
 #define PCIE_MMCFG_CONFOFFSET_MASK  0xfff
-- 
2.20.1




Re: [libvirt RFC] virFile: new VIR_FILE_WRAPPER_BIG_PIPE to improve performance

2022-04-11 Thread Dr. David Alan Gilbert
* Claudio Fontana (cfont...@suse.de) wrote:
> On 4/7/22 3:57 PM, Claudio Fontana wrote:
> > On 4/7/22 3:53 PM, Dr. David Alan Gilbert wrote:
> >> * Claudio Fontana (cfont...@suse.de) wrote:
> >>> On 4/5/22 10:35 AM, Dr. David Alan Gilbert wrote:
>  * Claudio Fontana (cfont...@suse.de) wrote:
> > On 3/28/22 10:31 AM, Daniel P. Berrangé wrote:
> >> On Sat, Mar 26, 2022 at 04:49:46PM +0100, Claudio Fontana wrote:
> >>> On 3/25/22 12:29 PM, Daniel P. Berrangé wrote:
>  On Fri, Mar 18, 2022 at 02:34:29PM +0100, Claudio Fontana wrote:
> > On 3/17/22 4:03 PM, Dr. David Alan Gilbert wrote:
> >> * Claudio Fontana (cfont...@suse.de) wrote:
> >>> On 3/17/22 2:41 PM, Claudio Fontana wrote:
>  On 3/17/22 11:25 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 17, 2022 at 11:12:11AM +0100, Claudio Fontana wrote:
> >> On 3/16/22 1:17 PM, Claudio Fontana wrote:
> >>> On 3/14/22 6:48 PM, Daniel P. Berrangé wrote:
>  On Mon, Mar 14, 2022 at 06:38:31PM +0100, Claudio Fontana 
>  wrote:
> > On 3/14/22 6:17 PM, Daniel P. Berrangé wrote:
> >> On Sat, Mar 12, 2022 at 05:30:01PM +0100, Claudio Fontana 
> >> wrote:
> >>> the first user is the qemu driver,
> >>>
> >>> virsh save/resume would slow to a crawl with a default 
> >>> pipe size (64k).
> >>>
> >>> This improves the situation by 400%.
> >>>
> >>> Going through io_helper still seems to incur in some 
> >>> penalty (~15%-ish)
> >>> compared with direct qemu migration to a nc socket to a 
> >>> file.
> >>>
> >>> Signed-off-by: Claudio Fontana 
> >>> ---
> >>>  src/qemu/qemu_driver.c|  6 +++---
> >>>  src/qemu/qemu_saveimage.c | 11 ++-
> >>>  src/util/virfile.c| 12 
> >>>  src/util/virfile.h|  1 +
> >>>  4 files changed, 22 insertions(+), 8 deletions(-)
> >>>
> >>> Hello, I initially thought this to be a qemu performance 
> >>> issue,
> >>> so you can find the discussion about this in qemu-devel:
> >>>
> >>> "Re: bad virsh save /dev/null performance (600 MiB/s max)"
> >>>
> >>> https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg03142.html
> >
> >
> >> Current results show these experimental averages maximum 
> >> throughput
> >> migrating to /dev/null per each FdWrapper Pipe Size (as per 
> >> QEMU QMP
> >> "query-migrate", tests repeated 5 times for each).
> >> VM Size is 60G, most of the memory effectively touched before 
> >> migration,
> >> through user application allocating and touching all memory 
> >> with
> >> pseudorandom data.
> >>
> >> 64K: 5200 Mbps (current situation)
> >> 128K:5800 Mbps
> >> 256K:   20900 Mbps
> >> 512K:   21600 Mbps
> >> 1M: 22800 Mbps
> >> 2M: 22800 Mbps
> >> 4M: 22400 Mbps
> >> 8M: 22500 Mbps
> >> 16M:22800 Mbps
> >> 32M:22900 Mbps
> >> 64M:22900 Mbps
> >> 128M:   22800 Mbps
> >>
> >> This above is the throughput out of patched libvirt with 
> >> multiple Pipe Sizes for the FDWrapper.
> >
> > Ok, its bouncing around with noise after 1 MB. So I'd suggest 
> > that
> > libvirt attempt to raise the pipe limit to 1 MB by default, but
> > not try to go higher.
> >
> >> As for the theoretical limit for the libvirt architecture,
> >> I ran a qemu migration directly issuing the appropriate QMP
> >> commands, setting the same migration parameters as per libvirt,
> >> and then migrating to a socket netcatted to /dev/null via
> >> {"execute": "migrate", "arguments": { "uri", 
> >> "unix:///tmp/netcat.sock" } } :
> >>
> >> QMP:37000 Mbps
> >
> >> So although the Pipe size improves things (in particular the
> >> large jump is for the 256K size, although 1M seems a very good 
> >> value),
> >> there is still a second bottleneck in there somewhere that
> >> accounts for a loss of ~14200 Mbps in throughput.
> >>>
> >>>
> >>> Interesting addition: I tested quickly on a system with faster 
> >>>

Re: [PATCH 6/7] target/arm: Define cortex-a76

2022-04-11 Thread Richard Henderson

On 4/11/22 11:09, Peter Maydell wrote:

+cpu->isar.id_aa64pfr0  = 0x11001012ull;


This has the GIC field clear. On the one hand this is true
also of all our other CPU implementations. On the other hand
if we wire up a GICv3 in the board code then we will be
presenting the GIC CPU interface registers, which is what this
ID register field is supposed to be telling software.
I guess we should handle this by having gicv3_init_cpuif()
arrange for the ID field to be set. Which is mildly painful,
because that will mean the value for the cpreg isn't constant.


We already handle this via id_aa64pfr0_read().


+cpu->isar.id_pfr1  = 0x1001;


Here you have set the GIC field. We should at least be consistent :-)


Oops.  :-)  We have id_pfr1_read() for that as well.


+cpu->midr = 0x413fd0b1;


This is r3p1; the r4p1 TRM is available so we might as
well claim to be that.


Ok.


Missing (just cross-checking what other CPUs are setting):
   cpu->revidr
   cpu->reset_fpsid
   cpu->id_afr0


revidr and id_afr0 are 0 -- explicit zero required?  We certainly assume we begin with 
zero for other registers for other cpus...


FPSID is deprecated, and not mentioned in the a76 or n1 specs.  Presumably this is because 
it is not accessible at all: FPSID is not accessible from EL0 for VFPv3, and the A76 does 
not support aa32 at other than EL0.



   cpu->isar.dbgdidr


"If EL1 cannot use AArch32 then the implementation of this register is OPTIONAL and 
deprecated."



r~



Re: [libvirt RFC] virFile: new VIR_FILE_WRAPPER_BIG_PIPE to improve performance

2022-04-11 Thread Claudio Fontana
On 4/7/22 3:57 PM, Claudio Fontana wrote:
> On 4/7/22 3:53 PM, Dr. David Alan Gilbert wrote:
>> * Claudio Fontana (cfont...@suse.de) wrote:
>>> On 4/5/22 10:35 AM, Dr. David Alan Gilbert wrote:
 * Claudio Fontana (cfont...@suse.de) wrote:
> On 3/28/22 10:31 AM, Daniel P. Berrangé wrote:
>> On Sat, Mar 26, 2022 at 04:49:46PM +0100, Claudio Fontana wrote:
>>> On 3/25/22 12:29 PM, Daniel P. Berrangé wrote:
 On Fri, Mar 18, 2022 at 02:34:29PM +0100, Claudio Fontana wrote:
> On 3/17/22 4:03 PM, Dr. David Alan Gilbert wrote:
>> * Claudio Fontana (cfont...@suse.de) wrote:
>>> On 3/17/22 2:41 PM, Claudio Fontana wrote:
 On 3/17/22 11:25 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 17, 2022 at 11:12:11AM +0100, Claudio Fontana wrote:
>> On 3/16/22 1:17 PM, Claudio Fontana wrote:
>>> On 3/14/22 6:48 PM, Daniel P. Berrangé wrote:
 On Mon, Mar 14, 2022 at 06:38:31PM +0100, Claudio Fontana 
 wrote:
> On 3/14/22 6:17 PM, Daniel P. Berrangé wrote:
>> On Sat, Mar 12, 2022 at 05:30:01PM +0100, Claudio Fontana 
>> wrote:
>>> the first user is the qemu driver,
>>>
>>> virsh save/resume would slow to a crawl with a default pipe 
>>> size (64k).
>>>
>>> This improves the situation by 400%.
>>>
>>> Going through io_helper still seems to incur in some 
>>> penalty (~15%-ish)
>>> compared with direct qemu migration to a nc socket to a 
>>> file.
>>>
>>> Signed-off-by: Claudio Fontana 
>>> ---
>>>  src/qemu/qemu_driver.c|  6 +++---
>>>  src/qemu/qemu_saveimage.c | 11 ++-
>>>  src/util/virfile.c| 12 
>>>  src/util/virfile.h|  1 +
>>>  4 files changed, 22 insertions(+), 8 deletions(-)
>>>
>>> Hello, I initially thought this to be a qemu performance 
>>> issue,
>>> so you can find the discussion about this in qemu-devel:
>>>
>>> "Re: bad virsh save /dev/null performance (600 MiB/s max)"
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg03142.html
>
>
>> Current results show these experimental averages maximum 
>> throughput
>> migrating to /dev/null per each FdWrapper Pipe Size (as per QEMU 
>> QMP
>> "query-migrate", tests repeated 5 times for each).
>> VM Size is 60G, most of the memory effectively touched before 
>> migration,
>> through user application allocating and touching all memory with
>> pseudorandom data.
>>
>> 64K: 5200 Mbps (current situation)
>> 128K:5800 Mbps
>> 256K:   20900 Mbps
>> 512K:   21600 Mbps
>> 1M: 22800 Mbps
>> 2M: 22800 Mbps
>> 4M: 22400 Mbps
>> 8M: 22500 Mbps
>> 16M:22800 Mbps
>> 32M:22900 Mbps
>> 64M:22900 Mbps
>> 128M:   22800 Mbps
>>
>> This above is the throughput out of patched libvirt with 
>> multiple Pipe Sizes for the FDWrapper.
>
> Ok, its bouncing around with noise after 1 MB. So I'd suggest that
> libvirt attempt to raise the pipe limit to 1 MB by default, but
> not try to go higher.
>
>> As for the theoretical limit for the libvirt architecture,
>> I ran a qemu migration directly issuing the appropriate QMP
>> commands, setting the same migration parameters as per libvirt,
>> and then migrating to a socket netcatted to /dev/null via
>> {"execute": "migrate", "arguments": { "uri", 
>> "unix:///tmp/netcat.sock" } } :
>>
>> QMP:37000 Mbps
>
>> So although the Pipe size improves things (in particular the
>> large jump is for the 256K size, although 1M seems a very good 
>> value),
>> there is still a second bottleneck in there somewhere that
>> accounts for a loss of ~14200 Mbps in throughput.
>>>
>>>
>>> Interesting addition: I tested quickly on a system with faster cpus 
>>> and larger VM sizes, up to 200GB,
>>> and the difference in throughput libvirt vs qemu is basically the 
>>> same ~14500 Mbps.
>>>
>>> ~5 mbps qemu to netcat socket to /dev/null
>>> ~35500 mbps virsh save to /dev/null

Re: [PATCH 7/7] target/arm: Define neoverse-n1

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 07:15, Richard Henderson
 wrote:
>
> Enable the n1 for virt and sbsa board use.
>
> Signed-off-by: Richard Henderson 
> ---

Comments on previous patch apply here too, by and large.

thanks
-- PMM



Re: [PATCH 6/7] target/arm: Define cortex-a76

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 07:13, Richard Henderson
 wrote:
>
> Enable the a76 for virt and sbsa board use.
>
> Signed-off-by: Richard Henderson 
> ---
>  hw/arm/sbsa-ref.c  |  1 +
>  hw/arm/virt.c  |  1 +
>  target/arm/cpu64.c | 64 ++
>  3 files changed, 66 insertions(+)
>
> diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
> index 2387401963..2ddde88f5e 100644
> --- a/hw/arm/sbsa-ref.c
> +++ b/hw/arm/sbsa-ref.c
> @@ -145,6 +145,7 @@ static const int sbsa_ref_irqmap[] = {
>  static const char * const valid_cpus[] = {
>  ARM_CPU_TYPE_NAME("cortex-a57"),
>  ARM_CPU_TYPE_NAME("cortex-a72"),
> +ARM_CPU_TYPE_NAME("cortex-a76"),
>  ARM_CPU_TYPE_NAME("max"),
>  };
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index d2e5ecd234..ce15c36a7f 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -202,6 +202,7 @@ static const char *valid_cpus[] = {
>  ARM_CPU_TYPE_NAME("cortex-a53"),
>  ARM_CPU_TYPE_NAME("cortex-a57"),
>  ARM_CPU_TYPE_NAME("cortex-a72"),
> +ARM_CPU_TYPE_NAME("cortex-a76"),
>  ARM_CPU_TYPE_NAME("a64fx"),
>  ARM_CPU_TYPE_NAME("host"),
>  ARM_CPU_TYPE_NAME("max"),

Need to update the list in docs/system/arm/virt.rst as well.

> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 199ca437a0..a00c02be2c 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -251,6 +251,69 @@ static void aarch64_a72_initfn(Object *obj)
>  define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
>  }
>
> +static void aarch64_a76_initfn(Object *obj)
> +{
> +ARMCPU *cpu = ARM_CPU(obj);
> +
> +cpu->dtb_compatible = "arm,cortex-a76";
> +set_feature(&cpu->env, ARM_FEATURE_V8);
> +set_feature(&cpu->env, ARM_FEATURE_NEON);
> +set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
> +set_feature(&cpu->env, ARM_FEATURE_AARCH64);
> +set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
> +set_feature(&cpu->env, ARM_FEATURE_EL2);
> +set_feature(&cpu->env, ARM_FEATURE_EL3);
> +set_feature(&cpu->env, ARM_FEATURE_PMU);
> +
> +/* Ordered by B2.4 AArch64 registers by functional group */
> +cpu->clidr = 0x8223;
> +cpu->ctr = 0x8444C004;
> +cpu->dcz_blocksize = 4;
> +cpu->isar.id_aa64dfr0  = 0x10305408ull;
> +cpu->isar.id_aa64isar0 = 0x100010211120ull;
> +cpu->isar.id_aa64isar1 = 0x0011ull;
> +cpu->isar.id_aa64mmfr0 = 0x00101122ull;
> +cpu->isar.id_aa64mmfr1 = 0x10212122ull;
> +cpu->isar.id_aa64mmfr2 = 0x1011ull;
> +cpu->isar.id_aa64pfr0  = 0x11001012ull;

This has the GIC field clear. On the one hand this is true
also of all our other CPU implementations. On the other hand
if we wire up a GICv3 in the board code then we will be
presenting the GIC CPU interface registers, which is what this
ID register field is supposed to be telling software.
I guess we should handle this by having gicv3_init_cpuif()
arrange for the ID field to be set. Which is mildly painful,
because that will mean the value for the cpreg isn't constant.

(In real hardware the cpuif really is part of the CPU proper,
so it (ie the sysregs for the GICv3) exists whether the
GICv3 proper is present somewhere outside the CPU in the
SoC. But our implementation doesn't put the dividing line
quite where the h/w does.)

> +cpu->isar.id_aa64pfr1  = 0x0010ull;
> +cpu->isar.id_dfr0  = 0x04010088;
> +cpu->isar.id_isar0 = 0x02101110;
> +cpu->isar.id_isar1 = 0x13112111;
> +cpu->isar.id_isar2 = 0x21232042;
> +cpu->isar.id_isar3 = 0x01112131;
> +cpu->isar.id_isar4 = 0x00010142;
> +cpu->isar.id_isar5 = 0x01011121;
> +cpu->isar.id_isar6 = 0x0010;
> +cpu->isar.id_mmfr0 = 0x10201105;
> +cpu->isar.id_mmfr1 = 0x4000;
> +cpu->isar.id_mmfr2 = 0x0126;
> +cpu->isar.id_mmfr3 = 0x02122211;
> +cpu->isar.id_mmfr4 = 0x00021110;
> +cpu->isar.id_pfr0  = 0x10010131;
> +cpu->isar.id_pfr1  = 0x1001;

Here you have set the GIC field. We should at least be consistent :-)

> +cpu->isar.id_pfr2  = 0x0011;
> +cpu->midr = 0x413fd0b1;

This is r3p1; the r4p1 TRM is available so we might as
well claim to be that.

> +
> +/* From B2.18 CCSIDR_EL1 */
> +cpu->ccsidr[0] = 0x701fe01a; /* 64KB L1 dcache */
> +cpu->ccsidr[1] = 0x201fe01a; /* 64KB L1 icache */
> +cpu->ccsidr[2] = 0x707fe03a; /* 512KB L2 cache */
> +
> +/* From B2.93 SCTLR_EL3 */
> +cpu->reset_sctlr = 0x30c50838;
> +
> +/* From B4.23 ICH_VTR_EL2 */
> +cpu->gic_num_lrs = 4;
> +cpu->gic_vpribits = 5;
> +cpu->gic_vprebits = 5;

(side note, we should really support having the non-virtual
pribits/prebits for the GIC be configurable too. I have a
half-written set of patches for that.)

> +
> +/* From B5.1 AdvSIMD AArch64 register summary */
> +cpu->isar.mvfr0 = 0x10110222;
> +cpu->isar.mvfr1 = 0x1321;
> +cpu->isar.mvfr2 = 0x0043;

Missing (just cross-che

Re: [PATCH] migration/dirtyrate: Replace malloc with g_new

2022-04-11 Thread Richard Henderson

On 4/11/22 02:47, jianchunfu wrote:

Using macro g_new() to handling potential memory allocation failures
in dirtyrate.

Signed-off-by: jianchunfu
---
  migration/dirtyrate.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 08/16] target/arm: Enable FEAT_Debugv8p2 for -cpu max

2022-04-11 Thread Peter Maydell
On Mon, 11 Apr 2022 at 14:09, Peter Maydell  wrote:
>
> On Sat, 9 Apr 2022 at 01:18, Richard Henderson
>  wrote:
> >
> > The only portion of FEAT_Debugv8p2 that is relevant to QEMU
> > is CONTEXTIDR_EL2, which is also conditionally implemented
> > with FEAT_VHE.  The rest of the debug extension concerns the
> > External debug interface, which is outside the scope of QEMU.
> >
> > Signed-off-by: Richard Henderson 
> > ---
> >  target/arm/cpu.c | 1 +
> >  target/arm/cpu64.c   | 1 +
> >  target/arm/cpu_tcg.c | 2 ++
> >  3 files changed, 4 insertions(+)
> Reviewed-by: Peter Maydell 

...except that I've just remembered that this patch, and the
others in this and the other series that add support for new
FEAT_* need to update the list in docs/system/arm/emulation.rst
of all the features we implement.

thanks
-- PMM



Re: [PATCH 3/7] target/arm: Enable FEAT_CSV2_2 for -cpu max

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 07:03, Richard Henderson
 wrote:
>
> There is no branch prediction in TCG, therefore there is no
> need to actually include the context number into the predictor.
> Therefore all we need to do is add the state for SCXTNUM_ELx.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu.h| 16 +++
>  target/arm/cpu64.c  |  2 +-
>  target/arm/helper.c | 70 -
>  3 files changed, 86 insertions(+), 2 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index c6c6d89a69..0b89620662 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -688,6 +688,8 @@ typedef struct CPUArchState {
>  ARMPACKey apdb;
>  ARMPACKey apga;
>  } keys;
> +
> +uint64_t scxtnum_el[4];
>  #endif
>
>  #if defined(CONFIG_USER_ONLY)
> @@ -1211,6 +1213,7 @@ void pmu_init(ARMCPU *cpu);
>  #define SCTLR_WXN (1U << 19)
>  #define SCTLR_ST  (1U << 20) /* up to ??, RAZ in v6 */
>  #define SCTLR_UWXN(1U << 20) /* v7 onward, AArch32 only */
> +#define SCTLR_TSCXT   (1U << 20) /* FEAT_CSV2_1p2, AArch64 only */
>  #define SCTLR_FI  (1U << 21) /* up to v7, v8 RES0 */
>  #define SCTLR_IESB(1U << 21) /* v8.2-IESB, AArch64 only */
>  #define SCTLR_U   (1U << 22) /* up to v6, RAO in v7 */
> @@ -4368,6 +4371,19 @@ static inline bool isar_feature_aa64_dit(const 
> ARMISARegisters *id)
>  return FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, DIT) != 0;
>  }
>
> +static inline bool isar_feature_aa64_scxtnum(const ARMISARegisters *id)
> +{
> +int key = FIELD_EX64(id->id_aa64pfr0, ID_AA64PFR0, CSV2);
> +if (key >= 2) {
> +return true;  /* FEAT_CSV2_2 */
> +}
> +if (key == 1) {
> +key = FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, CSV2_FRAC);
> +return key >= 2;  /* FEAT_CSV2_1p2 */
> +}
> +return false;
> +}
> +
>  static inline bool isar_feature_aa64_ssbs(const ARMISARegisters *id)
>  {
>  return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, SSBS) != 0;
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index c1006a067c..9ff08bd995 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -805,7 +805,7 @@ static void aarch64_max_initfn(Object *obj)
>  t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
>  t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);  /* FEAT_SEL2 */
>  t = FIELD_DP64(t, ID_AA64PFR0, DIT, 1);   /* FEAT_DIT */
> -t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 1);  /* FEAT_CSV2 */
> +t = FIELD_DP64(t, ID_AA64PFR0, CSV2, 2);  /* FEAT_CSV2_2 */

I think we should probably explicitly zero ID_AA64PFR1.CSV2_frac.
Doesn't matter now, but might if in future we move 'max' from
"a57 with extras" to "some CPU with CSV2_1p1 plus extras".

>  cpu->isar.id_aa64pfr0 = t;
>
>  t = cpu->isar.id_aa64pfr1;
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index bd1c8e01cb..66af3397ee 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -1780,6 +1780,9 @@ static void scr_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  if (cpu_isar_feature(aa64_mte, cpu)) {
>  valid_mask |= SCR_ATA;
>  }
> +if (cpu_isar_feature(aa64_scxtnum, cpu)) {
> +valid_mask |= SCR_ENSCXT;
> +}
>  } else {
>  valid_mask &= ~(SCR_RW | SCR_ST);
>  if (cpu_isar_feature(aa32_ras, cpu)) {
> @@ -5312,6 +5315,9 @@ static void do_hcr_write(CPUARMState *env, uint64_t 
> value, uint64_t valid_mask)
>  if (cpu_isar_feature(aa64_mte, cpu)) {
>  valid_mask |= HCR_ATA | HCR_DCT | HCR_TID5;
>  }
> +if (cpu_isar_feature(aa64_scxtnum, cpu)) {
> +valid_mask |= HCR_ENSCXT;
> +}
>  }
>
>  /* Clear RES0 bits.  */
> @@ -5965,6 +5971,10 @@ static void define_arm_vh_e2h_redirects_aliases(ARMCPU 
> *cpu)
>  { K(3, 0,  5, 6, 0), K(3, 4,  5, 6, 0), K(3, 5, 5, 6, 0),
>"TFSR_EL1", "TFSR_EL2", "TFSR_EL12", isar_feature_aa64_mte },
>
> +{ K(3, 0, 0xd, 0, 7), K(3, 4, 0xd, 0, 7), K(3, 5, 0xd, 0, 7),

Use decimal to follow the style of the rest of this table, please.

> +  "SCXTNUM_EL1", "SCXTNUM_EL2", "SCXTNUM_EL12",
> +  isar_feature_aa64_scxtnum },
> +
>  /* TODO: ARMv8.2-SPE -- PMSCR_EL2 */
>  /* TODO: ARMv8.4-Trace -- TRFCR_EL2 */
>  };
> @@ -7434,7 +7444,61 @@ static const ARMCPRegInfo mte_el0_cacheop_reginfo[] = {
>  REGINFO_SENTINEL
>  };
>
> -#endif
> +static CPAccessResult access_scxtnum(CPUARMState *env, const ARMCPRegInfo 
> *ri,
> + bool isread)
> +{
> +uint64_t hcr;
> +
> +switch (arm_current_el(env)) {
> +case 0:
> +hcr = arm_hcr_el2_eff(env);
> +if ((hcr & (HCR_TGE | HCR_E2H)) != (HCR_TGE | HCR_E2H)) {
> +if (env->cp15.sctlr_el[1] & SCTLR_TSCXT) {
> +if (hcr & HCR_TGE) {
> +return CP_ACCESS_TRAP_EL2;
> +}
> +  

Re: [RFC PATCH] target/i386: avoid copying junk to extended ZMMReg fields

2022-04-11 Thread Peter Maydell
On Mon, 11 Apr 2022 at 17:56, Paolo Bonzini  wrote:
> Yeah, I actually wrote the memcpy() invocation because I was going to
> look at AVX later this year, which of course you couldn't know. :)
> What I came up after stealing parts of your nice comment is the
> following:
>
> /*
>   * Copy the relevant parts of a Reg value around. In the case where
>   * sizeof(Reg) > SIZE, these helpers operate only on the lower bytes of
>   * a 64 byte ZMMReg, so we must copy only those and keep the top bytes
>   * untouched in the guest-visible destination destination register.
>   * Note that the "lower bytes" are placed last in memory on big-endian
>   * hosts, which store the vector backwards in memory.  In that case the
>   * copy *starts* at B(SIZE - 1) and ends at B(0), the opposite of
>   * the little-endian case.
>   */
> #ifdef HOST_WORDS_BIGENDIAN
> #define MOVE(d, r) memcpy(&((d).B(SIZE - 1)), &(d).B(SIZE - 1), SIZE)

Typo -- 2nd argument should be operating on 'r', not 'd'.

> #else
> #define MOVE(d, r) memcpy(&(d).B(0), &(r).B(0), SIZE)
> #endif

Otherwise looks good.

thanks
-- PMM



[PATCH v2 1/2] hw/misc: Add PWRON STRAP bit fields in GCR module

2022-04-11 Thread Hao Wu
Similar to the Aspeed code in include/misc/aspeed_scu.h, we define
the PWRON STRAP fields in their corresponding module for NPCM7XX.

Signed-off-by: Hao Wu 
Reviewed-by: Patrick Venture 
---
 include/hw/misc/npcm7xx_gcr.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/hw/misc/npcm7xx_gcr.h b/include/hw/misc/npcm7xx_gcr.h
index 13109d9d32..9419e0a7d2 100644
--- a/include/hw/misc/npcm7xx_gcr.h
+++ b/include/hw/misc/npcm7xx_gcr.h
@@ -19,6 +19,36 @@
 #include "exec/memory.h"
 #include "hw/sysbus.h"
 
+/*
+ * NPCM7XX PWRON STRAP bit fields
+ * 12: SPI0 powered by VSBV3 at 1.8V
+ * 11: System flash attached to BMC
+ * 10: BSP alternative pins.
+ * 9:8: Flash UART command route enabled.
+ * 7: Security enabled.
+ * 6: HI-Z state control.
+ * 5: ECC disabled.
+ * 4: Reserved
+ * 3: JTAG2 enabled.
+ * 2:0: CPU and DRAM clock frequency.
+ */
+#define NPCM7XX_PWRON_STRAP_SPI0F18 BIT(12)
+#define NPCM7XX_PWRON_STRAP_SFABBIT(11)
+#define NPCM7XX_PWRON_STRAP_BSPABIT(10)
+#define NPCM7XX_PWRON_STRAP_FUP(x)  ((x) << 8)
+#define FUP_NORM_UART2  3
+#define FUP_PROG_UART3  2
+#define FUP_PROG_UART2  1
+#define FUP_NORM_UART3  0
+#define NPCM7XX_PWRON_STRAP_SECEN   BIT(7)
+#define NPCM7XX_PWRON_STRAP_HIZ BIT(6)
+#define NPCM7XX_PWRON_STRAP_ECC BIT(5)
+#define NPCM7XX_PWRON_STRAP_RESERVE1BIT(4)
+#define NPCM7XX_PWRON_STRAP_J2ENBIT(3)
+#define NPCM7XX_PWRON_STRAP_CKFRQ(x)(x)
+#define CKFRQ_SKIPINIT  0x000
+#define CKFRQ_DEFAULT   0x111
+
 /*
  * Number of registers in our device state structure. Don't change this without
  * incrementing the version_id in the vmstate.
-- 
2.35.1.1178.g4f1659d476-goog




Re: [PATCH 5/7] target/arm: Enable FEAT_DGH for -cpu max

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 07:07, Richard Henderson
 wrote:
>
> This extension concerns not merging memory access, which TCG does
> not implement.  Thus we can trivially enable this feature.
> Add a comment to handle_hint for the DGH instruction, but no code.
>
> Signed-off-by: Richard Henderson 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM



[PATCH v2 2/2] hw/arm: Use bit fields for NPCM7XX PWRON STRAPs

2022-04-11 Thread Hao Wu
This patch uses the defined fields to describe PWRON STRAPs for
better readability.

Signed-off-by: Hao Wu 
Reviewed-by: Patrick Venture 
---
 hw/arm/npcm7xx_boards.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
index 0678a56156..6bc6f5d2fe 100644
--- a/hw/arm/npcm7xx_boards.c
+++ b/hw/arm/npcm7xx_boards.c
@@ -30,11 +30,25 @@
 #include "sysemu/sysemu.h"
 #include "sysemu/block-backend.h"
 
-#define NPCM750_EVB_POWER_ON_STRAPS 0x1ff7
-#define QUANTA_GSJ_POWER_ON_STRAPS 0x1fff
-#define QUANTA_GBS_POWER_ON_STRAPS 0x17ff
-#define KUDO_BMC_POWER_ON_STRAPS 0x1fff
-#define MORI_BMC_POWER_ON_STRAPS 0x1fff
+#define NPCM7XX_POWER_ON_STRAPS_DEFAULT (   \
+NPCM7XX_PWRON_STRAP_SPI0F18 |   \
+NPCM7XX_PWRON_STRAP_SFAB |  \
+NPCM7XX_PWRON_STRAP_BSPA |  \
+NPCM7XX_PWRON_STRAP_FUP(FUP_NORM_UART2) |   \
+NPCM7XX_PWRON_STRAP_SECEN | \
+NPCM7XX_PWRON_STRAP_HIZ |   \
+NPCM7XX_PWRON_STRAP_ECC |   \
+NPCM7XX_PWRON_STRAP_RESERVE1 |  \
+NPCM7XX_PWRON_STRAP_J2EN |  \
+NPCM7XX_PWRON_STRAP_CKFRQ(CKFRQ_DEFAULT))
+
+#define NPCM750_EVB_POWER_ON_STRAPS ( \
+NPCM7XX_POWER_ON_STRAPS_DEFAULT & ~NPCM7XX_PWRON_STRAP_J2EN)
+#define QUANTA_GSJ_POWER_ON_STRAPS NPCM7XX_POWER_ON_STRAPS_DEFAULT
+#define QUANTA_GBS_POWER_ON_STRAPS ( \
+NPCM7XX_POWER_ON_STRAPS_DEFAULT & ~NPCM7XX_PWRON_STRAP_SFAB)
+#define KUDO_BMC_POWER_ON_STRAPS NPCM7XX_POWER_ON_STRAPS_DEFAULT
+#define MORI_BMC_POWER_ON_STRAPS NPCM7XX_POWER_ON_STRAPS_DEFAULT
 
 static const char npcm7xx_default_bootrom[] = "npcm7xx_bootrom.bin";
 
-- 
2.35.1.1178.g4f1659d476-goog




[PATCH v2 0/2] Define NPCM7XX PWRON bit fields

2022-04-11 Thread Hao Wu
Currently, the PWRON STRAP values in NPCM7XX boards are magic
numbers. Similar to the aspeed ones in hw/arm/aspeed.c, we
define bit fields constants for them and use these fields instead
of the magic numbers in the current implementation. The code
should behave exactly the same as the existing one.

-- Changes since v1
* Fix errors and apply suggestions Peter made on v1.

Hao Wu (2):
  hw/misc: Add PWRON STRAP bit fields in GCR module
  hw/arm: Use bit fields for NPCM7XX PWRON STRAPs

 hw/arm/npcm7xx_boards.c   | 24 +++-
 include/hw/misc/npcm7xx_gcr.h | 30 ++
 2 files changed, 49 insertions(+), 5 deletions(-)

-- 
2.35.1.1178.g4f1659d476-goog




Re: [PATCH 4/7] target/arm: Enable FEAT_CSV3 for -cpu max

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 07:07, Richard Henderson
 wrote:
>
> This extension concerns cache speculation, which TCG does
> not implement.  Thus we can trivially enable this feature.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu64.c   | 1 +
>  target/arm/cpu_tcg.c | 1 +
>  2 files changed, 2 insertions(+)
Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [RFC PATCH] target/i386: avoid copying junk to extended ZMMReg fields

2022-04-11 Thread Paolo Bonzini

On 4/11/22 17:18, Peter Maydell wrote:

Looking a bit more closely, this won't work on big-endian
hosts, because there we want to copy across the last 16
bytes of the struct, not the first 16. So I think we need
some more macro magic:

#if SHIFT == 0
#define COPY_REG(DEST, SRC) (DEST) = (SRC)
#else
#define COPY_REG(DEST, SRC) do { \
 (DEST).Q(0) = (SRC).Q(0);\
 (DEST).Q(1) = (SRC).Q(1);\
   } while (0)
#endif

and then use COPY_REG(*d, r);


Right, I have written something similar after seeing your response to
the bug.


We could probably try to write endian-specific flavours of
memcpy() invocation, but "do two 64-bit word copies" is what
the compiler would hopefully turn the memcpy into anyway :-)


Yeah, I actually wrote the memcpy() invocation because I was going to
look at AVX later this year, which of course you couldn't know. :)
What I came up after stealing parts of your nice comment is the
following:

/*
 * Copy the relevant parts of a Reg value around. In the case where
 * sizeof(Reg) > SIZE, these helpers operate only on the lower bytes of
 * a 64 byte ZMMReg, so we must copy only those and keep the top bytes
 * untouched in the guest-visible destination destination register.
 * Note that the "lower bytes" are placed last in memory on big-endian
 * hosts, which store the vector backwards in memory.  In that case the
 * copy *starts* at B(SIZE - 1) and ends at B(0), the opposite of
 * the little-endian case.
 */
#ifdef HOST_WORDS_BIGENDIAN
#define MOVE(d, r) memcpy(&((d).B(SIZE - 1)), &(d).B(SIZE - 1), SIZE)
#else
#define MOVE(d, r) memcpy(&(d).B(0), &(r).B(0), SIZE)
#endif

I'll still your nice comment and submit a patch later when 7.1 opens.

Paolo



Re: [PATCH v1] hw/ppc: change indentation to spaces from TABs

2022-04-11 Thread Guo Zhi
Sure, I will send a v2 patch.

Thanks,

Guo

- Original Message -
From: "Daniel Henrique Barboza" 
To: "Thomas Huth" , "Bin Meng" 
Cc: "Guo Zhi" , "Cédric Le Goater" , 
"David Gibson" , "Greg Kurz" , 
"qemu-ppc" , "qemu-devel@nongnu.org Developers" 
, "Peter Maydell" , "open 
list:RISC-V" 
Sent: Tuesday, April 12, 2022 12:32:23 AM
Subject: Re: [PATCH v1] hw/ppc: change indentation to spaces from TABs

On 4/11/22 04:23, Thomas Huth wrote:
> On 11/04/2022 08.57, Bin Meng wrote:
>> On Mon, Apr 11, 2022 at 2:45 PM Thomas Huth  wrote:
>>>
>>> On 08/04/2022 21.19, Daniel Henrique Barboza wrote:


 On 4/6/22 07:08, Bin Meng wrote:
> On Tue, Apr 5, 2022 at 10:36 PM Guo Zhi  wrote:
>>
>> There are still some files in the QEMU PPC code base that use TABs for
>> indentation instead of using  spaces.
>> The TABs should be replaced so that we have a consistent coding style.
>>
>> If this patch is applied, issue:
>>
>> https://gitlab.com/qemu-project/qemu/-/issues/374
>>
>> can be closed.

 Please add the following tag in the commit:


 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/374


 This will make Gitlab automatically close the issue when the patch is 
 accepted.

>>
>> Signed-off-by: Guo Zhi 
>> ---
>>    hw/core/uboot_image.h  | 185 -
>>    hw/ppc/ppc440_bamboo.c |   6 +-
>>    hw/ppc/spapr_rtas.c    |  18 ++--
>>    include/hw/ppc/ppc.h   |  10 +--
>>    4 files changed, 109 insertions(+), 110 deletions(-)
>>
>> diff --git a/hw/core/uboot_image.h b/hw/core/uboot_image.h
>
> uboot_image.h was taken from the U-Boot source, I believe it should be
> kept as it is.


 (CCing Thomas since het explictly listed hw/core/uboot_image.h in the bug)


 I am not sure about keeping this file as is.
>>>
>>> Seems like uboot_image.h has originally been taken from U-Boot's
>>> include/image.h file ... but the two files are completely out of sync
>>> nowadays, e.g. U-Boot switched to enums instead of #defines at one point in
>>> time. So I think it does not make much sense to keep the TABs in here, and
>>> I'd rather like to see them replaced with spaces indeed.
>>
>> This file has been sync'ed recently.
>>
>> See 
>> http://patchwork.ozlabs.org/project/qemu-devel/patch/20220324134812.541274-1-bmeng...@gmail.com/
> 
> Oh, ok, thanks, good to know. So we should maybe really rather drop the 
> uboot_image.h from the whitespace cleanup here, indeed (and rather add a 
> comment to the header file instead that this is a file that is sync'ed with 
> U-Boot and thus does not follow the QEMU coding conventions?)


Agree. I just updated the gitlab issue description to remove the reference to
this file.


Guo Zhi, can you please send another version of this patch with the updated
commit message and not touching uboot_image.h?



Thanks,


Daniel

> 
> Anyway, seems like that u-boot sync patch felt through the cracks, likely 
> since it was not quite clear which tree it should go through ... ARM? PPC? 
> RISC-V?
> 
>   Thomas
>



Re: [PATCH 2/7] target/arm: Update ISAR fields for ARMv8.8

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 06:58, Richard Henderson
 wrote:
>
> Update isar fields per ARM DDI0487 H.a.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu.h | 23 +++
>  1 file changed, 23 insertions(+)

> @@ -2067,7 +2087,9 @@ FIELD(ID_AA64DFR0, CTX_CMPS, 28, 4)
>  FIELD(ID_AA64DFR0, PMSVER, 32, 4)
>  FIELD(ID_AA64DFR0, DOUBLELOCK, 36, 4)
>  FIELD(ID_AA64DFR0, TRACEFILT, 40, 4)
> +FIELD(ID_AA64DFR0, TRACEBUFFER, 44, 4)
>  FIELD(ID_AA64DFR0, MTPMU, 48, 4)
> +FIELD(ID_AA64DFR0, BRBE, 52, 4)

Also
   FIELD(ID_AA64DFR0, HPMN0, 60, 4)

Otherwise
Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH 1/7] target/arm: Enable FEAT_CSV2 for -cpu max

2022-04-11 Thread Peter Maydell
On Sun, 10 Apr 2022 at 06:58, Richard Henderson
 wrote:
>
> This extension concerns branch speculation, which TCG does
> not implement.  Thus we can trivially enable this feature.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu64.c   | 1 +
>  target/arm/cpu_tcg.c | 1 +


Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH 16/16] target/arm: Enable FEAT_IESB for -cpu max

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:23, Richard Henderson
 wrote:
>
> This feature is AArch64 only, and applies to physical SErrors,
> which QEMU does not implement, thus the feature is a nop.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu64.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 03c6707111..def0f1fdcb 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -838,6 +838,7 @@ static void aarch64_max_initfn(Object *obj)
>  t = cpu->isar.id_aa64mmfr2;
>  t = FIELD_DP64(t, ID_AA64MMFR2, CNP, 1);  /* FEAT_TTCNP */
>  t = FIELD_DP64(t, ID_AA64MMFR2, UAO, 1);  /* FEAT_UAO */
> +t = FIELD_DP64(t, ID_AA64MMFR2, IESB, 1); /* FEAT_IESB */
>  t = FIELD_DP64(t, ID_AA64MMFR2, VARANGE, 1);  /* FEAT_LVA */
>  t = FIELD_DP64(t, ID_AA64MMFR2, ST, 1);   /* FEAT_TTST */
>  cpu->isar.id_aa64mmfr2 = t;
> --
> 2.25.1

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH 13/16] target/arm: Implement virtual SError exceptions

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:11, Richard Henderson
 wrote:
>
> Virtual SError exceptions are raised by setting HCR_EL2.VSE,
> and are routed to EL1 just like other virtual exceptions.
>
> Signed-off-by: Richard Henderson 

> @@ -10041,6 +10048,20 @@ static void arm_cpu_do_interrupt_aarch32(CPUState 
> *cs)
>  mask = CPSR_A | CPSR_I | CPSR_F;
>  offset = 4;
>  break;
> +case EXCP_VSERR:
> +{
> +/* Construct the SError syndrome from AET and ExT fields. */
> +ARMMMUFaultInfo fi = { .type = ARMFault_AsyncExternal, };
> +env->exception.fsr = arm_fi_to_sfsc(&fi);
> +env->exception.fsr |= env->cp15.vsesr_el2 & 0xd000;
> +A32_BANKED_CURRENT_REG_SET(env, dfsr, env->exception.fsr);
> +
> +new_mode = ARM_CPU_MODE_ABT;
> +addr = 0x10;
> +mask = CPSR_A | CPSR_I;
> +offset = 8;
> +}
> +break;
>  case EXCP_SMC:

Having looked at the following patch I came back to the AArch32 handling
of taking an SError in this patch...

(1) I think you need to look at TTBCR.EAE in the usual way to
decide whether to report the FSR in long-descriptor or
short-descriptor format
(2) maybe log the FSR value, the way we do for prefetch and
data aborts ?
(3) maybe mention that this is reported like a data abort but that
the DFAR has an unknown value ?

thanks
-- PMM



Re: [PATCH 15/16] target/arm: Enable FEAT_RAS for -cpu max

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:14, Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu64.c   | 1 +
>  target/arm/cpu_tcg.c | 1 +
>  2 files changed, 2 insertions(+)
Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v1] hw/ppc: change indentation to spaces from TABs

2022-04-11 Thread Daniel Henrique Barboza




On 4/11/22 04:23, Thomas Huth wrote:

On 11/04/2022 08.57, Bin Meng wrote:

On Mon, Apr 11, 2022 at 2:45 PM Thomas Huth  wrote:


On 08/04/2022 21.19, Daniel Henrique Barboza wrote:



On 4/6/22 07:08, Bin Meng wrote:

On Tue, Apr 5, 2022 at 10:36 PM Guo Zhi  wrote:


There are still some files in the QEMU PPC code base that use TABs for
indentation instead of using  spaces.
The TABs should be replaced so that we have a consistent coding style.

If this patch is applied, issue:

https://gitlab.com/qemu-project/qemu/-/issues/374

can be closed.


Please add the following tag in the commit:


Resolves: https://gitlab.com/qemu-project/qemu/-/issues/374


This will make Gitlab automatically close the issue when the patch is accepted.



Signed-off-by: Guo Zhi 
---
   hw/core/uboot_image.h  | 185 -
   hw/ppc/ppc440_bamboo.c |   6 +-
   hw/ppc/spapr_rtas.c    |  18 ++--
   include/hw/ppc/ppc.h   |  10 +--
   4 files changed, 109 insertions(+), 110 deletions(-)

diff --git a/hw/core/uboot_image.h b/hw/core/uboot_image.h


uboot_image.h was taken from the U-Boot source, I believe it should be
kept as it is.



(CCing Thomas since het explictly listed hw/core/uboot_image.h in the bug)


I am not sure about keeping this file as is.


Seems like uboot_image.h has originally been taken from U-Boot's
include/image.h file ... but the two files are completely out of sync
nowadays, e.g. U-Boot switched to enums instead of #defines at one point in
time. So I think it does not make much sense to keep the TABs in here, and
I'd rather like to see them replaced with spaces indeed.


This file has been sync'ed recently.

See 
http://patchwork.ozlabs.org/project/qemu-devel/patch/20220324134812.541274-1-bmeng...@gmail.com/


Oh, ok, thanks, good to know. So we should maybe really rather drop the 
uboot_image.h from the whitespace cleanup here, indeed (and rather add a 
comment to the header file instead that this is a file that is sync'ed with 
U-Boot and thus does not follow the QEMU coding conventions?)



Agree. I just updated the gitlab issue description to remove the reference to
this file.


Guo Zhi, can you please send another version of this patch with the updated
commit message and not touching uboot_image.h?



Thanks,


Daniel



Anyway, seems like that u-boot sync patch felt through the cracks, likely since 
it was not quite clear which tree it should go through ... ARM? PPC? RISC-V?

  Thomas





Re: [PATCH] tpm_crb: mark command buffer as dirty on request completion

2022-04-11 Thread Stefan Berger




On 4/11/22 10:47, Anthony PERARD wrote:

From: Anthony PERARD 

At the moment, there doesn't seems to be any way to know that QEMU
made modification to the command buffer. This is potentially an issue
on Xen while migrating a guest, as modification to the buffer after
the migration as started could be ignored and not transfered to the
destination. >
Mark the memory region of the command buffer as dirty once a request
is completed.


Not sure about the CRB...

The TIS at least carries the buffer as part of the state and stores it 
when the interface is saved:


https://github.com/qemu/qemu/blob/v6.2.0/hw/tpm/tpm_tis_isa.c#L56
https://github.com/qemu/qemu/blob/v6.2.0/hw/tpm/tpm_tis_sysbus.c#L56

With the CRB the memory is registered using these functions.

memory_region_init_io(&s->mmio, OBJECT(s), &tpm_crb_memory_ops, s,
"tpm-crb-mmio", sizeof(s->regs));
memory_region_init_ram(&s->cmdmem, OBJECT(s),
"tpm-crb-cmd", CRB_CTRL_CMD_SIZE, errp);

memory_region_add_subregion(get_system_memory(),
TPM_CRB_ADDR_BASE, &s->mmio);
memory_region_add_subregion(get_system_memory(),
TPM_CRB_ADDR_BASE + sizeof(s->regs), &s->cmdmem);


The state of the registers is saved using this here:

static const VMStateDescription vmstate_tpm_crb = {
.name = "tpm-crb",
.pre_save = tpm_crb_pre_save,
.fields = (VMStateField[]) {
VMSTATE_UINT32_ARRAY(regs, CRBState, TPM_CRB_R_MAX),
VMSTATE_END_OF_LIST(),
}
};

The buffer with the commands is not part of this. So likely it needs to 
be marked dirty but then I am not sure whether that is going to work if 
the response to a command on the CRB is only received when 
tpm_crb_pre_save() is called.. Maybe this buffer would have to be save 
explicitly in a .save function or also as part of vmstate_tpm_crb... ?



  Stefan






Signed-off-by: Anthony PERARD 
---

I have only read code to find out whether the tpm-crb device was fine
with regards to migration, and I don't think there's anything that
could mark the memory region as dirty once a request is completed.

There is one call to memory_region_get_ram_ptr(), but nothing seems to
be done with the pointer is regards to ram migration. Am I wrong?

Thanks.
---
  hw/tpm/tpm_crb.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c
index aa9c00aad3..67db594c48 100644
--- a/hw/tpm/tpm_crb.c
+++ b/hw/tpm/tpm_crb.c
@@ -197,6 +197,7 @@ static void tpm_crb_request_completed(TPMIf *ti, int ret)
  ARRAY_FIELD_DP32(s->regs, CRB_CTRL_STS,
   tpmSts, 1); /* fatal error */
  }
+memory_region_set_dirty(&s->cmdmem, 0, CRB_CTRL_CMD_SIZE);
  }

  static enum TPMVersion tpm_crb_get_version(TPMIf *ti)




Re: [PATCH 03/16] target/arm: Update qemu-system-arm -cpu max to cortex-a57

2022-04-11 Thread Richard Henderson

On 4/11/22 08:37, Peter Maydell wrote:

+/* aarch64_a57_initfn, advertising none of the aarch64 features */
+cpu->dtb_compatible = "arm,cortex-a57";
+set_feature(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
+set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
+set_feature(&cpu->env, ARM_FEATURE_EL2);
+set_feature(&cpu->env, ARM_FEATURE_EL3);
+set_feature(&cpu->env, ARM_FEATURE_PMU);
+cpu->midr = 0x411fd070;


If we're going to claim in the MIDR that we're an A57 then we
should provide the A57's impdef sysregs, at least those of
them that are visible to AArch32. This may otherwise cause
problems if the guest OS tries to write to one of them as
part of some errata workaround.


Ah yes.  Thanks,

r~



Re: [PATCH V6 21/27] vfio-pci: cpr part 3 (intx)

2022-04-11 Thread Steven Sistare
On 3/29/2022 7:03 AM, Fam Zheng wrote:
> On 2021-08-06 14:43, Steve Sistare wrote:
>> Preserve vfio INTX state across cpr restart.  Preserve VFIOINTx fields as
>> follows:
>>   pin : Recover this from the vfio config in kernel space
>>   interrupt : Preserve its eventfd descriptor across exec.
>>   unmask : Ditto
>>   route.irq : This could perhaps be recovered in vfio_pci_post_load by
>> calling pci_device_route_intx_to_irq(pin), whose implementation reads
>> config space for a bridge device such as ich9.  However, there is no
>> guarantee that the bridge vmstate is read before vfio vmstate.  Rather
>> than fiddling with MigrationPriority for vmstate handlers, explicitly
>> save route.irq in vfio vmstate.
>>   pending : save in vfio vmstate.
>>   mmap_timeout, mmap_timer : Re-initialize
>>   bool kvm_accel : Re-initialize
>>
>> In vfio_realize, defer calling vfio_intx_enable until the vmstate
>> is available, in vfio_pci_post_load.  Modify vfio_intx_enable and
>> vfio_intx_kvm_enable to skip vfio initialization, but still perform
>> kvm initialization.
>>
>> Signed-off-by: Steve Sistare 
> 
> Hi Steve,
> 
> Not directly related to this patch, but since the context is close: it looks
> like this series only takes care of exec restart mode of vfio-pci, have you 
> had
> any thoughts on kexec reboot mode with vfio-pci?
> 
> The general idea is if DMAR context is not lost during kexec, we should be 
> able
> to set up irqfds again and things will just work?
> 
> Fam

Hi Fam,
  I have thought about that use case, but only in general terms.
IMO it best fits in the cpr framework as a new mode (rather than as 
a new -restore command line argument).  

In your code below, you would have fewer code changes if you set 
'reused = true' for the new mode, rather than testing both 'reused and 
restored' 
at multiple sites. Lastly, I cleaned up the vector handling somewhat from V6 
to V7, so you may want to try your code using V7 as a base.

- Steve

> PS some more info below:
> 
> I have some local kernel patches to kexec reboot most part of the host kernel
> while keeping IOMMU DMAR tables in a valid state; with that, not many extra
> things are needed in addition to restore it. A PoC is like below (I can share
> more details of the kernel changes if this patch makes any sense):
> 
> 
> commit f8951e58be86bd6e37f816394a9a73f28d8059fc
> Author: Fam Zheng 
> Date:   Mon Mar 21 13:19:49 2022 +
> 
> cpr: Add live-update support to vfio-pci devices
> 
> In cpr-save, always serialize the vfio-pci states.
> 
> In cpr-load, add a '-restore' mode that will do
> VFIO_GROUP_GET_DEVICE_FD_INTACT and skip DMAR setup, somewhat similar to
> the current cpr exec mode.
> 
> Signed-off-by: Fam Zheng 
> 
> diff --git a/hw/pci/msix.c b/hw/pci/msix.c
> index 73f4259556..e36f0ef97d 100644
> --- a/hw/pci/msix.c
> +++ b/hw/pci/msix.c
> @@ -584,10 +584,15 @@ void msix_init_vector_notifiers(PCIDevice *dev,
>  MSIVectorReleaseNotifier release_notifier,
>  MSIVectorPollNotifier poll_notifier)
>  {
> +int vector;
> +
>  assert(use_notifier && release_notifier);
>  dev->msix_vector_use_notifier = use_notifier;
>  dev->msix_vector_release_notifier = release_notifier;
>  dev->msix_vector_poll_notifier = poll_notifier;
> +for (vector = 0; vector < dev->msix_entries_nr; ++vector) {
> +msix_handle_mask_update(dev, vector, true);
> +}
>  }
>  
>  int msix_set_vector_notifiers(PCIDevice *dev,
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 605ffbb5d0..f1240410a8 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -2066,6 +2066,9 @@ static int vfio_connect_container(VFIOGroup *group, 
> AddressSpace *as,
>  bool reused;
>  VFIOAddressSpace *space;
>  
> +if (restore) {
> +return 0;
> +}
>  space = vfio_get_address_space(as);
>  fd = cpr_find_fd("vfio_container_for_group", group->groupid);
>  reused = (fd > 0);
> @@ -2486,7 +2489,8 @@ int vfio_get_device(VFIOGroup *group, const char *name,
>  fd = cpr_find_fd(name, 0);
>  reused = (fd >= 0);
>  if (!reused) {
> -fd = ioctl(group->fd, VFIO_GROUP_GET_DEVICE_FD, name);
> +int op = restore ? VFIO_GROUP_GET_DEVICE_FD_INTACT : 
> VFIO_GROUP_GET_DEVICE_FD;
> +fd = ioctl(group->fd, op, name);
>  }
>  
>  if (fd < 0) {
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index e32513c668..9da5f93228 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -361,7 +361,7 @@ static int vfio_intx_enable(VFIOPCIDevice *vdev, Error 
> **errp)
>   * Do not alter interrupt state during vfio_realize and cpr-load.  The
>   * reused flag is cleared thereafter.
>   */
> -if (!vdev->pdev.reused) {
> +if (!vdev->pdev.reused && !restore) {
>  vfio_disable_interrupts(vdev);
>  }
>  
> @@ -388,7 +388,7 @@ static int vfio_intx_enable(VFIOPCIDevice *vdev

Re: [PATCH 14/16] target/arm: Implement ESB instruction

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:18, Richard Henderson
 wrote:
>
> Check for and defer any pending virtual SError.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper.h|  1 +
>  target/arm/a32.decode  | 16 +-
>  target/arm/t32.decode  | 18 +++
>  target/arm/op_helper.c | 45 ++
>  target/arm/translate-a64.c |  7 ++
>  target/arm/translate.c | 10 +
>  6 files changed, 82 insertions(+), 15 deletions(-)
>
> diff --git a/target/arm/helper.h b/target/arm/helper.h
> index b463d9343b..bb7f901668 100644
> --- a/target/arm/helper.h
> +++ b/target/arm/helper.h
> @@ -54,6 +54,7 @@ DEF_HELPER_1(wfe, void, env)
>  DEF_HELPER_1(yield, void, env)
>  DEF_HELPER_1(pre_hvc, void, env)
>  DEF_HELPER_2(pre_smc, void, env, i32)
> +DEF_HELPER_1(esb, void, env)
>
>  DEF_HELPER_3(cpsr_write, void, env, i32, i32)
>  DEF_HELPER_2(cpsr_write_eret, void, env, i32)
> diff --git a/target/arm/a32.decode b/target/arm/a32.decode
> index fcd8cd4f7d..f2ca480949 100644
> --- a/target/arm/a32.decode
> +++ b/target/arm/a32.decode
> @@ -187,13 +187,17 @@ SMULTT    0001 0110    1110 
>   @rd0mn
>
>  {
>{
> -YIELD 0011 0010     0001
> -WFE   0011 0010     0010
> -WFI   0011 0010     0011
> +[
> +  YIELD   0011 0010     0001
> +  WFE 0011 0010     0010
> +  WFI 0011 0010     0011
>
> -# TODO: Implement SEV, SEVL; may help SMP performance.
> -# SEV 0011 0010     0100
> -# SEVL    0011 0010     0101
> +  # TODO: Implement SEV, SEVL; may help SMP performance.
> +  # SEV   0011 0010     0100
> +  # SEVL  0011 0010     0101
> +
> +  ESB 0011 0010    0001 
> +]

Why don't we decode bits [11:8] here? I see it's the same
as YIELD/WFE/WFI, but I'm not sure why we're not decoding
those bits in those insns either...

>
>  # The canonical nop ends in , but the whole of the
>  # rest of the space executes as nop if otherwise unsupported.
> diff --git a/target/arm/t32.decode b/target/arm/t32.decode
> index 78fadef9d6..f21ad0167a 100644
> --- a/target/arm/t32.decode
> +++ b/target/arm/t32.decode
> @@ -364,17 +364,17 @@ CLZ   1010 1011    1000 
>   @rdm
>[
>  # Hints, and CPS
>  {
> -  YIELD   0011 1010  1000   0001
> -  WFE 0011 1010  1000   0010
> -  WFI 0011 1010  1000   0011
> +  [
> +YIELD 0011 1010  1000   0001
> +WFE   0011 1010  1000   0010
> +WFI   0011 1010  1000   0011
>
> -  # TODO: Implement SEV, SEVL; may help SMP performance.
> -  # SEV   0011 1010  1000   0100
> -  # SEVL  0011 1010  1000   0101
> +# TODO: Implement SEV, SEVL; may help SMP performance.
> +# SEV 0011 1010  1000   0100
> +# SEVL    0011 1010  1000   0101
>
> -  # For M-profile minimal-RAS ESB can be a NOP, which is the
> -  # default behaviour since it is in the hint space.
> -  # ESB   0011 1010  1000  0001 
> +ESB   0011 1010  1000  0001 
> +  ]
>
># The canonical nop ends in  , but the whole rest
># of the space is "reserved hint, behaves as nop".
> diff --git a/target/arm/op_helper.c b/target/arm/op_helper.c
> index 70b42b55fd..f50424b301 100644
> --- a/target/arm/op_helper.c
> +++ b/target/arm/op_helper.c
> @@ -972,3 +972,48 @@ void HELPER(probe_access)(CPUARMState *env, target_ulong 
> ptr,
>   access_type, mmu_idx, ra);
>  }
>  }
> +
> +void HELPER(esb)(CPUARMState *env)
> +{
> +/*
> + * QEMU does not have a source of physical SErrors, so we are
> + * only concerned with virtual SErrors.
> + *
> + * During translation, we have already checked: RAS enabled,
> + * EL2 present (enabled check done in arm_hcr_el2_eff), and
> + * PSTATE.EL in {EL0, EL1}.  This function corresponds to
> + * AArch64.vESBOperation(), noting that the AArch32 version
> + * is not functionally different.
> + */
> +uint64_t hcr = arm_hcr_el2_eff(env);
> +bool enabled = !(hcr & HCR_TGE) && (hcr & HCR_AMO);
> +bool pending = enabled && (hcr & HCR_VSE);
> +bool masked  = (env->daif & PSTATE_A);
> +
> +/* If VSE pending and masked, defer the exception.  */
> +if (pending && masked) {
> +uint32_t syndrome;
> +
> +if (arm_el_is_aa64(env, 1)) {
> +/* Copy across IDS and ISS from VSESR. */
> +

Re: [PATCH 13/16] target/arm: Implement virtual SError exceptions

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:11, Richard Henderson
 wrote:
>
> Virtual SError exceptions are raised by setting HCR_EL2.VSE,
> and are routed to EL1 just like other virtual exceptions.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu.h   |  2 ++
>  target/arm/internals.h |  8 
>  target/arm/syndrome.h  |  5 +
>  target/arm/cpu.c   | 38 +-
>  target/arm/helper.c| 29 -
>  5 files changed, 80 insertions(+), 2 deletions(-)

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH 12/16] target/arm: Enable SCR and HCR bits for RAS

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:11, Richard Henderson
 wrote:
>
> Enable writes to the TERR and TEA bits when RAS is enabled.
> These bits are otherwise RES0.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper.c | 9 +
>  1 file changed, 9 insertions(+)


Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH 11/16] target/arm: Add minimal RAS registers

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:14, Richard Henderson
 wrote:
>
> Add only the system registers required to implement zero error
> records.  This means we need to save state for ERRSELR, but all
> values are out of range, so none of the indexed error record
> registers need be implemented.
>
> Add the EL2 registers required for injecting virtual SError.
>
> Signed-off-by: Richard Henderson 

> +/*
> + * Minimal RAS implementation with no Error Records.
> + * Which means that all of the Error Record registers:
> + *   ERXADDR_EL1
> + *   ERXCTLR_EL1
> + *   ERXFR_EL1
> + *   ERXMISC0_EL1
> + *   ERXMISC1_EL1
> + *   ERXMISC2_EL1
> + *   ERXMISC3_EL1
> + *   ERXPFGCDN_EL1  (RASv1p1)
> + *   ERXPFGCTL_EL1  (RASv1p1)
> + *   ERXPFGF_EL1(RASv1p1)
> + *   ERXSTATUS_EL1
> + * may generate UNDEFINED, which is the effect we get by not
> + * listing them at all.
> + */
> +static const ARMCPRegInfo minimal_ras_reginfo_el1[] = {
> +{ .name = "DISR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 0xc, .crm = 1, .opc2 = 1,

".crn = 12", please -- no other reginfo struct uses hex here.
Similarly below.

> +  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.disr_el1),
> +  .readfn = disr_read, .writefn = disr_write, .raw_writefn = raw_write },
> +{ .name = "ERRIDR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 3, .opc2 = 0,
> +  .access = PL1_R, .accessfn = access_terr,
> +  .type = ARM_CP_CONST, .resetvalue = 0 },
> +{ .name = "ERRSELR_EL1", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 3, .opc2 = 1,
> +  .access = PL1_RW, .accessfn = access_terr,
> +  .fieldoffset = offsetof(CPUARMState, cp15.errselr_el1) },

By my reading of the spec we could make ERRSELR_EL1 RAZ/WI, because
writing an over-large number has a number of behaviours including
that the value the guest can read back is UNKNOWN. That would save
having the CPU state struct field.

> +REGINFO_SENTINEL
> +};
> +
> +static const ARMCPRegInfo minimal_ras_reginfo_el2[] = {
> +{ .name = "VDISR_EL2", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 4, .crn = 0xc, .crm = 1, .opc2 = 1,
> +  .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.vdisr_el2) 
> },
> +{ .name = "VSESR_EL2", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 2, .opc2 = 3,
> +  .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.vsesr_el2) 
> },
> +REGINFO_SENTINEL
> +};
> +
> +static const ARMCPRegInfo minimal_ras_reginfo_no_el2[] = {
> +{ .name = "VDISR_EL2", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 4, .crn = 0xc, .crm = 1, .opc2 = 1,
> +  .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
> +{ .name = "VSESR_EL2", .state = ARM_CP_STATE_BOTH,
> +  .opc0 = 3, .opc1 = 4, .crn = 5, .crm = 2, .opc2 = 3,
> +  .access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
> +REGINFO_SENTINEL
> +};
> +
>  /* Return the exception level to which exceptions should be taken
>   * via SVEAccessTrap.  If an exception should be routed through
>   * AArch64.AdvSIMDFPAccessTrap, return 0; fp_exception_el should
> @@ -8452,6 +8550,15 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>  define_one_arm_cp_reg(cpu, &ssbs_reginfo);
>  }
>
> +if (cpu_isar_feature(any_ras, cpu)) {
> +define_arm_cp_regs(cpu, minimal_ras_reginfo_el1);
> +if (arm_feature(env, ARM_FEATURE_EL2)) {
> +define_arm_cp_regs(cpu, minimal_ras_reginfo_el2);
> +} else {
> +define_arm_cp_regs(cpu, minimal_ras_reginfo_no_el2);
> +}
> +}
> +
>  if (cpu_isar_feature(aa64_vh, cpu) ||
>  cpu_isar_feature(aa64_debugv8p2, cpu)) {
>  if (arm_feature(env, ARM_FEATURE_EL2)) {
> --
> 2.25.1

Otherwise
Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH] contrib/vhost-user-blk: add missing GOptionEntry NULL terminator

2022-04-11 Thread Michael S. Tsirkin
On Mon, Apr 11, 2022 at 04:00:57PM +0100, Stefan Hajnoczi wrote:
> The GLib documentation says "a NULL-terminated array of GOptionEntrys"
> so we'd better make sure there is a terminator that lets
> g_option_context_add_main_entries() know when the end of the array has
> been reached.
> 
> Signed-off-by: Stefan Hajnoczi 

Reviewed-by: Michael S. Tsirkin 

feel free to merge

> ---
>  contrib/vhost-user-blk/vhost-user-blk.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/contrib/vhost-user-blk/vhost-user-blk.c 
> b/contrib/vhost-user-blk/vhost-user-blk.c
> index d14b2896bf..cd4a5d7335 100644
> --- a/contrib/vhost-user-blk/vhost-user-blk.c
> +++ b/contrib/vhost-user-blk/vhost-user-blk.c
> @@ -593,7 +593,8 @@ static GOptionEntry entries[] = {
>  {"blk-file", 'b', 0, G_OPTION_ARG_FILENAME, &opt_blk_file,
>   "block device or file path", "PATH"},
>  { "read-only", 'r', 0, G_OPTION_ARG_NONE, &opt_read_only,
> -  "Enable read-only", NULL }
> +  "Enable read-only", NULL },
> +{ NULL, },
>  };
>  
>  int main(int argc, char **argv)
> -- 
> 2.35.1




Re: [PATCH 03/16] target/arm: Update qemu-system-arm -cpu max to cortex-a57

2022-04-11 Thread Peter Maydell
On Sat, 9 Apr 2022 at 01:11, Richard Henderson
 wrote:
>
> Instead of starting with cortex-a15 and adding v8 features to
> a v7 cpu, begin with a v8 cpu stripped of its aarch64 features.
> This fixes the long-standing to-do where we only enabled v8
> features for user-only.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu_tcg.c | 134 ++-
>  1 file changed, 80 insertions(+), 54 deletions(-)
>
> diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
> index 13d0e9b195..43ac3e27fa 100644
> --- a/target/arm/cpu_tcg.c
> +++ b/target/arm/cpu_tcg.c
> @@ -938,71 +938,97 @@ static void arm_v7m_class_init(ObjectClass *oc, void 
> *data)
>  static void arm_max_initfn(Object *obj)
>  {
>  ARMCPU *cpu = ARM_CPU(obj);
> +uint32_t t;
>
> -cortex_a15_initfn(obj);
> +/* aarch64_a57_initfn, advertising none of the aarch64 features */
> +cpu->dtb_compatible = "arm,cortex-a57";
> +set_feature(&cpu->env, ARM_FEATURE_V8);
> +set_feature(&cpu->env, ARM_FEATURE_NEON);
> +set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
> +set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
> +set_feature(&cpu->env, ARM_FEATURE_EL2);
> +set_feature(&cpu->env, ARM_FEATURE_EL3);
> +set_feature(&cpu->env, ARM_FEATURE_PMU);
> +cpu->midr = 0x411fd070;

If we're going to claim in the MIDR that we're an A57 then we
should provide the A57's impdef sysregs, at least those of
them that are visible to AArch32. This may otherwise cause
problems if the guest OS tries to write to one of them as
part of some errata workaround.

thanks
-- PMM



RE: [PATCH v8 10/12] target/hexagon: import parser for idef-parser

2022-04-11 Thread Taylor Simpson



> -Original Message-
> From: Anton Johansson 
> Sent: Wednesday, February 9, 2022 11:03 AM
> To: qemu-devel@nongnu.org
> Cc: a...@rev.ng; Taylor Simpson ; Brian Cain
> ; Michael Lambert ;
> bab...@rev.ng; ni...@rev.ng; richard.hender...@linaro.org
> Subject: [PATCH v8 10/12] target/hexagon: import parser for idef-parser
> 
> Signed-off-by: Alessandro Di Federico 
> Signed-off-by: Paolo Montesel 
> Signed-off-by: Anton Johansson 


> diff --git a/target/hexagon/idef-parser/parser-helpers.c
> b/target/hexagon/idef-parser/parser-helpers.c
> new file mode 100644



> +void gen_set_overflow(Context *c, YYLTYPE *locp, HexValue *value)
> +{
> +HexValue value_m = *value;
> +
> +if (is_inside_ternary(c)) {
> +/* Inside ternary operator, need to take care of the side-effect */
> +HexValue cond = get_ternary_cond(c, locp);
> +HexValue zero = gen_constant(c, locp, "0", cond.bit_width,
> UNSIGNED);
> +bool is_64bit = cond.bit_width == 64;
> +unsigned bit_width = cond.bit_width;
> +value_m = rvalue_materialize(c, locp, &value_m);
> +if (is_64bit) {
> +value_m = gen_rvalue_extend(c, locp, &value_m);
> +}
> +OUT(c, locp, "tcg_gen_movcond_i", &bit_width,
> + "(TCG_COND_NE, ", &value_m, ", ", &cond);
> +OUT(c, locp, ", ", &zero, ", ", &value_m, ", ", &zero, ");\n");

You shouldn't write zero when the condition is false - you should do nothing.  
Try a test where OVF is already set.  You can't overwrite the bit with zero 
when the current instruction doesn't overflow.



> +if (is_64bit) {
> +value_m = gen_rvalue_truncate(c, locp, &value_m);
> +}
> +gen_rvalue_free(c, locp, &cond);
> +}
> +
> +OUT(c, locp, "SET_USR_FIELD(USR_OVF, ", &value_m, ");\n");
> +gen_rvalue_free(c, locp, &value_m);
> +}



Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK

2022-04-11 Thread Kirill A. Shutemov
On Thu, Apr 07, 2022 at 04:05:36PM +, Sean Christopherson wrote:
> Hmm, shmem_writepage() already handles SHM_F_INACCESSIBLE by rejecting the 
> swap, so
> maybe it's just the page migration path that needs to be updated?

My early version prevented migration with -ENOTSUPP for
address_space_operations::migratepage().

What's wrong with that approach?

-- 
 Kirill A. Shutemov



Re: [RFC] migration/dirtyrate: check malloc() return

2022-04-11 Thread Alex Bennée


Richard Henderson  writes:

> On 4/9/22 20:58, jianchunfu wrote:
>> Handling potential memory allocation failures in dirtyrate.
>> Signed-off-by: jianchunfu 
>> ---
>>   migration/dirtyrate.c | 8 
>>   1 file changed, 8 insertions(+)
>> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
>> index aace12a787..5dd40f32c8 100644
>> --- a/migration/dirtyrate.c
>> +++ b/migration/dirtyrate.c
>> @@ -523,9 +523,17 @@ static void calculate_dirtyrate_dirty_ring(struct 
>> DirtyRateConfig config)
>>   }
>> dirty_pages = malloc(sizeof(*dirty_pages) * nvcpu);
>> +if (!dirty_pages) {
>> +error_report("malloc dirty pages for vcpus failed.");
>> +exit(1);
>> +}
>> DirtyStat.dirty_ring.nvcpu = nvcpu;
>>   DirtyStat.dirty_ring.rates = malloc(sizeof(DirtyRateVcpu) * nvcpu);
>> +if (!DirtyStat.dirty_ring.rates) {
>> +error_report("malloc dirty rates for vcpu ring failed.");
>> +exit(1);
>> +}
>
> You might as well use g_new(), which handles the sizeof and
> multiplication, and error reporting.

It will also assert if the alloc fails. If this is an allocation QEMU
can recover from then you need to use the try_new variants of the
g_malloc/new functions. However here we are exiting so no actual check
is needed as the g_malloc will exit for us.

-- 
Alex Bennée



Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK

2022-04-11 Thread Kirill A. Shutemov
On Fri, Apr 08, 2022 at 09:02:54PM +0800, Chao Peng wrote:
> > I think the correct approach is to not do the locking automatically for 
> > SHM_F_INACCESSIBLE,
> > and instead require userspace to do shmctl(.., SHM_LOCK, ...) if userspace 
> > knows the
> > consumers don't support migrate/swap.  That'd require wrapping 
> > migrate_page() and then
> > wiring up notifier hooks for migrate/swap, but IMO that's a good thing to 
> > get sorted
> > out sooner than later.  KVM isn't planning on support migrate/swap for TDX 
> > or SNP,
> > but supporting at least migrate for a software-only implementation a la 
> > pKVM should
> > be relatively straightforward.  On the notifiee side, KVM can terminate the 
> > VM if it
> > gets an unexpected migrate/swap, e.g. so that TDX/SEV VMs don't die later 
> > with
> > exceptions and/or data corruption (pre-SNP SEV guests) in the guest.
> 
> SHM_LOCK sounds like a good match.

Emm, no. shmctl(2) and SHM_LOCK are SysV IPC thing. I don't see how they
fit here.

-- 
 Kirill A. Shutemov



Re: [PATCH v5 01/13] mm/memfd: Introduce MFD_INACCESSIBLE flag

2022-04-11 Thread Kirill A. Shutemov
On Thu, Mar 10, 2022 at 10:08:59PM +0800, Chao Peng wrote:
> From: "Kirill A. Shutemov" 
> 
> Introduce a new memfd_create() flag indicating the content of the
> created memfd is inaccessible from userspace through ordinary MMU
> access (e.g., read/write/mmap). However, the file content can be
> accessed via a different mechanism (e.g. KVM MMU) indirectly.
> 
> It provides semantics required for KVM guest private memory support
> that a file descriptor with this flag set is going to be used as the
> source of guest memory in confidential computing environments such
> as Intel TDX/AMD SEV but may not be accessible from host userspace.
> 
> Since page migration/swapping is not yet supported for such usages
> so these pages are currently marked as UNMOVABLE and UNEVICTABLE
> which makes them behave like long-term pinned pages.
> 
> The flag can not coexist with MFD_ALLOW_SEALING, future sealing is
> also impossible for a memfd created with this flag.
> 
> At this time only shmem implements this flag.
> 
> Signed-off-by: Kirill A. Shutemov 
> Signed-off-by: Chao Peng 
> ---
>  include/linux/shmem_fs.h   |  7 +
>  include/uapi/linux/memfd.h |  1 +
>  mm/memfd.c | 26 +++--
>  mm/shmem.c | 57 ++
>  4 files changed, 88 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index e65b80ed09e7..2dde843f28ef 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -12,6 +12,9 @@
>  
>  /* inode in-kernel data */
>  
> +/* shmem extended flags */
> +#define SHM_F_INACCESSIBLE   0x0001  /* prevent ordinary MMU access (e.g. 
> read/write/mmap) to file content */
> +
>  struct shmem_inode_info {
>   spinlock_t  lock;
>   unsigned intseals;  /* shmem seals */
> @@ -24,6 +27,7 @@ struct shmem_inode_info {
>   struct shared_policypolicy; /* NUMA memory alloc policy */
>   struct simple_xattrsxattrs; /* list of xattrs */
>   atomic_tstop_eviction;  /* hold when working on inode */
> + unsigned intxflags; /* shmem extended flags */
>   struct inodevfs_inode;
>  };
>  

AFAICS, only two bits of 'flags' are used. And that's very strange that
VM_ flags are used for the purpose. My guess that someone was lazy to
introduce new constants for this.

I think we should fix this: introduce SHM_F_LOCKED and SHM_F_NORESERVE
alongside with SHM_F_INACCESSIBLE and stuff them all into info->flags.
It also makes shmem_file_setup_xflags() go away.

-- 
 Kirill A. Shutemov



Re: [PATCH v5 03/13] mm/shmem: Support memfile_notifier

2022-04-11 Thread Kirill A. Shutemov
On Thu, Mar 10, 2022 at 10:09:01PM +0800, Chao Peng wrote:
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 9b31a7056009..7b43e274c9a2 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -903,6 +903,28 @@ static struct folio *shmem_get_partial_folio(struct 
> inode *inode, pgoff_t index)
>   return page ? page_folio(page) : NULL;
>  }
>  
> +static void notify_fallocate(struct inode *inode, pgoff_t start, pgoff_t end)
> +{
> +#ifdef CONFIG_MEMFILE_NOTIFIER
> + struct shmem_inode_info *info = SHMEM_I(inode);
> +
> + memfile_notifier_fallocate(&info->memfile_notifiers, start, end);
> +#endif

All these #ifdefs look ugly. Could you provide dummy memfile_* for
!MEMFILE_NOTIFIER case?

-- 
 Kirill A. Shutemov



  1   2   >