qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mostafa Saleh <smostafa@google.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: eric.auger@redhat.com, qemu-devel@nongnu.org,
	jean-philippe@linaro.org, qemu-arm@nongnu.org,
	richard.henderson@linaro.org
Subject: Re: [RFC PATCH v2 10/11] hw/arm/smmuv3: Populate OAS based on CPU PARANGE
Date: Tue, 21 Mar 2023 13:42:56 +0000	[thread overview]
Message-ID: <ZBm0YP1Mh0XCItYY@google.com> (raw)
In-Reply-To: <CAFEAcA_NZiby7=DWaDBu7b5Dbo5sXF9N7T-0_wskZ46FR9Esxw@mail.gmail.com>

Hi Peter,

On Tue, Mar 21, 2023 at 01:34:55PM +0000, Peter Maydell wrote:
> > >>> +    s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, oas);
> > >> I am not sure you can change that easily. In case of migration this is
> > >> going to change the behavior of the device, no?
> > > I see IDR registers are not migrated. I guess we can add them in a
> > > subsection and if they were not passed (old instances) we set OAS to
> > > 44.
> > > Maybe this should be another change outside of this series.
> > Indeed tehy are not migrated so it can lead to inconsistent behavior in
> > both source and dest. This deserves more analysis to me. In case you
> > would decide to migrate IDR regs this would need to be done in that
> > series I think. Migration must not be broken by this series.
> 
> Jumping in here without having read much of the context, but why
> would we need to migrate the ID registers? They are constant, read-only,
> so they will be the same value on both source and destination.

Currently OAS for SMMU is hardcoded to 44 bits, and the SMMU manual says
"OAS reflects the maximum usable PA output from the last stage of
AArch64 translations, and must match the system physical address size.
The OAS is discoverable from SMMU_IDR5.OAS."
This patch implements OAS based on CPU PARANGE, but this would break
migration from old instances that ran with 44 bits OAS to new code that
configures it based on the current CPU.
So one idea is to migrate the IDRs (or atleast IDR5).
Maybe that is not the best solution, we just need a way to know if the
old instance needs to be 44 bits or not.


Thanks,
Mostafa


  reply	other threads:[~2023-03-21 13:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-26 22:06 [RFC PATCH v2 00/11] Add stage-2 translation for SMMUv3 Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 01/11] hw/arm/smmuv3: Add missing fields for IDR0 Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 02/11] hw/arm/smmuv3: Update translation config to hold stage-2 Mostafa Saleh
2023-03-17 11:37   ` Eric Auger
2023-03-17 14:43     ` Mostafa Saleh
2023-03-17 17:36       ` Eric Auger
2023-02-26 22:06 ` [RFC PATCH v2 03/11] hw/arm/smmuv3: Refactor stage-1 PTW Mostafa Saleh
2023-03-17 18:31   ` Eric Auger
2023-03-19  8:38     ` Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 04/11] hw/arm/smmuv3: Add page table walk for stage-2 Mostafa Saleh
2023-03-20 14:56   ` Eric Auger
2023-03-20 18:52     ` Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 05/11] hw/arm/smmuv3: Parse STE config " Mostafa Saleh
2023-03-20 15:14   ` Eric Auger
2023-03-20 19:11     ` Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 06/11] hw/arm/smmuv3: Make TLB lookup work " Mostafa Saleh
2023-03-20 16:05   ` Eric Auger
2023-03-20 19:14     ` Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 07/11] hw/arm/smmuv3: Add VMID to tlb tagging Mostafa Saleh
2023-03-20 16:16   ` Eric Auger
2023-02-26 22:06 ` [RFC PATCH v2 08/11] hw/arm/smmuv3: Add CMDs related to stage-2 Mostafa Saleh
2023-03-20 16:51   ` Eric Auger
2023-03-20 19:29     ` Mostafa Saleh
2023-02-26 22:06 ` [RFC PATCH v2 09/11] hw/arm/smmuv3: Add stage-2 support in iova notifier Mostafa Saleh
2023-03-20 16:57   ` Eric Auger
2023-02-26 22:06 ` [RFC PATCH v2 10/11] hw/arm/smmuv3: Populate OAS based on CPU PARANGE Mostafa Saleh
2023-03-20 17:12   ` Eric Auger
2023-03-21 13:06     ` Mostafa Saleh
2023-03-21 13:23       ` Eric Auger
2023-03-21 13:29         ` Mostafa Saleh
2023-03-21 13:34           ` Eric Auger
2023-03-21 13:34         ` Peter Maydell
2023-03-21 13:42           ` Mostafa Saleh [this message]
2023-03-21 13:45           ` Eric Auger
2023-03-21 13:54           ` Mostafa Saleh
2023-03-21 14:08             ` Peter Maydell
2023-02-26 22:06 ` [RFC PATCH v2 11/11] hw/arm/smmuv3: Add knob to choose translation stage and enable stage-2 Mostafa Saleh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZBm0YP1Mh0XCItYY@google.com \
    --to=smostafa@google.com \
    --cc=eric.auger@redhat.com \
    --cc=jean-philippe@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).