Hi Meysam, I hope you have had a good week, similar greetings to everyone else on the forum as well.
The notion of a 'volatile' variable arguably doesn't have much relevance in modern C/C++ code and would have even less so in the context of an argument to an ECALL. Understanding why requires a bit of explanation as to what the edger8r utility that processes the EDL definitions and generates interface code actually does.
Under the hood the ECALL entry code only handles a single argument. As a result, the edger8r code marshals the arguments to an ECALL function in untrusted space into a structure. A pointer to that structure is passed into the ECALL interface code that then passes the marshaled arguments as arguments to a function that runs in enclave context (trusted space).
In the case of pointers the generated interface code does things like create deep copies of a referenced memory region into memory that is allocated in enclave context. In addition the generated interface code verifies that memory regions are in the appropriate context,trusted vs. untrusted space, and conducts fencing operations after pointer dereferences in order to thwart side channel attacks.
The 'volatile' keyword implies to the compiler that the value of a variable may change asynchronously with respect to actions by the compiler. The classic example would be a memory location that is updated by a hardware device. The 'volatile' keyword is designed to act as a hint to the compiler that it should reload the value from memory every time it is referenced.
This isn't to say that the concept of a 'volatile' memory location wouldn't have relevance inside of an enclave. Code running in enclave context has the ability to access untrusted memory. so code running in this context could repeatedly poll a memory location to capture changing values, but there is no support for this in the current ECALL interface architecture.
If you have a need for this type of architecture we would recommend that you look at the 'switchless' sample code that comes with the Intel SDK. In this model there is a 'producer' thread that runs in standard userspace and produces data for consumption by a 'consumer' thread running in enclave context. The rationale for this architecture is to avoid the latency costs associated with trusted<->untrusted execution domain transitions.
You would need to implement a guarantee that the producer thread would reference the contents of a memory location with volatile semantics and make the contents of that location available to the consumer thread. This model requires that the 'consumer' thread running in enclave context do so in essentially a tight loop which may or may not have implications with respect to your architecture and performance load requirements.
Hopefully all of this helpful information. What you are desiring to do may make sense and is doable but is going to require writing some code rather then simply applying a 'volatile' attribute to a function argument.
Good luck with your project and best wishes for a pleasant weekend.