From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Xen-devel" <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH for 4.19 v4 01/10] tools/hvmloader: Fix non-deterministic cpuid()
Date: Wed, 26 Jun 2024 17:52:59 +0100 [thread overview]
Message-ID: <D2A3SPBBBYCT.CYFCF8WCBM10@cloud.com> (raw)
In-Reply-To: <7ecf1b46-c1c2-42b5-b3cb-ab737ab67900@citrix.com>
On Wed Jun 26, 2024 at 5:43 PM BST, Andrew Cooper wrote:
> On 26/06/2024 5:28 pm, Alejandro Vallejo wrote:
> > hvmloader's cpuid() implementation deviates from Xen's in that the value passed
> > on ecx is unspecified. This means that when used on leaves that implement
> > subleaves it's unspecified which one you get; though it's more than likely an
> > invalid one.
> >
> > Import Xen's implementation so there are no surprises.
>
> Fixes: 318ac791f9f9 ("Add utilities needed for SMBIOS generation to
> hvmloader")
>
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> >
> >
> > diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> > index deb823a892ef..3ad7c4f6d6a2 100644
> > --- a/tools/firmware/hvmloader/util.h
> > +++ b/tools/firmware/hvmloader/util.h
> > @@ -184,9 +184,30 @@ int uart_exists(uint16_t uart_base);
> > int lpt_exists(uint16_t lpt_base);
> > int hpet_exists(unsigned long hpet_base);
> >
> > -/* Do cpuid instruction, with operation 'idx' */
> > -void cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx,
> > - uint32_t *ecx, uint32_t *edx);
> > +/* Some CPUID calls want 'count' to be placed in ecx */
> > +static inline void cpuid_count(
> > + uint32_t op,
> > + uint32_t count,
> > + uint32_t *eax,
> > + uint32_t *ebx,
> > + uint32_t *ecx,
> > + uint32_t *edx)
> > +{
> > + asm volatile ( "cpuid"
> > + : "=a" (*eax), "=b" (*ebx), "=c" (*ecx), "=d" (*edx)
> > + : "0" (op), "c" (count) );
>
> "a" to be consistent with "c".
>
> Also it would be better to name the parameters as leaf and subleaf.
>
> Both can be fixed on commit. However, there's no use in HVMLoader
> tickling this bug right now, so I'm not sure we want to rush this into
> 4.19 at this point.
>
> ~Andrew
All sound good to me. For the record, the static inlines are copied verbatim
from Xen so if you'd like these adjusted you probably also want to make a
postit to change Xen's too.
Cheers,
Alejandro
next prev parent reply other threads:[~2024-06-26 16:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 16:28 [PATCH for-4.19 v4 00/10] x86: Expose consistent topology to guests Alejandro Vallejo
2024-06-26 16:28 ` [PATCH for 4.19 v4 01/10] tools/hvmloader: Fix non-deterministic cpuid() Alejandro Vallejo
2024-06-26 16:43 ` Andrew Cooper
2024-06-26 16:52 ` Alejandro Vallejo [this message]
2024-06-27 9:48 ` oleksii.kurochko
2024-06-26 16:28 ` [PATCH for 4.19 v4 02/10] x86/vlapic: Move lapic migration checks to the check hooks Alejandro Vallejo
2024-06-26 16:28 ` [PATCH for-4.19 v4 03/10] xen/x86: Add initial x2APIC ID to the per-vLAPIC save area Alejandro Vallejo
2024-06-26 16:28 ` [PATCH v4 04/10] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves Alejandro Vallejo
2024-06-26 16:28 ` [PATCH v4 05/10] xen/x86: Add supporting code for uploading LAPIC contexts during domain create Alejandro Vallejo
2024-06-26 16:28 ` [PATCH v4 06/10] tools/libguest: Make setting MTRR registers unconditional Alejandro Vallejo
2024-06-27 9:42 ` Jan Beulich
2024-06-27 12:02 ` Alejandro Vallejo
2024-06-27 14:53 ` Jan Beulich
2024-06-26 16:28 ` [PATCH v4 07/10] xen/lib: Add topology generator for x86 Alejandro Vallejo
2024-06-26 16:28 ` [PATCH v4 08/10] xen/x86: Derive topologically correct x2APIC IDs from the policy Alejandro Vallejo
2024-06-26 16:28 ` [PATCH v4 09/10] xen/x86: Synthesise domain topologies Alejandro Vallejo
2024-06-26 16:28 ` [PATCH v4 10/10] tools/libguest: Set topologically correct x2APIC IDs for each vCPU Alejandro Vallejo
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=D2A3SPBBBYCT.CYFCF8WCBM10@cloud.com \
--to=alejandro.vallejo@cloud.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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.