Reg. guest unaligned accesses in TCG

Reg. guest unaligned accesses in TCG

[Pranith Kumar]

Hi Richard and Alex,

I am trying to implement efficient x86 guest on ARM64 host
virtualization where the host has FEAT_LRCPC2 instructions. If I
translate every x86 load to LDAPR and every x86 store to STLR, it will
meet the memory consistency requirements.

The necessary condition for using these RCpc instructions is the
alignment. The manual states that alignment fault will be raised if:

* Not all bytes of the memory access lie within a 16-byte quantity
aligned to 16 bytes, and
* The value of SCTLR_ELx.nAA applicable to the current Exception level is 0.

How does TCG check for alignment? How do I check if the guest memory
access is within the 16-byte alignment? Will alignment fault be raised
if it is not?

Any pointers are greatly appreciated!

Thank you,
-- 
Pranith

Re: Reg. guest unaligned accesses in TCG

[Mohamed Mediouni]

> On 4. Oct 2025, at 08:34, Pranith Kumar <bobby.prani@gmail.com> wrote:
> 
> Hi Richard and Alex,
> 
> I am trying to implement efficient x86 guest on ARM64 host
> virtualization where the host has FEAT_LRCPC2 instructions. If I
> translate every x86 load to LDAPR and every x86 store to STLR, it will
> meet the memory consistency requirements.
Hello,

If you’re targeting Apple chips, note that RCpc is really slow on those
as they expect you to use the hardware TSO mode instead.

But to get TSO mode on those you’ll need to use HVF…
> The necessary condition for using these RCpc instructions is the
> alignment. The manual states that alignment fault will be raised if:
> 
> * Not all bytes of the memory access lie within a 16-byte quantity
> aligned to 16 bytes, and
> * The value of SCTLR_ELx.nAA applicable to the current Exception level is 0.
> 
> How does TCG check for alignment? How do I check if the guest memory
> access is within the 16-byte alignment? Will alignment fault be raised
> if it is not?
The hardware will raise an alignment fault in that case. Other emulators
then do backpatching to a barrier-reliant sequence in that case.

> Any pointers are greatly appreciated!
> 
> Thank you,
> -- 
> Pranith
> 

Re: Reg. guest unaligned accesses in TCG

[Pranith Kumar]

Hi Mohamed,

On Sat, Oct 4, 2025 at 12:22 AM Mohamed Mediouni
<mohamed@unpredictable.fr> wrote:
>

> Hello,
>
> If you’re targeting Apple chips, note that RCpc is really slow on those
> as they expect you to use the hardware TSO mode instead.
>
> But to get TSO mode on those you’ll need to use HVF…

It is for general ARMv8.4+ CPUs where there is no TSO mode. Hence why
I am planning to use the RCpc instructions.


> > How does TCG check for alignment? How do I check if the guest memory
> > access is within the 16-byte alignment? Will alignment fault be raised
> > if it is not?
> The hardware will raise an alignment fault in that case. Other emulators
> then do backpatching to a barrier-reliant sequence in that case.

Do we have to add support in QEMU to handle this alignment fault? I
recall there being alignment checks for loads/stores but I wasn't
quite sure.

Thanks,
-- 
Pranith

Re: Reg. guest unaligned accesses in TCG

[Richard Henderson]

On 10/3/25 23:34, Pranith Kumar wrote:
> Hi Richard and Alex,
> 
> I am trying to implement efficient x86 guest on ARM64 host
> virtualization where the host has FEAT_LRCPC2 instructions. If I
> translate every x86 load to LDAPR and every x86 store to STLR, it will
> meet the memory consistency requirements.
> 
> The necessary condition for using these RCpc instructions is the
> alignment. The manual states that alignment fault will be raised if:
> 
> * Not all bytes of the memory access lie within a 16-byte quantity
> aligned to 16 bytes, and
> * The value of SCTLR_ELx.nAA applicable to the current Exception level is 0.
> 
> How does TCG check for alignment? How do I check if the guest memory
> access is within the 16-byte alignment? Will alignment fault be raised
> if it is not?

See prepare_host_addr in tcg/aarch64/tcg-target.c.inc.

a_mask is the alignment required by the guest, s_mask is the access size, so a_mask >= 
s_mask is required to be at least naturally aligned.

That's only enough to get you to the slow path for page crossings or guest misalignment. 
For additional host alignment along the fast path, you'd need to generate additional 
branches, and probably not here.

I'll warn you that I tried this once, and the extra work proving alignment overwhelmed the 
savings from substituting acquire/release for separate memory barriers.  I'd love for you 
to succeed, but this won't be a trivial task.


r~