Jeremy Fitzhardinge wrote:

Nakajima, Jun wrote:

quoted

Jeremy Fitzhardinge wrote:

quoted

+	.pv_irq_ops = {
+		 .init_IRQ = native_init_IRQ,
+		 .save_fl = native_save_fl,
+		 .restore_fl = native_restore_fl,
+		 .irq_disable = native_irq_disable,
+		 .irq_enable = native_irq_enable,
+		 .safe_halt = native_safe_halt,
+		 .halt = native_halt,
+	 },

I think the halt stuff should be moved to pv_cpu_ops?

You mean halt's alternate "shutdown vcpu" meaning if you call it with
interrupts disabled?  Yeah, I'd be happy to have an explicit op for
that, rather than making it a secondary overloaded meaning.  And use
"safe_halt" for all uses of "wait for next interrupt".

Yes. For the native, "safe_halt" is "sti; hlt". The "native_halt" is
just "hlt". So the para_virt part of "hlt" could be moved to pv_cpu_ops,
and the "sti" part stays in pv_irq_ops.

quoted

quoted

+	.pv_misc_ops = {
+		 .set_lazy_mode = paravirt_nop,
+	 },

Or you can split it to pv_cpu_ops and pv_mmu_ops, assuming that they
don't need to interact with each other in terms of the lazy

handling.

quoted

You mean have separate lazy_mmu and lazy_cpu (lazy_context_switch)

ops?

Possible, but they're still exclusive.  (I think VMI, at least,

assumes

that you can't have lazy_mmu and lazy_cpu active at the same time, and
its nice to enforce this in the interface.)

Okay I understand what you are saying.

But having a whole misc structure for this interface is pretty warty,

I

admit.

    J

Actually my concern was that such misc ops might grow to include the
things don't fit well anywhere else. To me, then pv_lazy_ops (with just
.set_mode) might be better.

Jun
---
Intel Open Source Technology Center