[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 5/8] xen/arm: platforms: Add NXP S32CC platform code



Hi,

On 08/10/2024 20:01, Andrei Cherechesu wrote:
Hi Julien,

On 04/10/2024 19:24, Julien Grall wrote:


On 04/10/2024 16:37, Andrei Cherechesu wrote:
Hi Julien, Stefano,

Hi Andrei,


On 01/10/2024 13:01, Julien Grall wrote:
Hi Andrei,

On 30/09/2024 12:47, Andrei Cherechesu (OSS) wrote:
From: Andrei Cherechesu <andrei.cherechesu@xxxxxxx>

Add code for NXP S32CC platforms (S32G2, S32G3, S32R45).

S32CC platforms use the NXP LINFlexD UART driver for
console by default, and rely on Dom0 having access to
SCMI services for system-level resources from firmware
at EL3.

Platform-related quirks will be addressed in following
commits.

I don't see any specific quirks in the series. Are you intended to send 
follow-up?

[...]

Well, we could use an opinion on some SoC erratum implementation
and if it would be acceptable for you or not, from any of
the ARM maintainers.

The erratum is about some TLB Invalidate (tlbi) instruction
variants (by Virtual Address) which are handled incorrectly
in some cases (for some VAs), and that need to be replaced
with broader versions.

Can you provide more details:
   1. Is this a processor issue?
   2. Which VAs are affected?
   3. What is the impact if the erratum is hit?
   3. Do we need to do anything on the behalf of the guests?

Sure:
1. This is an SoC issue, present in a subset of the S32CC processors family.
2. VAs whose bits [48:41] are not all zero.
3. Well, TLB corruption.

Can you provide a bit more details? Is it a corruption within the same stage/ASID/VMID? IOW if a guest corrupt the TLB, does this mean only the stage-1?

Also, if a guest manage to corrupt its TLB, does this mean it could end up to access host physical address it should not?

BTW, do you have any more documentation about the erratum?

4. There are instructions affected at both levels 1 and 2 of translation.
The guest will have to work its own way around it.

In Xen, just `tlbi vae2is` (only used in flush_xen_tlb_range_va()) seems to
be affected, and if we go with the 2nd approach from the ones proposed,
it should not be very ugly to implement. I am of course open to any of your
suggestions.



It doesn't apply for all S32CC platforms, but we can use the
Host DT compatible to identify this. My idea is that we define
a platform quirk for this and check for it using
platform_has_quirk().
Then, we either:>      - modify the definition for the affected 'tlbi' variant
      in arm64/flushtlb.h to actually execute the broader one
      if needed
or:
      - define a new wrapper for the tlbi variant we want to
      replace the affected one with
      - check for this quirk before its usage and call the
      more potent version if needed (there's only one
      occurrence of usage for the affected version).

Number 2 seems better to me, it's more customizable and
it's similar to the existing handling for
PLATFORM_QUIRK_GIC_64K_STRIDE for some other Arm platform.

I need a bit more details first (see my questions above). But if there are not 
many VAs affected, then we may be able to re-order the Xen memory layout to 
avoid the VAs. So we wouldn't need any specific change in the TLB flush 
operations.

I'm not sure what to say here, we would need to have the layout
limited under the mentioned VA range in our case, right?

Correct. Is your SoC going to ever have more than a couple of TBs of memory?

What
about the GVA layout?

That's control by the guest. We could potentially tell the guest less VA is supported, but it is free to ignore.

Can you clarify why we would need to care about the GVA layout?

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.