From db6524fb36bbf1f297ae171f18de382c32ed6840 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Tue, 29 Jan 2008 08:17:57 +0800
Subject: [PATCH] KVM: VMX: Fix invalid opcode of VPID
Add the missing "memory" in VPID clobber list, otherwise it would cause
invalid opcode on host.
Yang, Sheng wrote:
> From db6524fb36bbf1f297ae171f18de382c32ed6840 Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Tue, 29 Jan 2008 08:17:57 +0800
> Subject: [PATCH] KVM: VMX: Fix invalid opcode of VPID
>
> Add the missing "memory" in VPID clobber list, otherwise it would ca
Marcelo Tosatti wrote:
> Hi,
>
> The CR3 cache feature of VMX CPU's does not seem to increase
> context switch performance significantly as it did in the original
> implementation (http://lkml.org/lkml/2007/1/5/205).
>
> The following is similar to the original, but it also caches roots for
> 4-l
Hollis Blanchard wrote:
> This allows kvm_host.h to be #included even when struct preempt_notifier is
> undefined. This is needed to build asm-offsets.h.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Gerd Hoffmann wrote:
> Hmm, what kvm version is this against? latest git I guess? After
> applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
Looks like the mmu.h chunk is missing in the patch.
cheers,
Gerd
Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
>> Hmm, what kvm version is this against? latest git I guess? After
>> applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
>
> Looks like the mmu.h chunk is missing in the patch.
Hmm, and x86.c looks incomplete too. vcpu->arc
Explicitly enable the NM intercept in svm_set_cr0 if we enable TS in the guest
copy of CR0 for lazy FPU switching. This fixes guest SMP with Linux under SVM.
Without that patch Linux deadlocks or panics right after trying to boot the
other CPUs.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Sign
This should fix the aging bugs you introduced through the faulty cpp
expansion. This is hard to write for me, given any time somebody does
a ptep_clear_flush_young w/o manually cpp-expandin "|
mmu_notifier_age_page" after it, it's always a bug that needs fixing,
similar bugs can emerge with time fo
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:
> +struct mmu_notifier_head {
> + struct hlist_head head;
> +};
> +
> struct mm_struct {
> struct vm_area_struct * mmap; /* list of VMAs */
> struct rb_root mm_rb;
> @@ -219,6 +223,8 @@ struct mm_struct {
Andrea Arcangeli wrote:
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index ea4764b..9349160 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -118
您好!
因本公司进项较多,现完成不了每月销售额度,
每月有一部 (国税、增值、 地税)等票。最优惠
代开或合作,点数较低.代开范围:(商品销售、广
告、运输、其它服务、租赁、建筑安装、餐饮
定额发票等)。可待您查验之后付款!期待与您的
合作！
联系人：张生
联系电话：13510115082。
[EMAIL PROTECTED]
Q Q：4 1 3 8 9 6 7 8 0
-
I am going to seperate my comments into individual replies to help
reduce the chance they are lost.
> +void mmu_notifier_release(struct mm_struct *mm)
...
> + hlist_for_each_entry_safe_rcu(mn, n, t,
> + &mm->mmu_notifier.head, hlist) {
> +
Hi;
29 Oca 2008 Sal tarihinde, Izik Eidus şunları yazmıştı:
> we better wait for qemu to merge it and then when we will merge with
> qemu cvs we will have it
OK fair enough, seems they submitted to qemu-devel yesterday by Aurelien Jarno
[1] [2], although xen merged these 3 months ago :(
[1] h
What is the status of getting invalidate_all adjusted to indicate a need
to also call _release?
Thanks,
Robin
On Mon, Jan 28, 2008 at 12:28:46PM -0800, Christoph Lameter wrote:
> when a task exits we can remove all external pts at once. At that point the
> extern mmu may also unregister itself fr
Carsten Otte wrote:
>> #include
>> @@ -118,6 +119,7 @@ struct kvm {
>> struct kvm_io_bus pio_bus;
>> struct kvm_vm_stat stat;
>> struct kvm_arch arch;
>> +struct mmu_notifier mmu_notifier;
>> };
>>
>> /* The guest did something we don't support. */
>>
> This should not b
The attached patch corrects a bug in qemu/slirp/tcp_var.h that defines
the seg_next field in struct tcpcb to be 32 bits wide regardless of
32/64-bitness. seg_next is assigned a pointer value in
qemu/slirp/tcp_subr.c, then cast back to a pointer in qemu/slirp/tcp_input.c
and dereferenced. That pr
On Mon, 2008-01-28 at 23:38 -0600, Jerone Young wrote:
> A patch I submitted yesterday to use the call qemu_kvm_cpu_env() in
> the dcr handles is not needed since in kvm_arch_post_kvm_run variable
> cpu_single_env is set to env. So just use cpu_single_env to get env.
>
> Signed-off-by: Jerone Youn
On Tue, Jan 29, 2008 at 06:24:12PM +0200, Avi Kivity wrote:
> Carsten Otte wrote:
>>> #include
>>> @@ -118,6 +119,7 @@ struct kvm {
>>> struct kvm_io_bus pio_bus;
>>> struct kvm_vm_stat stat;
>>> struct kvm_arch arch;
>>> + struct mmu_notifier mmu_notifier;
>>> };
>>>
>>> /* The g
Didn't realize s390 doesn't need those at all. Do you think
mmu_notifier.h should also go in asm/mmu_notifier? We can always move
them there later after merging with some compat code if needed.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kc
A Rose http://89.139.80.119/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Andrea Arcangeli wrote:
> Hello,
>
> I'm testing KVM swapping on top of Christoph's latest patch
> series. However the host is hanging hard for me. Could others test it?
>
i will ask alexey to run it
> I changed test-hardware, kernel version and kvm kernel version at the
> same time, so it mig
Hello,
I'm testing KVM swapping on top of Christoph's latest patch
series. However the host is hanging hard for me. Could others test it?
I changed test-hardware, kernel version and kvm kernel version at the
same time, so it might not be an issue with MMU Notifiers V2 but
something else with my ne
On Mon, Jan 28, 2008 at 12:28:44PM -0800, Christoph Lameter wrote:
> if (!migration && ((vma->vm_flags & VM_LOCKED) ||
> - (ptep_clear_flush_young(vma, address, pte {
> + (ptep_clear_flush_young(vma, address, pte) ||
> +
On Tue, Jan 29, 2008 at 11:28:00AM +0100, Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
> > Hmm, what kvm version is this against? latest git I guess? After
> > applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
>
> Looks like the mmu.h chunk is missing in the patch.
Yes
On Tue, Jan 29, 2008 at 07:04:59PM +0200, Avi Kivity wrote:
> Andrea Arcangeli wrote:
>> Didn't realize s390 doesn't need those at all. Do you think
>> mmu_notifier.h should also go in asm/mmu_notifier? We can always move
>> them there later after merging with some compat code if needed.
>>
>
>
On Mon, 2008-01-28 at 19:03 -0600, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1201568508 21600
> # Node ID a568d031723942e1baf77077031d2b77795cbd8a
> # Parent 5ce532cf9a1f711d1fecb42814d301abd37aa378
> Cleanup extern declerations for now removed v
Andrea Arcangeli wrote:
> Didn't realize s390 doesn't need those at all. Do you think
> mmu_notifier.h should also go in asm/mmu_notifier? We can always move
> them there later after merging with some compat code if needed.
>
s390 is the odd bird, not x86, so I'd like a solution that doesn't
i
Carsten Otte wrote:
> Avi Kivity wrote:
>> Every arch except s390 needs it. An ugly #ifndef
>> CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating the code.
> BTW, from reading AMDs spec I don't expect NPT to need this vehicle
> for swapping either. They can just let core-vm page out guest
On Tue, Jan 29, 2008 at 06:17:51PM +0100, Carsten Otte wrote:
> Andrea Arcangeli wrote:
>> Well I already moved that bit to x86, at least that had a good reason
>> for being moved there, it's really invisible code to s390. The memslot
>> are all but invisible to s390 instead, and so the locking rul
S.Çağlar Onur wrote:
> Hi;
>
> This patch (rediffed againg kvm-60) from Tavis Ormandy <[EMAIL PROTECTED]>
> fixes an infinite
> loop in the emulated SB16 device (See http://taviso.decsystem.org/virtsec.pdf
> for more details.)
>
> I'm not sure why qemu upstream not merged these but Xen already di
On Tue, Jan 29, 2008 at 05:35:34PM +0100, Carsten Otte wrote:
> Avi Kivity wrote:
> > Every arch except s390 needs it. An ugly #ifndef
> > CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating the code.
> BTW, from reading AMDs spec I don't expect NPT to need this vehicle
By your conclusion
Andrea Arcangeli wrote:
> On Tue, Jan 29, 2008 at 05:35:34PM +0100, Carsten Otte wrote:
>
>> Avi Kivity wrote:
>>
>>> Every arch except s390 needs it. An ugly #ifndef
>>> CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating the code.
>>>
>> BTW, from reading AMDs spec I don't e
Andrea Arcangeli wrote:
>
>> duplication for x86, ppc, and ia64.
>>
>
> There is a few lines of duplication yes, the bulk of the code was
> already only in x86.c and it has to stay there. It's only the few
> lines of registration we're talking about it, so I don't think the
> #ifdef would save
Hi,
What are the command-line options necessary to get the guest devices
to use the paravirt layer?
Thanks,
Cam
---
A. Cameron Macdonell
Ph.D. Student
Department of Computing Science
University of Alberta
[EMAIL PROTECTED]
--
On Tue, Jan 29, 2008 at 07:02:52PM +0200, Avi Kivity wrote:
> Carsten Otte wrote:
> >Avi Kivity wrote:
> >>Every arch except s390 needs it. An ugly #ifndef
> >>CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating
> >>the code.
> >BTW, from reading AMDs spec I don't expect NPT to need this ve
Andrea Arcangeli wrote:
> Didn't realize s390 doesn't need those at all. Do you think
> mmu_notifier.h should also go in asm/mmu_notifier? We can always move
> them there later after merging with some compat code if needed.
No I think mmu_notifier.h is fine in include/linux. I just think kvm
shoul
The npt patches started me thinking on large page support (2MB/4MB
pages), and I think we can implement them even when npt/ept are not
available.
Here's a rough sketch of my proposal:
- For every memory slot, allocate an array containing one int for every
potential large page included within t
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>>
>>> PCI-e has a common reset concept (warm and cold). I've been looking
>>> around and I can't seem to find any common reset mechanism for PCI.
>>> Is FLR something that is per-device or a standard PCI mechanism? If
>>>
Joerg Roedel wrote:
> Explicitly enable the NM intercept in svm_set_cr0 if we enable TS in the guest
> copy of CR0 for lazy FPU switching. This fixes guest SMP with Linux under SVM.
> Without that patch Linux deadlocks or panics right after trying to boot the
> other CPUs.
>
Applied, thanks.
-
On Tue, Jan 29, 2008 at 02:59:14PM +0100, Andrea Arcangeli wrote:
> The down_write is garbage. The caller should put it around
> mmu_notifier_register if something. The same way the caller should
> call synchronize_rcu after mmu_notifier_register if it needs
> synchronous behavior from the notifier
On Tue, Jan 29, 2008 at 05:35:34PM +0100, Carsten Otte wrote:
> Avi Kivity wrote:
> > Every arch except s390 needs it. An ugly #ifndef
> > CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating the code.
> BTW, from reading AMDs spec I don't expect NPT to need this vehicle
> for swapping eithe
Avi Kivity wrote:
> Every arch except s390 needs it. An ugly #ifndef
> CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating the code.
Yea I guess you've got a point there. The struct should be in struct
kvm, but the call to initialize/destroy it should go out to arch_init.
-
Andrea Arcangeli wrote:
> Well I already moved that bit to x86, at least that had a good reason
> for being moved there, it's really invisible code to s390. The memslot
> are all but invisible to s390 instead, and so the locking rules of the
> memslots should be common as long as memslots remains a
On Mon, Jan 28, 2008 at 12:28:42PM -0800, Christoph Lameter wrote:
> Index: linux-2.6/mm/fremap.c
> ===
> --- linux-2.6.orig/mm/fremap.c2008-01-25 19:31:05.0 -0800
> +++ linux-2.6/mm/fremap.c 2008-01-25 19:32:49.000
I don't understand how this is intended to work. I think the page flag
needs to be maintained by the mmu_notifier subsystem.
Let's assume we have a mapping that has a grant from xpmem and an
additional grant from kvm. The exporters are not important, the fact
that there may be two is.
Assume th
Avi Kivity wrote:
> Every arch except s390 needs it. An ugly #ifndef
> CONFIG_KVM_HARDWARE_TLB_SYNC is preferred to duplicating the code.
BTW, from reading AMDs spec I don't expect NPT to need this vehicle
for swapping either. They can just let core-vm page out guest pages
and will receive a pr
Christoph, the below patch should fix the current leak of the pinned
pages. I hope the page-pin that should be dropped by the
invalidate_range op, is enough to prevent the "physical page" mapped
on that "mm+address" to change before invalidate_range returns. If
that would ever happen, there would b
On Tue, Jan 29, 2008 at 11:55:10AM -0800, Christoph Lameter wrote:
> I am not sure. AFAICT you wrote that code.
Actually I didn't need to change a single line in do_wp_page because
ptep_clear_flush was already doing everything transparently for
me. This was the memory.c part of my last patch I pos
Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
>
>>> + struct mmu_notifier_head mmu_notifier; /* MMU notifier list */
>>> };
>>>
>> Not sure why you prefer to waste ram when MMU_NOTIFIER=n, this is a
>> regression (a minor one though).
>>
>
> Andrew does
On Tue, Jan 29, 2008 at 01:35:58PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > > It seems to be okay to invalidate range if you hold mmap_sem writably. In
> > > that case no additional faults can happen that would create new ptes.
> >
> > In that place th
On Tue, Jan 29, 2008 at 12:30:06PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > diff --git a/mm/fremap.c b/mm/fremap.c
> > --- a/mm/fremap.c
> > +++ b/mm/fremap.c
> > @@ -212,8 +212,8 @@ asmlinkage long sys_remap_file_pages(uns
> > spin_unlock(&m
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> diff --git a/mm/fremap.c b/mm/fremap.c
> --- a/mm/fremap.c
> +++ b/mm/fremap.c
> @@ -212,8 +212,8 @@ asmlinkage long sys_remap_file_pages(uns
> spin_unlock(&mapping->i_mmap_lock);
> }
>
> + err = populate_range(mm, vma, start
On Tue, 29 Jan 2008, Robin Holt wrote:
> What is the status of getting invalidate_all adjusted to indicate a need
> to also call _release?
Release is only called if the mmu_notifier is still registered. If you
take it out on invalidate_all then there will be no call to release
(provided you dea
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> > + mmu_notifier(invalidate_range, mm, address,
> > + address + PAGE_SIZE - 1, 0);
> > page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
> > if (likely(pte_same(*page_table, orig_pte))) {
> > if
On Tue, Jan 29, 2008 at 07:19:18PM +0100, Joerg Roedel wrote:
> Since NPT uses the host page table format it is in theory possible to
> add the pagetable to the Linux MM rmap. In this case it would not be
> necessary to use MMU notifiers. But I think this would complicate the
> NPT support code sig
On Tue, Jan 29, 2008 at 08:05:20PM +0200, Avi Kivity wrote:
> If a hypervisor mandates (host virtual) == (guest physical), it would work.
> x86 still misses the dual-tagged tlb, so mmu notifiers are needed
> regardless. With s390, they have an additional offset parameter, so (host
Yep. NPT is
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> > + struct mmu_notifier_head mmu_notifier; /* MMU notifier list */
> > };
>
> Not sure why you prefer to waste ram when MMU_NOTIFIER=n, this is a
> regression (a minor one though).
Andrew does not like #ifdefs and it makes it possible to verify c
Thanks I will put that into V3.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> > It seems to be okay to invalidate range if you hold mmap_sem writably. In
> > that case no additional faults can happen that would create new ptes.
>
> In that place the mmap_sem is taken but in readonly mode. I never rely
> on the mmap_sem in the
On Tue, Jan 29, 2008 at 01:53:05PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > > We invalidate the range *after* populating it? Isnt it okay to establish
> > > references while populate_range() runs?
> >
> > It's not ok because that function can very well
On Tue, 2008-01-29 at 10:50 -0700, Cameron Macdonell wrote:
> Hi,
>
> What are the command-line options necessary to get the guest devices
> to use the paravirt layer?
>
For network you use '-net nic,model=virtio',
I hope to write a wiki page for it tomorrow.
> Thanks,
> Cam
>
> ---
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> > We invalidate the range *after* populating it? Isnt it okay to establish
> > references while populate_range() runs?
>
> It's not ok because that function can very well overwrite existing and
> present ptes (it's actually the nonlinear common case
n Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> hmm, "there" where? When I said it was taken in readonly mode I meant
> for the quoted code (it would be at the top if it wasn't cut), so I
> quote below again:
>
> > > + mmu_notifier(invalidate_range, mm, address,
> > > +
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> But now I think there may be an issue with a third thread that may
> show unsafe the removal of invalidate_page from ptep_clear_flush.
>
> A third thread writing to a page through the linux-pte and the guest
> VM writing to the same page through the
On Tue, 2008-01-29 at 16:46 -0600, Anthony Liguori wrote:
> The following patch eliminates almost all uses of #ifdef USE_KVM by
> introducing a kvm_enabled() macro. If USE_KVM is set, this macro
> evaluates to kvm_allowed. If USE_KVM isn't set, the macro evaluates to
> 0.
This is badly needed IMH
All,
Attached is a patch that fixes the first (of at least a couple) migration
problem that I am running into. Basically, using the setup I described in my
last post, I was always getting "Disabling IRQ #11" once the guest reached the
destination side, and then no further activity. Dumping t
Hollis Blanchard wrote:
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -67,7 +67,9 @@ void kvm_io_bus_register_dev(struct kvm_
>
> struct kvm_vcpu {
> struct kvm *kvm;
> +#ifdef CONFIG_PREEMPT_NOTIFI
This removes an unnecessary include of linux/kvm.h which happens to silence
a warning introduced by my previous patch :-)
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d798841..048054b 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@
On Tue, Jan 29, 2008 at 02:55:56PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > But now I think there may be an issue with a third thread that may
> > show unsafe the removal of invalidate_page from ptep_clear_flush.
> >
> > A third thread writing to a page
On Tue, Jan 29, 2008 at 02:39:00PM -0800, Christoph Lameter wrote:
> If it does not run in write mode then concurrent faults are permissible
> while we remap pages. Weird. Maybe we better handle this like individual
> page operations? Put the invalidate_page back into zap_pte. But then there
> wo
On Tue, 2008-01-29 at 18:22 -0500, Chris Lalancette wrote:
> Hollis Blanchard wrote:
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -67,7 +67,9 @@ void kvm_io_bus_register_dev(struct kvm_
> >
> > s
This is not really going to work out if we want to merge with QEMU. We can't
have magic in QEMU that relies on some external define being set.
Since the define is needed by linux/kvm.h the solution is to define it as
needed before including linux/kvm.h. This probably depends on my previous
patch
On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
> On Wed, Jan 30, 2008 at 01:00:39AM +0100, Andrea Arcangeli wrote:
> > get_user_pages, regular linux writes don't fault unless it's
> > explicitly writeprotect, which is mandatory in a few archs, x86 not).
>
> actually get_user_pages doesn't fault eit
On Tue, Jan 29, 2008 at 04:20:50PM -0800, Christoph Lameter wrote:
> On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
>
> > > invalidate_range after populate allows access to memory for which ptes
> > > were zapped and the refcount was released.
> >
> > The last refcount is released by the invalidat
On Wed, Jan 30, 2008 at 01:00:39AM +0100, Andrea Arcangeli wrote:
> get_user_pages, regular linux writes don't fault unless it's
> explicitly writeprotect, which is mandatory in a few archs, x86 not).
actually get_user_pages doesn't fault either but it calls into
set_page_dirty, however get_user_p
On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
> > A user space spinlock plays into this??? That is irrelevant to the kernel.
> > And we are discussing "your" placement of the invalidate_range not mine.
>
> With "my" code, invalidate_range wasn't placed there at all, my
> modification to ptep_clea
On Tue, 29 Jan 2008, Jack Steiner wrote:
> > That is true for your implementation and to address Robin's issues. Jack:
> > Is that true for the GRU?
>
> I'm not sure I understand the question. The GRU never (currently) takes
> a reference on a page. It has no mechanism for tracking pages that
>
On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
> > invalidate_range after populate allows access to memory for which ptes
> > were zapped and the refcount was released.
>
> The last refcount is released by the invalidate_range itself.
That is true for your implementation and to address Robin's is
On Tue, Jan 29, 2008 at 04:22:46PM -0800, Christoph Lameter wrote:
> That is only partially true. pte are created wronly in order to track
> dirty state these days. The first write will lead to a fault that switches
> the pte to writable. When the page undergoes writeback the page again
> become
This patch sucks. Let me finish up playing around with this stuff and
I'll send out a better one.
Regards,
Anthony Liguori
Anthony Liguori wrote:
> This removes an unnecessary include of linux/kvm.h which happens to silence
> a warning introduced by my previous patch :-)
>
> Signed-off-by: Ant
On Tue, 2008-01-29 at 18:22 -0500, Chris Lalancette wrote:
> Hollis Blanchard wrote:
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -67,7 +67,9 @@ void kvm_io_bus_register_dev(struct kvm_
> >
> >
Anthony Liguori wrote:
> This patch attempts to clean up the interactions between KVM and
> QEMU. Sorry
> for such a big patch, but I don't think there's a better way to
> approach this
> such that it's still bisect friendly. I think this is most of what's
> needed to
> get basic KVM support i
Problem for external rmaps: There is no pagelock held on the page.
Signed-off-by: Robin Holt <[EMAIL PROTECTED]>
---
mm/filemap_xip.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6/mm/filemap_xip.c
===
--- linux-2.6
Callbacks to remove individual pages if the subsystem has an
rmap capability. The pagelock is held but no spinlocks are held.
The refcount of the page is elevated so that dropping the refcount
in the subsystem will not directly free the page.
The callbacks occur after the Linux rmaps have been wal
when a task exits we can remove all external pts at once. At that point the
extern mmu may also unregister itself from the mmu notifier chain to avoid
future calls.
Note the complications because of RCU. Other processors may not see that the
notifier was unlinked until a quiescent period has passe
These notifiers here use the Linux rmaps to perform the callbacks.
In order to walk the rmaps locks must be held. Callbacks can therefore
only operate in an atomic context.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/rmap.c | 12 +---
1 file changed, 9 insertions(+), 3
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
---
include/linux/list.h | 14 ++
include/linux/mm_types.h |6 +
include/linux/mmu_notifier.h | 210 +++
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
Most of the VM address space changes can use the range invalidate
callback.
invalidate_range() is generally called with mmap_sem held but
no spinlocks are active. If invalidate
This is a patchset implementing MMU notifier callbacks based on Andrea's
earlier work. These are needed if Linux pages are referenced from something
else than tracked by the rmaps of the kernel. The known immediate users are
KVM (establishes a refcount to the page. External references called spte)
Scott Pakin wrote:
> The attached patch corrects a bug in qemu/slirp/tcp_var.h that defines
> the seg_next field in struct tcpcb to be 32 bits wide regardless of
> 32/64-bitness. seg_next is assigned a pointer value in
> qemu/slirp/tcp_subr.c, then cast back to a pointer in
> qemu/slirp/tcp_input.
This removes an unnecessary include of linux/kvm.h which happens to silence
a warning introduced by my previous patch :-) We have to move the ABI check
too until we've included libkvm.h.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d7988
91 matches
Mail list logo
