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: Andrea A. <an...@qu...> - 2008-04-22 12:02:31
|
On Tue, Apr 22, 2008 at 09:20:26AM +0200, Andrea Arcangeli wrote:
> invalidate_range_start {
> spin_lock(&kvm->mmu_lock);
>
> kvm->invalidate_range_count++;
> rmap-invalidate of sptes in range
>
write_seqlock; write_sequnlock;
> spin_unlock(&kvm->mmu_lock)
> }
>
> invalidate_range_end {
> spin_lock(&kvm->mmu_lock);
>
> kvm->invalidate_range_count--;
write_seqlock; write_sequnlock;
>
> spin_unlock(&kvm->mmu_lock)
> }
Robin correctly pointed out by PM there should be a seqlock in
range_begin/end too like corrected above.
I guess it's better to use an explicit sequence counter so we avoid an
useless spinlock of the write_seqlock (mmu_lock is enough already in
all places) and so we can increase it with a single op with +=2 in the
range_begin/end. The above is a lower-perf version of the final
locking but simpler for reading purposes.
|
|
From: Avi K. <av...@qu...> - 2008-04-22 11:36:50
|
Jerone Young wrote: > Recent change now requires target-ppc/helper.c to now include "qemu-kvm.h" to get the definition for kvm_enabled(). This fixes it so things now compile again. > > Applied, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-22 11:35:28
|
Luca Tettamanti wrote: > Is cfq still fair in the guest? The VM re-dispatches the requests (at > least when using QEMU IDE) and the host can reschedule them at will. > The same problem occurs (to a lesser extent) in non-virtualized environments; disks (and esp. array controllers) also have their own I/O schedulers. -- error compiling committee.c: too many arguments to function |
|
From: Luca T. <kro...@gm...> - 2008-04-22 11:27:37
|
On Tue, Apr 22, 2008 at 1:10 PM, Avi Kivity <av...@qu...> wrote: > Damjan wrote: > > I have some questions for the FAQ, about the configuration of Linux guests: > > a) is swap needed in the guest (I'd say no, but..) > > b) what filesystem is best for a guest > > c) what io scheduler in the guest (noop? or cfq) > > d) are there any runtime kernel tweaks for the guest (/proc/sys)? > > For the first four questions, do whatever you'd do for a similarly > configured host running a similar workload. It's fine to use cfq as the > I/O scheduler. Is cfq still fair in the guest? The VM re-dispatches the requests (at least when using QEMU IDE) and the host can reschedule them at will. Luca |
|
From: Avi K. <av...@qu...> - 2008-04-22 11:22:49
|
Rusty Russell wrote: > [Christian, Hollis, how much is this ABI breakage going to hurt you?] > > A recent proposed feature addition to the virtio block driver revealed > some flaws in the API, in particular how easy it is to break big > endian machines. > > The virtio config space was originally chosen to be little-endian, > because we thought the config might be part of the PCI config space > for virtio_pci. It's actually a separate mmio region, so that > argument holds little water; as only x86 is currently using the virtio > mechanism, we can change this (but must do so now, before the > impending s390 and ppc merges). > > This will probably annoy Hollis which has guests that can go both ways. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-22 11:21:20
|
Chris Wright wrote: > The pci hotadd patches make it easy to trigger segfaults when adding more > devices than a single PCI bus can handle. The following 2 patches fix the > pci nic devices and virtio-blk device. Now the following the following: > > OK bus 0, slot 31, function 0 (devfn 248) > (qemu) pci_add 0 nic model=virtio > Segmentation fault > > OK bus 0, slot 31, function 0 (devfn 248) > (qemu) pci_add 0 storage file=/mnt/disk1,if=virtio > Segmentation fault > > become: > > OK bus 0, slot 31, function 0 (devfn 248) > (qemu) pci_add 0 nic model=virtio > qemu: Unable to initialze NIC: virtio > failed to add model=virtio > > OK bus 0, slot 31, function 0 (devfn 248) > (qemu) pci_add 0 storage file=/mnt/disk1,if=virtio > failed to add file=/mnt/disk1,if=virtio > Applied all three, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-22 11:18:16
|
Jes Sorensen wrote: > Hi, > > This one fixes a segfault problem I am seeing on ia64 due to the > malloc'ed address being truncated to 32 bit. > Applied, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-22 11:16:35
|
Jerone Young wrote: > What I am asking is do I have all the proper options in my kernel config > set to use it? > > I have: [avi@cleopatra linux-2.6 (kvm-updates-2.6.26)]$ grep VIRTIO .config CONFIG_VIRTIO_BLK=m CONFIG_VIRTIO_NET=m CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m -- error compiling committee.c: too many arguments to function |
|
From: Christian E. <ehr...@li...> - 2008-04-22 11:11:13
|
Jerone Young wrote: > virtio net device does not appear to show itself in the guest. I'm > curious of what options I may be missing. Here is my config > > CONFIG_VIRTIO_NET=y [..] > CONFIG_VIRTUALIZATION=y > CONFIG_KVM=y > CONFIG_KVM_BOOKE_HOST=y > CONFIG_VIRTIO=y > CONFIG_VIRTIO_RING=y > CONFIG_VIRTIO_PCI=y That should be enough in .config, but be aware that you need the proper qemu command line like "-net nic,model=virtio,macaddr=00:00:00:00:00:AA -net tap" as well as a /etc/qemu-ifup script (I sent one for our purpose to kvm-ppc-devel a while ago) + you need some tools installed e.g. brctl and you need to create /dev/net/tun in the host because we have no dynamic /dev. If you have done all that already and it is still not working you should continue with anthonys suggestion and send what lspci shows you. If you want to be complete use "lspci -vvvx" And maybe it is worth to add debug to the kernel command line of the guest and attach a full dmesg to the same response too, just in case someone might want to look at driver messages. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization |
|
From: Avi K. <av...@qu...> - 2008-04-22 11:10:39
|
Damjan wrote: > I have some questions for the FAQ, about the configuration of Linux guests: > a) is swap needed in the guest (I'd say no, but..) > b) what filesystem is best for a guest > c) what io scheduler in the guest (noop? or cfq) > d) are there any runtime kernel tweaks for the guest (/proc/sys)? > For the first four questions, do whatever you'd do for a similarly configured host running a similar workload. It's fine to use cfq as the I/O scheduler. > e) suggested linux kernel source configuration (.config) With newer kernels, be sure to enable virtio drivers, kvm clock, and kvm mmu paravirtualization. -- error compiling committee.c: too many arguments to function |
|
From: Конкурс <rhi...@re...> - 2008-04-22 10:37:44
|
Размeщeниe гoсудаpствeннoгo и муниципальнoгo заказа на тopгах: спopныe вoпpoсы сoвpeмeннoй пpактики 25 апpeля 2008, г. Мoсква Пpoгpамма сeминаpа - Анализ кoнкpeтных аpбитpажных дeл, являющихся наибoлee pаспpoстpанeнными (типичными) в судeбнo-аpбитpажнoй пpактикe oспаpивания pазмeщeния гoсудаpствeннoгo и муниципальнoгo заказа. - Аналитичeский кoммeнтаpий спopных ситуаций, вoзникающих как в хoдe пpoвeдeния тopгoв, так и в пpoцeссe заключeния и испoлнeния гoсудаpствeнных (муниципальных) кoнтpактoв), заключeнных пo их итoгам. - Исслeдoваниe тopгoв нoсит кoмплeксный хаpактep, т.к. затpагиваются и пpoцeссуальныe oсoбeннoсти pассмoтpeния спopoв o нeдeйствитeльнoсти тopгoв. - oтвeты на ключeвыe вoпpoсы сeминаpа аpгумeнтиpуются сo ссылкoй на научнo-пpикладныe исслeдoвания, матepиалы заpубeжнoй и мeждунаpoднoй пpактики пpoвeдeния аукциoнoв и кoнкуpсoв. - Пo каждoй тeмe пpoгpаммы мoгут быть пpoанализиpoваны пpoблeмныe ситуации из пpактики слушатeлeй, пo хoду oбсуждeния автopoм даются кoнкpeтныe peкoмeндации. Ключeвыe вoпpoсы пpoгpаммы ∙ Скoлькo мoжeт быть пoбeдитeлeй на тopгах? Впpавe ли участники oбъeдинять свoи пpeдлoжeния дo или в пpoцeссe пpoвeдeния тopгoв? ∙ Какиe лица впpавe заявить иск o пpизнании тopгoв нeдeйствитeльными? Как oпpeдeлить "заинтepeсoваннoсть" в oспаpивании peзультатoв тopгoв? ∙ Чтo oзначаeт "нeдeйствитeльнoсть" аукциoна или кoнкуpса: oспopимoсть или ничтoжнoсть? ∙ Как oцeнить сoстязатeльнoсть участникoв? Есть ли oснoвания пpизнать тopги нeсoстoявшимися, eсли участникoв былo двoe? ∙ Чeм oбeспeчиваeтся заявка на участиe в аукциoнe (кoнкуpсe)? Мoжeт ли opганизатop тopгoв пpинимать oт участникoв банкoвскиe гаpантии, пpoстыe вeксeля или дeнeжныe сpeдства на услoвиях залoга? ∙ В чeм пpинципиальныe oтличия пpавoвoгo статуса участника тopгoв и участника pазмeщeния заказа? ∙ Каким oбpазoм фopмулиpуются кpитepии кoнкуpснoгo (аукциoннoгo) oтбopа и мoжнo ли oт них oтступить пpи oпpeдeлeнии пoбeдитeля? ∙ Чтo дeлать пpи пoлучeнии oдинакoвых пpeдлoжeний oт нeскoльких участникoв? ∙ Нeoбхoдимo ли пpoвoдить пoвтopныe тopги, eсли пoбeдитeль нe испoлняeт заключeнный на тopгах дoгoвop / уклoняeтся oт eгo заключeния? ∙ Мoжeт ли суд, пpизнав факты наpушeния закoнoдатeльства, oставить в силe peзультаты тopгoв на pазмeщeниe гoсудаpствeннoгo и муниципальнoгo заказа? oпopныe тeмы пpoгpаммы ∙ Пpeимущeства и нeдoстатки заключeния дoгoвopoв путeм пpoвeдeния тopгoв. oснoвныe pазнoвиднoсти аукциoнoв и кoнкуpсoв. ∙ Пpавoвыe пpoблeмы участия в тopгах дoгoвopных oбъeдинeний участникoв, а такжe аффилиpoванных лиц. ∙ Пpoцeссуальныe oсoбeннoсти pассмoтpeния спopoв o нeдeйствитeльнoсти тopгoв. ∙ oснoвания для пpизнания тopгoв нeсoстoявшимися. ∙ Пpавoвoe значeниe oбeспeчeния аукциoннoй или кoнкуpснoй заявки. ∙ Тpeбoвания закoнoдатeльства к извeщeнию o пpoвeдeнии тopгoв, хаpактepистика "нeнадлeжащих" извeщeний. ∙ oпpeдeлeниe кpитepиeв кoнкуpснoгo или аукциoннoгo oтбopа, пpавoвыe pамки pабoты кoнкуpснoй (аукциoннoй) кoмиссии. ∙ "Аннулиpoваниe тopгoв", "Пpизнаниe тopгoв нeдeйствитeльными", "oбъявлeниe тopгoв нeсoстoявшимися": pазличия пpoцeдуp и их пpавoвыe пoслeдствия. ∙ Сooтнoшeниe администpативнoгo и судeбнoгo спoсoбoв защиты пpав и закoнных интepeсoв участникoв pазмeщeния заказа. Пpoдoлжитeльнoсть oбучeния: с 10 дo 17 часoв (с пepepывoм на oбeд и кoфe-паузу). Мeстo oбучeния: г. Мoсква, 5 мин. пeшкoм oт м. Акадeмичeская. Стoимoсть oбучeния: 4900 pуб. (с НДС). (В стoимoсть вxoдит: pаздатoчный матepиал, кoфe-пауза, oбeд в peстopанe). Пpи oтсутствии вoзмoжнoсти пoсeтить сeминаp, мы пpeдлагаeм пpиoбpeсти eгo видeoвepсию на DVD/CD дискаx или видeoкассeтаx (пpилагаeтся автopский pаздатoчный матepиал). Цeна видeoкуpса - 3500 pублeй, с учeтoм НДС. Для peгистpации на сeминаp нeoбxoдимo oтпpавить нам пo факсу: peквизиты opганизации, тeму и дату сeминаpа, пoлнoe ФИo участникoв, кoнтактный тeлeфoн и факс. Для заказа видeoкуpса нeoбxoдимo oтпpавить нам пo факсу: peквизиты opганизации, тeму видeoкуpса, указать нoситeль (ДВД или СД диски), тeлeфoн, факс, кoнтактнoe лицo и тoчный адpeс дoставки. Пoлучить дoпoлнитeльную инфopмацию и заpeгистpиpoваться мoжнo: пo т/ф: ( 4 9 5 ) 54 З 8 8 4 6 |
|
From: Alexander G. <al...@cs...> - 2008-04-22 10:35:55
|
I believe that's the way to go. If you have spare time on your hands, feel free to integrate my multiboot patches as well. Alex On Apr 22, 2008, at 11:07 AM, Nguyen Anh Quynh wrote: > Hi, > > I am thinking about comibing this ROM with the extboot. Both two ROM > are about "booting", so I think that is reasonable. So we will have > only 1 ROM that supports both external boot and Linux boot. > > Is that desirable or not? > > Thanks, > Quynh > > On 4/21/08, Nguyen Anh Quynh <aq...@gm...> wrote: >> Hmm, the last patch includes a binary. So please take this patch >> instead. >> >> Thanks, >> >> Q >> >> # diffstat linuxboot1.diff >> Makefile | 13 ++++- >> linuxboot/Makefile | 40 +++++++++++++++ >> linuxboot/boot.S | 54 +++++++++++++++++++++ >> linuxboot/farvar.h | 130 +++++++++++++++++++++++++++++++++++++++ >> ++++++++++++ >> linuxboot/rom.c | 104 ++++++++++++++++++++++++++++++++++++++++ >> >> linuxboot/signrom.c | 128 ++++++++++++++++++++++++++++++++++++++++ >> ++++++++++ >> linuxboot/util.h | 69 +++++++++++++++++++++++++++ >> qemu/Makefile | 3 - >> qemu/Makefile.target | 2 >> qemu/hw/linuxboot.c | 39 +++++++++++++++ >> qemu/hw/pc.c | 22 +++++++- >> qemu/hw/pc.h | 5 + >> >> 12 files changed, 600 insertions(+), 9 deletions(-) >> >> >> >> >> >> >> On Mon, Apr 21, 2008 at 12:33 PM, Nguyen Anh Quynh >> <aq...@gm...> wrote: >>> Forget to say that this patch is against kvm-66. >>> >>> Thanks, >>> Q >>> >>> >>> >>> On Mon, Apr 21, 2008 at 12:32 PM, Nguyen Anh Quynh >>> <aq...@gm...> wrote: >>>> Hi, >>>> >>>> This should be submitted to upstream (but not to kvm-devel list), >>>> but >>>> this is only the test code that I want to quickly send out for >>>> comments. In case it looks OK, I will send it to upstream later. >>>> >>>> Inspired by extboot and conversations with Anthony and HPA, this >>>> linuxboot option ROM is a simple option ROM that intercepts int19 >>>> in >>>> order to execute linux setup code. This approach eliminates the >>>> need >>>> to manipulate the boot sector for this purpose. >>>> >>>> To test it, just load linux kernel with your KVM/QEMU image using >>>> -kernel option in normal way. >>>> >>>> I succesfully compiled and tested it with kvm-66 on Ubuntu 7.10, >>>> guest >>>> Ubuntu 8.04. >>>> >>>> Thanks, >>>> Quynh >>>> >>>> >>>> # diffstat linuxboot1.diff >>>> Makefile | 13 ++++- >>>> linuxboot/Makefile | 40 +++++++++++++++ >>>> linuxboot/boot.S | 54 +++++++++++++++++++++ >>>> linuxboot/farvar.h | 130 +++++++++++++++++++++++++++++++++++++ >>>> ++++++++++++++ >>>> linuxboot/rom.c | 104 +++++++++++++++++++++++++++++++++++++ >>>> +++ >>>> linuxboot/signrom |binary >>>> linuxboot/signrom.c | 128 +++++++++++++++++++++++++++++++++++++ >>>> +++++++++++++ >>>> linuxboot/util.h | 69 +++++++++++++++++++++++++++ >>>> qemu/Makefile | 3 - >>>> qemu/Makefile.target | 2 >>>> qemu/hw/linuxboot.c | 39 +++++++++++++++ >>>> qemu/hw/pc.c | 22 +++++++- >>>> qemu/hw/pc.h | 5 + >>>> 13 files changed, 600 insertions(+), 9 deletions(-) >>>> >>> >> >> > > |
|
From: Avi K. <av...@qu...> - 2008-04-22 10:17:07
|
Yang, Sheng wrote: > From 73c33765f3d879001818cd0719038c78a0c65561 Mon Sep 17 00:00:00 2001 > From: Sheng Yang <she...@in...> > Date: Fri, 18 Apr 2008 17:15:39 +0800 > Subject: [PATCH] kvm: qemu: Enable EPT support for real mode > > This patch build a identity page table on the last page of VGA bios, and use > it as the guest page table in nonpaging mode for EPT. > > Doing this in qemu means older versions of qemu can't work with an ept-enabled kernel. Also, placing the table in the vga bios might conflict with video card assignment to a guest. Suggest placing this near the realmode tss (see vmx.c:init_rmode_tss()) which serves a similar function. -- error compiling committee.c: too many arguments to function |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-22 09:37:18
|
Hi, I am thinking about comibing this ROM with the extboot. Both two ROM are about "booting", so I think that is reasonable. So we will have only 1 ROM that supports both external boot and Linux boot. Is that desirable or not? Thanks, Quynh On 4/21/08, Nguyen Anh Quynh <aq...@gm...> wrote: > Hmm, the last patch includes a binary. So please take this patch instead. > > Thanks, > > Q > > # diffstat linuxboot1.diff > Makefile | 13 ++++- > linuxboot/Makefile | 40 +++++++++++++++ > linuxboot/boot.S | 54 +++++++++++++++++++++ > linuxboot/farvar.h | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++ > linuxboot/rom.c | 104 ++++++++++++++++++++++++++++++++++++++++ > > linuxboot/signrom.c | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++ > linuxboot/util.h | 69 +++++++++++++++++++++++++++ > qemu/Makefile | 3 - > qemu/Makefile.target | 2 > qemu/hw/linuxboot.c | 39 +++++++++++++++ > qemu/hw/pc.c | 22 +++++++- > qemu/hw/pc.h | 5 + > > 12 files changed, 600 insertions(+), 9 deletions(-) > > > > > > > On Mon, Apr 21, 2008 at 12:33 PM, Nguyen Anh Quynh <aq...@gm...> wrote: > > Forget to say that this patch is against kvm-66. > > > > Thanks, > > Q > > > > > > > > On Mon, Apr 21, 2008 at 12:32 PM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > Hi, > > > > > > This should be submitted to upstream (but not to kvm-devel list), but > > > this is only the test code that I want to quickly send out for > > > comments. In case it looks OK, I will send it to upstream later. > > > > > > Inspired by extboot and conversations with Anthony and HPA, this > > > linuxboot option ROM is a simple option ROM that intercepts int19 in > > > order to execute linux setup code. This approach eliminates the need > > > to manipulate the boot sector for this purpose. > > > > > > To test it, just load linux kernel with your KVM/QEMU image using > > > -kernel option in normal way. > > > > > > I succesfully compiled and tested it with kvm-66 on Ubuntu 7.10, guest > > > Ubuntu 8.04. > > > > > > Thanks, > > > Quynh > > > > > > > > > # diffstat linuxboot1.diff > > > Makefile | 13 ++++- > > > linuxboot/Makefile | 40 +++++++++++++++ > > > linuxboot/boot.S | 54 +++++++++++++++++++++ > > > linuxboot/farvar.h | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++ > > > linuxboot/rom.c | 104 ++++++++++++++++++++++++++++++++++++++++ > > > linuxboot/signrom |binary > > > linuxboot/signrom.c | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++ > > > linuxboot/util.h | 69 +++++++++++++++++++++++++++ > > > qemu/Makefile | 3 - > > > qemu/Makefile.target | 2 > > > qemu/hw/linuxboot.c | 39 +++++++++++++++ > > > qemu/hw/pc.c | 22 +++++++- > > > qemu/hw/pc.h | 5 + > > > 13 files changed, 600 insertions(+), 9 deletions(-) > > > > > > > |
|
From: Yunfeng Z. <yun...@in...> - 2008-04-22 08:54:03
|
Hi All, This is today's KVM test result against kvm.git 6cf59734fc9bc89954d0157524eea156c2f9a5ab and kvm-userspace.git 5157358e1946770847271e3602f1adae85002871. One Issue Fixed: ================================================ 1. booting smp windows guests has 30% chance of hang https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1910923&group_id=180599 Two Old Issues: ================================================ 1. Booting four guests likely fails https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1919354&group_id=180599 2. Cannot boot guests with hugetlbfs https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599 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 32-bit HVM guests PASS 13. live migration 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 ================================================ 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 64-bit linux guests PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 16. boot 32-bit SMP Windows xp with ACPI enabled PASS 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled PASS 19. boot 32-bit Windows xp without ACPI PASS 20. boot 64-bit UP vista PASS 21. boot 64-bit SMP vista PASS 22. kernel build in 32-bit linux guest OS PASS 23. kernel build in 64-bit linux guest OS PASS 24. LTP on 32-bit linux guest OS PASS 25. LTP on 64-bit linux guest OS PASS 26. boot 64-bit guests with ACPI enabled PASS 27. boot 32-bit x-server PASS 28. boot 64-bit SMP windows XP with ACPI enabled PASS 29. boot 64-bit SMP windows 2003 with ACPI enabled PASS 30. live migration 64bit linux guests PASS 31. live migration 32bit linux guests PASS 32. reboot 32bit windows xp guest PASS 33. reboot 32bit windows xp guest PASS Report Summary on IA32-pae Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 7 5 2 0 0 Restart 2 2 0 0 0 gtest 15 15 0 0 0 ===================================================================== control_panel 7 5 2 0 0 :KVM_LM_PAE_gPAE 1 0 1 0 0 :KVM_four_sguest_PAE_gPA 1 1 0 0 0 :KVM_256M_guest_PAE_gPAE 1 1 0 0 0 :KVM_linux_win_PAE_gPAE 1 1 0 0 0 :KVM_1500M_guest_PAE_gPA 1 1 0 0 0 :KVM_SR_PAE_gPAE 1 0 1 0 0 :KVM_two_winxp_PAE_gPAE 1 1 0 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 15 15 0 0 0 :ltp_nightly_PAE_gPAE 1 1 0 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 1 0 0 0 :boot_up_acpi_xp_PAE_gPA 1 1 0 0 0 :boot_up_acpi_win2k3_PAE 1 1 0 0 0 :boot_base_kernel_PAE_gP 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 :bootx_PAE_gPAE 1 1 0 0 0 :kb_nightly_PAE_gPAE 1 1 0 0 0 ===================================================================== Total 24 22 2 0 0 Report Summary on IA32e Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 15 15 0 0 0 Restart 3 3 0 0 0 gtest 25 25 0 0 0 ===================================================================== control_panel 15 15 0 0 0 :KVM_LM_64_g64 1 1 0 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_4G_guest_64_g64 1 1 0 0 0 :KVM_four_sguest_64_g64 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 1 0 0 0 :KVM_1500M_guest_64_gPAE 1 1 0 0 0 :KVM_SR_64_g64 1 1 0 0 0 :KVM_LM_64_gPAE 1 1 0 0 0 :KVM_256M_guest_64_g64 1 1 0 0 0 :KVM_1500M_guest_64_g64 1 1 0 0 0 :KVM_4G_guest_64_gPAE 1 1 0 0 0 :KVM_SR_64_gPAE 1 1 0 0 0 :KVM_256M_guest_64_gPAE 1 1 0 0 0 :KVM_two_winxp_64_gPAE 1 1 0 0 0 :KVM_four_dguest_64_gPAE 1 1 0 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 25 25 0 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 1 0 0 0 :boot_base_kernel_64_gPA 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_up_noacpi_win2k_64 1 1 0 0 0 :boot_smp_acpi_xp_64_gPA 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 :bootx_64_g64 1 1 0 0 0 :boot_up_vista_64_g64 1 1 0 0 0 :boot_smp_vista_64_g64 1 1 0 0 0 :boot_up_acpi_xp_64_g64 1 1 0 0 0 :boot_up_vista_64_gPAE 1 1 0 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 43 43 0 0 0 Thanks Yunfeng |
|
From: Avi K. <av...@qu...> - 2008-04-22 08:53:12
|
[Note: KVM Forum registration is now open at http://kforum.qumranet.com/KVMForum/about_kvmforum.php] [The deadline for submitting presentations has been extended by two weeks, until May 4th] This is the Call for Presentations for the second annual KVM Developer's Forum, to be held on June 10-13, 2008, in Napa, California, USA [1]. We are looking for presentations on KVM development, quality assurance, management, security, interoperability, architecture support, and interesting use cases. Presentations are 50 minutes in length; there are also 25-minute mini-presentation slots available. KVM Forum presentations are an excellent way to inform the KVM development community about your work, and to gather valuable feedback about your approach. Please send your presentation proposal to the KVM Forum 2008 Content Committee at kf2...@qu... by May 4th. KVM Forum 2008 Content Committee: Dor Laor Anthony Liguori Avi Kivity [1] http://kforum.qumranet.com/KVMForum/about_kvmforum.php -- Any sufficiently difficult bug is indistinguishable from a feature. |
|
From: Avi K. <av...@qu...> - 2008-04-22 08:10:28
|
Jamie Lokier wrote: > Avi Kivity wrote: > >>> At such a tiny difference, I'm wondering why Linux-AIO exists at all, >>> as it complicates the kernel rather a lot. I can see the theoretical >>> appeal, but if performance is so marginal, I'm surprised it's in >>> there. >>> >> Linux aio exists, but that's all that can be said for it. It works >> mostly for raw disks, doesn't integrate with networking, and doesn't >> advance at the same pace as the rest of the kernel. I believe only >> databases use it (and a userspace filesystem I wrote some time ago). >> > > And video streaming on some embedded devices with no MMU! (Due to the > page cache heuristics working poorly with no MMU, sustained reliable > streaming is managed with O_DIRECT and the app managing cache itself > (like a database), and that needs AIO to keep the request queue busy. > At least, that's the theory.) > > Could use threads as well, no? >>> I'm also surprised the Glibc implementation of AIO using ordinary >>> threads is so close to it. >>> >> Why are you surprised? >> > > Because I've read that Glibc AIO (which uses a thread pool) is a > relatively poor performer as AIO implementations go, and is only there > for API compatibility, not suggested for performance. > > But I read that quite a while ago, perhaps it's changed. > > It's me at fault here. I just assumed that because it's easy to do aio in a thread pool efficiently, that's what glibc does. Unfortunately the code does some ridiculous things like not service multiple requests on a single fd in parallel. I see absolutely no reason for it (the code says "fight for resources"). So my comments only apply to linux-aio vs a sane thread pool. Sorry for spreading confusion. >> Actually the glibc implementation could be improved from what I've >> heard. My estimates are for a thread pool implementation, but there is >> not reason why glibc couldn't achieve exactly the same performance. >> > > Erm... I thought you said it _does_ achieve nearly the same > performance, not that it _could_. > > Do you mean it could achieve exactly the same performance by using > Linux AIO when possible? > > It could and should. It probably doesn't. A simple thread pool implementation could come within 10% of Linux aio for most workloads. It will never be "exactly", but for small numbers of disks, close enough. >>> And then, I'm wondering why use AIO it >>> all: it suggests QEMU would run about as fast doing synchronous I/O in >>> a few dedicated I/O threads. >>> >> Posix aio is the unix API for this, why not use it? >> > > Because far more host platforms have threads than have POSIX AIO. (I > suspect both options will end up supported in the end, as dedicated > I/O threads were already suggested for other things.) > Agree. > >>>> Also, I'd presume that those that need 10K IOPS and above will not place >>>> their high throughput images on a filesystem; rather on a separate SAN >>>> LUN. >>>> >>> Does the separate LUN make any difference? I thought O_DIRECT on a >>> filesystem was meant to be pretty close to block device performance. >>> >> On a good extent-based filesystem like XFS you will get good performance >> (though more cpu overhead due to needing to go through additional >> mapping layers. Old clunkers like ext3 will require additional seeks or >> a ton of cache (1 GB per 1 TB). >> > > Hmm. Thanks. I may consider switching to XFS now.... > > I'm rooting for btrfs myself. -- error compiling committee.c: too many arguments to function |
|
From: Christian B. <bor...@de...> - 2008-04-22 07:44:21
|
Am Dienstag, 22. April 2008 schrieb Rusty Russell:
> [Christian, Hollis, how much is this ABI breakage going to hurt you?]
It is ok for s390 at the moment. We are still working on making userspace
ready and I plan to change the guest<->host for s390 anyway. I try to make
these changes for drivers/s390/kvm/kvm_virtio.c before 2.6.26. The main
reason is, that we are currently limited to around 80 devices. I am not sure,
if I should change the allocation of the virtqueues and descriptors to guest
memory as well.
Back to your patch:
I have still some ideas about virtio between little endian and big endian
systems, but it requires more and different marshalling anyway - even on
driver level. No idea yet how to solve that properly.
Consider your change
Acked-by: Christian Bornraeger <bor...@de...>
given that you fix the issue below:
[...]
> --- a/drivers/virtio/virtio_balloon.c Sun Apr 20 14:41:02 2008 +1000
> +++ b/drivers/virtio/virtio_balloon.c Sun Apr 20 15:07:45 2008 +1000
> @@ -155,9 +155,9 @@ static inline s64 towards_target(struct
> static inline s64 towards_target(struct virtio_balloon *vb)
> {
> u32 v;
> - __virtio_config_val(vb->vdev,
> - offsetof(struct virtio_balloon_config, num_pages),
> - &v);
> + vb->vdev->config->get(vb->vdev,
> + offsetof(struct virtio_balloon_config, num_pages),
> + &v);
this is missing a sizeof(v), no?
Christian
|
|
From: Andrea A. <an...@qu...> - 2008-04-22 07:20:43
|
This is a followup of the locking of the mmu-notifier methods against
the secondary-mmu page fault, each driver can implement differently
but this is to show an example of what I planned for KVM, others may
follow closely if they find this useful. I post this as pseudocode to
hide 99% of kvm internal complexities and to focus only on the
locking. The KVM locking scheme should be something on these lines:
invalidate_range_start {
spin_lock(&kvm->mmu_lock);
kvm->invalidate_range_count++;
rmap-invalidate of sptes in range
spin_unlock(&kvm->mmu_lock)
}
invalidate_range_end {
spin_lock(&kvm->mmu_lock);
kvm->invalidate_range_count--;
spin_unlock(&kvm->mmu_lock)
}
invalidate_page {
spin_lock(&kvm->mmu_lock);
write_seqlock()
rmap-invalidate of sptes of page
write_sequnlock()
spin_unlock(&kvm->mmu_lock)
}
kvm_page_fault {
seq = read_seqlock()
get_user_pages() (aka gfn_to_pfn() in kvm terms)
spin_lock(&kvm->mmu_lock)
if (seq_trylock(seq) || kvm->invalidate_range_count)
goto out; /* reply page fault */
map sptes and build rmap
out:
spin_unlock(&kvm->mmu_lock)
}
This will allow to remove the page pinning from KVM. I'd appreciate if
you Robin and Christoph can have a second look and pinpoint any
potential issue in my plan.
invalidate_page as you can notice, allows to decrease the fixed cost
overhead from all VM code that works with a single page and where
freeing the page _after_ calling invalidate_page is zero runtime/tlb
cost. We need invalidate_range_begin/end because when we work on
multiple pages, we can reduce cpu utilization and avoid many tlb
flushes by holding off the kvm page fault when we work on the range.
invalidate_page also allows to decrease the window where the kvm page
fault could possibly need to be replied (the ptep_clear_flush <->
invalidate_page window is shorter than a
invalidate_range_begin(PAGE_SIZE) <->
invalidate_range_end(PAGE_SIZE)).
So even if only as a microoptimization it worth it to decrease the
impact on the common VM code. The cost of having both a seqlock and a
range_count is irrlevant in kvm terms as they'll be in the same
cacheline and checked at the same time by the page fault and it won't
require any additional blocking (or writing) lock.
Note that the kvm page fault can't happen unless the cpu switches to
guest mode, and it can't switch to guest mode if we're in the
begin/end critical section, so in theory I could loop inside the page
fault too without risking deadlocking, but replying it by restarting
guest mode sounds nicer in sigkill/scheduling terms.
Soon I'll release a new mmu notifier patchset with patch 1 being the
mmu-notifier-core self-included and ready to go in -mm and mainline in
time for 2.6.26. Then I'll be glad to help merging any further patch
in the patchset to allow methods to sleep so XPMEM can run on mainline
2.6.27 the same way GRU/KVM/Quadrics will run fine on 2.6.26, in a
fully backwards compatible way with 2.6.26 (and of course it doesn't
really need to be backwards compatible because this is a kernel
internal API only, ask Greg etc... ;). But that will likely require a
new config option to avoid hurting AIM performance in fork because the
anon_vma critical sections are so short in the fast path.
|
|
From: Avi K. <av...@qu...> - 2008-04-22 06:03:40
|
Chris Wright wrote:
> During hotadd of SCSI devices lsi_scsi_init() handles failed
> pci_device_register(), but qemu_system_hot_add_storage() will try and
> attach a drive any way. Handle this error case rather the generating
> SEGV.
>
> Cc: Marcelo Tosatti <mto...@re...>
> Signed-off-by: Chris Wright <ch...@so...>
> ---
> qemu/hw/device-hotplug.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/qemu/hw/device-hotplug.c
> +++ b/qemu/hw/device-hotplug.c
> @@ -125,7 +125,7 @@ static PCIDevice *qemu_system_hot_add_st
> switch (type) {
> case IF_SCSI:
> opaque = lsi_scsi_init (pci_bus, -1);
> - if (drive_idx >= 0)
> + if (opaque && drive_idx >= 0)
> lsi_scsi_attach (opaque, drives_table[drive_idx].bdrv,
> drives_table[drive_idx].unit);
> break;
>
It's not so opaque if you're testing it against NULL...
long term we want better error reporting here.
--
Any sufficiently difficult bug is indistinguishable from a feature.
|
|
From: Chris W. <ch...@so...> - 2008-04-22 05:14:59
|
During hotadd of SCSI devices lsi_scsi_init() handles failed
pci_device_register(), but qemu_system_hot_add_storage() will try and
attach a drive any way. Handle this error case rather the generating
SEGV.
Cc: Marcelo Tosatti <mto...@re...>
Signed-off-by: Chris Wright <ch...@so...>
---
qemu/hw/device-hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/qemu/hw/device-hotplug.c
+++ b/qemu/hw/device-hotplug.c
@@ -125,7 +125,7 @@ static PCIDevice *qemu_system_hot_add_st
switch (type) {
case IF_SCSI:
opaque = lsi_scsi_init (pci_bus, -1);
- if (drive_idx >= 0)
+ if (opaque && drive_idx >= 0)
lsi_scsi_attach (opaque, drives_table[drive_idx].bdrv,
drives_table[drive_idx].unit);
break;
|
|
From: Chris W. <ch...@so...> - 2008-04-22 05:07:41
|
* Marcelo Tosatti (mto...@re...) wrote: > > Looks good. Does SCSI handle pci_register_device() failure too? Yeah, but it missed actually checking the return value from lsi_scsi_init. Patch to follow. thanks, -chris |
|
From: Rusty R. <ru...@ru...> - 2008-04-22 05:06:27
|
On Wednesday 09 April 2008 01:44:04 Andrea Arcangeli wrote:
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1050,6 +1050,15 @@
> unsigned long addr, unsigned long len,
> unsigned long flags, struct page **pages);
>
> +struct mm_lock_data {
> + spinlock_t **i_mmap_locks;
> + spinlock_t **anon_vma_locks;
> + unsigned long nr_i_mmap_locks;
> + unsigned long nr_anon_vma_locks;
> +};
> +extern struct mm_lock_data *mm_lock(struct mm_struct * mm);
> +extern void mm_unlock(struct mm_struct *mm, struct mm_lock_data *data);
As far as I can tell you don't actually need to expose this struct at all?
> + data->i_mmap_locks = vmalloc(nr_i_mmap_locks *
> + sizeof(spinlock_t));
This is why non-typesafe allocators suck. You want 'sizeof(spinlock_t *)'
here.
> + data->anon_vma_locks = vmalloc(nr_anon_vma_locks *
> + sizeof(spinlock_t));
and here.
> + err = -EINTR;
> + i_mmap_lock_last = NULL;
> + nr_i_mmap_locks = 0;
> + for (;;) {
> + spinlock_t *i_mmap_lock = (spinlock_t *) -1UL;
> + for (vma = mm->mmap; vma; vma = vma->vm_next) {
...
> + data->i_mmap_locks[nr_i_mmap_locks++] = i_mmap_lock;
> + }
> + data->nr_i_mmap_locks = nr_i_mmap_locks;
How about you track your running counter in data->nr_i_mmap_locks, leave
nr_i_mmap_locks alone, and BUG_ON(data->nr_i_mmap_locks != nr_i_mmap_locks)?
Even nicer would be to wrap this in a "get_sorted_mmap_locks()" function.
Similarly for anon_vma locks.
Unfortunately, I just don't think we can fail locking like this. In your next
patch unregistering a notifier can fail because of it: that not usable.
I think it means you need to add a linked list element to the vma for the
CONFIG_MMU_NOTIFIER case. Or track the max number of vmas for any mm, and
keep a pool to handle mm_lock for this number (ie. if you can't enlarge the
pool, fail the vma allocation).
Both have their problems though...
Rusty.
|
|
From: Jerone Y. <jy...@us...> - 2008-04-22 04:47:46
|
What I am asking is do I have all the proper options in my kernel config set to use it? On Mon, 2008-04-21 at 17:13 -0500, Anthony Liguori wrote: > Jerone Young wrote: > > virtio net device does not appear to show itself in the guest. I'm > > curious of what options I may be missing. Here is my config > > You'll have to be more specific about what "does not appear to show > itself" means. What's the output of lspci? > > Regards, > > Anthony Liguori > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > 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: Rusty R. <ru...@ru...> - 2008-04-22 03:57:35
|
[Christian, Hollis, how much is this ABI breakage going to hurt you?]
A recent proposed feature addition to the virtio block driver revealed
some flaws in the API, in particular how easy it is to break big
endian machines.
The virtio config space was originally chosen to be little-endian,
because we thought the config might be part of the PCI config space
for virtio_pci. It's actually a separate mmio region, so that
argument holds little water; as only x86 is currently using the virtio
mechanism, we can change this (but must do so now, before the
impending s390 and ppc merges).
API changes:
- __virtio_config_val() just becomes a striaght vdev->config_get() call.
Signed-off-by: Rusty Russell <ru...@ru...>
---
drivers/block/virtio_blk.c | 4 +--
drivers/virtio/virtio_balloon.c | 6 ++---
include/linux/virtio_config.h | 47 +++++++++++++---------------------------
3 files changed, 21 insertions(+), 36 deletions(-)
diff -r a098f19a6da5 drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.c Sun Apr 20 14:41:02 2008 +1000
+++ b/drivers/block/virtio_blk.c Sun Apr 20 15:07:45 2008 +1000
@@ -246,8 +246,8 @@ static int virtblk_probe(struct virtio_d
blk_queue_ordered(vblk->disk->queue, QUEUE_ORDERED_TAG, NULL);
/* Host must always specify the capacity. */
- __virtio_config_val(vdev, offsetof(struct virtio_blk_config, capacity),
- &cap);
+ vdev->config->get(vdev, offsetof(struct virtio_blk_config, capacity),
+ &cap, sizeof(cap));
/* If capacity is too big, truncate with warning. */
if ((sector_t)cap != cap) {
diff -r a098f19a6da5 drivers/virtio/virtio_balloon.c
--- a/drivers/virtio/virtio_balloon.c Sun Apr 20 14:41:02 2008 +1000
+++ b/drivers/virtio/virtio_balloon.c Sun Apr 20 15:07:45 2008 +1000
@@ -155,9 +155,9 @@ static inline s64 towards_target(struct
static inline s64 towards_target(struct virtio_balloon *vb)
{
u32 v;
- __virtio_config_val(vb->vdev,
- offsetof(struct virtio_balloon_config, num_pages),
- &v);
+ vb->vdev->config->get(vb->vdev,
+ offsetof(struct virtio_balloon_config, num_pages),
+ &v);
return v - vb->num_pages;
}
diff -r a098f19a6da5 include/linux/virtio_config.h
--- a/include/linux/virtio_config.h Sun Apr 20 14:41:02 2008 +1000
+++ b/include/linux/virtio_config.h Sun Apr 20 15:07:45 2008 +1000
@@ -16,7 +16,7 @@
#define VIRTIO_CONFIG_S_FAILED 0x80
#ifdef __KERNEL__
-struct virtio_device;
+#include <linux/virtio.h>
/**
* virtio_config_ops - operations for configuring a virtio device
@@ -30,13 +30,11 @@ struct virtio_device;
* offset: the offset of the configuration field
* buf: the buffer to write the field value into.
* len: the length of the buffer
- * Note that contents are conventionally little-endian.
* @set: write the value of a configuration field
* vdev: the virtio_device
* offset: the offset of the configuration field
* buf: the buffer to read the field value from.
* len: the length of the buffer
- * Note that contents are conventionally little-endian.
* @get_status: read the status byte
* vdev: the virtio_device
* Returns the status byte
@@ -70,40 +68,27 @@ struct virtio_config_ops
};
/**
- * virtio_config_val - look for a feature and get a single virtio config.
+ * virtio_config_val - look for a feature and get a virtio config entry.
* @vdev: the virtio device
* @fbit: the feature bit
* @offset: the type to search for.
* @val: a pointer to the value to fill in.
*
* The return value is -ENOENT if the feature doesn't exist. Otherwise
- * the value is endian-corrected and returned in v. */
-#define virtio_config_val(vdev, fbit, offset, v) ({ \
- int _err; \
- if ((vdev)->config->feature((vdev), (fbit))) { \
- __virtio_config_val((vdev), (offset), (v)); \
- _err = 0; \
- } else \
- _err = -ENOENT; \
- _err; \
-})
+ * the config value is copied into whatever is pointed to by v. */
+#define virtio_config_val(vdev, fbit, offset, v) \
+ virtio_config_buf((vdev), (fbit), (offset), (v), sizeof(v))
-/**
- * __virtio_config_val - get a single virtio config without feature check.
- * @vdev: the virtio device
- * @offset: the type to search for.
- * @val: a pointer to the value to fill in.
- *
- * The value is endian-corrected and returned in v. */
-#define __virtio_config_val(vdev, offset, v) do { \
- BUILD_BUG_ON(sizeof(*(v)) != 1 && sizeof(*(v)) != 2 \
- && sizeof(*(v)) != 4 && sizeof(*(v)) != 8); \
- (vdev)->config->get((vdev), (offset), (v), sizeof(*(v))); \
- switch (sizeof(*(v))) { \
- case 2: le16_to_cpus((__u16 *) v); break; \
- case 4: le32_to_cpus((__u32 *) v); break; \
- case 8: le64_to_cpus((__u64 *) v); break; \
- } \
-} while(0)
+static inline int virtio_config_buf(struct virtio_device *vdev,
+ unsigned int fbit,
+ unsigned int offset,
+ void *buf, unsigned len)
+{
+ if (!vdev->config->feature(vdev, fbit))
+ return -ENOENT;
+
+ vdev->config->get(vdev, offset, buf, len);
+ return 0;
+}
#endif /* __KERNEL__ */
#endif /* _LINUX_VIRTIO_CONFIG_H */
|
157 messages has been excluded from this view by a project administrator.
