Re: [XEN v2] xen/arm64: io: Decode 32-bit ldr/str post-indexing instructions

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.12.2021 12:58, Andre Przywara wrote:
> On Tue, 30 Nov 2021 19:13:41 +0000
> Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> wrote:
>> On 30/11/2021 09:49, Andre Przywara wrote:
>>> On Mon, 29 Nov 2021 19:16:38 +0000
>>> Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> wrote:
>>>> At the moment, Xen is only handling data abort with valid syndrome (i.e.
>>>> ISV=0). Unfortunately, this doesn't cover all the instructions a domain
>>>> could use to access MMIO regions.
>>>>
>>>> For instance, Xilinx baremetal OS will use:
>>>>
>>>>          volatile u32 *LocalAddr = (volatile u32 *)Addr;
>>>>          *LocalAddr = Value;
>>>>
>>>> This leave the compiler to decide which store instructions to use.  
>>>
>>> As mentioned in the other email, this is wrong, if this points to MMIO:
>>> don't let the compiler do MMIO accesses. If a stage 2 fault isn't in
>>> an MMIO area, you should not see traps that you cannot handle already.
>>>
>>> So I don't think it's a good idea to use that as an example. And since
>>> this patch only seems to address this use case, I would doubt its
>>> usefulness in general.  
>> Yes, I should have fixed the comment.
>>
>> Currently, I am testing with baremetal app which uses inline assembly 
>> code with post indexing instructions, to access the MMIO.
>>
>> ATM, I am testing with 32 bit MMIO only.
>>
>> On the usefulness, I am kind of torn as it is legitimate for post 
>> indexing instructions to be used in an inline-assembly code for 
>> accessing MMIO. However, that may not be something commonly seen.
> 
> It is legitimate, but I question the usefulness: for a start it wouldn't
> work under today's Xen (or KVM), and I doubt this would be backported. So
> you would always require users to use the newest version of the hypervisor.
> Also MMIO accesses are slow anyway, so while using post-indexing might be
> convenient from an assembly writer's point of view, it doesn't give you
> much performance-wise, probably.

Just so it gets mentioned: Smaller code size may also be a consideration
here, beyond the more general one about performance.

Jan