Bernhard Kaindl wrote:
Hi,
I found that on kvm-61 the cpuid in the guest was reported incorrectly
when qemu-kvm was compiled with gcc-4.1 or 4.3.
This resulted in linux-64bit not booting, complaining that it is not
running on a 64-bit machine.
Symptom: Unexpected behaviour after the
Andreas Winkelbauer wrote:
hi,
the attached patch fixes the issues with widescreen resolutions for me
when using -std-vga.
in vgabios/vbetables-gen.c I changed the video memory from 8MB to 16MB
which is sufficient for resolutions up to 2560x1600. I've also added
some more video modes
Hi,All
KVM Test result, kernel d6f633e.., userspace c51d737..
No new issue has been found in the testing.
Five old issues:
1. Fails to save/restore guests
https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_
id=180599atid=893831
2. smp windows installer crashes while rebooting
Harvey Harrison wrote:
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
Andreas Winkelbauer wrote:
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
On Feb 21, 2008, at 10:05 AM, Avi Kivity wrote:
Andreas Winkelbauer wrote:
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
On Feb 21, 2008, at 9:46 AM, Avi Kivity wrote:
Bernhard Kaindl wrote:
Hi,
I found that on kvm-61 the cpuid in the guest was reported
incorrectly
when qemu-kvm was compiled with gcc-4.1 or 4.3.
This resulted in linux-64bit not booting, complaining that it is not
running on a 64-bit
On Thu, Feb 21, 2008 at 10:16:27AM +0100, Alexander Graf wrote:
On Feb 21, 2008, at 10:05 AM, Avi Kivity wrote:
I guess it needs the same treatment as cirrus and stdvga (register the
framebuffer with kvm as a memory slot).
So my guess would be, that Linux targets with vmware vga should be
On Thu, 2008-02-21 at 13:58 +0800, Zhao, Yunfeng wrote:
Izik Eidus wrote:
On Wed, 2008-02-20 at 21:12 +0800, Zhao, Yunfeng wrote:
On Wed, 2008-02-20 at 20:58 +0800, Zhao, Yunfeng wrote:
Five old issues:
1. Fails to save/restore guests
Save/restore may cause host to hang.
On Thu, 2008-02-21 at 11:29 +0100, Arne Brutschy wrote:
Hi,
On Mi, 2008-02-20 at 22:16 +0100, Andreas Winkelbauer wrote:
the attached patch fixes the issues with widescreen resolutions for me
when using -std-vga.
I would appreciate any suggestions, comments and of course testing.
On Feb 21, 2008, at 10:14 AM, Alexander Graf wrote:
On Feb 21, 2008, at 9:46 AM, Avi Kivity wrote:
Bernhard Kaindl wrote:
Hi,
I found that on kvm-61 the cpuid in the guest was reported
incorrectly
when qemu-kvm was compiled with gcc-4.1 or 4.3.
This resulted in linux-64bit not
Hi,
On Mi, 2008-02-20 at 22:16 +0100, Andreas Winkelbauer wrote:
the attached patch fixes the issues with widescreen resolutions for me
when using -std-vga.
I would appreciate any suggestions, comments and of course testing.
Thanks for the patch, Andreas! You found the magic limitation to
Hi,
this is mostly the same patch I sent to the list several weeks ago,
but with fixed whitespaces and comments.
It implements a dummy value for the MSR_PERF_STATUS MSR. Darwin relies
on this and ceases to work without.
Signed-off-by: Alexander Graf [EMAIL PROTECTED]
Regards,
Alex
On Do, 2008-02-21 at 10:56 +0200, Avi Kivity wrote:
What about VGA_RAM_SIZE in qemu/hw/pc.h?
On Do, 2008-02-21 at 12:40 +0200, Izik Eidus wrote:
there is a DEFINE name VGA_RAM_SIZE or something like that
D'oh. Must have missed it. :\ Thanks! Unfortunately, it still does not work.
Qemu crashes
On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
So why can't you export a device from your xpmem driver, which
can be mmap()ed to give out anonymous memory pages to be used
for these communication buffers?
Because we need to have heap and stack available as well. MPT
Alexander Graf wrote:
This version fixes a wrong identifier (%0 instead of %1) and makes
things work without touching the stack. This works by using %esi as
backup-register for %ebx. It furthermore moves function directly to
eax, without relying on gcc optimizations to realize this.
Alexander Graf wrote:
Hi,
this is mostly the same patch I sent to the list several weeks ago,
but with fixed whitespaces and comments.
It implements a dummy value for the MSR_PERF_STATUS MSR. Darwin relies
on this and ceases to work without.
Applied, thanks.
--
error compiling
Dor Laor wrote:
On Mon, 2008-01-21 at 12:50 +0200, Avi Kivity wrote:
Dor Laor wrote:
On Mon, 2008-01-21 at 12:13 +0200, Avi Kivity wrote:
Jan Kiszka wrote:
Hi Avi,
commit kvm: qemu: consume all pending I/O in I/O loop
(8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data
hi,
What about VGA_RAM_SIZE in qemu/hw/pc.h?
I already tried changing the VGA_RAM_SIZE value in pc.h to 16 * 1024 *
1024 (16MB), but then kvm crashes when the guest os switches to graphics
mode.
Changing VGA_RAM_SIZE in pc.h to 16MB works when I use the latest cvs
snapshot of qemu (didn't
hi,
Most likely it only works with Linux; it was probably written by
reverse-engineering the Linux driver.
actually -vmwarevga works for me when using pure qemu (latest cvs
snapshot) without kqemu (-no-kqemu), but it does not work with kvm when
using -no-kvm.
anyway, I was testing
hi,
D'oh. Must have missed it. :\ Thanks! Unfortunately, it still does not work.
Qemu crashes now as windows switches to graphics mode. Safe mode does not
work either..
For now I'd suggest trying the following:
* download the latest qemu cvs snapshot
cvs -z3 -d:pserver:[EMAIL
On Thu, Feb 21, 2008 at 05:54:30AM +0100, Nick Piggin wrote:
will send you incremental changes that can be discussed more easily
that way (nothing major, mainly style and minor things).
I don't need to say you're very welcome ;).
I agree: your coherent, non-sleeping mmu notifiers are pretty
Marcelo Tosatti wrote:
Hypercall based pte updates are faster than faults, and also allow use
of the lazy MMU mode to batch operations.
Don't report the feature if two dimensional paging is enabled.
+static int kvm_hypercall_mmu_write(struct kvm_vcpu *vcpu, gpa_t addr,
+
Marcelo Tosatti wrote:
Add basic KVM paravirt support. Avoid vm-exits on IO delays.
Add KVM_GET_PARA_FEATURES ioctl so paravirt features can be reported in a
single bitmask. This allows the host to disable features on runtime if
appropriate, which would require one ioctl per feature
Marcelo Tosatti wrote:
Batch pte updates and tlb flushes in lazy MMU mode.
v1-v2:
- report individual hypercall error code, have multicall return number of
processed entries.
- cover entire multicall duration with slots_lock instead of
acquiring/reacquiring.
But not all hypercalls
hi,
* copy the modified vgabios.bin to the qemu dir
wget http://www.wina.at/vgabios.bin
# cp vgabios.bin /usr/local/qemu-cvs/share/qemu (as root; change to
target path according to the prefix you used above)
I'm guess I've uploaded to wrong vgabios.bin, so if you don't want to compile it
I really want suggestions on Jack's concern about issuing an
invalidate per pte entry or per-pte instead of per-range. I'll answer
that in a separate email. For KVM my patch is already close to optimal
because each single spte invalidate requires a fixed amount of work,
but for GRU a large
Marcelo Tosatti wrote:
Mark zapped root pagetables as invalid and ignore such pages during lookup.
This is a problem with the cr3-target feature, where a zapped root table fools
the faulting code into creating a read-only mapping. The result is a lockup
if the instruction can't be emulated.
Hello all,
When I try to run kvm with the following command line,
/usr/bin/qemu-system-x86_64 -m 1024 -kernel
/kernels/git/kvm/arch/x86/boot/bzImage -append root=/dev/sda -drive
file=f8.img,boot=on,if=virtio
I get an error saying 'A disk image must be given for 'hda' when booting a
Linux
On Thu, Feb 21, 2008 at 05:52:25PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Batch pte updates and tlb flushes in lazy MMU mode.
v1-v2:
- report individual hypercall error code, have multicall return number of
processed entries.
- cover entire multicall duration with slots_lock
On Thu, Feb 21, 2008 at 05:38:30PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Add basic KVM paravirt support. Avoid vm-exits on IO delays.
Add KVM_GET_PARA_FEATURES ioctl so paravirt features can be reported in a
single bitmask. This allows the host to disable features on runtime if
Marcelo Tosatti wrote:
One ioctl per feature sounded like unnecessary code duplication. I have
no problems with it though. So you prefer that way?
Yes. I think we can avoid code duplication.
--
error compiling committee.c: too many arguments to function
I know this issue has been discussed on this list before, but I am still
experiencing network freezes in a guest that requires a restart to clear. When
the network freezes in the guest I no longer see the network interrupts counter
incrementing (i.e., the eth0 counter in /proc/interrupts in the
Marcelo Tosatti wrote:
On Thu, Feb 21, 2008 at 05:52:25PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Batch pte updates and tlb flushes in lazy MMU mode.
v1-v2:
- report individual hypercall error code, have multicall return number of
processed entries.
- cover entire
On Thu, Feb 21, 2008 at 08:30:04PM +0200, Avi Kivity wrote:
Perhaps you want to move that enforcement to the host.
This allows batching of future hypercalls (if appropriate) to be easy.
I'm still uneasy about it, though I have no rational reasons left now.
Oh, there is one: with a
From: Glauber Costa [EMAIL PROTECTED]
In situations, like, cpu hotplugging, a cpu can arrive
later on the game and register its paravirt clock
while everything else is already running, which will lead to
breakage, since the time readings will return bogus values.
To prevent this, we write system
This patch actually allows KVM to be used with more than 4 VCPUs. The change
in qemu-kvm.c was pretty difficult to find because it was using an open coded
array size of 4. I changed that array to be 256 since that's the real maximum
on x86 and the additional storage space is a pretty trivial
On Wed, Feb 20, 2008 at 04:25:42PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
+ /*
+ * Largepage creation is susceptible to a upper-level
+ * table to be shadowed and write-protected in the
+ * area being mapped.
hi,
I found out what crashed kvm when I increased VGA_RAM_SIZE in pc.h. The
crash was caused by a really _dirty_ hack in a kvm specific part of
vga.c (it took me at least an hour to find this amazing piece of code...
at least the HACK ALERT was a good hint ;-) ).
I've attached the patch. It
Andreas Winkelbauer andreas.winkelbauer at gmx.at writes:
hi,
I found out what crashed kvm when I increased VGA_RAM_SIZE in pc.h. The
crash was caused by a really _dirty_ hack in a kvm specific part of
vga.c (it took me at least an hour to find this amazing piece of code...
at least
Marcelo Tosatti wrote:
On Thu, Feb 21, 2008 at 08:30:04PM +0200, Avi Kivity wrote:
Perhaps you want to move that enforcement to the host.
This allows batching of future hypercalls (if appropriate) to be easy.
I'm still uneasy about it, though I have no rational reasons left
Marcelo Tosatti wrote:
I don't follow. Can you describe the scenario in more detail? The state
of the guest and shadow page tables, and what actually happens?
Have a kernel level-3 table at guest physical address 0x280.
The kernel direct translation which maps to that
Jan Kiszka wrote:
I think this got lost somehow. Find refreshed patch below. Avi, could
you apply it kvm-userland to fix the still existent regression?
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Andreas Winkelbauer wrote:
hi,
I found out what crashed kvm when I increased VGA_RAM_SIZE in pc.h.
The crash was caused by a really _dirty_ hack in a kvm specific part
of vga.c (it took me at least an hour to find this amazing piece of
code... at least the HACK ALERT was a good hint ;-)
Glauber de Oliveira Costa wrote:
From: Glauber Costa [EMAIL PROTECTED]
In situations, like, cpu hotplugging, a cpu can arrive
later on the game and register its paravirt clock
while everything else is already running, which will lead to
breakage, since the time readings will return bogus
45 matches
Mail list logo
