Chris said, and I agree, that we should try to get the basic PV-ops
infrastructure stuff into 2.6.19. To me this means being able to run a
kernel native with CONFIG_PARAVIRT, and see little or no functional or
performance degradation. What do we need to do to get there:
* fix the slowdown bug, which seems to be something to do with
rdmsr/wrmsr on SMP systems
* work out how to handle all the low-level system interfaces, like
ACPI, PnP BIOS, APM
* what else?
The system interfaces question is interesting. I'm assuming that if
we're running under a hypervisor, all those interfaces are either
missing or (later) virtualized - ie, the hypervisor deals with them.
But we still need to do that stuff running native, so the pv-ops
interface needs to have a way of selectively enabling them. Or maybe it
doesn't; will those pieces of code lie there passively if they're not
poked?
J
On Friday 04 August 2006 20:34, Jeremy Fitzhardinge wrote:> Chris said, and I agree, that we should try to get the basic PV-ops > infrastructure stuff into 2.6.19. To me this means being able to run a > kernel native with CONFIG_PARAVIRT, and see little or no functional or > performance degradation. What do we need to do to get there: > > * fix the slowdown bug, which seems to be something to do with > rdmsr/wrmsr on SMP systems > * work out how to handle all the low-level system interfaces, like > ACPI, PnP BIOS, APM > * what else?You're already too late for most of this. The merge window will open in the forseeable future and you don't have had significant -mm* or x86_64-* testing yet and in general stuff is still very fresh. Maybe we can get some basic "obvious" stuff like a few macro substitutions in (if you submit them properly), but probably not the full support. -Andi
* Jeremy Fitzhardinge (jeremy@goop.org) wrote:> Chris said, and I agree, that we should try to get the basic PV-ops > infrastructure stuff into 2.6.19. To me this means being able to run a > kernel native with CONFIG_PARAVIRT, and see little or no functional or > performance degradation. What do we need to do to get there: > > * fix the slowdown bug, which seems to be something to do with > rdmsr/wrmsr on SMP systems > * work out how to handle all the low-level system interfaces, like > ACPI, PnP BIOS, APM > * what else?We should have a somewhat functioning prototype of non-native (say xen or VMI perhaps) as well, methinks. Just to verify. thanks, -chris
* Jeremy Fitzhardinge (jeremy@goop.org) wrote:> Chris said, and I agree, that we should try to get the basic PV-ops > infrastructure stuff into 2.6.19. To me this means being able to run a > kernel native with CONFIG_PARAVIRT, and see little or no functional or > performance degradation. What do we need to do to get there: > > * fix the slowdown bug, which seems to be something to do with > rdmsr/wrmsr on SMP systemsI believe this is fixed now, at least it's booting fine on my smp box now. #define wrmsr_safe(msr,a,b) ({ \ - u64 _l = ((u64)(a) << 32) | (b); \ + u64 _l = ((u64)(b) << 32) | (a); \ paravirt_ops.write_msr((msr),_l); \ }) thanks, -chris