AIESW-28045 : Add internal hw ctx function to get QoS

[rbramand-xilinx]

Problem solved by the commit

Added internal hw ctx function to get QoS. This function will be used by XDP to check QoS of a ctx and apply changes.

Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered

How problem was solved, alternative solutions (if any) and why they were rejected

Returning the QoS map from hw ctx using hw_context_int function

Risks (if any) associated the changes in the commit

Low

What has been tested and how, request additional testing if necessary

Documentation impact (if any)

NA

[Copilot]

Pull request overview

Adds an internal helper to retrieve a hardware context’s QoS/config parameter map for internal consumers (notably XDP) to inspect the context configuration.

Changes:

• Added hw_context_impl::get_qos_map() to return the context’s QoS/config map.
• Exposed xrt_core::hw_context_int::get_qos_map(const xrt::hw_context&) in the internal header and implemented it in xrt_hw_context.cpp.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/runtime_src/core/common/api/xrt_hw_context.cpp	Implements hw_context_impl::get_qos_map() and the xrt_core::hw_context_int::get_qos_map() wrapper.
src/runtime_src/core/common/api/hw_context_int.h	Declares the new internal exported get_qos_map() API for XDP/internal use.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

get_qos_map() returns m_cfg_param, but hw_context_impl::update_qos() only forwards to m_hdl->update_qos() and never updates m_cfg_param. That means callers of xrt_core::hw_context_int::get_qos_map() may observe stale QoS/config values after update_qos() is used. Consider making m_cfg_param the source of truth by updating it in update_qos() (and only calling into m_hdl if it exists), and protect reads/writes with a mutex similar to get_elf_map() to avoid data races once updates are supported.

Suggested change

	{
	{
	std::lock_guard lk(m_mutex);

[stsoe]

The lock make sense if there is also a lock on modification of the map.

[rbramand-xilinx]

Added lock when updating and getting QoS map, please review

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Comment says "updation" (non-idiomatic/incorrect here). Consider changing to "update" (e.g., "if update call to shim succeeded").

Suggested change

	// Store updated QoS if updation call to shim succeeded
	// Store updated QoS if update call to shim succeeded

[Copilot]

m_mutex is now used to protect both m_elf_map and m_cfg_param (via update_qos() / get_qos_map()), but the member comment still says it's only for the elf map. Consider updating the comment (or renaming the mutex) so future changes don't accidentally bypass the intended synchronization.