Glauber Costa wrote:
> So maybe declare the per-cpu areas in a special section, then in
> setup_per_cpu_areas, copy them into the definitive per-cpu section and
> update the callers?
The special section and the copy is implemented already.
That doesn't cut it for the kvmclock case though. We re
On Monday 12 May 2008 15:54:00 Avi Kivity wrote:
> 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 2008 16:0
Новые коллекции постельного белья на сайте www.postelmagaz.ru
Большой выбор на любой вкус, цвет и кошелёк.
Доставка по Москве, отправка по России!
Заходите www.postelmagaz.ru
-
This SF.net email is sponsored by: Microsoft
D
Hi Neo,
Amit Shah is working on pci passthrough. The trees are:
git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git
git-pull
git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm-userspace.git
Allen Kay has sent out a set of patches to support VT-d a few days ago.
They are base
That does the trick with kscand.
Do you have recommendations for clock source settings? For example in my
test case for this patch the guest gained 73 seconds (ahead of real
time) after only 3 hours, 5 min of uptime.
thanks,
david
Avi Kivity wrote:
> Avi Kivity wrote:
>> Avi Kivity wrote:
>>>
Weidong,
Just curious, is it any estimation of this feature? when will it be available?
If I can get a draft version, that would be great. I want to play with it.
Thanks,
Neo
On Mon, May 12, 2008 at 8:22 PM, Han, Weidong <[EMAIL PROTECTED]> wrote:
> Not yet. It's working in process.
>
> Randy
Not yet. It's working in process.
Randy (Weidong)
Neo Jia wrote:
> Does KVM provide VT-D to allow u pass through your PCI device?
>
> Thanks,
> Neo
>
> -
> I would remember that if researchers were not ambitious
> probably today we haven't the technology we are using!
>
> On May 12, 20
Does KVM provide VT-D to allow u pass through your PCI device?
Thanks,
Neo
-
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!
On May 12, 2008, at 9:07 AM, Gerry Reno <[EMAIL PROTECTED]> wrote:
> I would like to expose some fx
Ryan Harper wrote:
> * Anthony Liguori <[EMAIL PROTECTED]> [2008-05-12 15:05]:
>
>> Ryan Harper wrote:
>>
>>> I've been digging into some of the instability we see when running
>>> larger numbers of guests at the same time. The test I'm currently using
>>> involves launching 64 1vcpu guest
* Anthony Liguori <[EMAIL PROTECTED]> [2008-05-12 15:05]:
> Ryan Harper wrote:
> >I've been digging into some of the instability we see when running
> >larger numbers of guests at the same time. The test I'm currently using
> >involves launching 64 1vcpu guests on an 8-way AMD box.
>
> Note this
On Fri, May 09, 2008 at 09:32:30PM +0200, Andrea Arcangeli wrote:
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> With KVM/GFP/XPMEM there isn't just the primary CPU MMU pointing to
> pages. There are secondary MMUs (with secondary sptes and secondary
> tlbs) too. sptes in the kvm case are shadow
Ryan Harper wrote:
> I've been digging into some of the instability we see when running
> larger numbers of guests at the same time. The test I'm currently using
> involves launching 64 1vcpu guests on an 8-way AMD box.
Note this is a Barcelona system and therefore should have a
fixed-frequency
I've been digging into some of the instability we see when running
larger numbers of guests at the same time. The test I'm currently using
involves launching 64 1vcpu guests on an 8-way AMD box. With the latest
kvm-userspace git and kvm.git + Gerd's kvmclock fixes, I can launch all
64 of these 1
Bugs item #1962539, was opened at 2008-05-12 19:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1962539&group_id=180599
Please note that this message will contain a full copy
On Sat, May 10, 2008 at 10:12:02AM +0800, Yang, Sheng wrote:
> > Did you have kvm.git commit 8ae6dc90ac84d9734e343210c8ec709f50cd9d89
> > when testing this?
> >
> > I believe it should fix that issue, because "ps->inject_pending" won't
> > be set by kvm_pit_timer_intr_post() if the IRQ is masked. P
I would like to expose some fxo PCI cards to my Asterisk guest under
KVM. How can I do this? I see where maybe you can hotplug some nic |
storage devices but what about other PCI devices like my fxo cards? Is
there some kernel line options that could do this?
Regards,
Gerry
---
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
Avi Kivity wrote:
>> Now the VCPU threads never select so the whole loop can be simplified
>> to a single sigtimedwait() that always blocks.
>>
>> In reality, I don't think sigtimedwait() is really needed/useful for
>> VCPUs anymore. We only use it to catch SIG_IPI and we only use
>> SIG_IPI to
Avi Kivity wrote:
> 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 wil
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 activity in the I/O thread. All vcpus are cleanly
>>
Avi Kivity wrote:
> 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 litt
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 the emulated hardware
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 software to hardware breakpoints
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_
Refreshed version of the earlier posted patch, now also adding a safety
check about the correct vm state to kvm_load_registers.
Some monitor commands as well as the vm_stop() issued by the gdbstub on
external interruption so far deadlock on vcpu locks in the kernel. Patch
below resolves the issue
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.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
qemu/qemu-kvm.c | 11 ---
1 file changed, 4 in
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_cpu_reset is
introduced an
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 thread (as
kvm_mutex_unlo
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 2008 16:00:57 +0800
>>> Subject: [PATCH 3/4] KVM: VMX: En
Расходы на рекламу (для бухгалтера)
Однодневный семинар / 15 мая 2008 г. / Москва
Программа семинара
1. Понятие рекламы и нормативное регулирование. Правовые основы рекламы -
законы "О рекламе", "О лотереях", "О защите прав потребителей", Налоговый и
Гражданский Кодексы.
Виды рекламы - реклам
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
produ
35 matches
Mail list logo
