Zachary Amsden wrote:
For software-reliant paravirtualization, it is difficult to atomically
switch from natural instructions to simulated para-instructions on the
fly; you would need stop_machine_run that also holds off NMIs (so as
to keep IF flag state intact across a window where
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of paravirt_ops
implementations and they aren't large so I don't think there's a big
Zachary Amsden wrote:
For a VMM which supports both full emulation and para-virtualization,
testing CPUID leaves is not sufficient to determine applicability of a
paravirt device driver. This only indicates the presence of the
functionality, not the fact that the functionality has been
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of paravirt_ops
implementations
Anthony Liguori wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of
Zachary Amsden wrote:
Basically, it just makes it easier on distributors and allows any old
kernel with paravirt-ops module support to run on any modern, new
hypervisor - that might not have even existed at the time the distro
was created.
Hey, isn't that what VMI's for? ;)
I'd been
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Basically, it just makes it easier on distributors and allows any old
kernel with paravirt-ops module support to run on any modern, new
hypervisor - that might not have even existed at the time the distro
was created.
Hey, isn't that what
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you
Anthony Liguori wrote:
Zachary Amsden wrote:
Anthony Liguori wrote:
But what's the value in having it not in the kernel? Let's take Xen
and lhype out of the picture because it clearly has to be there for
them. You have a little less in the kernel now but then your kernel
boots more
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you
Jeremy Fitzhardinge wrote:
Hm, you need to quiesce the kernel in some way when you do a migrate,
so making sure it isn't in a hypercall would be just part of that. In
general you'd make sure all but one CPU is parked somewhere, and the
remaining CPU is doing the suspend, right?
The
Zachary Amsden wrote:
Unless you also migrate the hypercall page itself and impose migration
restrictions on compatible hypercall pages.
Seems unreasonable, especially if you support migration between VT and
SVM machines. The whole point of a hypercall page is to give you a
point of
Zachary Amsden wrote:
You only need to quiesce if you have guest-visible data-structures
that have details about the underlying hardware. So Xen needs to
quiesce, but I don't know of any other VMM that would.
VMI, KVM and lhype should be capable of transparent migration without
guest
Zachary Amsden wrote:
Yes, but if we want to stay with that forward compatibility story, we
need a way to allow paravirt device probing to be completely
orthogonal to paravirt-ops probing. Either the VMware hypervisor
needs to NOT implement a CPUID leaf, keeping the same ROM based
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Unless you also migrate the hypercall page itself and impose
migration restrictions on compatible hypercall pages.
Seems unreasonable, especially if you support migration between VT and
SVM machines. The whole point of a hypercall page is
On 6/20/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
I'm not wildly happy about the idea of using PCI for probing for
otherwise completely non-PCI devices,
Good :-)
Xen deals with it with Xenbus, but I
figure I'm unlikely to convince everyone to adopt that.
Especially those of us who
Jeremy Fitzhardinge wrote:
The completely identical device model is of course ideal, but the
implementation and consolidation of that is a long term prospect to
move towards, not something that will happen immediately. We at least
emulate physical hardware devices already, and will continue
Zachary Amsden wrote:
If I had a gentoo install,
Yes, but then you'd be a gentoo user. ;)
I would probably go so far as to want to recompile everything after
migration across CPU vendors; things like NMIs, MSRs, thermal controls
and sleep states are also vendor dependent and either need to
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will
Anthony Liguori wrote:
The real trick is doing it without the guest being involved at all.
Right now, it won't be a problem in KVM since the hypercall page only
differs by a single instruction across platforms. In the future,
we'll have to be smarter and wait for all VCPUs to leave the
Zachary Amsden wrote:
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change
Anthony Liguori wrote:
I don't see a compelling reason to paravirtualize earlier although I
also don't see a compelling reason not too. I noticed that VMI hooks
setup.c. It wasn't immediately obvious why it was hooking there but
perhaps it worthwhile to have a common hook? I suspect VMI
Jeremy Fitzhardinge wrote:
Well, I was suggesting we could print the banner later rather than
forcing an earlier init.
The important part is that you set your pv_ops before patching occurs,
since that will bake the function calls into the rest of the kernel, and
it will ignore any further
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Hi Jeremy,
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
sure which paravirt_ops calls are actually re-entrant.
I'm not sure
Anthony Liguori wrote:
Perhaps we can just print the banner before batching occurs? Then
it's being printed at the last possible moment.
s/batching/patching/? Yes, that would work.
J
-
This SF.net email is sponsored
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Perhaps we can just print the banner before batching occurs? Then
it's being printed at the last possible moment.
s/batching/patching/? Yes, that would work.
Yeah, sorry :-) I'll add another patch to the series.
Regards,
Hi,
This patch series is an update of my previous paravirt_ops patches.
They are loosely based on Ingo's original paravirt_ops implementation
for KVM. Some of the changes since the last series include:
1) Switch to using CPUID 0x4000 instead of using MSR writes to
discover shared memory
Anthony Liguori wrote:
1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
sure which paravirt_ops calls are actually re-entrant.
I'm not sure that has specifically come up. The main issue is whether a
particular call can be preempted and whether that matters. I guess the
Hi Jeremy,
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
sure which paravirt_ops calls are actually re-entrant.
I'm not sure that has specifically come up. The main issue is whether a
particular call can
Anthony Liguori wrote:
Hi Jeremy,
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
sure which paravirt_ops calls are actually re-entrant.
I'm not sure that has specifically come up. The main issue is whether
30 matches
Mail list logo
