Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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