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. HTH, Gerd
