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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
