[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 08/12] x86/paravirt: remove no longer needed 32-bit pvops cruft
- To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- From: Jürgen Groß <jgross@xxxxxxxx>
- Date: Fri, 20 Nov 2020 13:16:19 +0100
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, luto@xxxxxxxxxx, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Deep Shah <sdeep@xxxxxxxxxx>, "VMware, Inc." <pv-drivers@xxxxxxxxxx>
- Delivery-date: Fri, 20 Nov 2020 12:16:29 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 20.11.20 13:08, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
+#define ____PVOP_CALL(rettype, op, clbr, call_clbr, extra_clbr, ...) \
({ \
PVOP_CALL_ARGS; \
PVOP_TEST_NULL(op); \
+ BUILD_BUG_ON(sizeof(rettype) > sizeof(unsigned long)); \
+ asm volatile(paravirt_alt(PARAVIRT_CALL) \
+ : call_clbr, ASM_CALL_CONSTRAINT \
+ : paravirt_type(op), \
+ paravirt_clobber(clbr), \
+ ##__VA_ARGS__ \
+ : "memory", "cc" extra_clbr); \
+ (rettype)(__eax & PVOP_RETMASK(rettype)); \
})
This is now very similar to ____PVOP_VCALL() (note how PVOP_CALL_ARGS is
PVOP_VCALL_ARGS).
Could we get away with doing something horrible like:
#define ____PVOP_VCALL(X...) (void)____PVOP_CALL(long, X)
?
Oh, indeed. And in patch 9 the same could be done for the ALT variants.
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|
