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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).