Well I started reviewing the mmu notifier code, but it is kind of hard to
know what you're talking about just by reading through code and not trying
your suggestions for yourself...
So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers
are rather similar. However I have
Anthony Liguori wrote:
Keep in mind, this is not big real mode. The gfxboot code here was
actually rewritten to not use big real mode so that it worked with
Xen. It works with Xen because Xen uses vm86 mode within the host
whereas KVM uses vm86 mode in the guest's VT context.
I don't
Hollis Blanchard wrote:
Kernel data is physically contiguous (true for per-cpu data as well?),
so no there's issue here.
So this is an addition to the ABI, that the data must be physically
contiguous. That's a pretty subtle implicit requirement, and it's easy
to resolve the issue by
Index: linux-2.6/drivers/char/mmu_notifier_skel.c
===
--- /dev/null
+++ linux-2.6/drivers/char/mmu_notifier_skel.c
@@ -0,0 +1,255 @@
+#include linux/types.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
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
Hello,
I have a host running kvm-60-git (fc9e77f83b26089d6228e149605be69228905dc7) and
a
guest running a modified 2.6.16 kernel. Both are of the x86_64 arch.
kvm-userspace
is e978013e3a121aae54ad4c47be5e92a23b8084a4.
When the guest invokes kexec, the host crashes with the following Oopses (a
嫘笣庈拻猿俴籀眢衄癹鼠侗
薊炵: 輿窀埼 換淩/Fax: 020-33789285
薊炵萇趕/Tel:13631387231
祡!郬噹腔諦誧蠟疑!
掛鼠侗岆珨模軘磁俶妗薯倯綠隅塗馨阭き珛ㄛ迵弊跪華Е笲嗣鼠侗衄珛昢厘懂ㄛ褫酗ヽ測燴弊
跪華跪笱濬楷⑺脹珛昢ㄛㄗ妀ⅲ种忮 馱最膘耟 嫘豢 訰戙 逤醣 督昢 絃窊 堍怀﹝﹝脹阭⑺ㄘ砃俋
測羲﹝�藿騛屎麾迅尬猀拉稊龒妡藫頖�源醱衄剒猁ㄛ珩褫懂萇薊炵﹝掛鼠侗痑笭創霾ㄩ垀羲堤楷⑺歙
峈阭昢擁垀扠鍰ㄛ褫鼎厙奻脤戙麼阭昢擁桄痐綴葆遴﹝彶0.5%~1%阭
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers
are rather similar. However I have tried to make a point of minimising the
impact the the core mm/. I don't see why we need to invalidate or flush
anything
Bugs item #1896889, was opened at 2008-02-19 14:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1896889group_id=180599
Please note that this message will contain a full copy of
On Tue, Feb 19, 2008 at 07:54:14PM +1100, Nick Piggin wrote:
As far as sleeping inside callbacks goes... I think there are big
problems with the patch (the sleeping patch and the external rmap
patch). I don't think it is workable in its current state. Either
we have to make some big changes to
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
are rather similar. However I have tried to make a point of minimising the
impact the the core mm/. I don't see why we need to invalidate or flush
I also tried hard to minimise the impact of the core mm/, I also
argued with Christoph
On Tue, Feb 19, 2008 at 07:46:10PM +1100, Nick Piggin wrote:
On Sunday 17 February 2008 06:22, Christoph Lameter wrote:
On Fri, 15 Feb 2008, Andrew Morton wrote:
flush_cache_page(vma, address, pte_pfn(*pte));
entry = ptep_clear_flush(vma, address, pte);
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
understand the need for invalidate_begin/invalidate_end pairs at all.
The need of the pairs is crystal clear to me: range_begin is needed
for GRU _but_only_if_ range_end is called after releasing the
reference that the VM
hi,
After that, I called make which correctly updated vbemodes.h and
compiled the bios. I then copied the bios to /usr/share/kvm
and /usr/share/qemu.
well, I think it is very unlikely that the vgabios is located at /usr/share/kvm
or so. if you are unsure do a locate vgabios.bin. I've
Replaces open-coded mask calculation in macros.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Against kvm.git:master
arch/x86/kvm/x86_emulate.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index
Change to jmp_rel now that it is a function.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Against kvm.git:master
arch/x86/kvm/x86_emulate.c | 56 ---
1 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c
On Tue, Feb 19, 2008 at 06:03:03PM +0200, Avi Kivity wrote:
Dan Aloni wrote:
Hello,
I have a host running kvm-60-git (fc9e77f83b26089d6228e149605be69228905dc7)
and a
guest running a modified 2.6.16 kernel. Both are of the x86_64 arch.
kvm-userspace
is
hi,
When moving my mouse slowly upwards the lowest black pixels are not erased.
The attached screenshot shows the effect.
I've also seen this effect on kvm-61 but it is new for me, I didn't see it on
older kvm versions.
I tracked it down a litte bit further:
* I don't see this effect at all
hi,
is there a specific reason why the 1280x960 resolutions have two mode
numbers (one being an exact duplicate of the other) in vbetables-gen.c
(0x180 = 0x182, 0x181 = 0x183, see below)?
...
{ 1280, 960, 24 , 0x180},
{ 1280, 960, 32 , 0x181},
{ 1280,
hi,
I contacted the author of the VBEMP driver. He wrote me that there exist
several methods of requesting the available modes from the BIOS.
Apparently, by adding a mode to the vbetables-gen.c it's only added to
parts of the tables and not to all of them, which is incorrect. By only
using
Markus Armbruster wrote:
Balaji Rao [EMAIL PROTECTED] writes:
Hi all!
Earlier it was suggested that we go ahead with emulating Perf Mon Events in
exposing it to the guest. The serious limitation in this approach is that we
end up exposing only a small number of events to the guest,
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Against kvm.git:master
arch/x86/kvm/x86_emulate.c | 48 ++-
1 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index
Long time since the last release, hence the long changelog. If you have
an AMD Barcelona, you should see a very significant performance boost
from the Nested Page Table feature.
Changes from kvm-60:
- paravirtualized clock (Glauber de Oliveira Costa)
- mmu debug compile fix (Marcelo Tosatti)
-
Harvey Harrison wrote:
Change to jmp_rel now that it is a function.
Applied all three patches, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Arne Brutschy wrote:
Hi,
thanks for the response!
On Di, 2008-02-19 at 15:08 +, Andreas Winkelbauer wrote:
well, I think it is very unlikely that the vgabios is located at
/usr/share/kvm
or so.
It actually is, and qemu is using it correctly.
I contacted the author of the
hi,
I tried using the -vmwarevga switch but I didn't succeed. I've tested it
with kvm-snapshot-20080218, kvm-60 and kvm-61.
as soon as the VM (guest os is windows xp) switches from text mode to
graphics mode lots of messages kvm: get_dirty_pages returned -2 scroll
by on the console. after a
Hi,
thanks for the response!
On Di, 2008-02-19 at 15:08 +, Andreas Winkelbauer wrote:
well, I think it is very unlikely that the vgabios is located at
/usr/share/kvm
or so.
It actually is, and qemu is using it correctly.
I contacted the author of the VBEMP driver. He wrote me that
Dan Aloni wrote:
Hello,
I have a host running kvm-60-git (fc9e77f83b26089d6228e149605be69228905dc7)
and a
guest running a modified 2.6.16 kernel. Both are of the x86_64 arch.
kvm-userspace
is e978013e3a121aae54ad4c47be5e92a23b8084a4.
When the guest invokes kexec, the host crashes with
I start seeing the effect at 1400x1050 and higher. (including 1440x900)
This happens to be the native resolution for my monitor and the size of
my desktop.
The effect is notably worse when selecting 1600x1200
It happens at both full-screen and windowed.
btw: kvm crashes when in full screen with
Nesting __emulate_2op_nobyte inside__emulate_2op produces many shadowed
variable warnings on the internal variable _tmp used by both macros.
Change the outer macro to use __tmp.
Avoids a sparse warning like the following at every call site of __emulate_2op
arch/x86/kvm/x86_emulate.c:1091:3:
Fixes sparse warning as well.
arch/x86/kvm/svm.c:69:15: warning: symbol 'iopm_base' was not declared. Should
it be static?
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
arch/x86/kvm/svm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c
In two case statements, use the ever popular 'i' instead of index:
arch/x86/kvm/x86.c:1063:7: warning: symbol 'index' shadows an earlier one
arch/x86/kvm/x86.c:1000:9: originally declared here
arch/x86/kvm/x86.c:1079:7: warning: symbol 'index' shadows an earlier one
arch/x86/kvm/x86.c:1000:9:
On Sun, Feb 17, 2008 at 11:38:51AM +0200, Avi Kivity wrote:
+ * Return the pointer to the largepage write count for a given
+ * gfn, handling slots that are not large page aligned.
+ */
+static int *slot_largepage_idx(gfn_t gfn, struct kvm_memory_slot *slot)
+{
+unsigned long idx;
+
+
On Wed, Feb 13, 2008 at 12:49:42PM +0200, Avi Kivity wrote:
Glauber de Oliveira Costa wrote:
This is the host part of kvm clocksource implementation. As it does
not include clockevents, it is a fairly simple implementation. We
only have to register a per-vcpu area, and start writting to it
On Sun, Feb 17, 2008 at 10:40:56AM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Batch pte updates and tlb flushes in lazy MMU mode.
I am slightly uneasy about generic hypercall batching. An alternative
way to do it would be to define a kvm_mmu_op structure (with an embedded
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
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
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
anything when changing the pte to be _more_ permissive, and I don't
Note that in my patch the invalidate_pages in mprotect can be
trivially switched to a
On Tue, Feb 19, 2008 at 08:27:25AM -0600, Jack Steiner wrote:
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
understand the need for invalidate_begin/invalidate_end pairs at all.
The need of the pairs is crystal clear to me: range_begin is needed
for GRU
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
are rather similar. However I have tried to make a point of minimising the
impact the the core mm/. I don't see why we need to invalidate or flush
I also tried
On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
anything when changing the pte to be _more_ permissive, and I don't
Note that in my patch the
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
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
On Feb 19, 2008 4:53 PM, Sean Kellogg [EMAIL PROTECTED] wrote:
I don't usually post to devel lists because I tend to be entirely too
uneducated to really understand what's going on... but I'm just so close to
getting this setup that I would feel silly to sit around and wait for someone
else
I don't usually post to devel lists because I tend to be entirely too
uneducated to really understand what's going on... but I'm just so close to
getting this setup that I would feel silly to sit around and wait for someone
else to fix it.
Using kvm-60 from debian/unstable I have been able to
On Tue, Feb 19, 2008 at 11:59:23PM +0100, Nick Piggin wrote:
That's why I don't understand the need for the pairs: it should be
done like this.
Yes, except it can't be done like this for xpmem.
OK, I didn't see the invalidate_pages call...
See the last patch I posted to Andrew, you've
On Tuesday 19 February 2008 04:10:08 pm you wrote:
On Feb 19, 2008 4:53 PM, Sean Kellogg [EMAIL PROTECTED] wrote:
Here is the command I am using:
kvm -hda win2k3.img -m 256 -no-acpi -localtime -no-kvm
Have you tried running without '-no-acpi'?
Thanks for the suggestion, but sadly I get the
On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
Sorry, I realise I still didn't get this through my head yet (and also
have not seen your patch recently). So I don't know exactly what you
are doing...
The last version was posted here:
On Wed, Feb 20, 2008 at 10:08:49AM +1100, Nick Piggin wrote:
You can't sleep inside rcu_read_lock()!
I must say that for a patch that is up to v8 or whatever and is
posted twice a week to such a big cc list, it is kind of slack to
not even test it and expect other people to review it.
Well,
On Wed, Feb 20, 2008 at 01:52:06AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 12:04:27AM +0100, Nick Piggin wrote:
OK (thanks to Robin as well). Now I understand why you are using it,
but I don't understand why you don't defer new TLBs after the point
where the linux pte
On Wed, Feb 20, 2008 at 10:55:20AM +1100, Nick Piggin wrote:
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
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
On Wed, Feb 20, 2008 at 02:11:41PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:00, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:00:38AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 10:08:49AM +1100, Nick Piggin wrote:
Also, how to you resolve the case where you
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this condition.
It has been an issue since day 1. We have operated with that assumption
for 6 years and have not had issues with
Just tried kvm-61. Ran up an existing, well-used, VM image. kvm-intel
crashed instantly. First KVM problem ever in several months of use.
(Haven't told the VMWare-huggers at work yet. They tend towards
superciliousness in respect of open source virtualisation solutions.)
Standardish Slackware
Hi,All
This is testing result for KVM-61.
No new issue has been found in the testing.
Five old issues:
1. Fails to save/restore guests
Save/restore may cause host to hang.
https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_
id=180599atid=893831
2. smp windows installer
On Tue, Feb 19, 2008 at 05:23:58PM +0200, Avi Kivity wrote:
- e1000 pxe boot rom (Alexey Eremenko)
what specific NIC/ROM type and version was added for kvm-61?, if the ROM came
from ROM-o-matic version 5.4.3 (while all others are from 5.4.2) could that
be spelled as well in qemu/pc-bios/README?
54 matches
Mail list logo
