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
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
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
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 u
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?
>>
>> Unconditional
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: Micro
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
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
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
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 fami
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
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 pe
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.
>
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
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,
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
[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 ca
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 dr
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
>
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 argument
If you haven't already, please sign up for KVM Developer's Forum 2008.
The final agenda (now boasting twenty presentations) has been posted at:
http://kforum.qumranet.com/KVMForum/agenda.php
Registration details are at:
http://kforum.qumranet.com/KVMForum/register_now.php
--
error com
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
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 1006
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 w
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 w
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 i
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
Jan Kiszka wrote:
> Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
> read. Moreover, given the single caller of kvm_eat_signals, there is no
> real reason to keep it in a separate function.
>
>
Given that with the iothread we spend very little time processing
signals i
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:
> 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 kvm_arch_
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) Conferen
Yang, Sheng wrote:
> On Friday 09 May 2008 23:49:13 Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
>>> From 4942a5c35c97e5edb6fe1303e04fb86f25cac345 Mon Sep 17 00:00:00 2001
>>> From: Sheng Yang <[EMAIL PROTECTED]>
>>> Date: Thu, 8 May 20
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 consume
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
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 bu
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/module
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 pack
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 s
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 r
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
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
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)
>
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 b
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
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 th
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:
> 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 perfor
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,
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_
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:
>>>>
>>>>
>>>&g
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
>
> kv
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 t
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 si
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
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
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 compil
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 o
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 th
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
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 Ja
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 JavaOn
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'
Zhang, Xiantao wrote:
>>> #include
>>> +
>>> +#ifdef __KERNEL__
>>> #include
>>> +#else
>>> +#include
>>> +#endif
>>>
>>>
>> Fishy. A kernel header including a userspace header?
>>
>> Maybe you need to include unconditionally?
>>
> Hi, Avi
> You know, kvm.h is shared by us
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
> ha
Anthony Liguori wrote:
>> What should be done for unmodified guest where there is no PV driver in
>> the guest? Would a call to mlock() from
>> qemu/hw/pci-passthrough.c/add_pci_passthrough_device() a reasonable
>> thing to do?
>>
>>
>
> Yup. The idea is to ensure that the memory i
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.
--
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 @@
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.
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 pr
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).
>>
Chris Lalancette wrote:
> Attached is a patch that fixes a guest crash when booting older Linux kernels.
> The problem stems from the fact that we are currently emulating
> MSR_K7_EVNTSEL[0-3], but not emulating MSR_K7_PERFCTR[0-3]. Because of this,
> setup_k7_watchdog() in the Linux kernel receiv
Yunfeng Zhao wrote:
> Three New Issues:
>
> 1. "Unknown symbol in module" while loading kvm.ko on PAE host
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_id=180599
> 2. Fail to save restore and live migrate on 32e platfo
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 sponsore
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 Kbuil
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
Kay, Allen M wrote:
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +//#define DEBUG
> +
> +#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
>
The name "domain" is too generic; please use dma_domain or io_domain or
something similar.
> +static int kvm_iommu_map_memslots(stru
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
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 fla
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
>>> u
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:
>
> http://lists.gnu.org/archive/html/qemu-deve
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
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-b
Michal Ludvig wrote:
loaded kvm module (kvm-68)
kvm: emulating exchange as write
Unable to handle kernel NULL pointer dereference at
RIP:
[] :kvm:x86_emulate_insn+0x3fa/0x4240
Please apply the attached patch, and post 'dmesg | grep writeback'.
writeback: b 01 mordm e0
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 sigw
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.
load
Avi Kivity wrote:
> Izik Eidus wrote:
>> Michal Ludvig wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>> Avi Kivity wrote:
>>>>
>>>>> Michal Ludvig wrote:
>>>>>
>>>>>> Hi,
>>
Izik Eidus wrote:
> Michal Ludvig wrote:
>
>> Avi Kivity wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>> Michal Ludvig wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've experienced
[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
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 suppor
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 complex
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, an
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:0
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 ma
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
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
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
--
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 nev
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
> instead use a pipe() that is written
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
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 folde
1 - 100 of 4851 matches
Mail list logo
