On Fri, Feb 15, 2008 at 12:17:39AM +0100, Marcelo Tosatti wrote:
>
> On Wed, Feb 13, 2008 at 08:45:51AM +0200, Avi Kivity wrote:
> > >gfn_to_page() needs to grab the struct page corresponding to the large
> > >page, not the offset struct page for the faulting 4k address within
> > >the large frame
Hi,
this issue has already been talked about previously. Gfxboot on VMX is
broken, because it reads SS after switching from real to protected mode,
where SS contains an invalid value, which VMX does not allow.
As far as I know, gfxboot is the only application that suffers from this
issue.
The curr
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to indicate that no sleeping is
possible. Locks are only held for truncate and
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
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have to send out notifications to remote Linux instances
and receive
The skeleton for the rmap notifier leaves the invalidate_page method of
the mmu_notifier empty and hooks a new invalidate_page callback into the
global chain for mmu_rmap_notifiers.
There are seveal simplifications in here to avoid making this too complex.
The reverse maps need to consit of refere
This is example code for a simple device driver interface to unmap
pages that were externally mapped.
Locking is simple through a single lock that is used to protect the
device drivers data structures as well as a counter that tracks the
active invalidates on a single address space.
The invalidat
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such as DMA engines, scatter gather devices, networking,
sharing of address spaces across
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). MMU
notifiers allow us to get rid of the page pinning for RDMA and various
other purpo
Liu, Eric E wrote:
>> From e4fae3b29b694a489638b00214fc41530092c3d1 Mon Sep 17 00:00:00
>> 2001
> From: Feng (Eric) Liu <[EMAIL PROTECTED]>
> Date: Sat, 16 Feb 2008 03:41:17 -0500
> Subject: [PATCH] kvm: Fix building error of preempt.c
>
> current kernel code has merged the file processor_32.h an
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Fri, 15 Feb 2008 10:50:22 +0800
Subject: [PATCH] qemu: IA64 also need to workaround tcg code.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
qemu/dyngen.c|1 -
qemu/hw/ipf.c|1 -
qemu/target-ia64/fake-exec.
Dear,
We released new VMKNOPPIX for x86 (20080213).
http://unit.aist.go.jp/itri/knoppix/vmknoppix/index-en.html
Guide-PDF
http://unit.aist.go.jp/itri/knoppix/vmknoppix/VMKnoppix-x86-20080213e.pdf
# Special Features
* Xen3.2.0, KVM60, and QEMU091 are upgraded.
* Xen3.2.0 has a vTPM (TPM
>From e4fae3b29b694a489638b00214fc41530092c3d1 Mon Sep 17 00:00:00 2001
From: Feng (Eric) Liu <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 03:41:17 -0500
Subject: [PATCH] kvm: Fix building error of preempt.c
current kernel code has merged the file processor_32.h and
processor_64.h
to processor.h, so
On Thu, 14 Feb 2008, Caitlin Bestler wrote:
> So any solution that requires the upper layers to suspend operations
> for a brief bit will require explicit interaction with those layers.
> No RDMA layer can perform the sleight of hand tricks that you seem
> to want it to perform.
Looks like it has
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
kvm-devel@lists.sourceforge.net
Domain restaurandoisrael.com.br has exceeded the ma
> -Original Message-
> From: Christoph Lameter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 14, 2008 2:49 PM
> To: Caitlin Bestler
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
> [EMAIL PROTECTED]; kvm-devel@lists.sourceforge.net
> Subject: Re: [ofa-general] Re: D
the cr3 variable is now inside the vcpu->arch structure.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm.largepages/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1219,7 +1219,7
alloc_apic_access_page() can sleep, while vmx_vcpu_setup is called
inside a non preemptable region. Move it after put_cpu().
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: linux-2.6-x86-kvm/arch/x86/kvm/vmx.c
===
--- linu
On Wed, Feb 13, 2008 at 08:45:51AM +0200, Avi Kivity wrote:
> >gfn_to_page() needs to grab the struct page corresponding to the large
> >page, not the offset struct page for the faulting 4k address within
> >the large frame. Since gfn_to_page can sleep, there is no way to do
> >that in the mapping
On Thu, 14 Feb 2008, Caitlin Bestler wrote:
> I have no problem with that, as long as the application layer is responsible
> for
> tearing down and re-establishing the connections. The RDMA/transport layers
> are incapable of tearing down and re-establishing a connection transparently
> because c
On Thu, Feb 14, 2008 at 12:20 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2008, Caitlin Bestler wrote:
>
> > So suspend/resume to re-arrange pages is one thing. Suspend/resume to cover
> > swapping out pages so they can be reallocated is an exercise in futility.
> By the
>
Le jeudi 14 février 2008 à 23:46 +0200, Dor Laor a écrit :
> On Thu, 2008-02-14 at 12:08 -0500, Andrey Dmitriev wrote:
> > If I want to stick to debian, would the best way to do this be to just
> > download kvm60 source, compile the module and load it in, or does
> > kernel still require upgrading
On Thu, 2008-02-14 at 12:08 -0500, Andrey Dmitriev wrote:
> If I want to stick to debian, would the best way to do this be to just
> download kvm60 source, compile the module and load it in, or does
> kernel still require upgrading (I think latest on etch is .18 not .20)
You can stay with debain,
On Thu, 14 Feb 2008, Caitlin Bestler wrote:
> So suspend/resume to re-arrange pages is one thing. Suspend/resume to cover
> swapping out pages so they can be reallocated is an exercise in futility. By
> the
> time you resume the connections will be broken or at the minimum damaged.
The connectio
On Thu, Feb 14, 2008 at 11:39 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2008, Steve Wise wrote:
>
> > Note that for T3, this involves suspending _all_ rdma connections that are
> in
> > the same PD as the MR being remapped. This is because the driver doesn't
> know
> >
We're having a hard time tracking down a PowerPC bug that seems to be
related to KVM's signal handling (SIGALRM in particular), so we're
trying to understand the overall signal handling design.
It looks like the run sequence goes something like this:
1. qemu: block SIGALRM (and a couple other
On Thu, 14 Feb 2008, Steve Wise wrote:
> Note that for T3, this involves suspending _all_ rdma connections that are in
> the same PD as the MR being remapped. This is because the driver doesn't know
> who the application advertised the rkey/stag to. So without that knowledge,
> all connections t
On Wed, 13 Feb 2008, Kanoj Sarcar wrote:
> Oh ok, yes, I did see the discussion on this; sorry I
> missed it. I do see what notifiers bring to the table
> now (without endorsing it :-)).
>
> An orthogonal question is this: is IB/rdma the only
> "culprit" that elevates page refcounts? Are there no
I just tested the latest BOCHS from cvs, which includes the DMI/SMBIOS
patch from Filip, with qemu cvs HEAD, and kvm as well and the export DMI
tables are fully functional. Running dmidecide in the guest displays
all of the appropriate information. I was wondering what the process is
for qemu to
On Thu, Feb 14, 2008 at 8:23 AM, Steve Wise <[EMAIL PROTECTED]> wrote:
> Robin Holt wrote:
> > On Thu, Feb 14, 2008 at 09:09:08AM -0600, Steve Wise wrote:
> >> Note that for T3, this involves suspending _all_ rdma connections that are
> >> in the same PD as the MR being remapped. This is becaus
If I want to stick to debian, would the best way to do this be to just
download kvm60 source, compile the module and load it in, or does kernel
still require upgrading (I think latest on etch is .18 not .20)
Thanks,
Andrey
_
From: Alexey Eremenko [mailto:[EMAIL PROTECTED]
Sent: Wednesd
This patch moves the parts of the VMX guest debug code which can be reused for
SVM to the generic x86 code.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kvm/svm.c |3 ++-
arch/x86/kvm/vmx.c | 26 +-
arch/x86/kvm/x86.c | 28 ++
Hi,
this patch set implements guest debugging support for the kvm-amd module. It
moves the code from VMX which is common for x86 to the generic code and keeps
the machine dependent parts in the architecture files.
Since guest debugging in the qemu part seems to be broken atm these patches are
not
This patch implements guest debug support for KVM running on AMD hardware.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/x86/kvm/svm.c | 37 ++---
1 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
i
* Ryan Harper <[EMAIL PROTECTED]> [2008-02-14 08:02]:
> * Avi Kivity <[EMAIL PROTECTED]> [2008-02-14 04:28]:
> > Ryan Harper wrote:
> > >I posted[1] a dmi patches a bit ago on qemu-devel for this. There was a
> > >better solution that involved fixing up the BIOS bits (bochs and qemu).
> > >That pa
Robin Holt wrote:
> On Thu, Feb 14, 2008 at 09:09:08AM -0600, Steve Wise wrote:
>> Note that for T3, this involves suspending _all_ rdma connections that are
>> in the same PD as the MR being remapped. This is because the driver
>> doesn't know who the application advertised the rkey/stag to. S
On Thu, Feb 14, 2008 at 09:09:08AM -0600, Steve Wise wrote:
> Note that for T3, this involves suspending _all_ rdma connections that are
> in the same PD as the MR being remapped. This is because the driver
> doesn't know who the application advertised the rkey/stag to. So without
Is there a
Felix Marti wrote:
>
> That is correct, not a change we can make for T3. We could, in theory,
> deal with changing mappings though. The change would need to be
> synchronized though: the VM would need to tell us which mapping were
> about to change and the driver would then need to disable DMA to
* Avi Kivity <[EMAIL PROTECTED]> [2008-02-14 04:28]:
> Ryan Harper wrote:
> >I posted[1] a dmi patches a bit ago on qemu-devel for this. There was a
> >better solution that involved fixing up the BIOS bits (bochs and qemu).
> >That patch is available as well on qemu-devel. I've not see any
> >ind
On Thu, Feb 14, 2008 at 5:16 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> The only method that seems to work is to keep resending; eventually they
> get tired of ignoring it.
>
Please do not give up! :-)
--
There are 10 types of people in this world, those
that can read binary and those that can
I upgraded the guest kernel to 2.6.24, and the clock now seems to be
fine (at least 'sleep 10' takes about 10 seconds on the wall clock).
Thanks for all the help!
Best,
Koen
-
This SF.net email is sponsored by: Microsoft
De
Alexander Graf wrote:
>
> I do, yes. The patches are already lying around on the qemu ML but
> have not received any comments or commits. If you have any idea how to
> get them into qemu, please tell me. I'd love to see them included.
>
The only method that seems to work is to keep resending; ev
On Feb 14, 2008, at 11:08 AM, Avi Kivity wrote:
> Alexander Graf wrote:
>>
>> I would really love to see this as well. Mac OS X is rather picky on
>> the DMI tables, so I'm pretty sure I'll be able to find some bugs in
>> the implementation when it's posted.
>>
>> I also have several bios changes
Alexander Graf wrote:
>
> I would really love to see this as well. Mac OS X is rather picky on
> the DMI tables, so I'm pretty sure I'll be able to find some bugs in
> the implementation when it's posted.
>
> I also have several bios changes to include support for newer
> hardware, which was req
On Feb 14, 2008, at 10:52 AM, Avi Kivity wrote:
> Ryan Harper wrote:
>> I posted[1] a dmi patches a bit ago on qemu-devel for this. There
>> was a
>> better solution that involved fixing up the BIOS bits (bochs and
>> qemu).
>> That patch is available as well on qemu-devel. I've not see any
Ryan Harper wrote:
> I posted[1] a dmi patches a bit ago on qemu-devel for this. There was a
> better solution that involved fixing up the BIOS bits (bochs and qemu).
> That patch is available as well on qemu-devel. I've not see any
> indication of when either bochs or qemu will pick up the DMI c
Joerg Roedel wrote:
> This patch set enables the virtualization of the last branch record in SVM if
> this feature is supported by the hardware. To the previous post the fix for
> the
> XP 64 bit install crash has been removed from this series and was posted
> seperatly to keep it small enough for
Joerg Roedel wrote:
> While installing Windows XP 64 bit wants to access the DEBUGCTL and the last
> branch record (LBR) MSRs. Don't allowing this in KVM causes the installation
> to
> crash. This patch allow the access to these MSRs and fixes the issue.
>
>
Applied, thanks.
--
Any sufficien
Jerone Young wrote:
> This works better. Not sure why but when I had fake-exec in target-ppc,
> the build system was complaining that it could not find fake-exec.d. So
> then I just decided to move it to fake-exec-ppc.c.
>
> This patch works fine for powerpc.
>
Applied; thanks.
--
Any suffic
Glauber Costa wrote:
>>
>>> +static void kvm_write_wall_clock(struct kvm_vcpu *v, gpa_t wall_clock)
>>> +{
>>> +int version = 1;
>>> +struct kvm_wall_clock wc;
>>> +unsigned long flags;
>>> +struct timespec wc_ts;
>>> +
>>> +local_irq_save(flags);
>>> +kvm_get_msr(v, MSR_IA3
On Wed, 2008-02-13 at 09:58 -0800, Uri Lublin wrote:
> The host kernel or kvm.
> If you choose to upgrade your host kernel (and kvm that comes with
> it), make sure
> you are using recent kvm-userspace too (e.g. kvm-60).
Running 2.6.23 on the host with kvm 60 (userspace) and kvm-source 60
(modules
51 matches
Mail list logo
