x86 paravirt_ops: create no_paravirt.h for native ops

Review

Quoted 4 lines

(quoted diff) +2 -0

+#ifdef CONFIG_PARAVIRT
+void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)

It would be better to merge this with the existing LOCK prefix patching or perhaps the normal alternative() patcher (is there any particular reason you can't use it?)

Three alternative patching mechanisms just seems to be too many

This patch does the dumbest possible replacement of paravirtualized
instructions: calls through a "paravirt_ops" structure. Currently these are function implementations of native hardware: hypervisors will override the ops structure with their own variants.

Quoted 5 lines · Rusty Russell

This patch does the dumbest possible replacement of paravirtualized
instructions: calls through a "paravirt_ops" structure. Currently these are function implementations of native hardware: hypervisors will override the ops structure with their own variants.

You should call it HAL - that would make it clearer what it is.

I think I would prefer to patch always. Is there a particular reason you can't do that?

Quoted 4 lines · Rusty Russell

This patch does the dumbest possible replacement of paravirtualized
instructions: calls through a "paravirt_ops" structure. Currently these are function implementations of native hardware: hypervisors will override the ops structure with their own variants.

You should call it HAL - that would make it clearer what it is.

I think I would prefer to patch always. Is there a particular reason you can't do that?

It would be better to merge this with the existing LOCK prefix patching or perhaps the normal alternative() patcher (is there any particular reason you can't use it?)

Three alternative patching mechanisms just seems to be too many

Quoted 3 lines

I think I would prefer to patch always. Is there a particular reason you can't do that?

We could patch all the indirect calls into direct calls, but I don't think it's worth bothering: most simply don't matter.

Each backend wants a different patch, so alternative() doesn't cut it. We could look at generalizing alternative() I guess, but it works fine so I didn't want to touch it.

Quoted 5 lines

Quoted 2 lines

I think I would prefer to patch always. Is there a particular reason you can't do that?

We could patch all the indirect calls into direct calls, but I don't think it's worth bothering: most simply don't matter.

I still think it would be better to patch always.

Quoted 3 lines

Each backend wants a different patch, so alternative() doesn't cut it. We could look at generalizing alternative() I guess, but it works fine so I didn't want to touch it.

You could at least use a common function (with the replacement passed in as argument) for lock prefixes and your stuff

Unfortunately, due to include cycles, we can't put these in paravirt.h: we use a separate header for these.

The implementation comes from Zach's [RFC, PATCH 10/24] i386 Vmi descriptor changes:

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for custom exception frames or extra layers of indirection above the guest fault / IRQ handlers.

Quoted 5 lines · Rusty Russell

Unfortunately, due to include cycles, we can't put these in paravirt.h: we use a separate header for these.

The implementation comes from Zach's [RFC, PATCH 10/24] i386 Vmi descriptor changes:

Quoted 7 lines

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for custom exception frames or extra layers of indirection above the guest fault / IRQ handlers.

Nice cleanup. The old assembly mess was ripe to be killed for a long time.

Quoted 14 lines · Andi Kleen

Quoted 12 lines · Rusty Russell

Unfortunately, due to include cycles, we can't put these in paravirt.h: we use a separate header for these.

The implementation comes from Zach's [RFC, PATCH 10/24] i386 Vmi descriptor changes:

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for custom exception frames or extra layers of indirection above the guest fault / IRQ handlers.

Quoted 1 line

Nice cleanup. The old assembly mess was ripe to be killed for a long time.

OK, here's that patch extracted out.

Quoted 15 lines · Rusty Russell

Quoted 14 lines · Andi Kleen

Quoted 12 lines · Rusty Russell

Unfortunately, due to include cycles, we can't put these in paravirt.h: we use a separate header for these.

The implementation comes from Zach's [RFC, PATCH 10/24] i386 Vmi descriptor changes:

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for custom exception frames or extra layers of indirection above the guest fault / IRQ handlers.

Quoted 3 lines

Quoted 1 line

Nice cleanup. The old assembly mess was ripe to be killed for a long time.

OK, here's that patch extracted out.

Is there something wrong with your mailer? This one doesn't apply either:

(Andrew, please sit these in the -mm tree for cooking)

Create a paravirt.h header for (almost) all the critical operations which need to be replaced with hypervisor calls.

For the moment, this simply includes no_paravirt.h, where all the native implementations now live.

include/asm-i386/no_paravirt.h line 52

Quoted 7 lines

include/asm-i386/no_paravirt.h new file +6 -0

+/* Stop speculative execution */
+static inline void sync_core(void)
+{
+	unsigned int eax = 1, ebx, ecx, edx;
+	__cpuid(&eax, &ebx, &ecx, &edx);
+}

Actually I don't think this one should be para virtualized at all.
I don't see any reason at all why a hypervisor should trap it and it
is very time critical. I would recommend you move it back into the normal files without hooks.

Quoted 4 lines · Andi Kleen

Quoted 4 lines

include/asm-i386/no_paravirt.h new file +4 -0

+/* Stop speculative execution */
+static inline void sync_core(void)
+{
+	unsigned int eax = 1, ebx, ecx, edx;

Quoted 9 lines

include/asm-i386/no_paravirt.h line 52

Quoted 3 lines

include/asm-i386/no_paravirt.h new file +2 -0

+	__cpuid(&eax, &ebx, &ecx, &edx);
+}

Actually I don't think this one should be para virtualized at all. I don't see any reason at all why a hypervisor should trap it and it is very time critical. I would recommend you move it back into the normal files without hooks.

When VT/AMDV is enabled, cpuid could cause a vm exit,

so it would be
nice to use one of the other serializing instructions in this case.

Quoted 2 lines

so it would be nice to use one of the other serializing instructions in this case.

You would first need to find one that works in ring 3. On x86-64 it is used in the gettimeoday vsyscall in ring 3 to synchronize the TSC and afaik John was about to implement that for i386 too.

BTW another issue that I haven't checked but we will need to make
this also an alternative() for another case - it is faily important
to patch it out on Intel systems with a synchronized TSC where it is
fairly expensive. That is also not done yet on i386, but will be likely once vsyscall gettimeofday is implemented.

So basically you would need double patching. Ugly.

I would recommend to keep it out of para ops.

Quoted 4 lines · Andi Kleen

Quoted 4 lines

include/asm-i386/no_paravirt.h new file +4 -0

+/* Stop speculative execution */
+static inline void sync_core(void)
+{
+	unsigned int eax = 1, ebx, ecx, edx;

Quoted 8 lines

include/asm-i386/no_paravirt.h line 52

Quoted 3 lines

include/asm-i386/no_paravirt.h new file +2 -0

+	__cpuid(&eax, &ebx, &ecx, &edx);
+}

Actually I don't think this one should be para virtualized at all. I don't see any reason at all why a hypervisor should trap it and it is very time critical. I would recommend you move it back into the normal files without hooks.

Quoted 13 lines · Jeremy Fitzhardinge

Quoted 4 lines · Andi Kleen

Quoted 4 lines

include/asm-i386/no_paravirt.h new file +4 -0

+/* Stop speculative execution */
+static inline void sync_core(void)
+{
+	unsigned int eax = 1, ebx, ecx, edx;

Quoted 8 lines

include/asm-i386/no_paravirt.h line 52

Quoted 3 lines

include/asm-i386/no_paravirt.h new file +2 -0

+	__cpuid(&eax, &ebx, &ecx, &edx);
+}

Actually I don't think this one should be para virtualized at all. I don't see any reason at all why a hypervisor should trap it and it is very time critical. I would recommend you move it back into the normal files without hooks.

I don't see where it's time-critical...

include/asm-i386/no_paravirt.h

Quoted 3 lines

===================================================================

include/asm-i386/no_paravirt.h new file +0 -0

I can't say I like the name. After all that should be the normal case for a long time now ... native? normal? bareiron?

Also I would prefer if you split this file up a bit - the old processor/system/irqflags split wasn't too bad.

include/asm-i386/no_paravirt.h line 34

Quoted 5 lines

include/asm-i386/no_paravirt.h new file +5 -0

+
+/*
+ * Set IOPL bits in EFLAGS from given mask
+ */
+static inline void set_iopl_mask(unsigned mask)

This function can be completely written in C using local_save_flags()/local_restore_flags() Please do that. I guess it's still a good idea to keep it separated
though because it might allow other optimizations.

e.g. i've been thinking about special casing IF changes in save/restore flags to optimize CPUs which have slow pushf/popf. If you already make sure all non IF manipulations of flags are separated that would help.

include/asm-i386/no_paravirt.h line 56

Quoted 4 lines

include/asm-i386/no_paravirt.h new file +4 -0

+
+/*
+ * Clear and set 'TS' bit respectively
+ */

The comment seems out of date (no set TS)

include/asm-i386/no_paravirt.h line 60

Quoted 4 lines

include/asm-i386/no_paravirt.h new file +4 -0

+#define clts() __asm__ __volatile__ ("clts")
+#define read_cr0() ({ \
+	unsigned int __dummy; \
+	__asm__ __volatile__( \

Maybe it's just me, but can't you just drop all these __s around asm and volatile? They are completely useless as far I know.

Also the assembly will be easier readable if you just keep it on a single line for the simple ones.

Quoted 6 lines · Andi Kleen

include/asm-i386/no_paravirt.h

Quoted 3 lines

===================================================================

include/asm-i386/no_paravirt.h new file +0 -0

I can't say I like the name. After all that should be the normal case for a long time now ... native? normal? bareiron?

Yeah, I don't like it much either. native.h doesn't say what the alternative is. native_paravirt.h is kind of contradictory.

I'm just shuffling code here, and if the other approach works, I won't even be doing that.

Quoted 10 lines · Andi Kleen

Quoted 6 lines

include/asm-i386/no_paravirt.h

Quoted 3 lines

===================================================================

include/asm-i386/no_paravirt.h new file +0 -0

I can't say I like the name. After all that should be the normal case for a long time now ... native? normal? bareiron?

Yeah, I don't like it much either. native.h doesn't say what the alternative is. native_paravirt.h is kind of contradictory.

baremetal.h seems appropriate.

Quoted 2 lines

baremetal.h seems appropriate.

<vanilla.h>, in hommage to "vanilla kernel".

Quoted 3 lines

Quoted 1 line

baremetal.h seems appropriate.

<vanilla.h>, in hommage to "vanilla kernel".

I think most people use 'vanilla' to mean 'mainline', as in Linus's

Quoted 10 lines

include/asm-i386/no_paravirt.h line 34

Quoted 6 lines

include/asm-i386/no_paravirt.h new file +5 -0

+
+/*
+ * Set IOPL bits in EFLAGS from given mask
+ */
+static inline void set_iopl_mask(unsigned mask)

This function can be completely written in C using local_save_flags()/local_restore_flags() Please do that. I guess it's still a good idea to keep it separated
though because it might allow other optimizations.

Quoted 4 lines

e.g. i've been thinking about special casing IF changes in save/restore flags to optimize CPUs which have slow pushf/popf. If you already make sure all non IF manipulations of flags are separated that would help.

Quoted 10 lines · Rusty Russell

Quoted 10 lines

include/asm-i386/no_paravirt.h line 34

Quoted 6 lines

include/asm-i386/no_paravirt.h new file +5 -0

+
+/*
+ * Set IOPL bits in EFLAGS from given mask
+ */
+static inline void set_iopl_mask(unsigned mask)

This function can be completely written in C using local_save_flags()/local_restore_flags() Please do that. I guess it's still a good idea to keep it separated
though because it might allow other optimizations.

Quoted 4 lines

Quoted 4 lines

e.g. i've been thinking about special casing IF changes in save/restore flags to optimize CPUs which have slow pushf/popf. If you already make sure all non IF manipulations of flags are separated that would help.

Actually, that is not quite true. Local_save_flags / raw_local_irq_restore today is used only for operating on IF flag, and raw_local_restore_flags does not exist.

Our implementation of these in
VMI assumes that only the IF flag is being changed, and this is the default assumption under which Xen runs as well. Using local_restore to switch IOPL as well causes the extremely performance critical common case of pure IRQ restore to do potentially a lot more work in a hypervisor.

So if you do want us to go with the C approach, I would propose using raw_local_iopl_restore, which can make a different hypercall (actually, in our case, this is not even a hypercall, merely a VMI call).