Hey Michal,
On 12/18/24 06:04, Michal Orzel wrote:
Hi Daniel,
On 18/12/2024 02:17, Daniel P. Smith wrote:
On 17/12/2024 11:47, Sergiy Kibrik wrote:
Allow to build ARM configuration with support for initializing
hardware domain.
On ARM it is only possible to start hardware domain in multiboot mode, so
dom0less support is required. This is reflected by dependency on
DOM0LESS_BOOT
instead of directly depending on ARM config option.
Just to make sure my assumption is correct, you are looking to do a
multi-domain construction at boot time, with at least two domains. One
of those two domains is the "control domain" and one is the "hardware
domain", aka late hwdom except it's not constructed "late".
If you want such a configuration, I would highly recommend you first
enable setting flask labels via dom0less (assuming it is not there)
Speaking about dom0less and FLASK. A year ago, I did sent you (privately,
through
AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK
policy
for dom0less domUs. You then told me that you have a slightly different vision
on how it
should be done. Any update with that regard? TBH I though that you're going to
add this
support together with other hyperlaunch patches.
As I mentioned back in my March response, the concern I have with the
patch you provided was with the layering violation. A security label is
a flask-centric concept, at least currently, and thus not a concept you
want to expose in the general XSM api. The correct way to get an XSM
module's specific info, or translation, is to use the xsm_do_xsm_op(). I
do feel that xsm_do_xsm_op() has a laying violation in its
implementation, and is what I want to fix, it is still the correct
interface. Priorities in meeting the core requirements AMD needs from
hyperlaunch resulted in several abilities to fall to the wayside for the
time being. I understand things need to move along, so I would prefer
the use of existing interface that can be just updated when
xsm_do_xsm_op() does get fixed up.
v/r,
dps
