From: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>, David Daney <ddaney.cavm@gmail.com>,
James Hogan <james.hogan@imgtec.com>, <kvm@vger.kernel.org>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v2 09/13] MIPS: Add functions for hypervisor call
Date: Tue, 3 Jun 2014 17:03:37 +0200 [thread overview]
Message-ID: <20140603150337.GA28045@alberich> (raw)
In-Reply-To: <20140603083031.GP17197@linux-mips.org>
On Tue, Jun 03, 2014 at 10:30:31AM +0200, Ralf Baechle wrote:
> On Wed, May 28, 2014 at 11:52:12PM +0200, Andreas Herrmann wrote:
>
> > +/*
> > + * Hypercalls for KVM.
> > + *
> > + * Hypercall number is passed in v0.
> > + * Return value will be placed in v0.
> > + * Up to 3 arguments are passed in a0, a1, and a2.
> > + */
> > +static inline unsigned long kvm_hypercall0(unsigned long num)
> > +{
> > + register unsigned long n asm("v0");
> > + register unsigned long r asm("v0");
>
> Btw, is it safe to put two variables in the same register?
I think it's safe.
If we would have a matching constraint letter (say "v" for register v0) the
asm should translate to
__asm__ __volatile__(
KVM_HYPERCALL
: "=v" (n) : "v" (r) : "memory"
);
which isn't unusual on other archs. (Or maybe I am just biased from
x86 ... or missed something else.)
> The syscall wrappers that used to be in <asm/unistd.h> were occasionally
> hitting problems which eventually forced me to stop forcing variables
> into particular registers instead using a MOVE instruction to shove
> each variable into the right place.
>
> Of course they were being used from non-PIC and PIC code, kernel and userland
> so GCC had a much better chance to do evil than in the hypercall wrapper
> case - but it made me paranoid ...
Andreas
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, David Daney <ddaney.cavm@gmail.com>,
James Hogan <james.hogan@imgtec.com>,
kvm@vger.kernel.org, David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v2 09/13] MIPS: Add functions for hypervisor call
Date: Tue, 3 Jun 2014 17:03:37 +0200 [thread overview]
Message-ID: <20140603150337.GA28045@alberich> (raw)
Message-ID: <20140603150337.fGWfMoDdImY_nf4KtDqKvEzCrDviJEhSeSQmHBxoBHI@z> (raw)
In-Reply-To: <20140603083031.GP17197@linux-mips.org>
On Tue, Jun 03, 2014 at 10:30:31AM +0200, Ralf Baechle wrote:
> On Wed, May 28, 2014 at 11:52:12PM +0200, Andreas Herrmann wrote:
>
> > +/*
> > + * Hypercalls for KVM.
> > + *
> > + * Hypercall number is passed in v0.
> > + * Return value will be placed in v0.
> > + * Up to 3 arguments are passed in a0, a1, and a2.
> > + */
> > +static inline unsigned long kvm_hypercall0(unsigned long num)
> > +{
> > + register unsigned long n asm("v0");
> > + register unsigned long r asm("v0");
>
> Btw, is it safe to put two variables in the same register?
I think it's safe.
If we would have a matching constraint letter (say "v" for register v0) the
asm should translate to
__asm__ __volatile__(
KVM_HYPERCALL
: "=v" (n) : "v" (r) : "memory"
);
which isn't unusual on other archs. (Or maybe I am just biased from
x86 ... or missed something else.)
> The syscall wrappers that used to be in <asm/unistd.h> were occasionally
> hitting problems which eventually forced me to stop forcing variables
> into particular registers instead using a MOVE instruction to shove
> each variable into the right place.
>
> Of course they were being used from non-PIC and PIC code, kernel and userland
> so GCC had a much better chance to do evil than in the hypercall wrapper
> case - but it made me paranoid ...
Andreas
next prev parent reply other threads:[~2014-06-03 15:04 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 21:52 [PATCH v2 00/13] MIPS: Add mips_paravirt Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 01/13] MIPS: OCTEON: Enable use of FPU Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 02/13] MIPS: Move system level config items from CPU_CAVIUM_OCTEON to CAVIUM_OCTEON_SOC Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 03/13] MIPS: OCTEON: Move CAVIUM_OCTEON_CVMSEG_SIZE to CPU_CAVIUM_OCTEON Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 04/13] MIPS: Don't use RI/XI with 32-bit kernels on 64-bit CPUs Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 05/13] MIPS: Don't build fast TLB refill handler with 32-bit kernels Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 06/13] MIPS: Add minimal support for OCTEON3 to c-r4k.c Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 07/13] MIPS: Add function get_ebase_cpunum Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 08/13] MIPS: OCTEON: Add OCTEON3 to __get_cpu_type Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 09/13] MIPS: Add functions for hypervisor call Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-06-03 8:30 ` Ralf Baechle
2014-06-03 15:03 ` Andreas Herrmann [this message]
2014-06-03 15:03 ` Andreas Herrmann
2014-06-03 16:40 ` David Daney
2014-06-03 16:40 ` David Daney
2014-06-03 16:45 ` Pinski, Andrew
2014-05-28 21:52 ` [PATCH v2 10/13] MIPS: Add code for new system 'paravirt' Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 11/13] MIPS: paravirt: Add pci controller for virtio Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 12/13] MIPS: Enable build for new system 'paravirt' Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
2014-05-28 21:52 ` [PATCH v2 13/13] MIPS: Add minimal defconfig for mips_paravirt Andreas Herrmann
2014-05-28 21:52 ` Andreas Herrmann
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=20140603150337.GA28045@alberich \
--to=andreas.herrmann@caviumnetworks.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=james.hogan@imgtec.com \
--cc=kvm@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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.