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: Бухгалтерский о. < <te...@iq...> - 2008-05-12 07:12:57
|
Расходы на рекламу (для бухгалтера) Однодневный семинар / 15 мая 2008 г. / Москва Программа семинара 1. Понятие рекламы и нормативное регулирование. Правовые основы рекламы - законы "О рекламе", "О лотереях", "О защите прав потребителей", Налоговый и Гражданский Кодексы. Виды рекламы - реклама в СМИ, выставки, демонстрационные залы, витрины, наружная реклама, лотереи, розыгрыши и конкурсы, буклеты и каталоги, листовки, сувениры, призы и подарки, др. Нормируемые расходы на рекламу - перечень и комментарии. "Не реклама" - визитки, вывески, информация о производителе на упаковке, акции по продвижению, объявления о подборе кадров, фирменные бланки, PR-акции, мероприятия по продвижению товара и т.п. Типичные ошибки в учете расходов на рекламу. 2. Реклама в СМИ. Реклама в печатных средствах массовой информации, реклама по радио и ТВ. Условия размещения и порядок списания расходов с учетом последних разъяснений Минфина. Web-сайт фирмы, другая реклама в Интернет. 3. Наружная реклама. Рекламный щит, световой короб, растяжка и т.п., как основное средство или материалы - амортизация, признание расходов на изготовление и установку. 4. Реклама на транспорте 5. Участие в выставках, выставках-продажах, содержание комнат образцов, демонстрационных залов, экспозиций. Уценка и списание потерявших вид образцов. Признание затрат на оформление образцов продукции сопутствующими товарами. Презентации. 6. Печатная реклама. Каталоги, буклеты, листовки. Участие в каталогах торгующих организаций. Рассылка рекламных материалов. Расходы на рекламы или маркетинговые расходы? 7. Промоакции: подарки, дегустации, "пробные образцы" - особенности налогообложения и учета. НДС, налог на прибыль. Спорные вопросы и арбитражная практика. 8. Материалы оформления мест продаж (POS-материалы) - постеры, гирлянды, ростовые фигуры, стойки, стеллажи и т.п. 9. Сувениры и канцелярские товары с логотипом организации. Расходы на изготовление, раздача в представительских или рекламных целях. Экономическая оправданность таких расходов 10. Расходы на рекламу и НДС 11. Спонсорство. 12. Рекламная (стимулирующая) лотерея и розыгрыш призов. Проблемы организации и проведения. Отчетность и аудит лотереи. Признание стоимости приза в затратах, НДФЛ, ЕСН. Ответственность за нарушение порядка проведения лотереи. 13. Организация конкурсов в рамках проведения рекламных акций. Отличие конкурса от лотереи. Призы - принципы выдачи, обнародование правил конкурса. Правовые основы, избежание признания конкурса "притворным". Последствия неисполнения условий конкурса со стороны организатора. Приз и НДС (сложные вопросы вычета и уплаты налога), признание стоимости приза в затратах, НДФЛ. Ответственность за нарушение порядка проведения конкурса. 14. Разовые и накопительные скидки, ретроскидки, скидки по дисконтным картам, бонусы и премии и т.п. Налоговые последствия для продавца и покупателя. Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу). Место обучения: г. Москва, 5 мин. пешком от м. Академическая. Стоимость обучения: 4900 руб. (с НДС). (В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане). Для регистрации на семинар необходимо отправить нам реквизиты организации, тему и дату семинара, полное ФИО участников, контактный телефон и факс. Получить подробную программу и зарегистрироваться можно по телефону: ( 4 9 5 ) 5 4 3 = 8 8 = 4 6 |
|
From: Avi K. <av...@qu...> - 2008-05-12 06:59:54
|
Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >> >>>> How about the other way round: when the vlan consumer detects it >>>> can no longer receive packets, it tells that to the vlan. When all >>>> vlan consumers can no longer receive, tell the producer to stop >>>> producing. For the tap producer, this is simply removing its fd >>>> from the read poll list. When a vlan consumer becomes ready to >>>> receive again, it tells the vlan, which tells the producers, which >>>> then install their fds back again. >>>> >>> Yeah, that's a nice idea. I'll think about it. I don't know if >>> it's really worth doing as an intermediate step though. What I'd >>> really like to do is have a vlan interface where consumers published >>> all of their receive buffers. Then there's no need for >>> notifications of receive-ability. >>> >> >> That's definitely better, and is also more multiqueue nic / vringfd >> friendly. >> >> I still think interrupt-on-halfway-mark is needed much more >> urgently. It deals with concurrency much better: >> > > We already sort of do this. In try_fill_recv() in virtio-net.c, we > try to allocate as many skbs as we can to fill the rx queue. We keep > track of how many we've been able to allocate. Whenever we process an > RX packet, we check to see if the current number of RX packets is less > than half the maximum number of rx packets we've been able to allocate. > Then why are we dropping packets? We shouldn't run out of rx descriptors if this works. > In the common case of small queues, this should have exactly the > behavior you describe. We don't currently suppress the RX > notification even though we really could. The can_receive changes are > really the key to this. Unless we are suppressing tap fd > select()'ing, we can always suppress the RX notification. That's been > sitting on my TODO for a bit. > Sorry, totally confused. How does can_receive come into this? >> rx: >> host interrupts guest on halfway mark >> guest starts processing packets >> host keeps delivering >> >> tx: >> guest kicks host on halfway mark >> host starts processing packets >> second vcpu on guest keeps on queueing >> > > I'm not convinced it's at all practical to suppress notifications in > the front-end. We simply don't know whether we'll get more packets > which means we have to do TX mitigation within the front-end. We've > been there, it's not as nice as doing it in the back-end. > > What we really ought to do in the back-end though, is start processing > the TX packets as soon as we begin to do TX mitigation. This would > address the ping latency issue while also increasing throughput > (hopefully). One thing I've wanted to try is to register a > bottom-half or a polling function so that the IO thread was always > trying to process TX packets while the TX timer is active. Setting the timer clearly should be the host's job. But suppression needs to be coordinated. One fairly generic mechanism is for one side to tell the other at which ring index it wants the notification. There are four cases to consider: - tx guest->host Normally the host sets the notify index at current+1, to get immediate notifications. If it starts seeing many packets, it can gradually increasing this to current+size/2, setting a timer to limit latency. If the timer fires, drop the window size. - tx host->guest Returning descriptors is not an urgent task if the ring is large enough. Can be set to size/2 plus a longish timer. - rx guest->host Similar to above, set to size/2, don't even need a timer. - rx host->guest Similar to tx guest->host, start with a small window to get minimal latency, if we see many packets within a short time we can increase the window + set a timer. We should aim for the timer to fire only rarely. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Роснедвижимость <xwq...@bo...> - 2008-05-12 06:11:17
|
Измeнeнuя в правoвoм рeгyлuрoванuu
граgoстрouтeльнoй geятeльнoстu в 2008 гogy
Cанkт-Пeтeрбyрг
19-21 мая 2008г.
В прoграммe:
Граgoстрouтeльный kogekс РФ: гoсygарствeннoe рeгyлuрoванue развuтuя
тeррuтoрuй u пoсeлeнuй, oпрegeлeнuя вugoв uспoльзoванuя зeмeльных
yчастkoв, прoekтuрoванuя, стрouтeльства u рekoнстрykцuu oбъekтoв
нegвuжuмoстu. Рeгyлuрoванue застрoйku тeррuтoрuй
Пoряgok прegoставлeнuя зeмeльных yчастkoв пog стрouтeльствo.
Измeнeнue цeлeвoгo назначeнuя u разрeшeннoгo uспoльзoванuя зeмeльных
yчастkoв. Oсoбeннoстu прuмeнeнuя нoвoгo Граgoстрouтeльнoгo kogekса РФ.
Прuoбрeтeнue зeмeльных yчастkoв на тoргах.
Правoвыe пoслegствuя самoвoльнoгo стрouтeльства
Зeмeльный kogekс u граgoстрouтeльная geятeльнoсть.
Гoсygарствeнная рeгuстрацuя прав на зeмeльныe yчастku u распoлoжeнныe
на нuх oбъekты нegвuжuмoстu. Рeгламeнт прegoставлeнuя зeмeльнoгo
yчастkа в сoбствeннoсть. Oснoванuя oтkаза в прuoбрeтeнuu зeмeльнoгo
yчастkа в сoбствeннoсть
Прoблeмныe вoпрoсы развuтuя застрoeнных тeррuтoрuй. Прoцegyра выgeлeнuя
зeмeльных yчастkoв gля стрouтeльства. Прoблeмы распoряжeнuя зeмeльнымu
yчастkамu uз нeразгранuчeннoй гoсygарствeннoй сoбствeннoстu на зeмлю
в пoсeлeнuях
Kаgастрoвая oцeнkа зeмeль. Рынoчная, kаgастрoвая u нoрматuвная стouмoстu
зeмeльных yчастkoв √ пoряgok u мeтoguku oпрegeлeнuя. Oпрegeлeнue цeны
выkyпа зeмeльных yчастkoв пog прuватuзuрoваннымu зgанuямu u сooрyжeнuямu.
Пoряgok oпрegeлeнuя стouмoстu выkyпа свoбogных зeмeльных yчастkoв
Пoряgok прoвegeнuя мeжeванuя u зeмлeyстрouтeльных рабoт.
Мeтoguчeсkue рekoмeнgацuu прoвegeнuя зeмлeyстрoйства прu oбразoванuu
нoвых u yпoряgoчeнuя сyщeствyющuх oбъekтoв зeмлeyстрoйства.
Мeтoguчeсkue рekoмeнgацuu прoвegeнuя мeжeванuя oбъekтoв зeмлeyстрoйства
Oсoбeннoстu oфoрмлeнuя прав сoбствeннoстu прu фuнансuрoванuu пo goгoвoрy
goлeвoгo стрouтeльства. Гoсygарствeнная пoлuтukа в oбластu защuты прав
yчастнukoв goлeвoгo стрouтeльства
Hoвыe трeбoванuя пoряgkа выgачu разрeшeнuя на стрouтeльствo,
ввogа oбъekта в эkсплyатацuю
Oтвeтствeннoсть за нарyшeнue заkoнogатeльства o граgoстрouтeльнoй
geятeльнoстu
C пoлнoй прoграммoй сeмuнара Вы мoжeтe oзнаkoмuться,
запрoсuв пo тeлeфoнy (812) 983-5ЧЗ9
|
|
From: Yang, S. <she...@in...> - 2008-05-12 05:13:16
|
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)."
--
Thanks
Yang, Sheng
|
|
From: Zhang, X. <xia...@in...> - 2008-05-12 01:36:48
|
Could you help to try the attached one. Xiantao -----Original Message----- From: kvm...@li... [mailto:kvm...@li...] On Behalf Of Avi Kivity Sent: 2008年5月9日 23:56 To: Zhang, Xiantao Cc: kvm...@li...; kvm...@li... Subject: Re: [kvm-ia64-devel] [PATCH] KVM: Qemu: Build fix for kvm/ia64 Zhang, Xiantao wrote: > Avi, > Please drop the previous one due to a wrong attachment. > Xiantao > > From a9f479197f0a0efa45a930309fad03fd690cba60 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xia...@in...> > Date: Thu, 8 May 2008 10:16:05 +0800 > Subject: [PATCH] KVM: Qemu : IA-64 build fix. > > Remove unexisting header inclusion, and set correct phys_ram_size > for ipf machine. > Patch doesn't apply. Can you recheck? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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-ia64-devel mailing list kvm...@li... https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel |
|
From: Jiang, Y. <yun...@in...> - 2008-05-12 00:24:24
|
Dor Laor <mailto:dor...@qu...> wrote: > On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote: >> Avi Kivity <mailto:av...@qu...> wrote: > 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. Thanks for your clarification. I will try the new one when it is available. I'm wondering when you publish the binary, is it possible to share the pdb file also? That will be helpful if want to do some debug. > > >> -- 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...@li... >> https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: Terri D. <kry...@lf...> - 2008-05-11 23:03:28
|
Good evening, dear Friend. Start your own online casino - Starting from 5000 euro you can purchase and own a online casino. Buy it today. Tomorrow you can start earning $$$$ with your own private online casino site. http://casino-for-sale.info/ Regards. |
|
From: Dor L. <dor...@qu...> - 2008-05-11 21:09:31
|
On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote: > Avi Kivity <mailto:av...@qu...> 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...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: Anthony L. <an...@co...> - 2008-05-11 20:44:41
|
Avi Kivity wrote: > Anthony Liguori wrote: > >>> How about the other way round: when the vlan consumer detects it can >>> no longer receive packets, it tells that to the vlan. When all vlan >>> consumers can no longer receive, tell the producer to stop >>> producing. For the tap producer, this is simply removing its fd from >>> the read poll list. When a vlan consumer becomes ready to receive >>> again, it tells the vlan, which tells the producers, which then >>> install their fds back again. >>> >> Yeah, that's a nice idea. I'll think about it. I don't know if it's >> really worth doing as an intermediate step though. What I'd really >> like to do is have a vlan interface where consumers published all of >> their receive buffers. Then there's no need for notifications of >> receive-ability. >> > > That's definitely better, and is also more multiqueue nic / vringfd > friendly. > > I still think interrupt-on-halfway-mark is needed much more urgently. > It deals with concurrency much better: > We already sort of do this. In try_fill_recv() in virtio-net.c, we try to allocate as many skbs as we can to fill the rx queue. We keep track of how many we've been able to allocate. Whenever we process an RX packet, we check to see if the current number of RX packets is less than half the maximum number of rx packets we've been able to allocate. In the common case of small queues, this should have exactly the behavior you describe. We don't currently suppress the RX notification even though we really could. The can_receive changes are really the key to this. Unless we are suppressing tap fd select()'ing, we can always suppress the RX notification. That's been sitting on my TODO for a bit. > rx: > host interrupts guest on halfway mark > guest starts processing packets > host keeps delivering > > tx: > guest kicks host on halfway mark > host starts processing packets > second vcpu on guest keeps on queueing > I'm not convinced it's at all practical to suppress notifications in the front-end. We simply don't know whether we'll get more packets which means we have to do TX mitigation within the front-end. We've been there, it's not as nice as doing it in the back-end. What we really ought to do in the back-end though, is start processing the TX packets as soon as we begin to do TX mitigation. This would address the ping latency issue while also increasing throughput (hopefully). One thing I've wanted to try is to register a bottom-half or a polling function so that the IO thread was always trying to process TX packets while the TX timer is active. Regards, Anthony Liguori > It's also much better with multiqueue NICs, where there's no socket > buffer to hold the packets while we're out of descriptors. > > |
|
From: Avi K. <av...@qu...> - 2008-05-11 18:52:06
|
Anthony Liguori wrote: >> How about the other way round: when the vlan consumer detects it can >> no longer receive packets, it tells that to the vlan. When all vlan >> consumers can no longer receive, tell the producer to stop >> producing. For the tap producer, this is simply removing its fd from >> the read poll list. When a vlan consumer becomes ready to receive >> again, it tells the vlan, which tells the producers, which then >> install their fds back again. > > Yeah, that's a nice idea. I'll think about it. I don't know if it's > really worth doing as an intermediate step though. What I'd really > like to do is have a vlan interface where consumers published all of > their receive buffers. Then there's no need for notifications of > receive-ability. That's definitely better, and is also more multiqueue nic / vringfd friendly. I still think interrupt-on-halfway-mark is needed much more urgently. It deals with concurrency much better: rx: host interrupts guest on halfway mark guest starts processing packets host keeps delivering tx: guest kicks host on halfway mark host starts processing packets second vcpu on guest keeps on queueing It's also much better with multiqueue NICs, where there's no socket buffer to hold the packets while we're out of descriptors. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Anthony L. <ali...@us...> - 2008-05-11 18:33:07
|
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Normally, tap always reads packets and simply lets the client drop
>> them if it
>> cannot receive them. For virtio-net, this results in massive packet
>> loss and
>> about an 80% performance loss in TCP throughput.
>>
>> This patch modifies qemu_send_packet() to only deliver a packet to a
>> VLAN
>> client if it doesn't have a fd_can_read method or the fd_can_read method
>> indicates that it can receive packets. We also return a status of
>> whether
>> any clients were able to receive the packet.
>>
>> If no clients were able to receive a packet, we buffer the packet
>> until a
>> client indicates that it can receive packets again.
>>
>> This patch also modifies the tap code to only read from the tap fd if
>> at least
>> one client on the VLAN is able to receive a packet.
>>
>> Finally, this patch changes the tap code to drain all possible
>> packets from
>> the tap device when the tap fd is readable.
>>
>>
>> #if defined(CONFIG_SLIRP)
>> @@ -3970,6 +3976,8 @@ typedef struct TAPState {
>> VLANClientState *vc;
>> int fd;
>> char down_script[1024];
>> + char buf[4096];
>> + int size;
>> } TAPState;
>>
>
> This breaks large MTUs.
They've always been broken for tap.
> How about the other way round: when the vlan consumer detects it can
> no longer receive packets, it tells that to the vlan. When all vlan
> consumers can no longer receive, tell the producer to stop producing.
> For the tap producer, this is simply removing its fd from the read
> poll list. When a vlan consumer becomes ready to receive again, it
> tells the vlan, which tells the producers, which then install their
> fds back again.
Yeah, that's a nice idea. I'll think about it. I don't know if it's
really worth doing as an intermediate step though. What I'd really like
to do is have a vlan interface where consumers published all of their
receive buffers. Then there's no need for notifications of receive-ability.
Regards,
Anthony Liguori
> This is a bit difficult since virtio and tap are both consumers and
> producers, but could be made to work, I think.
>
>
|
|
From: Avi K. <av...@qu...> - 2008-05-11 15:31:22
|
Anthony Liguori wrote: >> I don't think we can do page migration with VT-d. You need to be able >> to detect whether the page has been changed by dma after you've copied >> it but before you changed the pte, but VT-d doesn't allow that AFAICT. >> > > Hrm, I would have to look at the VT-d but I suspect you're right. > That's unfortunate. > > That means mlock() isn't sufficient. It also means that the VMAs can't > be updated while the guest is running. Is there any way to lock a vma > region such that things like madvise/mmap(MAP_FIXED) will always fail? > Userspace can simply not issue them. Page migration is also controlled by userspace. Once active memory defragmentation goes in, we need a way to tell the kernel that the allocation is unreclaimable, perhaps with a new mmap flag. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-11 14:40:18
|
James Pike wrote: > Sorry that doesn't work. > > This does. > > --- kvm/configure 2008-05-02 19:20:13.000000000 +0800 > +++ kvm.new/configure 2008-05-07 19:34:28.000000000 +0800 > @@ -2,6 +2,7 @@ > > prefix=/usr/local > kerneldir=/lib/modules/$(uname -r)/build > +kernelsrcdir=/lib/modules/$(uname -r)/source > cc=gcc > ld=ld > objcopy=objcopy I don't think there is a guarantee that /source will be present, only /build. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-11 14:34:08
|
Anthony Liguori wrote:
> Normally, tap always reads packets and simply lets the client drop them if it
> cannot receive them. For virtio-net, this results in massive packet loss and
> about an 80% performance loss in TCP throughput.
>
> This patch modifies qemu_send_packet() to only deliver a packet to a VLAN
> client if it doesn't have a fd_can_read method or the fd_can_read method
> indicates that it can receive packets. We also return a status of whether
> any clients were able to receive the packet.
>
> If no clients were able to receive a packet, we buffer the packet until a
> client indicates that it can receive packets again.
>
> This patch also modifies the tap code to only read from the tap fd if at least
> one client on the VLAN is able to receive a packet.
>
> Finally, this patch changes the tap code to drain all possible packets from
> the tap device when the tap fd is readable.
>
>
> #if defined(CONFIG_SLIRP)
> @@ -3970,6 +3976,8 @@ typedef struct TAPState {
> VLANClientState *vc;
> int fd;
> char down_script[1024];
> + char buf[4096];
> + int size;
> } TAPState;
>
This breaks large MTUs.
How about the other way round: when the vlan consumer detects it can no
longer receive packets, it tells that to the vlan. When all vlan
consumers can no longer receive, tell the producer to stop producing.
For the tap producer, this is simply removing its fd from the read poll
list. When a vlan consumer becomes ready to receive again, it tells the
vlan, which tells the producers, which then install their fds back again.
This is a bit difficult since virtio and tap are both consumers and
producers, but could be made to work, I think.
--
error compiling committee.c: too many arguments to function
|
|
From: Avi K. <av...@qu...> - 2008-05-11 14:26:04
|
Marcelo Tosatti wrote: >> The best practice is to issue all vcpu ioctls from the thread that >> created the vcpu; this becomes mandatory if we ever switch to a syscall >> interface and remove the mutex. >> > > For things like register dumps I don't believe its worthwhile. Much > simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it > again (now that you mention the busy-spin, it is broken right now, if a > vcpu is spinning without exiting to userspace). > > 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. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-11 14:24:36
|
Marcelo Tosatti wrote: > On Fri, May 09, 2008 at 04:22:08PM -0300, Marcelo Tosatti wrote: > >> For things like register dumps I don't believe its worthwhile. Much >> simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it >> again (now that you mention the busy-spin, it is broken right now, if a >> vcpu is spinning without exiting to userspace). >> > > ... which is what Jan's gdb/monitor patch does. > We'd better change it. Suppose your vcpu is spinning, and you want to find out why? One nice thing would be to add an on_vcpu(void (*func)(void *data), void *data), so that people don't have to open-code it for things like this. I tried to do this once, but backed off due to the mess that qemu-kvm threading was at the time. I think it's much better off now. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-11 13:36:42
|
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. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-11 12:32:05
|
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. -- error compiling committee.c: too many arguments to function |
|
From: julien <ivr...@4g...> - 2008-05-11 11:52:25
|
Nick Cannon attributed his courting skills to us http://www.bualken.com/ |
|
From: SourceForge.net <no...@so...> - 2008-05-11 10:35:24
|
Bugs item #1959950, was opened at 2008-05-08 04:45 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959950&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to restore guests in real mode. Initial Comment: If save and restore a guest in real mode, for example guest running in grub or memtest86 program, the guest will crash. The error message: [root@vt-dp8 results]# qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:10:4d:f1,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img_gtp12_1210169969_1 -cdrom /root/memtest86-3.4a.iso -boot d -incoming file:///tmp/abc unhandled vm exit: 0x80000021 vcpu_id 0 rax 00000000000000e4 rbx 000000000001a8c0 rcx 0000000000000000 rdx 0000000000000020 rsi 000000000001c8dc rdi 0000000000000022 rsp 000000000001b880 rbp 0000000000000001 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 0000000000006069 rflags 00010002 cs 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0) ds 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0) es 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0) ss 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0) fs 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0) gs 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0) tr 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 25b4/2f idt 250c/9f cr0 11 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 Aborted ---------------------------------------------------------------------- >Comment By: Avi Kivity (avik) Date: 2008-05-11 13:35 Message: Logged In: YES user_id=539971 Originator: NO commit 662beb8baa37481d1cb32aff8354c931f8a73441 Author: Avi Kivity <av...@qu...> Date: Sun May 11 13:34:46 2008 +0300 kvm: qemu: remove hacking the segment attributes on reset The hack also corrupts the segment attributes on nonpaging save/restore, which is bad. The previous commit fixes the problem at the source, rendering the hack unnecessary. Fixes 1959950. Signed-off-by: Avi Kivity <av...@qu...> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959950&group_id=180599 |
|
From: Muli Ben-Y. <mu...@il...> - 2008-05-11 08:49:21
|
On Mon, May 05, 2008 at 02:36:23PM -0700, Kay, Allen M wrote:
> + for (j = 0; j < npages; j++) {
> + gpa += PAGE_SIZE;
> + page = gfn_to_page(kvm, gpa >> PAGE_SHIFT);
> + hpa = page_to_phys(page);
> + domain_page_mapping(kvm->arch.domain, gpa, hpa,
> PAGE_SIZE,
> + DMA_PTE_READ | DMA_PTE_WRITE);
> + vma = find_vma(current->mm, gpa);
> + if (!vma)
> + return 1;
> + write = (vma->vm_flags & VM_WRITE) != 0;
> + get_user_pages(current, current->mm, gpa,
> + PAGE_SIZE, write, 0, NULL, NULL);
> + }
> + return 0;
> +}
get_user_pages can fail. We should first try to fault in the pages and
only if succesfull map them in the IOMMU. Also, you need to protect
against the vma going away here.
Cheers,
Muli
|
|
From: SourceForge.net <no...@so...> - 2008-05-11 08:26:28
|
Bugs item #1874203, was opened at 2008-01-18 01:14 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1874203&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Y-Chromosome (y-chromosome) Assigned to: Nobody/Anonymous (nobody) Summary: qemu-kvm gives just black screen Initial Comment: kernel 2.6.24-rc6 qemu 0.9.1 kvm 58 / 59 tested i get just a black screen in the qemu window if i try to start my windows 98 version with qemu-kvm if i try it to start without it works flawlessly but slow. ---------------------------------------------------------------------- Comment By: Emmanuel Florac (eflorac) Date: 2008-01-23 20:17 Message: Logged In: YES user_id=546391 Originator: NO It works OK with version 60. ---------------------------------------------------------------------- Comment By: Emmanuel Florac (eflorac) Date: 2008-01-23 18:23 Message: Logged In: YES user_id=546391 Originator: NO Looks like a known bug, according to http://sourceforge.net/mailarchive/message.php?msg_name=477CB781.8090302%40qumranet.com I'm trying kvm 60... ---------------------------------------------------------------------- Comment By: Emmanuel Florac (eflorac) Date: 2008-01-23 17:41 Message: Logged In: YES user_id=546391 Originator: NO Same problem. Running linux 2.6.22.16 amd64, kvm 059. The command line I use: qemu-system-x86_64 -m 384 -hda image.vmdk -boot c -s With the -no-kvm option it works fine, but it freezes with kvm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1874203&group_id=180599 |
|
From: 测试 <zho...@si...> - 2008-05-11 05:36:51
|
您好！
上海汇盛税务代理有限公司优惠代开上海各区(浦东区、
徐汇区、闵行区、卢湾区、黄浦区、宝山区，松江区，青浦
区，虹口区等)房屋租赁发票，装潢费发票、工程款发票，服
务费发票，代购印花税等！均由上海市地方税务机关机打票
并出具全额完税凭证，绝对保真,税务局可查询,验证后付款！
上海汇盛税务代理有限公司并代理全国各种发票:(普通商品
销售、增值税、广告业、咨询服务业)等等相关发票。税点从优
欢迎有需要来电咨询于洽谈:
地址：上海市浦东新区东波路
电话：021-51901216 13501815099
E-mail：fap...@12...
hppe//www.shhs9988.com
|
|
From: 广东科税财务代理有限公司 <zha...@16...> - 2008-05-11 04:38:40
|
您好,广东科税财务代理有限公司是一家规模巨大的财务公司,现有大量剩余发票,可对外代开(包括增值税 发票,国税,地税,普通发票,普通增值税发票)若贵公司(厂家)在做帐或其他方面有需要,可来电联系.本公司郑 重承诺:所开出发票均为税务局申领,可供网上查询或税务局验证后付款.谢谢(如有打扰之处请谅解) 联系人:张国锋 联系电话:(020)31336685 13533883250 传真:(020)33789285 Email:zha...@16... |
|
From: W S <ws...@gm...> - 2008-05-11 03:00:26
|
I can also confirm I've seen this. On a heavily loaded KVM guest, and lots of network activity. On Thu, May 8, 2008 at 4:54 AM, Paolo Losi <pa...@hy...> wrote: > FYI. > Please review it at: > > https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/228163 > > Regards > Paolo > > ------------------------------------------------------------------------- > 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.
