Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

From: Avi Kivity
Date: Wed Dec 23 2009 - 15:27:13 EST


On 12/23/2009 09:27 PM, Andi Kleen wrote:
Ingo Molnar<mingo@xxxxxxx> writes:

Yes, there's (obviously) compatibility requirements and artifacts and past
mistakes (as with any software interface), but you need to admit it to
Yes that's exactly what I meant.

And we do make plenty of mistakes. And when we fix them, we have to maintain bug-compatibility to allow live migration from the broken version to the good version. If you're ever feeling overly happy, do some compat work in qemu and it will suck a year's worth or two of your life force a pop.

yourself that your "virtualization is sloppy just like hardware" claim is just
In my experience hardware is a lot less sloppy than software.
Imagine your latest CPU had as many regressions as 2.6.32 @)

I wish software and even VMs were as good.


Me too.

a cheap excuse to not do a proper job of interface engineering.
Past mistakes cannot be easily fixed. And undoubtedly even the new
shiny interfaces will have bugs and problems. Also the behaviour is
often not completely understood. Maybe it can be easier debugged with
fully available source, but even then it's hard to fix the old
software (or rather even if you can fix it deploy the fixes). In
that regard it's a lot like hardware.

I agree with you that this makes it important to design good
interfaces, but again realistically mistakes will be made
and they cannot be all fixed retroactively.

Our principal tool for this is to avoid introducing new interfaces whenever possible. We try to stick to established hardware standards (so we don't need to sloppily define them, and get guest compatibility for free).

Hardware (both virt and non-virt) faces the same problems as software here. So as hardware solutions are introduced, we adopt them, and usually the virt extensions vendors follow with accelerations for these paths as well.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
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/