Am Donnerstag, 31. Januar 2008 schrieb Anthony Liguori:
> There's are some other limitations to the number of virtio block
> devices. For instances...
>
> > sprintf(vblk->disk->disk_name, "vd%c", virtblk_index++);
>
> This gets bogus after 64 disks.
Right. I will fix that with an additio
Two callbacks to remove individual pages as done in rmap code
invalidate_page()
Called from the inner loop of rmap walks to invalidate pages.
age_page()
Called for the determination of the page referenced status.
If we do not care about page referenced status then an age_page c
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 (an external MMU).
The known immediate users are
KVM
- Establishes a refcount to the page via get_user_
Support for an additional 3rd class of users of mmu_notifier.
These special additional callbacks are required because XPmem does
use its own rmap (multiple processes on a serires of remote Linux instances
may be accessing the memory of a process). XPmem may have to send out
notifications to remote
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
invalidate_range_begin/end() is frequently called with only mmap_sem
held. If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to
Notifier functions for hardware and software that establishes external
references to pages of a Linux system. The notifier calls ensure that
external mappings are removed when the Linux VM removes memory ranges
or individual pages from a process.
This first portion is fitting for external mmu's th
On Thu, 31 Jan 2008, Robin Holt wrote:
> > Index: linux-2.6/mm/memory.c
> ...
> > @@ -1668,6 +1678,7 @@ gotten:
> > page_cache_release(old_page);
> > unlock:
> > pte_unmap_unlock(page_table, ptl);
> > + mmu_notifier(invalidate_range_end, mm, 0);
>
> I think we can get an _end c
> Index: linux-2.6/mm/memory.c
...
> @@ -1668,6 +1678,7 @@ gotten:
> page_cache_release(old_page);
> unlock:
> pte_unmap_unlock(page_table, ptl);
> + mmu_notifier(invalidate_range_end, mm, 0);
I think we can get an _end call without the _begin call before it.
Thanks,
Robi
?=
Date: Fri, 01 Feb 2008 12:19:50 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_001_0018_01C39816.2C871AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.110
On Thu, Jan 31, 2008 at 07:58:40PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Robin Holt wrote:
>
> > > + void (*invalidate_range_end)(struct mmu_notifier *mn,
> > > + struct mm_struct *mm, int atomic);
> >
> > I think we need to pass in the same start-end her
Akio Takebe wrote:
> Hi, Xiantao
>
>> +void thash_vhpt_insert(VCPU *v, u64 pte, u64 itir, u64 va, int
>> type) +{ + u64 phy_pte, psr;
>> +ia64_rr mrr;
>> +
>> +mrr.val = ia64_get_rr(va);
>> +phy_pte = translate_phy_pte(&pte, itir, va);
>> +
>> +if (itir_ps(itir) >= mrr.ps) {
>> +
Hi, Xiantao
>+void thash_vhpt_insert(VCPU *v, u64 pte, u64 itir, u64 va, int type)
>+{
>+ u64 phy_pte, psr;
>+ ia64_rr mrr;
>+
>+ mrr.val = ia64_get_rr(va);
>+ phy_pte = translate_phy_pte(&pte, itir, va);
>+
>+ if (itir_ps(itir) >= mrr.ps) {
>+ vhpt_insert(phy
Hi, Xiantao
>> Why do you remove ia64_srlz_d()?
>> We should need srlz.d if we change PSR bits(e.g. PSR.dt and so on).
>> Does srlz.i do also date serialization?
>Hi, Akio
>Srlz.i implicitly ensures srlz.d per SDM.
OK, thanks.
Best Regards,
Akio Takebe
-
On Thu, 31 Jan 2008, Robin Holt wrote:
> > + void (*invalidate_range_end)(struct mmu_notifier *mn,
> > +struct mm_struct *mm, int atomic);
>
> I think we need to pass in the same start-end here as well. Without it,
> the first invalidate_range would have to block fa
> Index: linux-2.6/include/linux/mmu_notifier.h
...
> +struct mmu_notifier_ops {
...
> + /*
> + * invalidate_range_begin() and invalidate_range_end() must paired.
> + * Multiple invalidate_range_begin/ends may be nested or called
> + * concurrently. That is legit. However, no new
Akio Takebe wrote:
> Hi, Xiantao
>
>> void __init
>> diff --git a/include/asm-ia64/processor.h
>> b/include/asm-ia64/processor.h index be3b0ae..038642f 100644 ---
>> a/include/asm-ia64/processor.h +++ b/include/asm-ia64/processor.h
>> @@ -472,7 +472,7 @@ ia64_set_psr (__u64 psr)
>> {
>> ia64_
On Thu, 31 Jan 2008, Jack Steiner wrote:
> I currently unlink the mmu_notifier when the last GRU mapping is closed. For
> example, if a user does a:
>
> gru_create_context();
> ...
> gru_destroy_context();
>
> the mmu_notifier is unlinked and all task tables allocated
> b
On Thu, 31 Jan 2008, Robin Holt wrote:
> Both xpmem and GRU have means of removing their context seperate from
> process termination. XPMEMs is by closing the fd, I believe GRU is
> the same. In the case of XPMEM, we are able to acquire the mmap_sem.
> For GRU, I don't think it is possible, but
On Thu, Jan 31, 2008 at 06:39:19PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Robin Holt wrote:
>
> > Jack has repeatedly pointed out needing an unregister outside the
> > mmap_sem. I still don't see the benefit to not having the lock in the mm.
>
> I never understood why this would
Hi, Xiantao
> void __init
>diff --git a/include/asm-ia64/processor.h b/include/asm-ia64/processor.h
>index be3b0ae..038642f 100644
>--- a/include/asm-ia64/processor.h
>+++ b/include/asm-ia64/processor.h
>@@ -472,7 +472,7 @@ ia64_set_psr (__u64 psr)
> {
> ia64_stop();
> ia64_setreg(_IA6
On Thu, Jan 31, 2008 at 06:39:19PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Robin Holt wrote:
>
> > Jack has repeatedly pointed out needing an unregister outside the
> > mmap_sem. I still don't see the benefit to not having the lock in the mm.
>
> I never understood why this would
Scott Pakin wrote:
> Zhang, Xiantao wrote:
>> 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,
On Thu, 31 Jan 2008, Robin Holt wrote:
> On Thu, Jan 31, 2008 at 05:57:25PM -0800, Christoph Lameter wrote:
> > Move page tables also needs to invalidate the external references
> > and hold new references off while moving page table entries.
>
> I must admit to not having spent any time thinking
On Thu, 31 Jan 2008, Jack Steiner wrote:
> Christoph, is it time to post a new series of patches? I've got
> as many fixup patches as I have patches in the original posting.
Maybe wait another day? This is getting a bit too frequent and so far we
have only minor changes.
--
On Thu, 31 Jan 2008, Robin Holt wrote:
> Jack has repeatedly pointed out needing an unregister outside the
> mmap_sem. I still don't see the benefit to not having the lock in the mm.
I never understood why this would be needed. ->release removes the
mmu_notifier right now.
---
On Thu, Jan 31, 2008 at 05:57:25PM -0800, Christoph Lameter wrote:
> Move page tables also needs to invalidate the external references
> and hold new references off while moving page table entries.
I must admit to not having spent any time thinking about this, but aren't
we moving the entries from
On Thu, Jan 31, 2008 at 08:24:44PM -0600, Robin Holt wrote:
> On Thu, Jan 31, 2008 at 07:56:12PM -0600, Jack Steiner wrote:
> > > @@ -2033,6 +2034,7 @@ void exit_mmap(struct mm_struct *mm)
> > > unsigned long end;
> > >
> > > /* mm's last user has gone, and its about to be pulled down */
> >
Christoph,
Jack has repeatedly pointed out needing an unregister outside the
mmap_sem. I still don't see the benefit to not having the lock in the mm.
Thanks,
Robin
Index: mmu_notifiers-cl-v4/include/linux/mm_types.h
===
--- mmu_no
On Thu, 31 Jan 2008, Robin Holt wrote:
> > Mutex locking? Could you be more specific?
>
> I think he is talking about the external locking that xpmem will need
> to do to ensure we are not able to refault pages inside of regions that
> are undergoing recall/page table clearing. At least that has
On Thu, Jan 31, 2008 at 07:56:12PM -0600, Jack Steiner wrote:
> > @@ -2033,6 +2034,7 @@ void exit_mmap(struct mm_struct *mm)
> > unsigned long end;
> >
> > /* mm's last user has gone, and its about to be pulled down */
> > + mmu_notifier(invalidate_all, mm, 0);
> > arch_exit_mmap(mm
On Thu, Jan 31, 2008 at 05:37:21PM -0800, Christoph Lameter wrote:
> On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
>
> > I appreciate the review! I hope my entirely bug free and
> > strightforward #v5 will strongly increase the probability of getting
> > this in sooner than later. If something else
mmu_notifier: Provide invalidate_range for move_page_tables
Move page tables also needs to invalidate the external references
and hold new references off while moving page table entries.
This is already guaranteed by holding a writelock
on mmap_sem for get_user_pages() but follow_page() is not su
> @@ -2033,6 +2034,7 @@ void exit_mmap(struct mm_struct *mm)
> unsigned long end;
>
> /* mm's last user has gone, and its about to be pulled down */
> + mmu_notifier(invalidate_all, mm, 0);
> arch_exit_mmap(mm);
>
The name of the "invalidate_all" callout is not very descr
On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> On Thu, Jan 31, 2008 at 02:21:58PM -0800, Christoph Lameter wrote:
> > Is this okay for KVM too?
>
> ->release isn't implemented at all in KVM, only the list_del generates
> complications.
Why would the list_del generate problems?
> I think current
On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> Good catch! This was missing also in my #v5 (KVM doesn't need that
> because the only possible cows on sptes can be generated by ksm, but
> it would have been a problem for GRU). The more I think about it, the
How do you think the GRU should know when
On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> GRU. Thanks to the PT lock this remains a totally obviously safe
> design and it requires zero additional locking anywhere (nor linux VM,
> nor in the mmu notifier methods, nor in the KVM/GRU page fault).
Na. I would not be so sure about having caught
Blue Swirl wrote:
> On 1/30/08, Scott Pakin <[EMAIL PROTECTED]> wrote:
>> Zhang, Xiantao wrote:
>>> 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 i
On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> > The GRU not covered? Why would you think that way? mremap is covered
> > because of the callbacks in unmap_region().
>
> I wouldn't be so sure. ptep_clear_flush is called for a reason and you
> have zero range_start _before_ the ptep_clear_flush. I
I just noticed that my previous patch hit one of the subtleties that
Blue Swirl warned about. Changing caddr32_t causes the IP header and
IP header overlay to be different sizes, which essentially breaks
networking altogether.
I humbly offer the following patch, which fixes only the "easy" 32/64-
On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> I appreciate the review! I hope my entirely bug free and
> strightforward #v5 will strongly increase the probability of getting
> this in sooner than later. If something else it shows the approach I
> prefer to cover GRU/KVM 100%, leaving the overkill
> > Are the CMOS contents documented anywhere?
>
> No, but if you have a suggestion of where to document them, I'll add
> documentation.
I suggest in or with the BIOS sources.
As we're using a common BIOS it seems a good idea to make sure this kind of
things is coordinated.
Paul
---
Paul Brook wrote:
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
>>> This seems fairly arbitrary. Why? Any limit is certainly target specific.
>>>
>> On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
>> in virtual address space. On a 64-bi
> >> +#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
> >
> > This seems fairly arbitrary. Why? Any limit is certainly target specific.
>
> On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
> in virtual address space. On a 64-bit host, there isn't this
> fundamental
Paul Brook wrote:
>> -cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
>> +cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
>>
>
> smp_cpus is a global variable. Why bother passing it around?
>
True, I'll update the patch
> Are the CMOS contents documente
Paul Brook wrote:
> On Thursday 31 January 2008, Anthony Liguori wrote:
>
>> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
>> fixes a number of type related issues where int's were being used when they
>> shouldn't have been. It also introduces CMOS support so the
> -cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
> +cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
smp_cpus is a global variable. Why bother passing it around?
Are the CMOS contents documented anywhere?
Paul
On Thu, Jan 31, 2008 at 02:21:58PM -0800, Christoph Lameter wrote:
> Is this okay for KVM too?
->release isn't implemented at all in KVM, only the list_del generates
complications.
I think current code could be already safe through the mm_count pin,
becasue KVM relies on the fact anybody pinning
On Thu, Jan 31, 2008 at 02:01:43PM -0800, Christoph Lameter wrote:
> Talking to Robin and Jack we found taht we still have a hole during fork.
> Fork may set a pte writeprotect. At that point the remote pte are
> not marked readonly(!). Remote writes may occur to pages that are marked
> readonly
On Thursday 31 January 2008, Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been. It also introduces CMOS support so the BIOS can build
> the appropr
On Thu, Jan 31, 2008 at 03:09:55PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Christoph Lameter wrote:
>
> > > pagefault against the main linux page fault, given we already have all
> > > needed serialization out of the PT lock. XPMEM is forced to do that
> >
> > pt lock cannot serial
Bugs item #1883972, was opened at 2008-02-01 00:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1883972&group_id=180599
Please note that this message will contain a full copy
On Thu, Jan 31, 2008 at 12:21:34PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
>
> > I doubt Christoph's V4 was close to final yet, GRU wasn't covered at
> > all yet, not even mremap was covered at all (nor XPMEM nor GRU) in V4.
>
> The GRU not covered? Why woul
On Thu, Jan 31, 2008 at 12:18:54PM -0800, Christoph Lameter wrote:
> pt lock cannot serialize with invalidate_range since it is split. A range
> requires locking for a series of ptes not only individual ones.
The lock I take already protects up to 512 ptes yes. I call
invalidate_pages only across
On Thu, 31 Jan 2008, Christoph Lameter wrote:
> > pagefault against the main linux page fault, given we already have all
> > needed serialization out of the PT lock. XPMEM is forced to do that
>
> pt lock cannot serialize with invalidate_range since it is split. A range
> requires locking for a
FYI, for the new files introduced, Avi should be following up with a
patch to add Copyrights to the files. They will be licensed under the GPL.
Regards,
Anthony Liguori
Anthony Liguori wrote:
> KVM is a Linux interface for providing userspace interfaces for accelerated
> virtualization. It ha
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has been included since 2.6.20 and supports Intel VT and
AMD-V. Ports are under way for ia64, embedded PowerPC, and s390.
This set of patches provide basic support for KVM in QEMU. It does not include
KVM requires that any ROM memory be registerd through a second interface. This
patch refactors the option ROM loading to simplify adding KVM support (which
will follow in the next patch).
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
Index: qemu/hw/acpi.c
===
--- qemu.orig/hw/acpi.c 2008-01-30
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
Index: qemu/cpu-all.h
===
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be
very unreliably because of startup timing issues. By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.
Index: qemu/hw/pc.c
=
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
Index: qemu/vl.c
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1201818508 21600
# Node ID 739668b2f1913a381899d82912517a6568b6f30c
# Parent 5b553559aa641bf36b190541f775396ecdbf0e78
Update Copyrights on PowerPC KVM Qemu code.
I missed a copyright that needed to be in one file. Also I placed a
mmu_notifier: Move mmu_notifier_release up to get rid of invalidate_all()
It seems that it is safe to call mmu_notifier_release() before we tear down
the pages and the vmas since we are the only executing thread.
mmu_notifier_release
can then also tear down all its external ptes and thus we can g
mmu_notifier: Reduce size of mm_struct if !CONFIG_MMU_NOTIFIER
Andrea and Peter had a concern about this.
Use an #ifdef to make the mmu_notifer_head structure empty if we have
no notifier. That allows the use of the structure in inline functions
(which allows parameter verification even if !CONFI
Talking to Robin and Jack we found taht we still have a hole during fork.
Fork may set a pte writeprotect. At that point the remote pte are
not marked readonly(!). Remote writes may occur to pages that are marked
readonly locally without this patch.
mmu_notifier: Provide invalidate_range on for
Christian Borntraeger wrote:
> Rusty,
>
> currently virtio_blk uses one major number per device. While this works
> quite well on most systems it is wasteful and will exhaust major numbers
> on larger installations.
>
> This patch allocates a major number on init and will use 16 minor numbers
> f
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> I doubt Christoph's V4 was close to final yet, GRU wasn't covered at
> all yet, not even mremap was covered at all (nor XPMEM nor GRU) in V4.
The GRU not covered? Why would you think that way? mremap is covered
because of the callbacks in unmap_regi
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> My suggestion is to add the invalidate_range_start/end incrementally
> with this, and to keep all the xpmem mmu notifiers in a separate
> incremental patch (those are going to require many more changes to
> perfect). They've very different things. GRU
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> On Wed, Jan 30, 2008 at 08:57:52PM -0800, Christoph Lameter wrote:
> > @@ -211,7 +212,9 @@ asmlinkage long sys_remap_file_pages(uns
> > spin_unlock(&mapping->i_mmap_lock);
> > }
> >
> > + mmu_notifier(invalidate_range_begin, mm, st
On Thu, Jan 31, 2008 at 01:58:42PM +0100, Andrea Arcangeli wrote:
> It might also be something stale in the buildsystem (perhaps a distcc
> of ccache glitch?), I also cleared 1G of ccache just to be sure in
My build problem might have been related to the fact the
kvm-userland/kernel/include direct
Zhang, Xiantao wrote:
> Unfortunately, it can's apply on tip. Could you attach the diff ?
It works for me:
$ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
remote: Generating pack...
remote: Done counting 37449 objects.
remote: Deltifying 37449 objects...
remote: 100% (37449/3
Avi Kivity wrote:
> It has the advantage of not falsely triggering any unshadowing
> heuristics, and of avoiding the lovely x86 emulator. Not sure how big
> that advantage is, though.
Fair enough. But doing partial pte updates needs an update-with-mask
hypercall (or something) to prevent the
Hi,
Usual patch but adapted to mmu notifier #v5, works fine here as
expected.
I doubt Christoph's V4 was close to final yet, GRU wasn't covered at
all yet, not even mremap was covered at all (nor XPMEM nor GRU) in V4.
The first workable APIs for XPMEM (to close the SMP race I explained
since exp
GRU should implement at least invalidate_page and invalidate_pages,
and it should be mostly covered with that.
My suggestion is to add the invalidate_range_start/end incrementally
with this, and to keep all the xpmem mmu notifiers in a separate
incremental patch (those are going to require many mo
Zhang, Xiantao wrote:
> Hi, Avi/Tony
> We have rebased kvm/ia64 code to latest kvm. In this version, we
> have fixed coding style issues, and all patches can pass checkpatch.pl,
> except one assembly header file, which is copyied from kernel, so we
> didn't change its issues.
> Compared with
Markus Armbruster wrote:
> As far as OProfile is concerned: we can make it work with whatever
> kind of virtual PMU we want, without a complete CPU fake. It just
> needs to be able to detect our virtual PMU.
>
>
Well, if the virtual PMU happens to match exactly the physical
architectural PMU,
Joerg Roedel wrote:
> This series of patches fixes a boot problem with PAE guests on a 32 bit
> KVM host. These guests try to access the EFER register when running on AMD,
> get
> an GP and crashing very soon in the boot process. These patches fix that. They
> were tested with 32 bit legacy and PA
[Note cc: Will, who knows much more about OProfile than I do]
Avi Kivity <[EMAIL PROTECTED]> writes:
> Markus Armbruster wrote:
>> Avi Kivity <[EMAIL PROTECTED]> writes:
>>
>>
>>> Markus Armbruster wrote:
>>>
System-wide profiling of the *virtual* machine is related to profiling
Rusty,
currently virtio_blk uses one major number per device. While this works
quite well on most systems it is wasteful and will exhaust major numbers
on larger installations.
This patch allocates a major number on init and will use 16 minor numbers
for each disk. That will allow ~64k virtio_blk
To allow access to the EFER register in 32bit KVM the EFER specific code has to
be exported to the x86 generic code. This patch does this in a backwards
compatible manner.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c |8
1 files changed, 0 insertions(+), 8 d
This series of patches fixes a boot problem with PAE guests on a 32 bit
KVM host. These guests try to access the EFER register when running on AMD, get
an GP and crashing very soon in the boot process. These patches fix that. They
were tested with 32 bit legacy and PAE Linux and Vista 32 bit.
Joer
This patch makes the EFER register accessible on a 32bit KVM host. This is
necessary to boot 32 bit PAE guests under SVM.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/
This patch aligns the bits the guest can set in the EFER register with the
features in the host processor. Currently it lets EFER.NX disabled if the
processor does not support it and enables EFER.LME and EFER.LMA only for KVM on
64 bit hosts.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
ar
This patch give the SVM and VMX implementations the ability to add some bits
the guest can set in its EFER register.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |9 -
include/asm-x86/kvm_host.h |1 +
2 files changed, 9 insertions(+), 1 deletions(
On Wed, Jan 30, 2008 at 06:51:26PM -0800, Christoph Lameter wrote:
> True. hlist_del_init ok? That would allow to check the driver that the
> mmu_notifier is already linked in using !hlist_unhashed(). Driver then
> needs to properly initialize the mmu_notifier list with INIT_HLIST_NODE().
A driv
On Thu, Jan 31, 2008 at 12:34:37PM +0200, Avi Kivity wrote:
> I see. Will merge that patch, thanks.
Thanks. BTW, with this fix I finally got KVM swapping 100% stable
on my test system.
However I had to rollback everything: I'm using my last mmu notifier
patch (not Christoph's ones), my mmu locki
On Wed, Jan 30, 2008 at 08:57:52PM -0800, Christoph Lameter wrote:
> @@ -211,7 +212,9 @@ asmlinkage long sys_remap_file_pages(uns
> spin_unlock(&mapping->i_mmap_lock);
> }
>
> + mmu_notifier(invalidate_range_begin, mm, start, start + size, 0);
> err = populate_range(
Rename smptest.c so it matches the right stem for building smp.flat
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
user/config-x86-common.mak |2 +-
user/test/x86/{smptest.c => smp.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename user/test/x86/{s
Fixes :
test/x86/access.c:577: warning: passing argument 1 of 'smp_init' from
incompatible pointer type
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
user/test/x86/lib/smp.c |4 ++--
user/test/x86/lib/smp.h |2 +-
user/test/x86/smptest.c |3 ++-
3 files change
The following series fixes the last remaining warning from the testsuite in
x86 and together with it the make rules for building the other test case
affected by this changes :
PATCH 1/2 : make smp_init parameter be a function that returns int
PATCH 2/2 : fix building smp.flat
Tested in x86_64
On Wed, Jan 30, 2008 at 05:46:21PM -0800, Christoph Lameter wrote:
> Well the GRU uses follow_page() instead of get_user_pages. Performance is
> a major issue for the GRU.
GRU is a external TLB, we have to allocate RAM instead but we do it
through the regular userland paging mechanism. Performan
Carlo Marcelo Arenas Belon wrote:
[I forgot to reply to the this:]
>>> --- kvm-60/user/test/x86/access.c
>>> +++ kvm-60/user/test/x86/access.c 2008/01/24 15:14:16
>>> @@ -1,6 +1,7 @@
>>>
>>> #include "smp.h"
>>> #include "printf.h"
>>> +#include "string.h"
>>>
>>> #define true 1
>>> #def
Carlo Marcelo Arenas Belon wrote:
> On Thu, Jan 24, 2008 at 06:21:56PM +0200, Avi Kivity wrote:
>
>> Bernhard Kaindl wrote:
>>
>>> I did not test this patch as I did not find documentation on how to run the
>>> test cases and I could not find a make target to run them from make.
>>>
>>>
Andrea Arcangeli wrote:
> On Thu, Jan 31, 2008 at 08:50:01AM +0200, Avi Kivity wrote:
>
>> This is surprising. pagefault_disable() is really a preempt_disable(), and
>> kvm_read_guest_atomic() should only be called from atomic contexts (with
>> preemption already disabled), no?
>>
>
> _s
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 14:03:04 +0800
Subject: [PATCH] kvm: ia64 : Export some symbols out for module use.
Export empty_zero_page, ia64_sal_cache_flush, ia64_sal_freq_base
in this patch.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/ker
Hi, Avi/Tony
We have rebased kvm/ia64 code to latest kvm. In this version, we
have fixed coding style issues, and all patches can pass checkpatch.pl,
except one assembly header file, which is copyied from kernel, so we
didn't change its issues.
Compared with last version, we implemented sm
Perfect stamins and hardness! http://76.114.107.60/kvjjm/
-
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/
__
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 29 Jan 2008 14:26:29 +0800
Subject: [PATCH] kvm/ia64: Add TLB virtulization support.
vtlb.c includes tlb/VHPT virtulization.
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kvm/vtlb.c |
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 17:10:52 +0800
Subject: [PATCH] Add API for allocating TR resouce.
Dynamic TR resouce should be managed in an uniform way.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
Signed-off-by: Anthony Xu<[EMAIL PROTECTED]>
---
arch/ia64/ker
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 29 Jan 2008 15:40:27 +0800
Subject: [PATCH] kvm/ia64: Update IA64 Kconfig and Makefile to include
kvm build.
Update IA64 Kconfig and Makefile to include kvm build.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/Kconfig |6 +++
1 - 100 of 118 matches
Mail list logo
