Re: [RFC, PATCH 1/24] i386 Vmi documentation

[Andi Kleen]

On Monday 13 March 2006 18:59, Zachary Amsden wrote:

> +     The general mechanism for providing customized features and
> +     capabilities is to provide notification of these feature through
> +     the CPUID call, 

How should that work since CPUID cannot be intercepted by 
a Hypervisor (without VMX/SVM)?  

> + Watchdog NMIs are of limited use if the OS is
> +     already correct and running on stable hardware;

So how would your Hypervisor detect a kernel hung with interrupts
off then?

>>       profiling NMIs are 
> +     similarly of less use, since this task is accomplished with more accuracy
> +     in the VMM itself

And how does oprofile know about this?

> ; and NMIs for machine check errors should be handled 
> +     outside of the VM.  

Right now yes, but if we ever implement intelligent memory ECC error handling it's questionable
the hypervisor can do a better job. It has far less information about how memory
is used than the kernel.

> +   The net result of these choices is that most of the calls are very
> +   easy to make from C-code, and calls that are likely to be required in
> +   low level trap handling code are easy to call from assembler.   Most
> +   of these calls are also very easily implemented by the hypervisor
> +   vendor in C code, and only the performance critical calls from
> +   assembler paths require custom assembly implementations.
> +
> +   CORE INTERFACE CALLS

Did I miss it or do you never describe how to find these entry points? 

> +    VMI_EnableInterrupts
> +
> +       VMICALL void VMI_EnableInterrupts(void);
> +
> +       Enable maskable interrupts on the processor.  Note that the
> +       current implementation always will deliver any pending interrupts
> +       on a call which enables interrupts, for compatibility with kernel
> +       code which expects this behavior.  Whether this should be required
> +       is open for debate.

A subtle trap is also that it will do so on the next instruction, not the 
followon to next like a real x86.  At some point there was code in Linux
that dependend on this.


> +       VMICALL VMI_UINT64 VMI_RDMSR(VMI_UINT64 dummy, VMI_UINT32 reg);
> +
> +       Read from a model specific register.  This functions identically to the
> +       hardware RDMSR instruction.  Note that a hypervisor may not implement
> +       the full set of MSRs supported by native hardware, since many of them
> +       are not useful in the context of a virtual machine.

So what happens when the kernel tries to access an unimplemented MSR?

Also we have had occasionally workarounds in the past that required 
MSR writes with magic "passwords". How would these be handled?
+
> +    VMI_CPUID
> +
> +       /* Not expressible as a C function */
> +
> +       The CPUID instruction provides processor feature identification in a
> +       vendor specific manner.  The instruction itself is non-virtualizable
> +       without hardware support, requiring a hypervisor assisted CPUID call
> +       that emulates the effect of the native instruction, while masking any
> +       unsupported CPU feature bits.

Doesn't seem to be very useful because everybody can just call CPUID directly.

> +       The RDTSC instruction provides a cycles counter which may be made
> +       visible to userspace.  For better or worse, many applications have made
> +       use of this feature to implement userspace timers, database indices, or
> +       for micro-benchmarking of performance.  This instruction is extremely
> +       problematic for virtualization, because even though it is selectively 
> +       virtualizable using trap and emulate, it is much more expensive to
> +       virtualize it in this fashion.  On the other hand, if this instruction
> +       is allowed to execute without trapping, the cycle counter provided
> +       could be wrong in any number of circumstances due to hardware drift,
> +       migration, suspend/resume, CPU hotplug, and other unforeseen
> +       consequences of running inside of a virtual machine.  There is no
> +       standard specification for how this instruction operates when issued
> +       from userspace programs, but the VMI call here provides a proper
> +       interface for the kernel to read this cycle counter.

Yes, but it will be wrong in a native kernel too so why do you want
to be better than native? 

Seems useless to me.

> +    VMI_RDPMC
> +
> +       VMICALL VMI_UINT64 VMI_RDPMC(VMI_UINT64 dummy, VMI_UINT32 counter);
> +
> +       Similar to RDTSC, this call provides the functionality of reading
> +       processor performance counters.  It also is selectively visible to
> +       userspace, and maintaining accurate data for the performance counters
> +       is an extremely difficult task due to the side effects introduced by
> +       the hypervisor.

Similar.

Overall feeling is you have far too many calls. You seem to try to implement
a full x86 replacement, but that makes it big and likely to be buggy. And 
it's likely impossible to implement in any Hypervisor short of a full emulator
like yours.

I would try a diet and only implement facilities that are actually likely
to be used by modern OS.

There was one other point I wanted to make but I forgot it now @)

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/