Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
conversions when a u64 MSR value is splitted into two u32.

Signed-off-by: Xin Li (Intel) <xin@zytor.com>
---
 arch/x86/coco/sev/core.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index ff82151f7718..b3ce6fc8b62d 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -282,12 +282,7 @@ static inline u64 sev_es_rd_ghcb_msr(void)
 
 static __always_inline void sev_es_wr_ghcb_msr(u64 val)
 {
-	u32 low, high;
-
-	low  = (u32)(val);
-	high = (u32)(val >> 32);
-
-	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
+	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, val);
 }
 
 static int vc_fetch_insn_kernel(struct es_em_ctxt *ctxt,
-- 
2.49.0

On 5/12/2025 1:45 AM, Xin Li (Intel) wrote:
> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> conversions when a u64 MSR value is splitted into two u32.
> 
> Signed-off-by: Xin Li (Intel) <xin@zytor.com>
> ---
>   arch/x86/coco/sev/core.c | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index ff82151f7718..b3ce6fc8b62d 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -282,12 +282,7 @@ static inline u64 sev_es_rd_ghcb_msr(void)
>   
>   static __always_inline void sev_es_wr_ghcb_msr(u64 val)
>   {
> -	u32 low, high;
> -
> -	low  = (u32)(val);
> -	high = (u32)(val >> 32);
> -
> -	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
> +	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, val);
>   }
>   
>   static int vc_fetch_insn_kernel(struct es_em_ctxt *ctxt,

Just noticed that this patch doesn't apply to tip/x86/core, I will send
it as a separate one.

Thanks!
     Xin

* Xin Li (Intel) <xin@zytor.com> wrote:

> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> conversions when a u64 MSR value is splitted into two u32.
> 
> Signed-off-by: Xin Li (Intel) <xin@zytor.com>
> ---
>  arch/x86/coco/sev/core.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index ff82151f7718..b3ce6fc8b62d 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -282,12 +282,7 @@ static inline u64 sev_es_rd_ghcb_msr(void)
>  
>  static __always_inline void sev_es_wr_ghcb_msr(u64 val)
>  {
> -	u32 low, high;
> -
> -	low  = (u32)(val);
> -	high = (u32)(val >> 32);
> -
> -	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
> +	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, val);

BTW., at this point we should probably just replace 
sev_es_wr_ghcb_msr() calls with direct calls to:

	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);

as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().

Thanks,

	Ingo

On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> 
> * Xin Li (Intel) <xin@zytor.com> wrote:
> 
>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
>> conversions when a u64 MSR value is splitted into two u32.
>>
> 
> BTW., at this point we should probably just replace
> sev_es_wr_ghcb_msr() calls with direct calls to:
> 
> 	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
> 
> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
> 

I thought about it, however it looks to me that current code prefers not
to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a 
__always_inline function.

But as you have asked, I will make the change unless someone objects.

Thanks!
     Xin

On 5/15/2025 10:54 AM, Xin Li wrote:
> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
>>
>> * Xin Li (Intel) <xin@zytor.com> wrote:
>>
>>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
>>> conversions when a u64 MSR value is splitted into two u32.
>>>
>>
>> BTW., at this point we should probably just replace
>> sev_es_wr_ghcb_msr() calls with direct calls to:
>>
>>     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
>>
>> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
>>
> 
> I thought about it, however it looks to me that current code prefers not
> to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a 
> __always_inline function.
> 
> But as you have asked, I will make the change unless someone objects.

Hi Ingo,

I took a further look and found that we can't simply replace
sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).

There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
arch/x86/boot/msr.h to do MSR write.

The other one is defined in arch/x86/include/asm/sev-internal.h, which
uses native_wrmsrq() from arch/x86/include/asm/msr.h to write MSR.

Because:
1) arch/x86/boot/startup/sev-shared.c is included in both
         arch/x86/boot/compressed/sev.c
    and
         arch/x86/boot/startup/sev-startup.c

2) arch/x86/boot/startup/sev-shared.c has several references to
    sev_es_wr_ghcb_msr(),

sev_es_wr_ghcb_msr() is converted to boot_wrmsr() when included in
arch/x86/boot/compressed/sev.c or native_wrmsrq() when included in
arch/x86/boot/startup/sev-startup.c.

It would change the compressed code to use native_wrmsrq() if we remove
sev_es_wr_ghcb_msr() from arch/x86/include/asm/sev-internal.h and use 
native_wrmsrq() directly in the startup code.

We probably should get rid of boot_wrmsr() and use native_wrmsrq() in
the compressed code because they are indeed the same thing.  But as we
are so close to the v6.16 merge window, I don't think it's a good idea
to make the change right now.

So maybe I should just drop this patch and we can do the job after the 
coming merge window.

But if you think it's not a bad idea to replace native_wrmsr() with
native_wrmsrq() right now, I can keep this original patch.

Thanks!
     Xin

* Xin Li <xin@zytor.com> wrote:

> On 5/15/2025 10:54 AM, Xin Li wrote:
> > On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> > > 
> > > * Xin Li (Intel) <xin@zytor.com> wrote:
> > > 
> > > > Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> > > > conversions when a u64 MSR value is splitted into two u32.
> > > > 
> > > 
> > > BTW., at this point we should probably just replace
> > > sev_es_wr_ghcb_msr() calls with direct calls to:
> > > 
> > >     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
> > > 
> > > as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
> > > 
> > 
> > I thought about it, however it looks to me that current code prefers not
> > to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a
> > __always_inline function.
> > 
> > But as you have asked, I will make the change unless someone objects.
> 
> Hi Ingo,
> 
> I took a further look and found that we can't simply replace
> sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).
> 
> There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
> arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
> arch/x86/boot/msr.h to do MSR write.

Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't 
have at the moment. Fair enough.

Thanks,

	Ingo

>>> On 5/15/2025 10:54 AM, Xin Li wrote:
>>> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
>>>> 
>>>> * Xin Li (Intel) <xin@zytor.com> wrote:
>>>> 
>>>>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
>>>>> conversions when a u64 MSR value is splitted into two u32.
>>>>> 
>>>> 
>>>> BTW., at this point we should probably just replace
>>>> sev_es_wr_ghcb_msr() calls with direct calls to:
>>>> 
>>>>     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
>>>> 
>>>> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
>>>> 
>>> 
>>> I thought about it, however it looks to me that current code prefers not
>>> to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a
>>> __always_inline function.
>>> 
>>> But as you have asked, I will make the change unless someone objects.
>> 
>> Hi Ingo,
>> 
>> I took a further look and found that we can't simply replace
>> sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).
>> 
>> There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
>> arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
>> arch/x86/boot/msr.h to do MSR write.
> 
> Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't
> have at the moment. Fair enough.

So you want me to drop this patch then?

Thanks!
    Xin

* Xin Li <xin@zytor.com> wrote:

> 
> >>> On 5/15/2025 10:54 AM, Xin Li wrote:
> >>> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> >>>> 
> >>>> * Xin Li (Intel) <xin@zytor.com> wrote:
> >>>> 
> >>>>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> >>>>> conversions when a u64 MSR value is splitted into two u32.
> >>>>> 
> >>>> 
> >>>> BTW., at this point we should probably just replace
> >>>> sev_es_wr_ghcb_msr() calls with direct calls to:
> >>>> 
> >>>>     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
> >>>> 
> >>>> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
> >>>> 
> >>> 
> >>> I thought about it, however it looks to me that current code prefers not
> >>> to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a
> >>> __always_inline function.
> >>> 
> >>> But as you have asked, I will make the change unless someone objects.
> >> 
> >> Hi Ingo,
> >> 
> >> I took a further look and found that we can't simply replace
> >> sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).
> >> 
> >> There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
> >> arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
> >> arch/x86/boot/msr.h to do MSR write.
> > 
> > Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't
> > have at the moment. Fair enough.
> 
> So you want me to drop this patch then?

No, patch #3 is fine as-is in its -v1 form, I was wrong.

Thanks,

	Ingo

On 5/17/2025 6:21 AM, Ingo Molnar wrote:
>>> Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't
>>> have at the moment. Fair enough.
>> So you want me to drop this patch then?
> No, patch #3 is fine as-is in its -v1 form

Thanks for confirming.

I'll just update patch #2 as version v1A then.

     Xin