On 5/24/2022 4:29 PM, Gerd Hoffmann wrote:
On Tue, May 24, 2022 at 04:11:56PM +0800, Xiaoyao Li wrote:
On 5/24/2022 2:59 PM, Gerd Hoffmann wrote:
On Tue, May 24, 2022 at 12:19:51PM +0800, Xiaoyao Li wrote:
On 5/23/2022 5:39 PM, Gerd Hoffmann wrote:
So, how is this supposed to work? Patch #2 introduces attributes as
user-settable property. So do users have to manually figure and pass
the correct value, so the check passes? Specifically the fixed1 check?
I think 'attributes' should not be user-settable in the first place.
Each feature-bit which is actually user-settable (and not already
covered by another option like pmu) should be a separate attribute for
tdx-object. Then the tdx code can create attributes from hardware
capabilities and user settings.
In patch #2, tdx-guest.attributes is defined as a field to hold a 64 bits
value of attributes but it doesn't provide any getter/setter for it. So it's
*not* user-settable.
Ok. Why it is declared as object property in the first place then?
Is there another way to define a member/field of object besides property?
Well, the C object struct is completely independent from the qapi
struct. Typically qapi-generated structs are added as struct fields.
Look at ui/input-linux.c for example.
struct InputLinux holds all the object state. It has a GrabToggleKeys
field, that is a qapi-generated enum (see qapi/common.json) and is
user-configurable (there are getter and setter for it).
So, you can have a private 'attributes' struct field in your tdx class,
but the field doesn't have to be in the qapi struct for that.
I see. Thanks for the explanation!
I will remove the qom property definition in patch 2.
HTH,
Gerd
