On Fri, Jan 25, 2008 at 08:14:16PM -0600, Walter Lundby wrote:
KVM version:/sbin/modinfo kvm
filename: /lib/modules/2.6.24-rc5/misc/kvm.ko
license:GPL
author: Qumranet
version:kvm-48
srcversion: 63B0F92A3F1152C05FE5A8F
depends:
vermagic:
Generally I see no problem with it. But at least for NPT I don't see a
reason why someone should want to disable it on a VM basis (as far as it
works stable). Avi, what do you think?
1. This is more user-friendly and easier-to-find
2. A lot of people would like to view (and Demo) it
On Sat, Jan 26, 2008 at 11:49:17AM +0200, Alexey Eremenko wrote:
Generally I see no problem with it. But at least for NPT I don't see a
reason why someone should want to disable it on a VM basis (as far as it
works stable). Avi, what do you think?
1. This is more user-friendly and
void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
{
- spin_lock(mmu_notifier_list_lock);
- hlist_add_head(mn-hlist, mm-mmu_notifier.head);
- spin_unlock(mmu_notifier_list_lock);
+ down_write(mm-mmap_sem);
+ __mmu_notifier_register(mn, mm);
+
1. invalidate_all()
That will be fine as long as we can unregister the ops notifier and free
the structure. Otherwise, we end up being called needlessly.
No you cannot do that because there are still callbacks that come later.
The invalidate_all may lead to invalidate_range() doing
Alexey Eremenko wrote:
Generally I see no problem with it. But at least for NPT I don't see a
reason why someone should want to disable it on a VM basis (as far as it
works stable). Avi, what do you think?
1. This is more user-friendly and easier-to-find
I'm inclined to disagree.
Joerg Roedel wrote:
Generally I see no problem with it. But at least for NPT I don't see a
reason why someone should want to disable it on a VM basis (as far as it
works stable). Avi, what do you think?
Unless there is a real-life workload that benefits from npt=0, I see no
reason to have
Walter Lundby wrote:
kernel BUG at /usr/src/modules/kvm/mmu.c:307!
invalid opcode: [1] SMP
...
version:kvm-48
This was fixed by kvm-49.
--
Any sufficiently difficult bug is indistinguishable from a feature.
Anthony Liguori wrote:
Looks like it's not. I just hung my host system after doing a bunch
of ballooning with a kernel that doesn't have MM notifiers.
I'm inclined to think that we should have a capability check for MM
notifiers and just not do madvise if they aren't present. I
Joerg Roedel wrote:
+static char *npt = on;
+
+module_param(npt, charp, S_IRUGO);
This would probably be better as an integer. Then we don't have to do nasty
things like
implicitly cast a literal to a char *.
Hmm, I used int for that first but typing npt=off seemed more
Anthony Liguori wrote:
Do others expect KVM to just cope with the virtual mapping being changed
out from underneath of it?
kvm should cope with both malicious guests and malicious (or buggy) host
userspace. It's difficuly to analyze, but mmu notifiers might be
necessary for the latter.
Bernhard Kaindl wrote:
This patch fixes user/test/x86/emulator.flat on kvm-59 with x86_64/E6850
and three other warnings:
Applied, thanks. Please send separate patches for separate problems in
the future.
--
error compiling committee.c: too many arguments to function
Anthony Liguori wrote:
This patch updates KVM's virtio implementation to the latest virtio ABI. This
includes a change in the network header and support for reset.
With this patch, the block and network driver from Rusty's latest queue are
functioning. Module unload and reload work and I no
Markus Rechberger wrote:
this patch adds support for the lbr MSR emulation, it also enables
support for Windows XP 64bit guests.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Signed-off-by: Markus Rechberger [EMAIL PROTECTED]
@@ -1171,6 +1187,19 @@
if (data != 0)
14 matches
Mail list logo
