[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a130fdd3a8e4bc6a86f595653cd53cc@AcuMS.aculab.com>
Date: Thu, 29 Jun 2023 08:30:55 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Binbin Wu' <binbin.wu@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"chao.gao@...el.com" <chao.gao@...el.com>,
"kai.huang@...el.com" <kai.huang@...el.com>,
"robert.hu@...ux.intel.com" <robert.hu@...ux.intel.com>
Subject: RE: [PATCH v9 4/6] KVM: x86: Introduce untag_addr() in kvm_x86_ops
From: Binbin Wu
> Sent: 29 June 2023 07:12
...
> >> +void vmx_untag_addr(struct kvm_vcpu *vcpu, gva_t *gva, u32 flags)
> >
> > Rather than modify the pointer, return the untagged address. That's more flexible
> > as it allows using the result in if-statements and whatnot. That might not ever
> > come into play, but there's no good reason to use an in/out param in a void
> > function.
>
> In earlier version, it did return the untagged address.
> In this version, I changed it as an in/out param to make the interface
> conditional and avoid to add a dummy one in SVM.
> Is it can be a reason?
You are always going to need a 'dummy' version.
If it ends up being 'x = x' the compiler will just optimise
it away.
But for a real function you'll get much better code from:
x = fn(x);
than
fn(&x);
It also lets you used 'void *' (etc) to avoid casts which
can easily hide bugs.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists