Re: [PATCH] x86/hvm: print valid CR4 bits in case of error

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.06.2023 16:24, Roger Pau Monné wrote:
> On Wed, Jun 07, 2023 at 04:00:14PM +0200, Jan Beulich wrote:
>> On 07.06.2023 15:46, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/domain.c
>>> +++ b/xen/arch/x86/hvm/domain.c
>>> @@ -266,8 +266,8 @@ int arch_set_info_hvm_guest(struct vcpu *v, const 
>>> vcpu_hvm_context_t *ctx)
>>>  
>>>      if ( v->arch.hvm.guest_cr[4] & ~hvm_cr4_guest_valid_bits(d) )
>>>      {
>>> -        gprintk(XENLOG_ERR, "Bad CR4 value: %#016lx\n",
>>> -                v->arch.hvm.guest_cr[4]);
>>> +        gprintk(XENLOG_ERR, "Bad CR4 value: %#016lx (valid: %016lx)\n",
>>> +                v->arch.hvm.guest_cr[4], hvm_cr4_guest_valid_bits(d));
>>>          return -EINVAL;
>>>      }
>>>  
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -1018,8 +1018,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain 
>>> *d, hvm_domain_context_t *h)
>>>  
>>>      if ( ctxt.cr4 & ~hvm_cr4_guest_valid_bits(d) )
>>>      {
>>> -        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" PRIx64 "\n",
>>> -               d->domain_id, ctxt.cr4);
>>> +        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#016lx (valid: 
>>> %016lx)\n",
>>
>> I'm not convinced printing a lot of leading zeros is really useful here.
>> However, if you switch to that model, then all uses of the # modifier
>> need to go away (in the earlier instance it would be nice if you also
>> fixed the pre-existing issue then).
> 
> Hm, I've got those messed up.  What would you be your preference then?
> (%#lx?)

Yes.

> I would be happy with that also.

Oh, even better then.

Jan