Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Anthony L. <ali...@us...> - 2008-05-13 19:13:49
|
Missed this one in my last series.
Signed-off-by: Anthony Liguori <ali...@us...>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 93bca1d..ca45775 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -246,6 +246,12 @@ static void virtio_net_flush_tx(VirtIONet *n, VirtQueue *vq)
while (virtqueue_pop(vq, &elem)) {
ssize_t len = 0;
+ if (elem.out_num < 1 ||
+ elem.out_sg[0].iov_len != sizeof(struct virtio_net_hdr)) {
+ fprintf(stderr, "virtio-net header not in first element\n");
+ exit(1);
+ }
+
/* ignore the header for now */
len = qemu_sendv_packet(n->vc, &elem.out_sg[1], elem.out_num - 1);
|
|
From: Ryan H. <ry...@us...> - 2008-05-13 18:58:20
|
* Anthony Liguori <an...@co...> [2008-05-12 17:00]: > Ryan Harper wrote: > >>BTW, what if you don't pace-out the startups? Do we still have issues > >>with that? > >> > > > >Do you mean without the 1 second delay or with a longer delay? My > >experience is that delay helps (fewer hangs), but doesn't solve things > >completely. > > > > So you see problems when using numactrl to pin and using a 0-second > delay? The short delay may help reduce the number of CPU migrations > which would explain your observation. > > If there are problems when doing a 0-second delay and numactl, then > perhaps it's not just a cpu-migration issue. nodelay, w/pinning -> all OK delay, w/pinning -> all OK with -no-kvm-irqchip (with or without any delay (1 to 30 seconds), I get in some guests: ..MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter > >In svm.c, I do think we account for most of that time since the delta > >calculation will shift the guest time forward to the tsc value read in > >svm_vcpu_load(). We'll still miss the time between fixing the offset > >and when the guest can actually read its tsc. > > > > Yes, which is the duration that the guest isn't scheduled on any > processor and the next time it runs happens to be on a different process. > > >>A possible way to fix this (that's only valid on a processor with a > >>fixed-frequency TSC), is to take a high-res timestamp on vcpu_put, and > >>then on vcpu_load, take the delta timestamp since the old TSC was saved, > >>and use the TSC frequency on the new pcpu to calculate the number of > >>elapsed cycles. > >> > >>Assuming a fixed frequency TSC, and a calibrated TSC across all > >>processors, you could get the same affects by using the VT tsc delta > >>logic. Basically, it always uses the new CPU's TSC unless that would > >>cause the guest to move backwards in time. As long as you have a > >>stable, calibrated TSC, this would work out. > >> > >>Can you try your old patch that did this and see if it fixes the problem? > >> > > > >Yeah, I'll give it a spin. Testing the old patch with no-pinning, but just the tsc check doesn't help the situation. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ry...@us... |
|
From: Сделки с в. < <ea...@bo...> - 2008-05-13 17:20:04
|
Применение векселя в хозяйственном обороте. Расчетные схемы, налоговые последствия, правовые риски участников вексельного оборота
Однодневный семинар / 19 мая 2008 г. / Москва
Программа семинара
1. Правовая природа векселя и сделок с ним.
∙ Содержание вексельного обязательства. Виды векселей. Конструкция обязательств в простых и переводных векселях
∙ Типовое ("стандартное") применение векселей в хозяйственной деятельности. Правовая характеристика сделок, лежащих в основании выдачи, передачи и погашения векселей. Займы под вексель, встречные векселя, продажа и залог векселей и др..
∙ Типовые (базовые) схемы "вексельных" взаиморасчетов.
2. Налоговые последствия базовых схем взаиморасчетов с применением простых векселей.
∙ НДС при расчетах собственными простыми векселями покупателя. Расчеты путем акцепта переводных векселей.
∙ НДС при расчетах векселями третьих лиц.
∙ НДС при расчетах переводными векселями.
∙ Налог на прибыль при операциях с дисконтным и процентным векселем.
3. Налоговые риски в случае нестандартных схем применения векселей в хозяйственной деятельности.
∙ Концепция реальных затрат в налогообложении НДС. Возможные налоговые претензии при наличии вспомогательных вексельных схем..
∙ Другие схемы
4. Основные правовые риски участников вексельного оборота и способы защиты прав.
∙ Обзор возможных возражений против требований об оплате векселя. Требования к форме, к процедуре предъявления к оплате. Понятие недобросовестного приобретения векселя и приобретения в ущерб должнику.
∙ Действия держателя в случае похищения или утраты векселя. Вызывное производство и связанные с этой процедурой риски.
∙ Действия векселеучастников в случае обнаружения подлога векселя. Средства доказывания факта подлога. Распределение обязанности доказывания. Несовершенство института публичной достоверности векселя.
Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу).
Место обучения: г. Москва, 5 мин. пешком от м. Академическая.
Стоимость обучения: 4900 руб. (с НДС).
(В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане).
Для регистрации на семинар необходимо отправить нам реквизиты организации, тему и дату семинара, полное ФИО участников, контактный телефон и факс.
Получить подробную программу и зарегистрироваться можно
по телефону: ( 4 9 5 ) 5 43 = 8 8 = 4 6
|
|
From: Avi K. <av...@qu...> - 2008-05-13 16:25:26
|
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 compiling committee.c: too many arguments to function
|
|
From: Robin H. <ho...@sg...> - 2008-05-13 15:32:38
|
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 |
|
From: Ian K. <bl...@bl...> - 2008-05-13 12:16:18
|
Hi,
I wanted to try running Vmware ESX without the effort of finding a
physical machine. Googling around I found that it is possible to run ESX
under other hypervisors/emulators, e.g. Vmware Workstation. So I thought
i'd give KVM a go.
Using kvm-66 on 2.6.24.4-64.fc8PAE, the (mostly text mode) installer
crashes after starting with "esx text". (I can't easily test kvm-68 at the
mo due to needing to do a reboot of the host)
Microsoft Virtual Server R2-SP1 kinda works, however the virtual NIC
is unsupported by the ESX installer.
Qemu 0.9.1 (for Windows) fails at a similar point.
Is this a "fixed in newer kvm" or a generic problem (be it kvm or ESX
installer CDROM kernel) ?
I hadn't even got as far as installing/running ESX.
Regards,
Ian
host dmesg says:
kvm: emulating exchange as write
kvm: 9329: cpu0 unhandled rdmsr: 0xc0000080
kvm: 9350: cpu0 unhandled rdmsr: 0xc0000080
guest kernel says:
Intel machine check reporting enabled on CPU#0.
general protection fault: 0000
CPU: 0
EIP: 0060:[<c02ba1b1>] Not tainted
EFLAGS: 00010206
EIP is at (2.4.21-47.0.1.ELBOOT/i686)
eax: 0191abfd ebx: c0293580 ecx: c0000080 edx: 00000001
esi: 00000001 edi: 00000002 ebp: c0293580 esp: c02b5fc8
ds: 0068 cs: 0060 es: 0068 ss: 0068
Process swapper (pid: 0, stackpage=c02b5000)
Stack: c02ba34a c0293580 c0293580 00000800 00039800 c0107000 0002e000
c02b6192
c0293580 c02b6679 0001fff0 0001fff0 c02e8480 c010018c
Call Trace: [<c0107000>] (0xc02b5fdc)
Code: 0f 32 a9 00 08 00 00 74 09 a1 74 0e 2d c0 85 c0 74 0d c7 05
Kernel panic: Fatal exception
In idle task - not syncing
|
|
From: Nick P. <nic...@ya...> - 2008-05-13 12:14:33
|
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 maj...@kv.... For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"do...@kv..."> em...@kv... </a> |
|
From: Nick P. <nic...@ya...> - 2008-05-13 12:07:00
|
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. |
|
From: Farkas L. <lf...@bp...> - 2008-05-13 10:18:05
|
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!" |
|
From: Avi K. <av...@qu...> - 2008-05-13 10:14:04
|
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=detail&atid=893831&aid=1959950&group_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=detail&atid=893831&aid=1959443&group_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=detail&aid=1920897&group_id=180599&atid=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 |
|
From: Joerg R. <joe...@am...> - 2008-05-13 10:11:53
|
On Wed, May 07, 2008 at 05:01:02PM -0500, Ryan Harper wrote:
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 5528121..c919ddd 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -685,8 +685,14 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> * increasing TSC.
> */
> rdtscll(tsc_this);
> - delta = vcpu->arch.host_tsc - tsc_this;
> - svm->vmcb->control.tsc_offset += delta;
> + /* we only need to adjust this if the old tsc was ahead
> + * also, we'll generate a massively large u64 value if
> + * tsc_this is less than host_tsc because of unsigned math
> + */
> + if (tsc_this < vcpu->arch.host_tsc) {
> + delta = vcpu->arch.host_tsc - tsc_this;
> + svm->vmcb->control.tsc_offset += delta;
> + }
> vcpu->cpu = cpu;
> kvm_migrate_apic_timer(vcpu);
> }
Hmm, I think this can result in inaccurate guest time because it makes
the tsc hopping. Does it fix the problem when you make delta an s64?
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
|
|
From: Bernd S. <bs...@q-...> - 2008-05-13 10:05:05
|
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 |
|
From: Yunfeng Z. <yun...@in...> - 2008-05-13 08:46:00
|
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=detail&atid=893831&aid=1959950&group_id=180599 2. XP crashes while rebooting https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_id=180599 3. linux virtio drivers won't work after runing save/restore https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959443&group_id=180599 4.Cannot boot guests with hugetlbfs https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599 5. KVM Guest Drivers fail on Windows https://sourceforge.net/tracker/index.php?func=detail&aid=1920897&group_id=180599&atid=893831 We met the issue too while testing Windows drivers on XP. Test environment ================================================ Platform Woodcrest 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 parallel PASS 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 guest PASS 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 enabled PASS 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 parallel PASS 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 parallel PASS 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 enabled PASS 18. boot 32-bit Windows 2000 without ACPI PASS 19. boot 64-bit Windows xp with ACPI enabled PASS 20. boot 32-bit Windows xp without ACPI PASS 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 OS PASS 26. LTP on 64-bit linux guest OS PASS 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 Report Summary on IA32-pae Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 9 5 4 0 0 Restart 2 2 0 0 0 gtest 17 14 3 0 0 ===================================================================== control_panel 9 5 4 0 0 :KVM_256M_guest_PAE_gPAE 1 1 0 0 0 :KVM_linux_win_PAE_gPAE 1 1 0 0 0 :KVM_two_winxp_PAE_gPAE 1 1 0 0 0 :KVM_SR_SMP_PAE_gPAE 1 0 1 0 0 :KVM_four_sguest_PAE_gPA 1 1 0 0 0 :KVM_1500M_guest_PAE_gPA 1 1 0 0 0 :KVM_LM_SMP_PAE_gPAE 1 0 1 0 0 :KVM_LM_Continuity_PAE_g 1 0 1 0 0 :KVM_SR_Continuity_PAE_g 1 0 1 0 0 Restart 2 2 0 0 0 :GuestPAE_PAE_g64 1 1 0 0 0 :BootTo32pae_PAE_g64 1 1 0 0 0 gtest 17 14 3 0 0 :ltp_nightly_PAE_gPAE 1 0 1 0 0 :boot_up_acpi_PAE_gPAE 1 1 0 0 0 :reboot_xp_PAE_gPAE 1 1 0 0 0 :boot_up_vista_PAE_gPAE 1 0 1 0 0 :boot_up_acpi_xp_PAE_gPA 1 1 0 0 0 :boot_up_acpi_win2k3_PAE 1 1 0 0 0 :boot_smp_acpi_win2k3_PA 1 1 0 0 0 :boot_smp_acpi_win2k_PAE 1 1 0 0 0 :boot_up_acpi_win2k_PAE_ 1 1 0 0 0 :boot_smp_acpi_xp_PAE_gP 1 1 0 0 0 :boot_up_noacpi_win2k_PA 1 1 0 0 0 :boot_smp_vista_PAE_gPAE 1 1 0 0 0 :boot_base_kernel_PAE_gP 1 1 0 0 0 :boot_up_win2008_PAE_gPA 1 1 0 0 0 :bootx_PAE_gPAE 1 1 0 0 0 :boot_smp_win2008_PAE_gP 1 0 1 0 0 :kb_nightly_PAE_gPAE 1 1 0 0 0 ===================================================================== Total 28 21 7 0 0 Report Summary on IA32e Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 19 11 8 0 0 Restart 3 3 0 0 0 gtest 29 26 3 0 0 ===================================================================== control_panel 19 11 8 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 1 0 0 0 :KVM_LM_SMP_64_g64 1 0 1 0 0 :KVM_LM_SMP_64_gPAE 1 0 1 0 0 :KVM_SR_Continuity_64_gP 1 0 1 0 0 :KVM_1500M_guest_64_g64 1 1 0 0 0 :KVM_4G_guest_64_gPAE 1 1 0 0 0 :KVM_LM_Continuity_64_g6 1 0 1 0 0 :KVM_four_dguest_64_gPAE 1 1 0 0 0 :KVM_SR_SMP_64_gPAE 1 0 1 0 0 :KVM_SR_SMP_64_g64 1 0 1 0 0 :KVM_4G_guest_64_g64 1 1 0 0 0 :KVM_1500M_guest_64_gPAE 1 1 0 0 0 :KVM_four_sguest_64_g64 1 1 0 0 0 :KVM_LM_Continuity_64_gP 1 0 1 0 0 :KVM_256M_guest_64_g64 1 1 0 0 0 :KVM_two_winxp_64_gPAE 1 1 0 0 0 :KVM_256M_guest_64_gPAE 1 1 0 0 0 :KVM_SR_Continuity_64_g6 1 0 1 0 0 Restart 3 3 0 0 0 :GuestPAE_64_gPAE 1 1 0 0 0 :BootTo64_64_gPAE 1 1 0 0 0 :Guest64_64_gPAE 1 1 0 0 0 gtest 29 26 3 0 0 :boot_up_acpi_64_gPAE 1 1 0 0 0 :boot_up_noacpi_xp_64_gP 1 1 0 0 0 :boot_smp_acpi_xp_64_g64 1 0 1 0 0 :boot_base_kernel_64_gPA 1 1 0 0 0 :boot_smp_win2008_64_g64 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_smp_acpi_win2k_64_ 1 1 0 0 0 :boot_base_kernel_64_g64 1 1 0 0 0 :bootx_64_gPAE 1 1 0 0 0 :kb_nightly_64_gPAE 1 1 0 0 0 :ltp_nightly_64_g64 1 1 0 0 0 :boot_up_acpi_64_g64 1 1 0 0 0 :boot_smp_win2008_64_gPA 1 1 0 0 0 :boot_smp_acpi_xp_64_gPA 1 1 0 0 0 :boot_up_noacpi_win2k_64 1 1 0 0 0 :boot_smp_vista_64_gPAE 1 1 0 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :reboot_xp_64_gPAE 1 1 0 0 0 :boot_up_win2008_64_g64 1 1 0 0 0 :bootx_64_g64 1 1 0 0 0 :reboot_xp_64_g64 1 0 1 0 0 :boot_up_vista_64_g64 1 1 0 0 0 :boot_up_win2008_64_gPAE 1 1 0 0 0 :boot_up_acpi_xp_64_g64 1 1 0 0 0 :boot_up_vista_64_gPAE 1 0 1 0 0 :ltp_nightly_64_gPAE 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_up_noacpi_win2k3_6 1 1 0 0 0 :kb_nightly_64_g64 1 1 0 0 0 ===================================================================== Total 51 40 11 0 0 Thanks Yunfeng |
|
From: Avi K. <av...@qu...> - 2008-05-13 08:04:01
|
Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann <kr...@re...>
> ---
> 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 = 1000000000LL;
> + 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
|
|
From: Юридичесикий о. <te...@ig...> - 2008-05-13 07:46:11
|
Договоры в строительстве (практические рекомендации) Однодневный семинар / 16 мая 2008 г. / Москва Программа семинара Договоры в строительстве: общие положения ∙ Общая характеристика договоров, сопровождающих строительную деятельность. ∙ Обзор договоров подрядного типа и практической сферы их применения. ∙ Анализ типичных спорных ситуаций с участием субподрядных организаций. Документальное оформление договорных отношений ∙ Виды документов, оформляющих договорные отношения, их назначение и правила составления. ∙ Правовое значение протоколов о намерениях и протоколов разногласий. ∙ Судебно-арбитражная практика по спорам, связанным с использованием предварительных договоров в строительной деятельности (анализ конкретных арбитражных решений). Договорные условия ∙ Существенные условия договора строительного подряда. ∙ Обзор судебно-арбитражной практики по спорам о несогласованных (неверно согласованных) существенных условиях договора. Тендерный отбор контрагентов (преимущества и недостатки) ∙ Особенности заключения договора по результатам торгов (включая специфику государственных заказов). ∙ Обобщение судебно-арбитражной практики по спорам о признании торгов недействительными. ∙ Анализ конкретных ситуаций исполнения договоров строительного подряда с организациями, отобранными на конкурсной основе. Обеспечение интересов заказчика в договорных отношениях ∙ Способы обеспечения прав заказчика в договоре строительного подряда. ∙ Цена договора и порядок расчетов. Установление условий о цене с учетом инфляции, удорожания материалов, рабочей силы и других тенденций изменения рыночных цен. ∙ Основные подходы к расчетам с подрядчиками, законодательные ограничения, возможные споры. Оформление сдачи-приемки работ ∙ Основные документы, правила подписания, законодательные ограничения. ∙ Судебно-арбитражная практика оспаривания оформления сдачи-приемки работ, оплаты работ по оформленным актам, полномочиям лиц, осуществившим приемку работ. Ответственность за нарушение договорных обязательств в строительной деятельности ∙ Основные меры ответственности за нарушение договорных обязательств. ∙ Практика взыскания, обобщение типичных судебных споров. Ответы на вопросы участников семинара. Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу). Место обучения: г. Москва, 5 мин. пешком от м. Академическая. Стоимость обучения: 4900 руб. (с НДС). (В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане). При отсутствии возможности посетить семинар, мы предлагаем приобрести его видеоверсию на DVD/CD дисках или видеокассетах (прилагается авторский раздаточный материал). Цена видеокурса - 3500 рублей, с учетом НДС. Для регистрации на семинар необходимо отправить нам по факсу: реквизиты организации, тему и дату семинара, полное ФИО участников, контактный телефон и факс. Для заказа видеокурса необходимо отправить нам по факсу: реквизиты организации, тему видеокурса, указать носитель (ДВД или СД диски), телефон, факс, контактное лицо и точный адрес доставки. Получить дополнительную информацию и зарегистрироваться можно: по т/ф: ( Ч 9 5 ) 5 Ч З - 8 8 - Ч 6 |
|
From: Avi K. <av...@qu...> - 2008-05-13 07:25:38
|
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 |
|
From: Yang, S. <she...@in...> - 2008-05-13 07:18:00
|
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 <she...@in...>
> > >>> 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
|
|
From: Gerd H. <kr...@re...> - 2008-05-13 06:54:05
|
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 registered the physical address via msr write in the host, and *that* needs an update too. Otherwise the host continues to update the pre-setup location, and the guest sees the (stale) values the kvm clock had at per-cpu-area-setup time (when the copy took place). cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ |
|
From: Yang, S. <she...@in...> - 2008-05-13 06:36:16
|
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 <she...@in...>
> >>> 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.
--
Thanks
Yang, Sheng
|
|
From: Подарок <tek...@ro...> - 2008-05-13 05:37:39
|
Новые коллекции постельного белья на сайте www.postelmagaz.ru Большой выбор на любой вкус, цвет и кошелёк. Доставка по Москве, отправка по России! Заходите www.postelmagaz.ru |
|
From: Han, W. <wei...@in...> - 2008-05-13 04:33:29
|
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 based on Amit's pci-passthrough tree. You can try them first. Randy (Weidong) Neo Jia 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 <wei...@in...> > wrote: >> 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, 2008, at 9:07 AM, Gerry Reno <gr...@ve...> >> wrote: > >> 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 >> >> >> >> >> >> --- >> >> >> ---------------------------------------------------------------------- >> >> 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/j >> avaone >> _______________________________________________ >> >> kvm-devel mailing list >> kvm...@li... >> >> 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/vse0120000070mrt/direct/01/ >> >> >>> _______________________________________________ >> > kvm-devel mailing list >> > kvm...@li... >> > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: David S. A. <da...@ci...> - 2008-05-13 03:49:22
|
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: >>> >>> 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 to speculated ptes and marks >> them as accessed, preventing the flooding on centos-3.1. >> Unfortunately it also causes a host oops midway through the boot process. >> >> I believe the oops is merely exposed by the patch, not caused by it. >> > > It was caused by the patch, please try the updated one attached. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: Neo J. <ne...@gm...> - 2008-05-13 03:43:49
|
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 <wei...@in...> wrote: > 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, 2008, at 9:07 AM, Gerry Reno <gr...@ve...> wrote: > > > >> 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 > >> > >> > >> --- > >> > ---------------------------------------------------------------------- > >> 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/j > avaone > >> _______________________________________________ > >> kvm-devel mailing list > >> kvm...@li... > >> 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/vse0120000070mrt/direct/01/ > > > > _______________________________________________ > > kvm-devel mailing list > > kvm...@li... > > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! |
|
From: Han, W. <wei...@in...> - 2008-05-13 03:23:07
|
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, 2008, at 9:07 AM, Gerry Reno <gr...@ve...> wrote: > >> 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 >> >> >> --- >> ---------------------------------------------------------------------- >> 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/j avaone >> _______________________________________________ >> kvm-devel mailing list >> kvm...@li... >> 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/vse0120000070mrt/direct/01/ > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: Neo J. <ne...@gm...> - 2008-05-12 23:45:40
|
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 <gr...@ve...> wrote: > 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 > > > --- > ---------------------------------------------------------------------- > 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...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
157 messages has been excluded from this view by a project administrator.
