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)
>
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
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:
> 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
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
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 are
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.
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 h
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 t
> 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(
> > > 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_ra
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
> 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 side-
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:
14 matches
Mail list logo
