From: Zhao Liu <zhao1.liu@intel.com>
To: Xin Li <xin@zytor.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH v1 2/3] target/i386: Add VMX control bits for nested FRED support
Date: Fri, 9 Aug 2024 17:02:34 +0800 [thread overview]
Message-ID: <ZrXbKsfe0LnZdA9V@intel.com> (raw)
In-Reply-To: <f4ece0e8-b2b3-4178-b281-6ba9cc9cab8a@zytor.com>
On Thu, Aug 08, 2024 at 11:38:11PM -0700, Xin Li wrote:
> Date: Thu, 8 Aug 2024 23:38:11 -0700
> From: Xin Li <xin@zytor.com>
> Subject: Re: [PATCH v1 2/3] target/i386: Add VMX control bits for nested
> FRED support
>
> > > > > @@ -1450,7 +1450,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
> > > > > NULL, "vmx-entry-ia32e-mode", NULL, NULL,
> > > > > NULL, "vmx-entry-load-perf-global-ctrl", "vmx-entry-load-pat", "vmx-entry-load-efer",
> > > > > "vmx-entry-load-bndcfgs", NULL, "vmx-entry-load-rtit-ctl", NULL,
> > > > > - NULL, NULL, "vmx-entry-load-pkrs", NULL,
> > > > > + NULL, NULL, "vmx-entry-load-pkrs", "vmx-entry-load-fred",
> > > >
> > > > Should we also define VMX_VM_ENTRY_LOAD_FRED? "vmx-entry-load-rtit-ctl"
> > > > and "vmx-entry-load-pkrs" have their corresponding bit definitions, even
> > > > if they are not used.
> > >
> > > I'm not sure, but why add something that is not being used (thus not
> > > tested)?
> >
> > Yes, the use of macros is a factor. My another consideration is the
> > integrity of the feature definitions. When the such feature definitions
> > were first introduced in commit 704798add83b (”target/i386: add VMX
> > definitions”), I understand thay were mainly used to enumerate and
> > reflect hardware support and not all defs are used directly.
> >
> > The feat word name and the feature definition should essentially be
> > bound, and it might be possible to generate the feature definition
> > from the feat word via some script without having to add it manually,
> > but right now there is no work on this, and no additional constraints,
> > so we have to manually add and manually check it to make sure that the
> > two correspond to each other. When a feature word is added, it means
> > that Host supports the corresponding feature, and from an integrity
> > perspective, so it is natural to continue adding definition (just like
> > the commit 52a44ad2b92b ("target/i386: Expose VMX entry/exit load pkrs
> > control bits")), right?
> >
> > Though I found that there are still some mismatches between the feature
> > word and the corresponding definition, but ideally they should coexist.
> >
> > About the test, if it's just enumerated and not added to a specific CPU
> > model or involved by other logic, it's harmless?
>
> Unless tests are ready, such code are literally dead code, and could get
> broken w/o being noticed for a long time.
>
> I think we should add it only when tests are also added. Otherwise we added
> burden to maintainers, hoping test will be added soon, which often
> never happen.
It makes sense and can reduce the burden on maintainers. Now I totally
agree with you.
Thanks,
Zhao
next prev parent reply other threads:[~2024-08-09 8:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 8:18 [PATCH v1 0/3] target/i386: Add nested FRED support Xin Li (Intel)
2024-08-07 8:18 ` [PATCH v1 1/3] target/i386: Delete duplicated macro definition CR4_FRED_MASK Xin Li (Intel)
2024-08-07 14:32 ` Zhao Liu
2024-08-07 8:18 ` [PATCH v1 2/3] target/i386: Add VMX control bits for nested FRED support Xin Li (Intel)
2024-08-07 15:58 ` Zhao Liu
2024-08-08 7:04 ` Xin Li
2024-08-08 9:40 ` Zhao Liu
2024-08-09 6:38 ` Xin Li
2024-08-09 9:02 ` Zhao Liu [this message]
2024-08-07 8:18 ` [PATCH v1 3/3] target/i386: Raise the highest index value used for any VMCS encoding Xin Li (Intel)
2024-08-07 15:39 ` Zhao Liu
2024-08-09 6:27 ` Xin Li
2024-08-09 7:38 ` Xin Li
2024-08-09 9:01 ` Zhao Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZrXbKsfe0LnZdA9V@intel.com \
--to=zhao1.liu@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=xin@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.