Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 04:12 PM, Ingo Molnar wrote:
>>>
>>> Again you are making an incorrect assumption: that information leakage via the
>>> PMU only occurs while the host is running on that CPU. It does not - the PMU
>>> can leak general system details _while the guest is running_.
>>>        
>> You mean like bus transactions on a multicore?  Well, we're already
>> exposed to cache timing attacks.
>>      
> If you give a full PMU to a guest it's a whole different dimension and quality
> of information. Literally hundreds of different events about all sorts of
> aspects of the CPU and the hardware in general.
>    

Well, we filter out the bad events then.

>>> So for this and for the many other reasons we dont want to give a raw PMU to
>>> guests:
>>>
>>>   - A paravirt event driver is more compatible and more transparent in the long
>>>     run: it allows hardware upgrade and upgraded PMU functionality (for Linux)
>>>     without having to upgrade the guest OS. Via that a guest OS could even be
>>>     live-migrated to a different PMU, without noticing anything about it.
>>>        
>> What about Windows?
>>      
> What is your question? Why should i limit Linux kernel design decisions based
> on any aspect of Windows? You might want to support it, but _please_ dont let
> the design be dictated by it ...
>    

In our case the quality of implementation is judged by how well we 
support workloads that users run, and that means we have to support 
Windows well.  And that more or less means we can't have a pv-only pmu.

Which part of this do you disagree with?

>>>     In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS
>>>     always assumes the guest OS is upgraded to the host. Also, 'raw' PMU state
>>>     cannot be live-migrated. (save/restore doesnt help)
>>>        
>> Why not?  So long as the source and destination are compatible?
>>      
> 'As long as it works' is certainly a good enough filter for quality ;-)
>    

We already have this.  If you expose sse4.2 to the guest, you can't 
migrate to a host which doesn't support it.  If you expose a Nehalem pmu 
to the guest, you can't migrate to a host which supports it.  Users and 
tools already understand this.

It's true that the pmu case is more difficult since you can't migrate 
forwards as well as backwards, but that's life.

>> No, we can hide insecure events with a full pmu.  Trap the control register
>> and don't pass it on to the hardware.
>>      
> So you basically concede partial emulation ...
>    

Yes.  Still appears to follow the spec to the guest, though.  And with 
the option of full emulation for those who need it and sign on the 
dotted line.

>>>   - There's proper event scheduling and event allocation. Time-slicing, etc.
>>>
>>>
>>> The thing is, we made quite similar arguments in the past, during the
>>> perfmon vs. perfcounters discussions. There's really a big advantage to
>>> proper abstractions, both on the host and on the guest side.
>>>        
>> We only control half of the equation.  That's very different compared to
>> tools/perf.
>>      
> You mean Windows?
>
> For heaven's sake, why dont you think like Linus thought 20 years ago. To the
> hell with Windows suckiness and lets make sure our stuff works well.

In our case, making our stuff work well means making sure guests of the 
user's choice run well.  Not ours.  Currently users mostly choose 
Windows and Linux, so we have to make them both work.

(btw, the analogy would be, 'To hell with Unix suckiness, let's make 
sure our stuff works well'; where Linux reimplemented the Unix APIs, 
ensuring source compatibility with applications, kvm reimplements the 
hardware interface, ensuring binary compatibility with guests).

>   Then the
> users will come, developers will come, and people will profile Linux under
> Linux and maybe the tools will be so good that they'll profile under Linux
> using Wine just to be able to use those good tools...
>    

If we don't support Windows well, users will walk away, followed by 
starving developers.

> If you gut Linux capabilities like that to accomodate for the suckiness of
> Windows, without giving a technological edge to Linux, and then we are bound
> to fail in the long run ...
>    

I'm all for abusing the tight relationship between Linux-as-a-host and 
Linux-as-a-guest to gain an advantage for both.  One fruitful area would 
be asynchronous page faults, which has the potential to increase memory 
overcommit, for example.  But first of all we need to make sure that 
there is a baseline of support for all commonly used guests.

I think of it this way: once kvm deployment becomes widespread, 
Linux-as-a-guest gains an advantage.  But in order for kvm deployment to 
become widespread, it needs excellent support for all guests users 
actually use.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.