Re: [kvm-devel] [RFC][PATCH 3/4] KVM: VMX: Enable NMI with in-kernel irqchip
On Tuesday 13 May 2008 14:42:17 Yang, Sheng wrote:
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: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)
{
int word_index = __ffs(vcpu-arch.irq_summary);
@@ -2146,9 +2159,11 @@ static void do_interrupt_requests(struct
kvm_vcpu *vcpu,
/*
* Interrupts blocked. Wait for unblock.
*/
- cpu_based_vm_exec_control |=
CPU_BASED_VIRTUAL_INTR_PENDING;
+ cpu_based_vm_exec_control |=
+ CPU_BASED_VIRTUAL_INTR_PENDING;
else
- cpu_based_vm_exec_control =
~CPU_BASED_VIRTUAL_INTR_PENDING;
+ cpu_based_vm_exec_control =
+ ~CPU_BASED_VIRTUAL_INTR_PENDING;
This seems spurious.
Sorry, seems I am too anxious to keep it in hand... I would like to
check it much careful in the future.
/* We need to handle NMIs before interrupts are enabled */
- if ((intr_info INTR_INFO_INTR_TYPE_MASK) == 0x200) { /* nmi */
+ if ((intr_info INTR_INFO_INTR_TYPE_MASK) == 0x200) {
KVMTRACE_0D(NMI, vcpu, handler);
- asm(int $2);
+ if (!cpu_has_virtual_nmis())
+ asm(int $2);
}
}
That's a host nmi. So does the PIN_BASED_VIRTUAL_NMI mean NMIs are
handled like unacked host interrupts?
Not exactly. No host NMI here if Virtual_NMI is set. Copy from SDM 3B
table 20-5:
If this control(Virtual NMIs) is 1, NMIs are never blocked and the
“blocking by NMI” bit (bit 3) in the interruptibility-state field
indicates “virtual-NMI blocking” (see Table 20-3). This control also
interacts with the “NMI-window exiting” VM-execution control (see
Section 20.6.2).
I still don't understand. What does NMIs are never blocked mean?
what happens if an NMI occurs while in guest mode? Obviously we don't
want it to be delivered to the guest.
Oops, I neglected it... When virtual_nmi is set, the host NMI would routed
to handle_exception. And we would handle it there, by judged the vector
number.
I will posted the updated patchset soon.
Faint, misunderstood again... Seems the cold affact my thinking...
Anyway, I will updated my patchset. Thanks!
--
Thanks
Yang, Sheng
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)
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 will likely cause a performance regression on other guests. While I was able to see excessive flooding, I couldn't reproduce your kscand problem. Running /bin/true always returned immediately for me. 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. The kernel is trying to correlate tsc and pit, which isn't going to work. Try disabling the tsc, set edx.bit4=0 for cpuid.eax=1 in qemu-kvm-x86 .c do_cpuid_ent(). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Существенные условия договора строительного подряда
Договоры в строительстве (практические рекомендации) Однодневный семинар / 16 мая 2008 г. / Москва Программа семинара Договоры в строительстве: общие положения ∙ Общая характеристика договоров, сопровождающих строительную деятельность. ∙ Обзор договоров подрядного типа и практической сферы их применения. ∙ Анализ типичных спорных ситуаций с участием субподрядных организаций. Документальное оформление договорных отношений ∙ Виды документов, оформляющих договорные отношения, их назначение и правила составления. ∙ Правовое значение протоколов о намерениях и протоколов разногласий. ∙ Судебно-арбитражная практика по спорам, связанным с использованием предварительных договоров в строительной деятельности (анализ конкретных арбитражных решений). Договорные условия ∙ Существенные условия договора строительного подряда. ∙ Обзор судебно-арбитражной практики по спорам о несогласованных (неверно согласованных) существенных условиях договора. Тендерный отбор контрагентов (преимущества и недостатки) ∙ Особенности заключения договора по результатам торгов (включая специфику государственных заказов). ∙ Обобщение судебно-арбитражной практики по спорам о признании торгов недействительными. ∙ Анализ конкретных ситуаций исполнения договоров строительного подряда с организациями, отобранными на конкурсной основе. Обеспечение интересов заказчика в договорных отношениях ∙ Способы обеспечения прав заказчика в договоре строительного подряда. ∙ Цена договора и порядок расчетов. Установление условий о цене с учетом инфляции, удорожания материалов, рабочей силы и других тенденций изменения рыночных цен. ∙ Основные подходы к расчетам с подрядчиками, законодательные ограничения, возможные споры. Оформление сдачи-приемки работ ∙ Основные документы, правила подписания, законодательные ограничения. ∙ Судебно-арбитражная практика оспаривания оформления сдачи-приемки работ, оплаты работ по оформленным актам, полномочиям лиц, осуществившим приемку работ. Ответственность за нарушение договорных обязательств в строительной деятельности ∙ Основные меры ответственности за нарушение договорных обязательств. ∙ Практика взыскания, обобщение типичных судебных споров. Ответы на вопросы участников семинара. Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу). Место обучения: г. Москва, 5 мин. пешком от м. Академическая. Стоимость обучения: 4900 руб. (с НДС). (В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане). При отсутствии возможности посетить семинар, мы предлагаем приобрести его видеоверсию на DVD/CD дисках или видеокассетах (прилагается авторский раздаточный материал). Цена видеокурса - 3500 рублей, с учетом НДС. Для регистрации на семинар необходимо отправить нам по факсу: реквизиты организации, тему и дату семинара, полное ФИО участников, контактный телефон и факс. Для заказа видеокурса необходимо отправить нам по факсу: реквизиты организации, тему видеокурса, указать носитель (ДВД или СД диски), телефон, факс, контактное лицо и точный адрес доставки. Получить дополнительную информацию и зарегистрироваться можно: по т/ф: ( Ч 9 5 ) 5 Ч З - 8 8 - Ч 6 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/4] kvm/host: fix paravirt clocksource to be compatible with xen.
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
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -493,7 +493,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t
wall_clock)
{
static int version;
struct kvm_wall_clock wc;
- struct timespec wc_ts;
+ struct timespec now,sys,boot;
Add spaces.
if (!wall_clock)
return;
@@ -502,9 +502,16 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t
wall_clock)
kvm_write_guest(kvm, wall_clock, version, sizeof(version));
- wc_ts = current_kernel_time();
- wc.wc_sec = wc_ts.tv_sec;
- wc.wc_nsec = wc_ts.tv_nsec;
+#if 0
+ /* Hmm, getboottime() isn't exported to modules ... */
+ getboottime(boot);
+#else
+ now = current_kernel_time();
+ ktime_get_ts(sys);
+ boot = ns_to_timespec(timespec_to_ns(now) - timespec_to_ns(sys));
+#endif
+ wc.wc_sec = boot.tv_sec;
+ wc.wc_nsec = boot.tv_nsec;
Please drop the #if 0.
wc.wc_version = version;
kvm_write_guest(kvm, wall_clock, wc, sizeof(wc));
@@ -537,20 +544,58 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
/*
* The interface expects us to write an even number signaling that the
* update is finished. Since the guest won't see the intermediate
- * state, we just write 2 at the end
+ * state, we just increase by 2 at the end.
*/
- vcpu-hv_clock.version = 2;
+ vcpu-hv_clock.version += 2;
shared_kaddr = kmap_atomic(vcpu-time_page, KM_USER0);
memcpy(shared_kaddr + vcpu-time_offset, vcpu-hv_clock,
- sizeof(vcpu-hv_clock));
+sizeof(vcpu-hv_clock));
kunmap_atomic(shared_kaddr, KM_USER0);
mark_page_dirty(v-kvm, vcpu-time PAGE_SHIFT);
}
+static uint32_t div_frac(uint32_t dividend, uint32_t divisor)
+{
+ uint32_t quotient, remainder;
+
+ __asm__ ( divl %4
+ : =a (quotient), =d (remainder)
+ : 0 (0), 1 (dividend), r (divisor) );
+ return quotient;
+}
do_div()?
+
+static void kvm_set_time_scale(uint32_t tsc_khz, struct kvm_vcpu_time_info
*hv_clock)
+{
+ uint64_t nsecs = 10LL;
+ int32_t shift = 0;
+ uint64_t tps64;
+ uint32_t tps32;
+
+ tps64 = tsc_khz * 1000LL;
+ while (tps64 nsecs*2) {
+ tps64 = 1;
+ shift--;
+ }
+
+ tps32 = (uint32_t)tps64;
+ while (tps32 = (uint32_t)nsecs) {
+ tps32 = 1;
+ shift++;
+ }
+
+ hv_clock-tsc_shift = shift;
+ hv_clock-tsc_to_system_mul = div_frac(nsecs, tps32);
+
+#if 0
+ printk(KERN_DEBUG %s: tsc_khz %u, tsc_shift %d, tsc_mul %u\n,
+__FUNCTION__, tsc_khz, hv_clock-tsc_shift,
+hv_clock-tsc_to_system_mul);
+#endif
+}
pr_debug() or something?
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
@@ -599,9 +644,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr,
u64 data)
/* ...but clean it before doing the actual write */
vcpu-arch.time_offset = data ~(PAGE_MASK | 1);
- vcpu-arch.hv_clock.tsc_to_system_mul =
- clocksource_khz2mult(tsc_khz, 22);
- vcpu-arch.hv_clock.tsc_shift = 22;
+ kvm_set_time_scale(tsc_khz, vcpu-arch.hv_clock);
What if the tsc frequency changes later on? we need to adjust the
multiplier, no?
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel 9071a6c.., userspace 4b1a087..
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 mode https://sourceforge.net/tracker/?func=detailatid=893831aid=1959950group_id=180599 2. XP crashes while rebooting https://sourceforge.net/tracker/?func=detailatid=893831aid=1959452group_id=180599 3. linux virtio drivers won't work after runing save/restore https://sourceforge.net/tracker/?func=detailatid=893831aid=1959443group_id=180599 4.Cannot boot guests with hugetlbfs https://sourceforge.net/tracker/?func=detailatid=893831aid=1941302group_id=180599 5. KVM Guest Drivers fail on Windows https://sourceforge.net/tracker/index.php?func=detailaid=1920897group_id=180599atid=893831 We met the issue too while testing Windows drivers on XP. Test environment PlatformWoodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallelPASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guestPASS 10. LTP on linux guest PASS 11. boot base kernel linux PASS 12. save/restore smp 32-bit HVM guests PASS 13. live migration smp 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabledPASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS 17. boot SMP Windows 2008 with ACPI enabled PASS IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallelPASS 11. boot four 32-bit different guest in para PASS 12. save/restore smp 64-bit linux guests PASS 13. save/restore smp 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP windows 2008 with ACPI enabled PASS 16. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 17. boot 32-bit SMP Windows xp with ACPI enabledPASS 18. boot 32-bit Windows 2000 without ACPIPASS 19. boot 64-bit Windows xp with ACPI enabledPASS 20. boot 32-bit Windows xp without ACPIPASS 21. boot 64-bit UP vista PASS 22. boot 64-bit SMP vista PASS 23. kernel build in 32-bit linux guest OS PASS 24. kernel build in 64-bit linux guest OS PASS 25. LTP on 32-bit linux guest OSPASS 26. LTP on 64-bit linux guest OSPASS 27. boot 64-bit guests with ACPI enabled PASS 28. boot 32-bit x-server PASS 29. boot 64-bit SMP windows XP with ACPI enabled PASS 30. boot 64-bit SMP windows 2003 with ACPI enabled PASS 31. boot 64-bit SMP windows 2008 with ACPI enabled PASS 32. live migration smp 64bit linux guests PASS 33. live migration smp 32bit linux guests PASS 34. reboot 32bit windows xp guest PASS 35. reboot 32bit windows xp guest PASS
Re: [kvm-devel] KVM Test result, kernel 9071a6c.., userspace 4b1a087..
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 mode https://sourceforge.net/tracker/?func=detailatid=893831aid=1959950group_id=180599 This should be fixed by 662beb8baa37481d1cb32aff8354c931f8a73441, which is included in the the sources you tested. 3. linux virtio drivers won't work after runing save/restore https://sourceforge.net/tracker/?func=detailatid=893831aid=1959443group_id=180599 This should be fixed by a00f04bd370738d65235387c1b3ccd394b595571 and c15c33996040e8d407a348ac4d9ccb84893429a4, also included. Perhaps you have stale binaries? 5. KVM Guest Drivers fail on Windows https://sourceforge.net/tracker/index.php?func=detailaid=1920897group_id=180599atid=893831 We met the issue too while testing Windows drivers on XP. A new driver will be released soon which corrects the problem (encountered on the ACPI Multiprocessor PC HAL). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [CentOS-devel] KVM-66 packages in testing
Avi Kivity wrote: 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. unfortunately i can't reproduce the kernel crash, now it's usually hang at starting udev both centos-5.1 i386 and x86_64. anyway i build kvm-68 and it's working. -- Levente Si vis pacem para bellum! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] can't boot 2.6.26-rcX
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 kvm and debugging. Will a sysrq+t trace of the host show something useful? Or will only full git-bisect help? Thanks, Bernd - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Supplements to promote sexual pleasure
Find out why Kevin Federline has it so easy http://www.ranetys.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem
On Thursday 08 May 2008 10:38, Robin Holt wrote: On Wed, May 07, 2008 at 02:36:57PM -0700, Linus Torvalds wrote: On Wed, 7 May 2008, Andrea Arcangeli wrote: I think the spinlock-rwsem conversion is ok under config option, as you can see I complained myself to various of those patches and I'll take care they're in a mergeable state the moment I submit them. What XPMEM requires are different semantics for the methods, and we never had to do any blocking I/O during vmtruncate before, now we have to. I really suspect we don't really have to, and that it would be better to just fix the code that does that. That fix is going to be fairly difficult. I will argue impossible. First, a little background. SGI allows one large numa-link connected machine to be broken into seperate single-system images which we call partitions. XPMEM allows, at its most extreme, one process on one partition to grant access to a portion of its virtual address range to processes on another partition. Those processes can then fault pages and directly share the memory. In order to invalidate the remote page table entries, we need to message (uses XPC) to the remote side. The remote side needs to acquire the importing process's mmap_sem and call zap_page_range(). Between the messaging and the acquiring a sleeping lock, I would argue this will require sleeping locks in the path prior to the mmu_notifier invalidate_* callouts(). Why do you need to take mmap_sem in order to shoot down pagetables of the process? It would be nice if this can just be done without sleeping. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem
On Thursday 08 May 2008 11:34, Andrea Arcangeli wrote: Sorry for not having completely answered to this. I initially thought stop_machine could work when you mentioned it, but I don't think it can even removing xpmem block-inside-mmu-notifier-method requirements. For stop_machine to solve this (besides being slower and potentially not more safe as running stop_machine in a loop isn't nice), we'd need to prevent preemption in between invalidate_range_start/end. I think there are two ways: 1) add global lock around mm_lock to remove the sorting 2) remove invalidate_range_start/end, nuke mm_lock as consequence of it, and replace all three with invalidate_pages issued inside the PT lock, one invalidation for each 512 pte_t modified, so serialization against get_user_pages becomes trivial but this will be not ok at all for SGI as it increases a lot their invalidation frequency This is what I suggested to begin with before this crazy locking was developed to handle these corner cases... because I wanted the locking to match with the tried and tested Linux core mm/ locking rather than introducing this new idea. I don't see why you're bending over so far backwards to accommodate this GRU thing that we don't even have numbers for and could actually potentially be batched up in other ways (eg. using mmu_gather or mmu_gather-like idea). The bare essential, matches-with-Linux-mm mmu notifiers that I first saw of yours was pretty elegant and nice. The idea that only one solution must go in and handle everything perfectly is stupid because it is quite obvious that the sleeping invalidate idea is just an order of magnitude or two more complex than the simple atomic invalidates needed by you. We should and could easily have had that code upstream long ago :( I'm not saying we ignore the sleeping or batching cases, but we should introduce the ideas slowly and carefully and assess the pros and cons of each step along the way. For KVM both ways are almost the same. I'll implement 1 now then we'll see... -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [EMAIL PROTECTED] For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] /a - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem
On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote: On Thursday 08 May 2008 10:38, Robin Holt wrote: In order to invalidate the remote page table entries, we need to message (uses XPC) to the remote side. The remote side needs to acquire the importing process's mmap_sem and call zap_page_range(). Between the messaging and the acquiring a sleeping lock, I would argue this will require sleeping locks in the path prior to the mmu_notifier invalidate_* callouts(). Why do you need to take mmap_sem in order to shoot down pagetables of the process? It would be nice if this can just be done without sleeping. We are trying to shoot down page tables of a different process running on a different instance of Linux running on Numa-link connected portions of the same machine. The messaging is clearly going to require sleeping. Are you suggesting we need to rework XPC communications to not require sleeping? I think that is going to be impossible since the transfer engine requires a sleeping context. Additionally, the call to zap_page_range expects to have the mmap_sem held. I suppose we could use something other than zap_page_range and atomically clear the process page tables. Doing that will not alleviate the need to sleep for the messaging to the other partitions. Thanks, Robin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Налоговые претензии при вексел ьных схемах
Применение векселя в хозяйственном обороте. Расчетные схемы, налоговые последствия, правовые риски участников вексельного оборота Однодневный семинар / 19 мая 2008 г. / Москва Программа семинара 1. Правовая природа векселя и сделок с ним. ∙ Содержание вексельного обязательства. Виды векселей. Конструкция обязательств в простых и переводных векселях ∙ Типовое (стандартное) применение векселей в хозяйственной деятельности. Правовая характеристика сделок, лежащих в основании выдачи, передачи и погашения векселей. Займы под вексель, встречные векселя, продажа и залог векселей и др.. ∙ Типовые (базовые) схемы вексельных взаиморасчетов. 2. Налоговые последствия базовых схем взаиморасчетов с применением простых векселей. ∙ НДС при расчетах собственными простыми векселями покупателя. Расчеты путем акцепта переводных векселей. ∙ НДС при расчетах векселями третьих лиц. ∙ НДС при расчетах переводными векселями. ∙ Налог на прибыль при операциях с дисконтным и процентным векселем. 3. Налоговые риски в случае нестандартных схем применения векселей в хозяйственной деятельности. ∙ Концепция реальных затрат в налогообложении НДС. Возможные налоговые претензии при наличии вспомогательных вексельных схем.. ∙ Другие схемы 4. Основные правовые риски участников вексельного оборота и способы защиты прав. ∙ Обзор возможных возражений против требований об оплате векселя. Требования к форме, к процедуре предъявления к оплате. Понятие недобросовестного приобретения векселя и приобретения в ущерб должнику. ∙ Действия держателя в случае похищения или утраты векселя. Вызывное производство и связанные с этой процедурой риски. ∙ Действия векселеучастников в случае обнаружения подлога векселя. Средства доказывания факта подлога. Распределение обязанности доказывания. Несовершенство института публичной достоверности векселя. Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу). Место обучения: г. Москва, 5 мин. пешком от м. Академическая. Стоимость обучения: 4900 руб. (с НДС). (В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане). Для регистрации на семинар необходимо отправить нам реквизиты организации, тему и дату семинара, полное ФИО участников, контактный телефон и факс. Получить подробную программу и зарегистрироваться можно по телефону: ( 4 9 5 ) 5 43 = 8 8 = 4 6 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] D e ntists Database in the United States
Fully exportable and can be used for any purpose: + 164,323 D.entists + 158,954 Civic Addresses + 163,539 Telephone Numbers + 77,236 Fax Numbers + 45,650 office emails Until May 16 the new lowered price is $292 Please reply to [EMAIL PROTECTED] to get off please email with 84128 for a subject - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/4] Use fragmented send for virtio
This patch converts virtio-net to use the new fragmented send interface.
We should have always supported this.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 85cc9d2..93bca1d 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -239,23 +239,15 @@ again:
static void virtio_net_flush_tx(VirtIONet *n, VirtQueue *vq)
{
VirtQueueElement elem;
-int count = 0;
if (!(n-vdev.status VIRTIO_CONFIG_S_DRIVER_OK))
return;
while (virtqueue_pop(vq, elem)) {
- int i;
- size_t len = 0;
+ ssize_t len = 0;
/* ignore the header for now */
- for (i = 1; i elem.out_num; i++) {
- qemu_send_packet(n-vc, elem.out_sg[i].iov_base,
-elem.out_sg[i].iov_len);
- len += elem.out_sg[i].iov_len;
- }
-
- count++;
+ len = qemu_sendv_packet(n-vc, elem.out_sg[1], elem.out_num - 1);
virtqueue_push(vq, elem, sizeof(struct virtio_net_hdr) + len);
virtio_notify(n-vdev, vq);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/4] Add fd_readv handler to tap
This allows fragmented packets to be sent with no additional copies over the
tap interface.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/vl.c b/qemu/vl.c
index 1f0a6ac..7900b76 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -4086,6 +4086,19 @@ static void tap_receive(void *opaque, const uint8_t
*buf, int size)
}
}
+static ssize_t tap_readv(void *opaque, const struct iovec *iov,
+int iovcnt)
+{
+TAPState *s = opaque;
+ssize_t len;
+
+do {
+ len = writev(s-fd, iov, iovcnt);
+} while (len == -1 (errno == EINTR || errno == EAGAIN));
+
+return len;
+}
+
static void tap_send(void *opaque)
{
TAPState *s = opaque;
@@ -4135,6 +4148,7 @@ static TAPState *net_tap_fd_init(VLANState *vlan, int fd)
s-no_poll = 0;
enable_sigio_timer(fd);
s-vc = qemu_new_vlan_client(vlan, tap_receive, NULL, s);
+s-vc-fd_readv = tap_readv;
qemu_set_fd_handler2(s-fd, tap_read_poll, tap_send, NULL, s);
snprintf(s-vc-info_str, sizeof(s-vc-info_str), tap: fd=%d, fd);
return s;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/4] Add method to send fragmented packets
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.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/net.h b/qemu/net.h
index 13daa27..5fb190e 100644
--- a/qemu/net.h
+++ b/qemu/net.h
@@ -1,12 +1,17 @@
#ifndef QEMU_NET_H
#define QEMU_NET_H
+#include sys/uio.h
+
/* VLANs support */
+typedef ssize_t (IOReadvHandler)(void *, const struct iovec *, int);
+
typedef struct VLANClientState VLANClientState;
struct VLANClientState {
IOReadHandler *fd_read;
+IOReadvHandler *fd_readv;
/* Packets may still be sent if this returns zero. It's used to
rate-limit the slirp code. */
IOCanRWHandler *fd_can_read;
@@ -30,6 +35,8 @@ VLANClientState *qemu_new_vlan_client(VLANState *vlan,
void *opaque);
int qemu_can_send_packet(VLANClientState *vc);
void qemu_send_packet(VLANClientState *vc, const uint8_t *buf, int size);
+ssize_t qemu_sendv_packet(VLANClientState *vc, const struct iovec *iov,
+ int iovcnt);
void qemu_handler_true(void *opaque);
void do_info_network(void);
diff --git a/qemu/vl.c b/qemu/vl.c
index 45c97af..1f0a6ac 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -3820,6 +3820,50 @@ void qemu_send_packet(VLANClientState *vc1, const
uint8_t *buf, int size)
}
}
+static ssize_t vc_sendv_compat(VLANClientState *vc, const struct iovec *iov,
+ int iovcnt)
+{
+char buffer[4096];
+size_t offset = 0;
+int i;
+
+for (i = 0; i iovcnt; i++) {
+ size_t len;
+
+ len = MIN(sizeof(buffer) - offset, iov[i].iov_len);
+ memcpy(buffer + offset, iov[i].iov_base, len);
+ offset += len;
+}
+
+vc-fd_read(vc-opaque, buffer, offset);
+
+return offset;
+}
+
+ssize_t qemu_sendv_packet(VLANClientState *vc1, const struct iovec *iov,
+ int iovcnt)
+{
+VLANState *vlan = vc1-vlan;
+VLANClientState *vc;
+ssize_t max_len = 0;
+
+for (vc = vlan-first_client; vc != NULL; vc = vc-next) {
+ ssize_t len = 0;
+
+ if (vc == vc1)
+ continue;
+
+ if (vc-fd_readv)
+ len = vc-fd_readv(vc-opaque, iov, iovcnt);
+ else if (vc-fd_read)
+ len = vc_sendv_compat(vc, iov, iovcnt);
+
+ max_len = MAX(max_len, len);
+}
+
+return max_len;
+}
+
#if defined(CONFIG_SLIRP)
/* slirp network adapter */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Add support for a configuration file
There has been an awful lot of discussion about a configuration file with
almost no general agreement except that one is strongly desired.
I thought about it a bit, and I think a nice step would be to simply allow
the current configuration parameters to be stored in a file using a pretty
familiar format.
I think this is pretty useful as-is. I think it also gives us a reasonable
way to move forward that will keep everyone pretty happy.
Here's a short example:
qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
Would become `foo.qemu':
# Main disk image
hda=/home/anthony/images/linux.img
# Redirect disk writes to a temporary image
snapshot
# Make the graphical display available on port 5902
vnc=:2
With:
qemu-system-x86_64 -config foo.qemu
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu-doc.texi b/qemu-doc.texi
index cca483c..4861fc0 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -395,6 +395,12 @@ Sets the @var{name} of the guest.
This name will be display in the SDL window caption.
The @var{name} will also be used for the VNC server.
[EMAIL PROTECTED] -config @var{file}
+Reads configuration options from @var{file}. The format of @var{file} is the
+same as the command line options, except no dash ``-'' is required. Options
+that take an argument are in the format @var{option=value}. A pound ``#''
+character can be used as a comment.
+
@end table
Display options:
diff --git a/vl.c b/vl.c
index 67712f0..2eb39dd 100644
--- a/vl.c
+++ b/vl.c
@@ -7276,6 +7276,7 @@ static void help(int exitcode)
-clock force the use of the given methods for timer
alarm.\n
To see what timers are available use -clock ?\n
-startdate select initial date of the clock\n
+ -config FILEread command line options from FILE\n
\n
During emulation, the following keys are useful:\n
ctrl-alt-f toggle full screen\n
@@ -7379,6 +7380,7 @@ enum {
QEMU_OPTION_old_param,
QEMU_OPTION_clock,
QEMU_OPTION_startdate,
+QEMU_OPTION_config,
};
typedef struct QEMUOption {
@@ -7490,6 +7492,7 @@ const QEMUOption qemu_options[] = {
#endif
{ clock, HAS_ARG, QEMU_OPTION_clock },
{ startdate, HAS_ARG, QEMU_OPTION_startdate },
+{ config, HAS_ARG, QEMU_OPTION_config },
{ NULL },
};
@@ -7665,9 +7668,106 @@ static BOOL WINAPI qemu_ctrl_handler(DWORD type)
}
#endif
+static char **insert_opts(char **old_argv, int *old_argc, int index,
+ char **argv, int argc)
+{
+char **new_argv;
+
+/* Allocate larger array */
+new_argv = realloc(old_argv, (*old_argc + argc) * sizeof(old_argv[0]));
+if (new_argv == NULL) {
+ fprintf(stderr, allocate failed in insert_opts\n);
+ exit(1);
+}
+
+/* move elements after insertion point to end of array */
+memmove(new_argv+index + argc, new_argv + index,
+ (*old_argc - index) * sizeof(argv[0]));
+
+/* copy in new elements */
+memcpy(new_argv + index, argv, argc * sizeof(argv[0]));
+
+*old_argc += argc;
+
+if (0) { /* for debugging */
+ int i;
+ printf(argv[] = {);
+ for (i = 0; i *old_argc; i++) {
+ if (i)
+ printf(, );
+ printf(\%s\, new_argv[i]);
+ }
+ printf(}\n);
+}
+
+return new_argv;
+}
+
+static char **parse_config_file(const char *file, int *pargc)
+{
+FILE *f;
+char buffer[4096];
+char **argv = NULL;
+int argc = 0;
+
+f = fopen(file, r);
+if (f == NULL)
+ return NULL;
+
+while (fgets(buffer, sizeof(buffer), f)) {
+ char *ptr = buffer;
+ char *tok, *key, *val;
+ char *targv[2];
+ int targc = 0;
+
+ /* skip whitespace */
+ while (isspace(*ptr)) ptr++;
+
+ /* skip comments or empty lines */
+ if (*ptr == '#' || *ptr == 0)
+ continue;
+
+ /* trim new line and carriage return if necessary */
+ tok = strchr(ptr, '\n');
+ if (tok)
+ *tok = 0;
+ tok = strchr(ptr, '\r');
+ if (tok)
+ *tok = 0;
+
+ /* check if it has an argument */
+ tok = strchr(ptr, '=');
+ if (tok)
+ *tok = 0;
+
+ /* add key */
+ if (asprintf(key, --%s, ptr) == -1)
+ return NULL;
+ targv[targc++] = key;
+
+ /* add argument (optionally) */
+ if (tok) {
+ if (asprintf(val, %s, tok + 1) == -1)
+ return NULL;
+ targv[targc++] = val;
+ }
+
+ /* insert new arguments */
+ argv = insert_opts(argv, argc, argc, targv, targc);
+ if (argv == NULL)
+ return NULL;
+}
+
+fclose(f);
+
+*pargc = argc;
+
+return argv;
+}
+
#define MAX_NET_CLIENTS 32
-int main(int argc, char **argv)
+int main(int orig_argc, char **orig_argv)
{
#ifdef CONFIG_GDBSTUB
int use_gdbstub;
@@ -7700,6 +7800,10 @@ int main(int argc,
Re: [kvm-devel] [PATCH] Add support for a configuration file
Anthony Liguori wrote:
I think this is pretty useful as-is. I think it also gives us a reasonable
way to move forward that will keep everyone pretty happy.
Here's a short example:
qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
Would become `foo.qemu':
# Main disk image
hda=/home/anthony/images/linux.img
# Redirect disk writes to a temporary image
snapshot
# Make the graphical display available on port 5902
vnc=:2
With:
qemu-system-x86_64 -config foo.qemu
One thought I had, is that it would be very nice to break up the -drive
file=foo.img,if=scsi syntax within the config file. In general, I'm
thinking something like:
[drive]
file=foo.img
if=scsi
or:
drive {
file=foo.img
if=scsi
}
or even:
drive:
file=foo.img
if=scsi
Basically, I'm looking for a syntax for sub-options. This would be
useful for -drive or -net but I also think would lay the foundations for
specifying a full machine config.
It would get very unwieldy on the command line to have a large number of
suboptions but it works reasonably well within a config.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Add support for a configuration file
On Tue, May 13, 2008 at 06:07:08PM -0500, Anthony Liguori wrote:
Anthony Liguori wrote:
I think this is pretty useful as-is. I think it also gives us a reasonable
way to move forward that will keep everyone pretty happy.
Here's a short example:
qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
Would become `foo.qemu':
# Main disk image
hda=/home/anthony/images/linux.img
# Redirect disk writes to a temporary image
snapshot
# Make the graphical display available on port 5902
vnc=:2
With:
qemu-system-x86_64 -config foo.qemu
One thought I had, is that it would be very nice to break up the -drive
file=foo.img,if=scsi syntax within the config file. In general, I'm
thinking something like:
Yes, that would be the main concern I have with the plain conversion
of existing command line args. It would essentially be limiting the
expressiveness of the config file to that of the command line - flat
key,value pairs. All we'd be gaining is avoidance of command line
length limits and persistent storage. Two worthy goals, but IMHO it
could be worth striving for more structure, so the config can explicitly
represent arrays and hashes as concepts.
[drive]
file=foo.img
if=scsi
This just feels like a bad 1/2 house compromise. Adds the complexity
of a more structured config file without giving the full benefits of
a more expressive format such as the 2 you show below.
drive {
file=foo.img
if=scsi
}
I like both this the next format because they're very expressive.
or even:
drive:
file=foo.img
if=scsi
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 can use standard tools for
generating and parsing the format.
Regards,
Daniel
[1] http://yaml.org/spec/1.2/
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Windows PV driver for KVM
Hi, Dor, I just checked the URL and seems it is not updated still, willyou update it? -- Yunhong Jiang Dor Laor mailto:[EMAIL PROTECTED] wrote: On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote: Avi Kivity mailto:[EMAIL PROTECTED] wrote: Jiang, Yunhong wrote: I noticed there is a windows PV driver based on virtIO in http://sourceforge.net/project/showfiles.php?group_id=180599 But when I enable the driver in guest, the guest will hang. I'm using changeset around April, 18. Since the driver is created in March, I assume the changeset in Apri should be ok. Are there any special action needed to enable the PV driver in windows? Have anyone tried it recently? We are using it in production. What HAL is the guest using? Are you running with smp? The HAL is ACPI multipprocessor PC. It is a UP guest. But I do notice one thing strange. When I use device manager-Processors, I see a lot of CPU listed. But it is really a UP system and I can only get one cpu in the task manager-performance window. Not sure if that's the reason of the hang. We just fixed an smp bug for virtio (also triggered by single processor with ACPI multiprocessor HAL). We'll publish a new binary tomorrow. The reason you see multiple cpus although there is only one is that we expose the maximum number in the bios. The system is actually uses the required number so this behavior is ok. -- Yunhong Jiang -- Any sufficiently difficult bug is indistinguishable from a feature. --- -- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java. sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 1/2] KVM: hlt emulation should take in-kernel APIC/PIT timers into account
On Tuesday 13 May 2008 00:40:05 Marcelo Tosatti wrote:
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. Please
correct me if I'm wrong.
Oh, sorry, I missed that commit. But... It just solved an half of the
problem. LAPIC suffered from it as well, and the current HLT emulation
still didn't work... And I can't find something like inject_pending in
LAPIC timer.
I have to say, I think my method is more preciously, directly and
efficient... It also can be extended easily if we got more clock sources
(though I don't think this would happen in near future...). In fact, I
think take care of pending counts is some kind of *wrong concept*... We
should take care of the window, or when the increment of pending counters
happened, CMIIW. And it got nothing to do with the current counter number
(yeah, I realized it after saw the hlt behaviour in XP, not before ;) ).
Sheng,
The problem is that you don't want to emulate hlt if you have a pending
timer _and_ the guest is accepting events. So for example if there are
two apic timers pending, you inject one of them, guest execute's hlt, we
end up in vcpu_block().
Does this work for you?
Yeah. I also suggest using the consistent implement for all the
_has_pending_timer. (in fact, if take pending counters as the interrupts
which have to delay their injection, the explanation is well :) )
--
Thanks
Yang, Sheng
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 7652f88..d41e34c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -961,7 +961,7 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu)
{
struct kvm_lapic *lapic = vcpu-arch.apic;
- if (lapic)
+ if (lapic apic_enabled(lapic) apic_lvt_enabled(lapic, APIC_LVTT))
return atomic_read(lapic-timer.pending);
return 0;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem
On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote: On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote: On Thursday 08 May 2008 10:38, Robin Holt wrote: In order to invalidate the remote page table entries, we need to message (uses XPC) to the remote side. The remote side needs to acquire the importing process's mmap_sem and call zap_page_range(). Between the messaging and the acquiring a sleeping lock, I would argue this will require sleeping locks in the path prior to the mmu_notifier invalidate_* callouts(). Why do you need to take mmap_sem in order to shoot down pagetables of the process? It would be nice if this can just be done without sleeping. We are trying to shoot down page tables of a different process running on a different instance of Linux running on Numa-link connected portions of the same machine. Right. You can zap page tables without sleeping, if you're careful. I don't know that we quite do that for anonymous pages at the moment, but it should be possible with a bit of thought, I believe. The messaging is clearly going to require sleeping. Are you suggesting we need to rework XPC communications to not require sleeping? I think that is going to be impossible since the transfer engine requires a sleeping context. I guess that you have found a way to perform TLB flushing within coherent domains over the numalink interconnect without sleeping. I'm sure it would be possible to send similar messages between non coherent domains. So yes, I'd much rather rework such highly specialized system to fit in closer with Linux than rework Linux to fit with these machines (and apparently slow everyone else down). Additionally, the call to zap_page_range expects to have the mmap_sem held. I suppose we could use something other than zap_page_range and atomically clear the process page tables. zap_page_range does not expect to have mmap_sem held. I think for anon pages it is always called with mmap_sem, however try_to_unmap_anon is not (although it expects page lock to be held, I think we should be able to avoid that). Doing that will not alleviate the need to sleep for the messaging to the other partitions. No, but I'd venture to guess that is not impossible to implement even on your current hardware (maybe a firmware update is needed)? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM: kvm_vcpu_block task state race
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 anything critical that issues vcpu ioctls outside its thread? While I much prefer wait_event_interruptible(), I don't want to break existing userspace. Well debugging can be critical, so IMO better avoid wait_event_interruptible() for now. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM: LAPIC: ignore pending timers if LVTT is disabled
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.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 7652f88..d41e34c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -961,7 +961,7 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu)
{
struct kvm_lapic *lapic = vcpu-arch.apic;
- if (lapic)
+ if (lapic apic_enabled(lapic) apic_lvt_enabled(lapic, APIC_LVTT))
return atomic_read(lapic-timer.pending);
return 0;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem
On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote: ea. I don't see why you're bending over so far backwards to accommodate this GRU thing that we don't even have numbers for and could actually potentially be batched up in other ways (eg. using mmu_gather or mmu_gather-like idea). I agree, we're better off generalizing the mmu_gather batching instead... I had some never-finished patches to use the mmu_gather for pretty much everything except single page faults, tho various subtle differences between archs and lack of time caused me to let them take the dust and not finish them... I can try to dig some of that out when I'm back from my current travel, though it's probably worth re-doing from scratch now. Ben. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
