Marcelo Tosatti wrote:
1) add is storing the result in the wrong register
6486: 66 64 89 3e 72 01 mov%edi,%fs:0x172
648c: 66 be 8d 03 00 00 mov$0x38d,%esi
6492: 66 c1 e6 04 shl$0x4,%esi
6496: 66 b8 98 0a 00 00
Bernd Schubert wrote:
Hello,
there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at
Calibrating delay using timer specific routine.. 4016.92 BogoMIPS
(lpj=8033846)
The kvm process then takes 100% of my host CPU.
This is with kvm-67 on an AM64-X2-
I'm not yet familiar with
Jan Kiszka wrote:
Hi,
before going wild with my idea, I would like to collect some comments on
this approach:
While doing first kernel debugging with my debug register patches for
kvm, I quickly ran into the 4-breakpoints-only limitation that comes
from the fact that we blindly map
Daniel P. Berrange wrote:
With this kind of syntax, now tools generating config files need to make
up unique names for each drive. So you'll probably end up with them just
naming things based on the class name + a number appended.
I would hope that tools don't have to resort to reading and
Anthony Liguori wrote:
FWIW, virtio-net is much better with my patches applied.
The can_receive patches?
Again, I'm not opposed to them in principle, I just think that if they
help that this points at a virtio deficiency. Virtio should never leave
the rx queue empty. Consider the case where
David S. Ahern wrote:
Avi Kivity wrote:
Not so fast... the patch updates the flood count to 5. Can you check
if a lower value still works? Also, whether updating the flood count to
5 (without the rest of the patch) works?
Unconditionally bumping the flood count to 5 will likely cause
Bernd Schubert wrote:
On Thursday 15 May 2008 09:36:41 Avi Kivity wrote:
Bernd Schubert wrote:
Hello,
there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at
Calibrating delay using timer specific routine.. 4016.92 BogoMIPS
(lpj=8033846)
The kvm process then takes
Alex Williamson wrote:
Trivial build warning/fixes when the local DEBUG define is enabled.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by:
Robin Holt wrote:
Then we need to deposit the information needed to do the invalidate.
Lastly, we would need to interrupt. Unfortunately, here we have a
thundering herd. There could be up to 16256 processors interrupting the
same processor. That will be a lot of work. It will need to look
Daniel P. Berrange wrote:
On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
Daniel P. Berrange wrote:
With this kind of syntax, now tools generating config files need to make
up unique names for each drive. So you'll probably end up with them just
naming things based
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
FWIW, virtio-net is much better with my patches applied.
The can_receive patches?
Again, I'm not opposed to them in principle, I just think that if
they help that this points at a virtio deficiency. Virtio should
never
Marcelo Tosatti wrote:
Only use the APIC pending timers count to break out of HLT emulation if
the timer vector is enabled.
Certain configurations of Windows simply mask out the vector without
disabling the timer.
Applied, thanks.
--
error compiling committee.c: too many arguments to
Marcelo Tosatti wrote:
On Sun, May 11, 2008 at 05:26:06PM +0300, Avi Kivity wrote:
So do you want to give wait_event_interruptible() a try or wait for that
change until userspace never issues vcpu ioctl's to a possibly busy vcpu
(and go with the patch above)?
Do we have
This is the second release of network drivers for Windows guests running
on a kvm host. The drivers are intended for Windows 2000 and Windows
XP, and Windows 2003. Both x86 and x64 variants are provided. kvm-61
or later is needed in the host. At the moment only binaries are available.
The
[I forgot to do this last weekend, so it's postponed to Saturday]
During the upcoming Saturday, the various kvm lists will move to
vger.kenel.org. This will improve responsiveness, and reduce spam and
advertising.
Please subscribe to the lists you are interested in as soon as
possible. You
Fabrice Bellard wrote:
I prefer:
drive.file=foo.img
drive.if=scsi
That doesn't support multiple drives very well.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by:
Zhang, Xiantao wrote:
Hi, Avi
This patch should be a fix for v2.6.26. Otherwise, guests can't
enable networking.
Xiantao
Subject: [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.
Guest's firmware needs the viosapic with 48 pins for ia64 guests.
Applied and queued, thanks.
Christian Borntraeger wrote:
as this patch is now in your queue, can you push this change
---
commit eee4646877b748afbfd34d8dbe6ea9b454a65745
Author: Heiko Carstens [EMAIL PROTECTED]
Date: Tue May 6 17:38:30 2008 +0300
s390: KVM guest: fix compile error
---
soon to Linus? kvm still
Anthony Liguori wrote:
We need to be able to send fragmented packets in KVM to avoid an extra copy
in the TX path. This patch adds a qemu_sendv_packet() function to send
fragemented packets. It also provides backwards compatibility for old clients
that don't support the new interface.
Daniel P. Berrange wrote:
That's very nearly YAML format[1], which is attractive because parsers
are available in every major programming language, and it is still
pretty human friendly.
So my preference would be to go with the last option and make sure
it really is YAML compliant so people
David S. Ahern wrote:
That does the trick with kscand.
Not so fast... the patch updates the flood count to 5. Can you check
if a lower value still works? Also, whether updating the flood count to
5 (without the rest of the patch) works?
Unconditionally bumping the flood count to 5
Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c | 63 +++
1 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 979f983..6906d54 100644
---
Yunfeng Zhao wrote:
Hi All,
This is today's KVM test result against kvm.git
9071a6c25634d037adb7129dc84814a7f5c7c34a and kvm-userspace.git
4b1a087a96ca9a7bf5ed1124367f7f3ac785c0d5.
Five Old Issues:
1. Fails to restore guests in real
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
How about the other way round: when the vlan consumer detects it
can no longer receive packets, it tells that to the vlan. When all
vlan consumers can no longer receive, tell the producer to stop
producing. For the tap
Zhang, Xiantao wrote:
Could you help to try the attached one.
Sure, applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by the 2008 JavaOne(SM)
Jan Kiszka wrote:
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues, following Marcelo's suggestion to
consolidate the reset activity in the I/O thread. All vcpus are cleanly
stopped before the emulated hardware is reset, and
Jan Kiszka wrote:
As suggested by Anthony, this patch encapsulates the sequence save
cpu_single_env, temporarily drop qemu_mutex, restore cpu_single_env for
condition variables in a helper function. It also adds a safety check to
the open-coded kvm_mutex_lock that the caller is not a vcpu
Jan Kiszka wrote:
Avi Kivity wrote:
Jan Kiszka wrote:
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues, following Marcelo's suggestion to
consolidate the reset activity in the I/O thread. All vcpus are cleanly
stopped before
Jan Kiszka wrote:
Given that with the iothread we spend very little time processing
signals in vcpu threads, maybe it's better to drop the loop completely.
The common case is zero or one pending signals. The uncommon case of
two or more pending signals will be handled by the KVM_RUN ioctl
Anthony Liguori wrote:
Yes. The loop was a (perhaps premature) optimization that is now
totally unnecessary, unless I'm missing something quite large.
It used to be that kvm_eat_signal() selected after consuming as many
signals as possible while only sleeping once. That's why there's
Avi Kivity wrote:
I asked fo this thinking bypass_guest_pf may help show more
information. But thinking a bit more, it will not.
I think I do know what the problem is. I will try it out. Is there a
free clone (like centos) available somewhere?
This patch tracks down emulated accesses
Avi Kivity wrote:
Avi Kivity wrote:
I asked fo this thinking bypass_guest_pf may help show more
information. But thinking a bit more, it will not.
I think I do know what the problem is. I will try it out. Is there
a free clone (like centos) available somewhere?
This patch tracks down
Marcelo Tosatti wrote:
On Fri, May 09, 2008 at 04:22:08PM -0300, Marcelo Tosatti wrote:
For things like register dumps I don't believe its worthwhile. Much
simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it
again (now that you mention the busy-spin, it is broken right
Marcelo Tosatti wrote:
The best practice is to issue all vcpu ioctls from the thread that
created the vcpu; this becomes mandatory if we ever switch to a syscall
interface and remove the mutex.
For things like register dumps I don't believe its worthwhile. Much
simpler to stop the
Anthony Liguori wrote:
Normally, tap always reads packets and simply lets the client drop them if it
cannot receive them. For virtio-net, this results in massive packet loss and
about an 80% performance loss in TCP throughput.
This patch modifies qemu_send_packet() to only deliver a packet
James Pike wrote:
Sorry that doesn't work.
This does.
--- kvm/configure2008-05-02 19:20:13.0 +0800
+++ kvm.new/configure2008-05-07 19:34:28.0 +0800
@@ -2,6 +2,7 @@
prefix=/usr/local
kerneldir=/lib/modules/$(uname -r)/build
+kernelsrcdir=/lib/modules/$(uname
Anthony Liguori wrote:
I don't think we can do page migration with VT-d. You need to be able
to detect whether the page has been changed by dma after you've copied
it but before you changed the pte, but VT-d doesn't allow that AFAICT.
Hrm, I would have to look at the VT-d but I
Anthony Liguori wrote:
How about the other way round: when the vlan consumer detects it can
no longer receive packets, it tells that to the vlan. When all vlan
consumers can no longer receive, tell the producer to stop
producing. For the tap producer, this is simply removing its fd from
Marcelo Tosatti wrote:
There's still a race in kvm_vcpu_block(), if a wake_up_interruptible()
call happens before the task state is set to TASK_INTERRUPTIBLE:
CPU0CPU1
kvm_vcpu_block
add_wait_queue
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Aurelien Jarno wrote:
On Wed, May 07, 2008 at 04:40:58PM -0500, Anthony Liguori wrote:
The current logic of the can_receive handler is to allow packets
whenever the
receiver is disabled or when
Marcelo Tosatti wrote:
On Fri, May 09, 2008 at 10:40:47AM +0300, Avi Kivity wrote:
Unfortunately it can't use wait_event_interruptible() due to
vcpu_put/vcpu_load.
schedule() will call vcpu_put()/vcpu_load() for us through preempt
notifiers. I feel a little uneasy about
Damjan wrote:
Strange situation, I have a Ubuntu JeOS image that crashes with this
error when started by the kvm-068 user-space. Bellow is the trace from
the kernel...
The same image, works with:
- kvm-066 user space, kvm-068 kernel module (on 2.6.24 and 2.6.25)
- kvm-066 user space,
Anthony Liguori wrote:
We're pretty sloppy in virtio right now about phys_ram_base assumptions. This
patch is an incremental step between what we have today and a full blown DMA
API. I backported the DMA API but the performance impact was not acceptable
to me. There's only a slight
Farkas Levente wrote:
mandrake 9, 10 and winxp run but neither centos-5.1 i386 nor x86_64 are
boot:-( i386 give a kernel panic x86_64 simple hang during boot.
Can you post the panic?
It's probably the 3Dnow! bug which is fixed for kvm-69.
--
Do not meddle in the internals of kernels,
Anthony Liguori wrote:
This patch implements the core of save/restore support for virtio. It's
modelled after how PCI save/restore works.
N.B. This makes savevm/loadvm work, but not live migration. The issue with
live migration is that we're manipulating guest memory without updating the
Yang, Sheng wrote:
From 650cad44069541fcd9fea8be6a78837e812b3dfd Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Thu, 8 May 2008 09:58:50 +0800
Subject: [PATCH 1/4] KVM: LAPIC: Unified the duplicate calling of setting IRR
It's strange got two callings of setting IRR
Zhang, Xiantao wrote:
Avi,
Please drop the previous one due to a wrong attachment.
Xiantao
From a9f479197f0a0efa45a930309fad03fd690cba60 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Thu, 8 May 2008 10:16:05 +0800
Subject: [PATCH] KVM: Qemu : IA-64 build fix.
Yang, Sheng wrote:
From 4942a5c35c97e5edb6fe1303e04fb86f25cac345 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Thu, 8 May 2008 16:00:57 +0800
Subject: [PATCH 3/4] KVM: VMX: Enable NMI with in-kernel irqchip
static void kvm_do_inject_irq(struct kvm_vcpu *vcpu)
{
Anthony Liguori wrote:
Aurelien Jarno wrote:
On Wed, May 07, 2008 at 04:40:58PM -0500, Anthony Liguori wrote:
The current logic of the can_receive handler is to allow packets
whenever the
receiver is disabled or when there are descriptors available in the
ring.
I think the logic ought
Anthony Liguori wrote:
This patch adds compatibility code so that we can make use of eventfd() within
QEMU. eventfd() is a pretty useful mechanism as it allows multiple
notifications to be batched in a single system call.
We emulate eventfd() using a standard pipe().
Applied all six
Avi Kivity wrote:
Note that flow control still makes sense since it allows us to buffer
some packets if the guest is scheduled out. But we can't use it as
the primary mechanism since it won't exist with multiqueue NICs (where
the virtio descriptors are fed to driver).
... are fed
Karl Rister wrote:
On Thursday 01 May 2008 7:16:53 pm Marcelo Tosatti wrote:
Does -no-kvm-irqchip or -no-kvm-pit makes a difference? If not, please
grab kvm_stat --once output when that happens.
Per some suggestions I have moved up to kvm-68 which is better, but still
having
Zhang, Xiantao wrote:
#include asm/types.h
+
+#ifdef __KERNEL__
#include asm/fpu.h
+#else
+#include signal.h
+#endif
Fishy. A kernel header including a userspace header?
Maybe you need to include linux/signal.h unconditionally?
Hi, Avi
You know, kvm.h is shared
Glauber Costa wrote:
qemu recently added support for 3dnow instructions. Because of
that, 3dnow will be featured among cpuid bits. But this will
break kvm in cpus that don't have those instructions (which includes
my laptop). So we fixup our cpuid before exposing it to the guest.
I've
Marcelo Tosatti wrote:
Otherwise hlt emulation fails if PIT is not injecting IRQ's.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by the 2008
Marcelo Tosatti wrote:
Slots 9 and 25 were using the identifier of the previous slot.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by the 2008
Alexander Graf wrote:
On May 6, 2008, at 6:27 PM, Glauber Costa wrote:
qemu recently added support for 3dnow instructions. Because of
that, 3dnow will be featured among cpuid bits. But this will
break kvm in cpus that don't have those instructions (which includes
my laptop). So we fixup our
Alexander Graf wrote:
Hi,
in the DSDT there are two different ways of defining, how an interrupt
is supposed to be routed. Currently we are using the LNKA - LNKD
method, which afaict is for legacy support.
The other method is to directly tell the Operating System, which APIC
pin the
Alexander Graf wrote:
Hi,
a patch recently introduced PCI device hotplugging. This added
pseudo-buses for every PCI slot, so that each device can be easily
ejected any time. The ACPI specification recommends the inclusion of a
_SUN entry in these though, to enable proper indexation of the
Zhang, Xiantao wrote:
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Wed, 7 May 2008 17:37:32 +0800
Subject: [PATCH] KVM: kvm/ia64 : Using self-defined kvm_fpreg strucutre
to replace
kernel's ia64_fpreg for avoiding conflicts with userspace headers.
Applied, thanks.
--
error compiling
Zhang, Xiantao wrote:
Critical fix for kvm/ia64 build. Issue introduced by
ea696f9cf37d8ab9236dd133ddb2727264f3add6.
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Wed, 7 May 2008 17:34:52 +0800
Subject: [PATCH] KVM: kvm/ia-64: GVMM module shouldn't link the
position-dependent objects.
Anthony Liguori wrote:
Avi Kivity wrote:
Marcelo Tosatti wrote:
Add three PCI bridges to support 128 slots.
Changes since v1:
- Remove I/O address range support (so standard PCI I/O space is
used).
- Verify that there's no special quirks for 82801 PCI bridge.
- Introduce separate flat
Alexander Graf wrote:
Marcelo Tosatti wrote:
Add three PCI bridges to support 128 slots.
Changes since v1:
- Remove I/O address range support (so standard PCI I/O space is
used).
- Verify that there's no special quirks for 82801 PCI bridge.
- Introduce separate flat IRQ mapping function
Kay, Allen M wrote:
+
+#include linux/list.h
+#include linux/kvm_host.h
+#include linux/pci.h
+#include linux/dmar.h
+#include linux/intel-iommu.h
+
+//#define DEBUG
+
+#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
The name domain is too generic; please use dma_domain or io_domain or
Kay, Allen M wrote:
Still todo: move vt.d to kvm-intel.ko module.
Not sure it's the right thing to do. If we get the iommus abstracted
properly, we can rename vtd.c to dma.c and move it to virt/kvm/.
The code is certainly a lot more about managing memory than anything vmx
specific. It's
Ryota OZAKI wrote:
Hi all,
Initial Comment:
Building KVM modules against 2.6.24 kernel is ok.
But building against 2.6.26 kernel will fail.
I got the same problem, but the following Andrea's patch helped me.
Hope this helps,
Yes, while I think it's a Kbuild problem, too
Carlo Marcelo Arenas Belon wrote:
apparently harmless and unique
Sloppy me. Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored
Yunfeng Zhao wrote:
Three New Issues:
1. Unknown symbol in module while loading kvm.ko on PAE host
https://sourceforge.net/tracker/?func=detailatid=893831aid=1958464group_id=180599
2. Fail to save restore and live migrate on 32e platform
Kay, Allen M wrote:
Following three patches contains vt-d support for pci passthrough. It
contains diff's base on Amit's 4/22 passthrough tree.
The hardware environment used for this work is an Intel Weybridge system
(Q35). The passthrough device is an E1000 NIC. I'm still using irqhook
Avi Kivity wrote:
[Resurrecting post from the dead]
Marcelo Tosatti wrote:
Forcing clustered APIC mode works only on SMP, and there were high CPU
consumption on Windows SMP guests due to C3 state being reported (fixed
in kvm-30 something).
So perhaps:
- Faking clustered APIC on SMP
Jan Luebbe wrote:
0f 0d 0bprefetchw (%ebx)
This is an AMD 3Dnow! instruction, which is not supported on Intel
processors. I guess the 3Dnow! cpuid bit leaked in via the qemu merge.
I guess two fixes are needed:
- remove the 3Dnow! bit
- add emulation for prefetchw (easy,
Martin Schwidefsky wrote:
I've added Heiko's patch to my patchqueue. But since this is
drivers/s390/kvm this should go in over the kvm.git. See patch below.
Thanks, I added this to my queue as well.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Zhang, Xiantao wrote:
Hi, Avi
This patch should go into RC1, otherwise it will block kvm/ia64
userspace build.
diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h
index eb2d355..62b5fad 100644
--- a/include/asm-ia64/kvm.h
+++ b/include/asm-ia64/kvm.h
@@ -22,7 +22,12 @@
*/
Jerone Young wrote:
These patches fell through the cracks.
Unfortunately, the cracks are getting wider.
Anyway, applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Izik Eidus wrote:
Michal Ludvig wrote:
Avi Kivity wrote:
Avi Kivity wrote:
Michal Ludvig wrote:
Hi,
I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in 64bit
mode while starting up WinXP:
The host is still alive but the XP guest is locked up
Avi Kivity wrote:
Izik Eidus wrote:
Michal Ludvig wrote:
Avi Kivity wrote:
Avi Kivity wrote:
Michal Ludvig wrote:
Hi,
I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in
64bit mode while starting up WinXP:
The host is still alive but the XP guest
Michal Ludvig wrote:
Hi again, just wanted to let you know that I still get this Oops with
kvm-68. It comes a bit later, not during the boot but after the XP
desktop comes up. As there were some changes in kernel/x86_emulate.c
the patch you provided for kvm-66 can't be applied anymore.
Anthony Liguori wrote:
This patch reworks the IO thread to use signalfd() instead of sigtimedwait().
This will eliminate the need to use SIGIO everywhere. In this version of the
patch, we use signalfd() when it's available. When it isn't available, we
create a separate thread and use
Michal Ludvig wrote:
loaded kvm module (kvm-68)
kvm: emulating exchange as write
Unable to handle kernel NULL pointer dereference at
RIP:
[88373b4a] :kvm:x86_emulate_insn+0x3fa/0x4240
Please apply the attached patch, and post 'dmesg | grep writeback'.
writeback:
Christian Borntraeger wrote:
Hmm... this should help:
---
drivers/s390/kvm/kvm_virtio.c | 40
+++-
1 file changed, 23 insertions(+), 17 deletions(-)
Thanks Heiko.
I did a short test and it seems to work.
Acked-by: Christian
Anthony Liguori wrote:
Please break the SIGUSR1 changes into a separate patch. Ditto with
*fd syscall compat.
Done. I didn't make the syscall compat stuff separate patches because
that would break bisect on older hosts. However, I did split it up
logically between the remove sigusr1
Daniel P. Berrange wrote:
I'm forwarding this patch from upstream QEMU because its impotant to get
this fixed in KVM to make serial console installs usable now libvirt can
talk to KVM serial ports over PTYs.
It was reported in this thread:
Bob Moran wrote:
The http://kvm.qumranet.com/kvmwiki/FAQ section3 Q13 RE. widescreen
resolution in KVM, refers me to:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/13557 which
describes a patch to be applied.
I am not familiar with patch application and unsure where to find
Marcelo Tosatti wrote:
Add three PCI bridges to support 128 slots.
Changes since v1:
- Remove I/O address range support (so standard PCI I/O space is used).
- Verify that there's no special quirks for 82801 PCI bridge.
- Introduce separate flat IRQ mapping function for non-SPARC targets.
Anthony Liguori wrote:
Anthony Liguori wrote:
While it has served us well, it is long overdue that we eliminate the
virtio-net tap hack. It turns out that zero-copy has very little
impact on
performance. The tap hack was gaining such a significant performance
boost
not because of
Hollis Blanchard wrote:
Avi, please apply these patches to the kvm-userspace repository. I've
submitted
the device emulation patches (UIC and PCI) to qemu-devel, but have received no
response.
Applied all, thanks.
Thinking ahead to qemu integration, many of these should be folded into
Karl Rister wrote:
Hi
I have been trying to do some testing of a large number of guests (72) on a
big multi-node IBM box (8 sockets, 32 cores, 128GB) and I am having various
issues with the guests. I can get the guests to boot, but then I start to
have problems. Some guests appear to
Anthony Liguori wrote:
Avi Kivity wrote:
Well, one user (me) has made this mistake, several times.
I guess it's usage patterns. I'm pretty religious about using -snapshot
unless I have a very specific reason not to. I have never encountered
this problem myself.
Most users
Glauber Costa wrote:
since the pv_apic_ops are only present if CONFIG_X86_LOCAL_APIC is compiled
in, kvmclock failed to build without this option. This patch fixes this
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Nehalem processors. The
implementation builds on the same code paths as AMD NPT (and real-mode
shadow) and is therefore small and safe for inclusion.
Andrea Arcangeli (1):
KVM: avoid fx_init() schedule in atomic
Avi Kivity (2):
KVM: x86 emulator: disable writeback on lmsw
KVM
Anthony Liguori wrote:
QEMU is rather aggressive about exhausting the wait period when selecting.
This is fine when the wait period is low and when there is significant delays
in-between selects as it improves IO throughput.
With the IO thread, there is a very small delay between selects and
Andrea Arcangeli wrote:
On Fri, May 02, 2008 at 12:28:32PM +0300, Avi Kivity wrote:
Applied, thanks. Dynamic allocation for the fpu state was introduced in
2.6.26-rc, right?
It seems very recent, hit mainline on 30 Apr.
Also we may want to think if there's something cheaper than
iMil wrote:
Hi,
Since I upgraded my ubuntu machine to 8.04,
/usr/local/bin/qemu-system-x86_64 segfaults when starting with -net
tap,ifname=tap0 flags. Of course, it's been recompiled.
$ sudo /usr/local/bin/qemu-system-x86_64 /data/virt/netbsd.img -net
nic,macaddr=00:56:01:02:03:04 -net
Aurelien Jarno wrote:
The in-kernel PIT emulation ignores pending timers if operating
under mode 3, which for example Hurd uses.
This mode should output a square wave, high for (N+1)/2 counts and low
for (N-1)/2 counts. As we only care about the resulting interrupts, the
period is N, and
Anthony Liguori wrote:
We can keep the signals blocked, but run the signalfd emulation in a
separate thread (where it can dequeue signals using sigwait as an
added bonus). This will reduce the differences between the two modes
at the expense of increased signalfd() emulation complexity,
No new architecture support today, but instead there is support for
Intel's Extended Page Tables, which increase virtualization performance
dramatically on Intel's Nehalem processors.
Also fix host oops on AMD running some 16-bit loaders and applications.
Changes from kvm-67:
- Intel EPT
[Resurrecting post from the dead]
Marcelo Tosatti wrote:
Forcing clustered APIC mode works only on SMP, and there were high CPU
consumption on Windows SMP guests due to C3 state being reported (fixed
in kvm-30 something).
So perhaps:
- Faking clustered APIC on SMP
- Faking C3 on UP
And
Jan Kiszka wrote:
This looks bogus, but it is so far without practical impact (phys_start
is always 0 when we do the calculation).
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/libkvm/libkvm.c
Jan Kiszka wrote:
Avi Kivity wrote:
Jan Kiszka wrote:
This still leaves me with the question how to handle the case when the
host sets and arms some debug registers to debug the guest and the
latter does the same to debug itself. Guest access will be trapped, OK,
but KVM
Jan Kiszka wrote:
Userland-located memory is not unconditionally available via
kvm-physical_memory + guest_address. To let kvm_show_code also dump
useful information when, e.g., some problem in ROM (BIOS...) occurs,
this patch tries to obtain the memory content via the mmio_read
callback. If
1 - 100 of 3824 matches
Mail list logo
