date:20080514

Marcelo Tosatti wrote:
> On Mon, May 12, 2008 at 02:19:24PM -0500, Ryan Harper wrote:
>   
> Hi Ryan,
>
> There are two places that attempt to use delivery mode 7: kexec crash
> and io_apic_64.c::check_timer().
>
> The later will happen if the guest fails to receive PIT IRQ's for 10
> ticks. If you're using HZ=1000 thats 10ms. See timer_irq_works().
>
> The in-kernel pit emulation has logic which avoids injecting more than
> one IRQ during 10ms.
>
> Note that the guest 10ms delay is TSC based and uses only the lower
> 32-bits of the value. It is quite likely that the TSC adjustment results
> in them increasing more rapidly then they should.
>   

Or that the TSC is terribly miscalibrated.  Here is the log of all 48 
guests.  In this case, the host detects 1995.008 as the frequency.  This 
is a Barcelona.  I suspect that we're masking the 
X86_FEATURE_CONSTANT_TSC though.

 From a quick look, I suspect that the number of wildly off TSC 
calibrations correspond to the VMs that are misbehaving.  I think this 
may mean that we have to re-examine the tsc delta computation.

10_serial.log:time.c: Detected 1995.038 MHz processor.
11_serial.log:time.c: Detected 2363.195 MHz processor.
12_serial.log:time.c: Detected 2492.675 MHz processor.
13_serial.log:time.c: Detected 1995.061 MHz processor.
14_serial.log:time.c: Detected 1994.917 MHz processor.
15_serial.log:time.c: Detected 4100.735 MHz processor.
16_serial.log:time.c: Detected 2075.800 MHz processor.
17_serial.log:time.c: Detected 2674.350 MHz processor.
18_serial.log:time.c: Detected 1995.002 MHz processor.
19_serial.log:time.c: Detected 1994.978 MHz processor.
1_serial.log:time.c: Detected 4384.310 MHz processor.
20_serial.log:time.c: Detected 1994.969 MHz processor.
21_serial.log:time.c: Detected 3670.696 MHz processor.
22_serial.log:time.c: Detected 1994.997 MHz processor.
23_serial.log:time.c: Detected 2218.613 MHz processor.
24_serial.log:time.c: Detected 1995.048 MHz processor.
25_serial.log:time.c: Detected 1995.015 MHz processor.
26_serial.log:time.c: Detected 1994.957 MHz processor.
27_serial.log:time.c: Detected 1995.051 MHz processor.
28_serial.log:time.c: Detected 1995.021 MHz processor.
29_serial.log:time.c: Detected 3679.640 MHz processor.
2_serial.log:time.c: Detected 2191.105 MHz processor.
30_serial.log:time.c: Detected 1995.086 MHz processor.
31_serial.log:time.c: Detected 1995.071 MHz processor.
32_serial.log:time.c: Detected 1995.051 MHz processor.
33_serial.log:time.c: Detected 2331.760 MHz processor.
34_serial.log:time.c: Detected 1995.011 MHz processor.
35_serial.log:time.c: Detected 1995.050 MHz processor.
36_serial.log:time.c: Detected 1994.911 MHz processor.
37_serial.log:time.c: Detected 1994.905 MHz processor.
38_serial.log:time.c: Detected 1994.881 MHz processor.
39_serial.log:time.c: Detected 1995.027 MHz processor.
3_serial.log:time.c: Detected 2051.467 MHz processor.
40_serial.log:time.c: Detected 1994.987 MHz processor.
41_serial.log:time.c: Detected 1994.970 MHz processor.
42_serial.log:time.c: Detected 1994.952 MHz processor.
43_serial.log:time.c: Detected 1995.042 MHz processor.
44_serial.log:time.c: Detected 1994.998 MHz processor.
45_serial.log:time.c: Detected 1995.016 MHz processor.
46_serial.log:time.c: Detected 1995.006 MHz processor.
47_serial.log:time.c: Detected 1995.000 MHz processor.
4_serial.log:time.c: Detected 1995.112 MHz processor.
5_serial.log:time.c: Detected 1995.081 MHz processor.
6_serial.log:time.c: Detected 2017.303 MHz processor.
7_serial.log:time.c: Detected 1995.046 MHz processor.
8_serial.log:time.c: Detected 1994.951 MHz processor.
9_serial.log:time.c: Detected 2184.754 MHz processor.

Regards,

Anthony Liguori

> So can you try setting KVM_MAX_PIT_INTR_INTERVAL to a lower value? HZ/10
> or something.
>
> You can confirm this theory by booting the guests with "apic=debug".
>
> -
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] pinning, tsc and apic

2008-05-14 Thread Marcelo Tosatti

On Mon, May 12, 2008 at 02:19:24PM -0500, Ryan Harper wrote:
> I've been digging into some of the instability we see when running
> larger numbers of guests at the same time.  The test I'm currently using
> involves launching 64 1vcpu guests on an 8-way AMD box.  With the latest
> kvm-userspace git and kvm.git + Gerd's kvmclock fixes, I can launch all
> 64 of these 1 second apart, and only a handful (1 to 3)  end up not
> making it up.  In dmesg on the host, I get a couple messages:
> 
> [321365.362534] vcpu not ready for apic_round_robin
> 
> and 
> 
> [321503.023788] Unsupported delivery mode 7
> 
> Now, the interesting bit for me was when I used numactl to pin the guest
> to a processor, all of the guests come up with no issues at all.  As I
> looked into it, it means that we're not running any of the vcpu
> migration code which on svm is comprised of tsc_offset recalibration and
> apic migration, and on vmx, a little more per-vcpu work

Hi Ryan,

There are two places that attempt to use delivery mode 7: kexec crash
and io_apic_64.c::check_timer().

The later will happen if the guest fails to receive PIT IRQ's for 10
ticks. If you're using HZ=1000 thats 10ms. See timer_irq_works().

The in-kernel pit emulation has logic which avoids injecting more than
one IRQ during 10ms.

Note that the guest 10ms delay is TSC based and uses only the lower
32-bits of the value. It is quite likely that the TSC adjustment results
in them increasing more rapidly then they should.

So can you try setting KVM_MAX_PIT_INTR_INTERVAL to a lower value? HZ/10
or something.

You can confirm this theory by booting the guests with "apic=debug".

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm trace support for ppc

On Tuesday 13 May 2008 03:06:19 Tan, Li wrote:
> Hollisb,
> I have 2 more questions:
> 1. seems record won't be overwritten because current code is as following:
> /*
>  *  The relay channel is used in "no-overwrite" mode, it keeps trace of how
>  *  many times we encountered a full subbuffer, to tell user space app the
>  *  lost records there were.
>  */
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
>void *prev_subbuf, size_t prev_padding)
> {
>   struct kvm_trace *kt;
> 
>   if (!relay_buf_full(buf))
>   return 1;
> 
>   kt = buf->chan->private_data;
>   atomic_inc(&kt->lost_records);
> 
>   return 0;
> }
> 
> 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use 
existing relayfs to output struct metadata with kmagic, if we update code as 
following?
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
>void *prev_subbuf, size_t prev_padding)
> {
>   struct kvm_trace *kt;
> 
>   if (!relay_buf_full(buf))
>   {
>   if (!prev_subbuf) {
>   //here is executed only once (when the channel is 
> opened)
>   subbuf_start_reserve(buf, sizeof(struct metadata));
>   ((struct metadata *)subbuf)->kmagic = 0x1234;
>   }
>   
>   return 1;
>   }
> 
>   kt = buf->chan->private_data;
>   atomic_inc(&kt->lost_records);
> 
>   return 0;
> }

Ah, I didn't understand what the "lost records" handling was about. Given that 
it won't be lost, it would be OK for the kernel to export the header, and in 
that case I guess you would want it to be the same size as the other records. 
I'm not sure how I feel about that from a layering point of view, but at 
least it would be functional.

-- 
Hollis Blanchard
IBM Linux Technology Center

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Protected mode transitions and big real mode... still an issue

2008-05-14 Thread Marcelo Tosatti

Hi Guillaume,

On Wed, May 14, 2008 at 09:29:11AM +0200, Guillaume Thouvenin wrote:
> On Tue, 6 May 2008 20:05:39 +0300
> "Mohammed Gamal" <[EMAIL PROTECTED]> wrote:
> 
> 
> > > > > WinXP fails with the patch applied too. Ubuntu 7.10 live CD and
> > > > > FreeDOS don't boot but complain about instruction mov 0x11,sreg not
> > > > > being emulated.
> 
> Mohammed, can you try the patch at the end of this mail? Here it's
> working with FreeDOS now (I added the emulation of 0x90 that is an xchg
> instruction). I can also boot winXP Professional X64 edition. I still
> have a weird issue with Ubuntu 7.10 that crashes sometimes with the
> error:
> 
> kvm_run: failed entry, reason 5
> kvm_run returned -8
> 
> It's a little bit strange because this error appears very often with
> the wmii window manager but never with XFCE. And with wmii, it only
> occurs when I move the mouse above the Qemu/KVM window. If I wait 30s
> until the automatic boot it works... 

This appears to be due to the vmport save/load bug:
https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/219165 

I'll look into it if nobody beats me to it.

Regarding FreeDOS, it necessary to emulate software interrupts and NOP
to get the "HIMEM XMS-memory driver" version to boot (with the FreeOSZOO
image).

The "maximum RAM free, using EMM86" version is more complicated, requiring 
ldt, ltr and a few other things.

There are two problems remaining:

1) add is storing the result in the wrong register

6486:   66 64 89 3e 72 01   mov%edi,%fs:0x172
648c:   66 be 8d 03 00 00   mov$0x38d,%esi
6492:   66 c1 e6 04 shl$0x4,%esi
6496:   66 b8 98 0a 00 00   mov$0xa98,%eax
649c:   66 03 f0add%eax,%esi

The destination for the add is "%esi", but the emulation stores the 
result in eax, because:

if ((c->d & ModRM) && c->modrm_mod == 3) {
u8 reg;
c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
c->dst.ptr = decode_register(c->modrm_rm, c->regs, c->d 
& ByteOp);
}

modrm_reg contains "6", which is the correct register index, but
modrm_rm contains 0, so the result is stored in "eax" (see hack).

2) iretl generates pagefaults

  1226df:   0f 06   clts
  1226e1:   b8 14 00mov$0x14,%ax
  1226e4:   8e e0   mov%ax,%fs
  1226e6:   66 64 a1 50 01  mov%fs:0x150,%eax
  1226eb:   0f 22 d8mov%eax,%cr3
  1226ee:   0f 20 c0mov%cr0,%eax
  1226f1:   66 0d 00 00 00 80   or $0x8000,%eax
  1226f7:   0f 22 c0mov%eax,%cr0
  1226fa:   66 cf   iretl

The iretl which happens after enabling paging faults in different ways:

kvm_inject_page_fault: EIP=1226fa
kvm_inject_page_fault: ADDR=1226fa

kvm_inject_page_fault: EIP=1226fa
kvm_inject_page_fault: ADDR=1237d1
kvm: inject_page_fault: double fault 0x1237d1


Index: kvm.tip/arch/x86/kvm/vmx.c
===
--- kvm.tip.orig/arch/x86/kvm/vmx.c
+++ kvm.tip/arch/x86/kvm/vmx.c
@@ -194,6 +194,12 @@ static inline int is_external_interrupt(
== (INTR_TYPE_EXT_INTR | INTR_INFO_VALID_MASK);
 }
 
+static inline int is_software_interrupt(u32 intr_info)
+{
+   return (intr_info & (INTR_TYPE_SOFT_INTR | INTR_INFO_VALID_MASK))
+   == (INTR_TYPE_SOFT_INTR | INTR_INFO_VALID_MASK);
+}
+
 static inline int cpu_has_vmx_msr_bitmap(void)
 {
return (vmcs_config.cpu_based_exec_ctrl & CPU_BASED_USE_MSR_BITMAPS);
@@ -2190,8 +2196,10 @@ static void kvm_guest_debug_pre(struct k
 }
 
 static int handle_rmode_exception(struct kvm_vcpu *vcpu,
- int vec, u32 err_code)
+ u32 intr_info, u32 err_code)
 {
+   int vec = intr_info & INTR_INFO_VECTOR_MASK;
+
if (!vcpu->arch.rmode.active)
return 0;
 
@@ -2202,6 +2210,10 @@ static int handle_rmode_exception(struct
if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0)
if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
return 1;
+   if (is_software_interrupt(intr_info) && err_code == 0) {
+   if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
+   return 1;
+   }
return 0;
 }
 
@@ -2257,8 +2269,7 @@ static int handle_exception(struct kvm_v
}
 
if (vcpu->arch.rmode.active &&
-   handle_rmode_exception(vcpu, intr_info & INTR_INFO_VECTOR_MASK,
-   error_code)) {
+   handle_rmode_exception(vcpu, intr_info, error_code)) {
if (vcpu->arch.halt_request) {
vcpu->arch.halt_request = 0;
return kvm

Re: [kvm-devel] [kvm-ppc-devel] [RFC] Reworking KVM_DEBUG_GUEST

On Wednesday 14 May 2008 16:11:39 Hollis Blanchard wrote:
> On Wednesday 14 May 2008 16:06:00 Hollis Blanchard wrote:
> > In 
> > fact, in the case of soft breakpoints, KVM doesn't even know where all the 
> > set breakpoints are.
> 
> Side note: I'm retract this sentence: I wrote it before I sketched out the 
> pseudocode, and forgot to remove it. :)

Er no, let me try that again:

In my proposed design, the stub needs to know where all breakpoints are, HW or 
SW. (That means it must implement Z0/Z1.)

However, KVM itself doesn't need to know any of that: all breakpoints are 
referred to the stub for handling, and the stub will notify KVM if further 
action is needed in-kernel.

-- 
Hollis Blanchard
IBM Linux Technology Center

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] [RFC] Reworking KVM_DEBUG_GUEST

On Wednesday 14 May 2008 16:06:00 Hollis Blanchard wrote:
> In 
> fact, in the case of soft breakpoints, KVM doesn't even know where all the 
> set breakpoints are.

Side note: I'm retract this sentence: I wrote it before I sketched out the 
pseudocode, and forgot to remove it. :)

-- 
Hollis Blanchard
IBM Linux Technology Center

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

2008-05-14 Thread Tomasz Chmielewski

Anthony Liguori schrieb:

(...)

>>> So, a PV network driver can do about 700Mb/s, and an emulated NIC can 
>>> do about 600 Mb/s, Windows guest to host?
>>>
>>> That would be about 20% improvement?
>>> 
> 
> FWIW, virtio-net is much better with my patches applied.  The difference 
> between the e1000 and virtio-net is that e1000 consumes almost twice as 
> much CPU as virtio-net so in my testing, the performance improvement 
> with virtio-net is about 2x.  We were loosing about 20-30% throughput 
> because of the delays in handling incoming packets.

Do you by chance have any recent numbers on disk performance (i.e., Windows 
guest vs Linux host)?


-- 
Tomasz Chmielewski
http://wpkg.org

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

2008-05-14 Thread Ответственность главного бухгалтера

On Wednesday 14 May 2008 14:49:02 Jan Kiszka wrote:
> > In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would 
> > just need to see if that address is for a breakpoint Qemu set or not. If 
so, 
> > it's happy. If not, (commence handwaving) tell KVM to forward the debug 
> > interrupt to the guest. This way, the list of breakpoints is maintained in 
> > userspace (in the qemu gdb stub), which is nice because it could be 
> > arbitrarily large.
> 
> Yes, but I would rather pass the debug registers (more general: some
> arch dependent state set) back in this slot. Those contain everything
> the gdbstub needs to know to catch relevant hardware-BP/watchpoint
> events (and report them to the gdb frontend).

But what would the stub *do* with the contents of the debug registers? The 
only reason they were set is on behalf of the stub in the first place. In 
fact, in the case of soft breakpoints, KVM doesn't even know where all the 
set breakpoints are. The only thing KVM needs to report is the address of the 
breakpoint that was just hit.

Sorry if this gets formatted badly:

gdb qemu stub   
KVM
break *0xf00
sends Z0 packet 0xf00
0xf00 -> BP list
ioctl(KVM_DEBUG, 0xf00)
continue
ioctl(KVM_RUN)

running...

breakpoint hit

exit_reason = KVM_EXIT_DEBUG

kvm_run.debug.address = current PC value
search BP list for address
bp hit  <---presentnot present ---> send debug 
interrupt to guest

Notes:
- KVM_DEBUG in this case will set a hardware breakpoint. The alternative is to 
write an int3 into guest memory.
- The stub doesn't care how the hardware registers were configured. All it 
needs to know is a) that a breakpoint was hit, and b) at what address.

Does this make sense?

-- 
Hollis Blanchard
IBM Linux Technology Center

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Forget all your diseases with our help.

2008-05-14 Thread Sascha

This will be the only place you will ever need for all you cravings. 
http://www.noppoeai.com/

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Юридический спецкурс для бухга лтеров

Юридический спецкурс для бухгалтеров

Курс ориентирован на бухгалтеров и работников финансовых служб, коммерческих
директоров, желающих получить дополнительные знания в области договорного права

02 - 04 июня, Санкт - Петербург

В рамках мероприятия:
Иерархия нормативных правовых актов, регулирующих вопросы налогообложения и
бухгалтерского учета, гражданского права.
Характеристика хозяйственных договоров, виды договоров (порядок заключения,
изменения, расторжение договоров, существенные условия договоров и пр.)
Гражданско-правовые и налоговые последствия несоблюдения установленных законом
форм сделок. и их государственной регистрации. - Что такое свобода договора с
точки зрения закона и руководителя организации. Виды договоров, определенные ГК
РФ. Группировка договоров для целей налогообложения. Договоры, имеющие особый
порядок налогообложения. Определение вида деятельности в зависимости от вида
заключаемого договора
Значение заключаемых договоров и их взаимосвязь с отражением в бухгалтерском
учете хозяйственных операций. Некоторые ограничения в договорах, вызываемые
действием законодательства о налогах и сборах. Толкование договора для
финансовых и налоговых целей
Договорная и налоговая цена сделки.
Договорная цена сделки и порядок ее формирования. Цена сделки как объект
налогообложения. Соотношение договорной и налоговой цены сделки. Когда
налоговые органы вправе проверить договорную цену сделки и порядок
осуществления налогового контроля. Товарообменные (бартерные) операции
Особенности заключения некоторых договоров и налоговые последствия: Договоры
купли-продажи и посредничества. Договор аренды. Договор займа
Расчеты по договору и налогообложение. Не денежные формы расчетов по договору и
налогообложение
Использование договоров для целей налогового планирования. Общие принципы
налогообложения. Возможность оптимизации налогообложения путем заключения
определенных видов договоров. Практическое использование особенностей различных
договоров для целей налогового планирования
Трудовые договоры: порядок заключения, изменения, расторжения. Условия и
порядок увольнения работников. Выплата компенсаций при увольнении
Органы налогового контроля: виды проверок. Основания для проведения проверок.
Правовое положение руководителя организации и должностных лиц. Права и
обязанности бухгалтера при осуществлении проверок. Выездная и камеральная
налоговая проверка - порядок осуществления с учетом всех последних изменений.
Акт налоговой проверки. Виды санкций
Ответственность главного бухгалтера

Информация по регистрации участников: (812) 983-54-39

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)

2008-05-14 Thread David S. Ahern

Avi Kivity wrote:
> 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.

I put the flood count back to 3, and the RHEL3 guest performance is even
better.

> 
> While I was able to see excessive flooding, I couldn't reproduce your
> kscand problem.  Running /bin/true always returned immediately for me.

A poor attempt at finding a simplistic, minimal re-create. The use case
I am investigating has over 500 processes/threads with a base memory
consumption around 1GB. I was finding it nearly impossible to have a
generic re-create of the problem for you to use in your investigations
on CentOS.

Thanks for the patch.

david

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote:
> Hollis Blanchard wrote:
> > On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
> >> So gdb on power relies only on those few hw-breakpoints? With x86 you
> >> can perfectly run gdb (with soft BPs) in parallel with the gdbstub
> >> (currently based on hw-BPs, but the same would be true for soft-BPs
> >> inserted by the gdbstub).
> > 
> > GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. 
It 
> > does not rely on the hardware breakpoints.
> > 
> > It gets a little more complicated when you involve a GDB stub. IIRC, GDB 
will 
> > ask the stub to set the breakpoint, and if the stub doesn't support it, 
GDB 
> > will fall back to overwriting the instructions in memory. Does the Qemu 
GDB 
> > stub advertise breakpoint support?
> 
> Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something
> even gdbserver does not do! It just handles watchpoints (Z2..4).
> 
> > 
> > If not, the only support needed in KVM would be to send all debug 
interrupts 
> > to qemu, and allow qemu to send them back down for in-guest breakpoints.
> > 
> 
> Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's
> kernel side should not yet inform QEMU about soft-BP exceptions. But in
> theory, this should be easily fixable (or is already the case for other
> archs). And it would safe us from keeping track of N software
> breakpoints, where N could even become larger than 32, the current
> hardcoded limit for plain QEMU. :)
> 
> Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is
> insufficient: We need a return channel for the debug register state
> (specifically to figure out details about hit watchpoints). I'm now
> favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us
> to write _and_ read-back the suggested data structure.

How about simply extending kvm_exit.debug to contain the virtual address of 
the breakpoint hit? In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would 
just need to see if that address is for a breakpoint Qemu set or not. If so, 
it's happy. If not, (commence handwaving) tell KVM to forward the debug 
interrupt to the guest. This way, the list of breakpoints is maintained in 
userspace (in the qemu gdb stub), which is nice because it could be 
arbitrarily large.

Also, this is not specific to hardware debug registers: soft and hard 
breakpoint interrupts would follow the same path. There's still a question of 
whether the GDB stub should set the breakpoint itself (Z0/Z1) or force GDB to 
modify memory, but either way the KVM code is simple.

-- 
Hollis Blanchard
IBM Linux Technology Center

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

2008-05-14 Thread Jan Kiszka

Hollis Blanchard wrote:
> On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote:
>> Hollis Blanchard wrote:
>>> On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
 So gdb on power relies only on those few hw-breakpoints? With x86 you
 can perfectly run gdb (with soft BPs) in parallel with the gdbstub
 (currently based on hw-BPs, but the same would be true for soft-BPs
 inserted by the gdbstub).
>>> GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. 
> It 
>>> does not rely on the hardware breakpoints.
>>>
>>> It gets a little more complicated when you involve a GDB stub. IIRC, GDB 
> will 
>>> ask the stub to set the breakpoint, and if the stub doesn't support it, 
> GDB 
>>> will fall back to overwriting the instructions in memory. Does the Qemu 
> GDB 
>>> stub advertise breakpoint support?
>> Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something
>> even gdbserver does not do! It just handles watchpoints (Z2..4).
>>
>>> If not, the only support needed in KVM would be to send all debug 
> interrupts 
>>> to qemu, and allow qemu to send them back down for in-guest breakpoints.
>>>
>> Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's
>> kernel side should not yet inform QEMU about soft-BP exceptions. But in
>> theory, this should be easily fixable (or is already the case for other
>> archs). And it would safe us from keeping track of N software
>> breakpoints, where N could even become larger than 32, the current
>> hardcoded limit for plain QEMU. :)
>>
>> Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is
>> insufficient: We need a return channel for the debug register state
>> (specifically to figure out details about hit watchpoints). I'm now
>> favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us
>> to write _and_ read-back the suggested data structure.
> 
> How about simply extending kvm_exit.debug to contain the virtual address of 
> the breakpoint hit?

Ah, there is an interface for such stuff already! And it can even take
quite some payload...

> In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would 
> just need to see if that address is for a breakpoint Qemu set or not. If so, 
> it's happy. If not, (commence handwaving) tell KVM to forward the debug 
> interrupt to the guest. This way, the list of breakpoints is maintained in 
> userspace (in the qemu gdb stub), which is nice because it could be 
> arbitrarily large.

Yes, but I would rather pass the debug registers (more general: some
arch dependent state set) back in this slot. Those contain everything
the gdbstub needs to know to catch relevant hardware-BP/watchpoint
events (and report them to the gdb frontend).

> 
> Also, this is not specific to hardware debug registers: soft and hard 
> breakpoint interrupts would follow the same path. There's still a question of 
> whether the GDB stub should set the breakpoint itself (Z0/Z1) or force GDB to 
> modify memory, but either way the KVM code is simple.

Only rejecting Z0 will enable us to avoid any soft-BP tracking in
qemu-kvm, and that is definitely my plan. Z1 may become an option to add
later on and would be answered as "unsupported" for now.

Jan



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

2008-05-14 Thread Jan Kiszka

Hollis Blanchard wrote:
> On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
>> So gdb on power relies only on those few hw-breakpoints? With x86 you
>> can perfectly run gdb (with soft BPs) in parallel with the gdbstub
>> (currently based on hw-BPs, but the same would be true for soft-BPs
>> inserted by the gdbstub).
> 
> GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It 
> does not rely on the hardware breakpoints.
> 
> It gets a little more complicated when you involve a GDB stub. IIRC, GDB will 
> ask the stub to set the breakpoint, and if the stub doesn't support it, GDB 
> will fall back to overwriting the instructions in memory. Does the Qemu GDB 
> stub advertise breakpoint support?

Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something
even gdbserver does not do! It just handles watchpoints (Z2..4).

> 
> If not, the only support needed in KVM would be to send all debug interrupts 
> to qemu, and allow qemu to send them back down for in-guest breakpoints.
> 

Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's
kernel side should not yet inform QEMU about soft-BP exceptions. But in
theory, this should be easily fixable (or is already the case for other
archs). And it would safe us from keeping track of N software
breakpoints, where N could even become larger than 32, the current
hardcoded limit for plain QEMU. :)

Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is
insufficient: We need a return channel for the debug register state
(specifically to figure out details about hit watchpoints). I'm now
favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us
to write _and_ read-back the suggested data structure.

Jan

signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

2008-05-14 Thread Muli Ben-Yehuda

On Wed, May 14, 2008 at 06:09:42PM +0300, Dor Laor wrote:

> > Do you have any performance numbers for networking to see how it
> > compares to the real hardware?
> > 
> > - Linux host (or: real Windows running on that host)
> 
> For host you can measure yourself but for Linux guest (to host) it
> currently do about 1G, using TSO (work in progress) it can do 2.5G,
> and there is also work in progress to make the kernel know virtio
> through the tap interface which will further boot performance.

... with what kind of CPU utilization?

> > - PV Windows (network driver)
> 
> About 700Mb+-, there is currently extra copy that we need to omit.
> Thanks for Anthony, we just have to change the driver.

Same question (although it's less interesting if we can't even
saturate the pipe).

> > - non-PV Windows
> 
> What do you mean? Other fully emulated nics like e1000?
> It does not perform as pv but depending on the guest it can do up to
> 600Mb+-.

Same question (although again it's less interesting if we can't even
saturate the pipe).

Cheers,
Muli

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Linus Torvalds

On Wed, 14 May 2008, Christoph Lameter wrote:
> 
> The problem is that the code in rmap.c try_to_umap() and friends loops 
> over reverse maps after taking a spinlock. The mm_struct is only known 
> after the rmap has been acccessed. This means *inside* the spinlock.

So you queue them. That's what we do with things like the dirty bit. We 
need to hold various spinlocks to look up pages, but then we can't 
actually call the filesystem with the spinlock held.

Converting a spinlock to a waiting lock for things like that is simply not 
acceptable. You have to work with the system.

Yeah, there's only a single bit worth of information on whether a page is 
dirty or not, so "queueing" that information is trivial (it's just the 
return value from "page_mkclean_file()". Some things are harder than 
others, and I suspect you need some kind of "gather" structure to queue up 
all the vma's that can be affected.

But it sounds like for the case of rmap, the approach of:

 - the page lock is the higher-level "sleeping lock" (which makes sense, 
   since this is very close to an IO event, and that is what the page lock 
   is generally used for)

   But hey, it could be anything else - maybe you have some other even 
   bigger lock to allow you to handle lots of pages in one go.

 - with that lock held, you do the whole rmap dance (which requires 
   spinlocks) and gather up the vma's and the struct mm's involved. 

 - outside the spinlocks you then do whatever it is you need to do.

This doesn't sound all that different from TLB shoot-down in SMP, and the 
"mmu_gather" structure. Now, admittedly we can do the TLB shoot-down while 
holding the spinlocks, but if we couldn't that's how we'd still do it: 
it would get more involved (because we'd need to guarantee that the gather 
can hold *all* the pages - right now we can just flush in the middle if we 
need to), but it wouldn't be all that fundamentally different.

And no, I really haven't even wanted to look at what XPMEM really needs to 
do, so maybe the above thing doesn't work for you, and you have other 
issues. I'm just pointing you in a general direction, not trying to say 
"this is exactly how to get there". 

Linus

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
> So gdb on power relies only on those few hw-breakpoints? With x86 you
> can perfectly run gdb (with soft BPs) in parallel with the gdbstub
> (currently based on hw-BPs, but the same would be true for soft-BPs
> inserted by the gdbstub).

GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It 
does not rely on the hardware breakpoints.

It gets a little more complicated when you involve a GDB stub. IIRC, GDB will 
ask the stub to set the breakpoint, and if the stub doesn't support it, GDB 
will fall back to overwriting the instructions in memory. Does the Qemu GDB 
stub advertise breakpoint support?

If not, the only support needed in KVM would be to send all debug interrupts 
to qemu, and allow qemu to send them back down for in-guest breakpoints.

-- 
Hollis Blanchard
IBM Linux Technology Center

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Christoph Lameter

On Wed, 14 May 2008, Linus Torvalds wrote:

> One thing to realize is that most of the time (read: pretty much *always*) 
> when we have the problem of wanting to sleep inside a spinlock, the 
> solution is actually to just move the sleeping to outside the lock, and 
> then have something else that serializes things.

The problem is that the code in rmap.c try_to_umap() and friends loops 
over reverse maps after taking a spinlock. The mm_struct is only known 
after the rmap has been acccessed. This means *inside* the spinlock.

That is why I tried to convert the locks to scan the revese maps to 
semaphores. If that is done then one can indeed do the callouts outside of 
atomic contexts.

> Can it be done? I don't know. But I do know that I'm unlikely to accept a 
> noticeable slowdown in some very core code for a case that affects about 
> 0.1% of the population. In other words, I think you *have* to do it.

With larger number of processor semaphores make a lot of sense since the 
holdoff times on spinlocks will increase. If we go to sleep then the 
processor can do something useful instead of hogging a cacheline.

A rw lock there can also increase concurrency during reclaim espcially if 
the anon_vma chains and the number of address spaces mapping a page is 
high.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

Dor Laor wrote:
> On Wed, 2008-05-14 at 17:49 +0200, Tomasz Chmielewski wrote:
>   
>> Dor Laor schrieb:
>>
>> (...)
>>
>> 
 - PV Windows (network driver)

>>> About 700Mb+-, there is currently extra copy that we need to omit.
>>> Thanks for Anthony, we just have to change the driver.
>>>
>>>   
 - non-PV Windows

>>> What do you mean? Other fully emulated nics like e1000?
>>> It does not perform as pv but depending on the guest it can do up to
>>> 600Mb+-.
>>>   
>> Just generally, how Windows PV drivers help to improve network performance.
>>
>> So, a PV network driver can do about 700Mb/s, and an emulated NIC can do 
>> about 
>> 600 Mb/s, Windows guest to host?
>>
>> That would be about 20% improvement?
>> 

FWIW, virtio-net is much better with my patches applied.  The difference 
between the e1000 and virtio-net is that e1000 consumes almost twice as 
much CPU as virtio-net so in my testing, the performance improvement 
with virtio-net is about 2x.  We were loosing about 20-30% throughput 
because of the delays in handling incoming packets.

Regards,

Anthony LIguori

>> 
>
> It's work in progress, doing zero copy in the guest, adding TSO, using
> virtio'd tap will drastically boot performance. There is no reason the
> performance won't match Linux guest.
> Also I don't exactly remember the numbers but the gain in the tx pass is
> grater. 
>
>
>
> -
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Fabrice Bellard

Paul Brook wrote:
>> I suggested it because my original plan for the configuration file was
>> based on this syntax with a strong inspiration from the OpenFirmware
>> device tree. The idea was that the object name ("drive" here) had no
>> hardcoded meaning, except for some predefined object names in order to
>> keep a kind of backward compatibility with the current QEMU options. In
>> order to create a new drive for example, you just have to do:
>>
>> mydrive.class=drive
>> mydrive.if=scsi
>> mydrive.file=abc.img
>>
>> the "class" field is used to select the device model. Then all the other
>> parameters are used to initialize the device model. That way it is
>> possible to keep the compatibility with the existing options and add a
>> provision to instanciate arbitrary new device models, such as:
> 
> I like the idea, but I'm not so keen on the automatic allocation. I generally 
> prefer explicit declaration over implicit things. The latter makes it very 
> easy to not notice when you make a typo.
> 
> It sounds like what you really want is something similar to an OF device 
> tree.  
> So you have something like:
> 
> # pciide0 may be an alias (possibly provided by qemu)
> # e.g. pci0.slot1.func1.ide
> alias hda ide0.primary.master
> 
> hda.type=disk
> hda.file=foo.img
> 
> You can then define some form of magic aliases that select the next unused 
> device. e.g.
> 
> alias mydrive $next_ide_disk
> 
> IMHO This provides the flexibility and structure that Fabrice is talking 
> about, and with suitable aliases can be made to look a lot like the existing 
> options.

Right. It is my intent too to allow aliases to keep the same "familiar" 
names as the command line.

Moreover the tree you suggest is necessary in order to derive the device 
instanciation order. In my idea, the tree has no relation with the 
actual device connections which are specified by explicit fields such as 
slots, functions, interface index, disk indexes or anything else.

An interesting shortcut can be to automatically define a field "index" 
if the device name terminates with a number (if I remember correctly 
OpenFirmware does something like this).

The initialization phase would consist in traversing the tree 
recursively and by instanciating a device for all nodes containing a 
"class" (or "type" if you prefer) field. The parents would be 
instanciated before the children to ensure a coherent initialization order.

Regarding the syntax, quoted strings must be supported of course. I 
don't think there is a great complexity in that :-) A cpp like 
preprocessing can be added, but it can be done later.

> This may require some internal restructuring to allow the machine 
> descriptions 
> to feed into the user config file.

Hopefully it is not necessary to fully implement the proposal now. But 
ultimately, each QEMU device would have to register its class name and 
an instanciation function. The machine descriptions would have to 
predefine some object names so that the user can modify parameters.

Regards,

Fabrice.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Linus Torvalds

On Wed, 14 May 2008, Robin Holt wrote:
> 
> Would it be acceptable to always put a sleepable stall in even if the 
> code path did not require the pages be unwritable prior to continuing?  
> If we did that, I would be freed from having a pool of invalidate 
> threads ready for XPMEM to use for that work. Maybe there is a better 
> way, but the sleeping requirement we would have on the threads make most 
> options seem unworkable.

I'm not understanding the question. If you can do you management outside 
of the spinlocks, then you can obviously do whatever you want, including 
sleping. It's changing the existing spinlocks to be sleepable that is not 
acceptable, because it's such a performance problem.

Linus

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

2008-05-14 Thread Jerone Young

On Wed, 2008-05-14 at 17:28 +0200, Jan Kiszka wrote:
> Jerone Young wrote:
> > On Mon, 2008-05-12 at 13:34 +0200, Jan Kiszka wrote:
> >> Hi,
> >>
> >> before going wild with my idea, I would like to collect some comments on
> >> this approach:
> >>
> >> While doing first kernel debugging with my debug register patches for
> >> kvm, I quickly ran into the 4-breakpoints-only limitation that comes
> >> from the fact that we blindly map software to hardware breakpoints.
> >> Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
> >> in the generic interface is not fair to arch that may support more.
> >> Moreover, we do not support watchpoints although this would easily be
> >> feasible. But if we supported watchpoints (via debug registers on x86),
> >> we would need the break out of the 4 slots limitations even earlier. In
> >> short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
> >> interface is required.
> > So embedded power is also limited to 4 hardware registers for break
> > points. But there are 2 sepreate registers fro watch points. The reason
> > to use the registers is the hardware does the work for you and (at least
> > on Power) will throw an exception or trap. Then you deal with it.
> > 
> > But you still face the fact that you can only have a small number of
> > breakpoints & watch points. Also you cannot use gdb in the guest at the
> > sametime while using the gdb stub on the guest itself (as there is only
> > one set of registers).
> 
> So gdb on power relies only on those few hw-breakpoints? With x86 you
> can perfectly run gdb (with soft BPs) in parallel with the gdbstub
> (currently based on hw-BPs, but the same would be true for soft-BPs
> inserted by the gdbstub).
> 
> > 
> > 
> >> Why do we set breakpoints in the kernel? Why not simply catching all
> >> debug traps, inserting software breakpoint ops into the guest code, and
> >> handling all this stuff as normal debuggers do? And the hardware
> >> breakpoints should just be pushed through the kernel interface like
> >> ptrace does.
> > 
> > See above...But the cpu basically does the work for you. So you don't
> > have to try and go through and first insert a trap into the code in
> > memory. But then you have to remember the code that you replaced with
> > the trap and execute it after you handle the trap. This can get a little
> > hairy. 
> 
> I cannot imaging that this is so hairy. It is basically daily (x86-)
> debugger business. Maybe we need to handle it differently if other
> arches prefer their own way. But for x86 I don't see a need to restrict
> our self to use hw-BPs _only_.
> 
> > 
> > Currently I'm actually implementing breakpoint support now in Power. But
> > you do have to create some mappings to handle traps and see if you put
> > the trap there, and execute the code you replaced. Also what if the
> > breakpoint is removed. Then you have to go back through and actually
> > replace the trap code. Doesn't sound hard, but I'm not sure of all the
> > pitfalls.
> 
> Again, this /should/ not be different from what gdb does to applications
> or kgdb does to the kernel. (Looks like I need to get my feet wet soon. :) )
> 
> > 
> >> The new KVM_DEBUG_GUEST interface I currently have in mind would look
> >> like this:
> >>
> >> #define KVM_DBGGUEST_ENABLE0x01
> >> #define KVM_DBGGUEST_SINGLESTEP0x02
> >>
> >> struct kvm_debug_guest {
> >>__u32 control;
> >>struct kvm_debug_guest_arch arch;
> >> }
> > 
> > 
> >> Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
> >> userspace first, which can then decide to handle or re-inject them.
> >> KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
> >> would look like this:
> >>
> >> struct kvm_debug_guest_arch {
> >>__u32 use_hw_breakpoints;
> >>__u64 debugreg[8];
> >> }
> >>
> >> If use_hw_breakpoints is non-zero, KVM would completely overwrite the
> >> guest's debug registers with the content of debugreg, giving full
> >> control of this feature to the host-side debugger (faking the content of
> >> debug registers, effectively disabling them for the guest - as we now do
> >> all the time).
> > 
> > Hmmm...so today at least the gdbstub in qemu does not inject traps and
> > track code that it trapped (I could be mistaken). This whould all need
> > to be implemented as well.
> 
> gdbstub inserts "virtual" traps today, ie. a call from the translated
> guest code to a helper which signals the breakpoint to the stub. And I
> don't want to change this. I want to add the BP injection/removal to
> qemu-kvm as it already takes over breakpoint (and soon also watchpoint)
> maintenance from qemu.
> 
> However, would the proposed interface for KVM_DEBUG_GUEST (with an
> appropriate kvm_debug_guest_arch for power) restrict your plans in any way?

I think you should go ahead and go for it. I will be required to make
changes around it for the use of hardware breakpoints if it goes in. But
ho

[kvm-devel] [PATCH] Fix hw/acpi.c build w/ DEBUG enabled

2008-05-14 Thread Alex Williamson

Trivial build warning/fixes when the local DEBUG define is enabled.

Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
--

diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index c4419c4..c305702 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -586,7 +586,7 @@ static uint32_t gpe_readb(void *opaque, uint32_t addr)
 }
 
 #if defined(DEBUG)
-printf("gpe read %lx == %lx\n", addr, val);
+printf("gpe read %x == %x\n", addr, val);
 #endif
 return val;
 }
@@ -619,7 +619,7 @@ static void gpe_writeb(void *opaque, uint32_t addr, 
uint32_t val)
}
 
 #if defined(DEBUG)
-printf("gpe write %lx <== %d\n", addr, val);
+printf("gpe write %x <== %d\n", addr, val);
 #endif
 }
 
@@ -639,7 +639,7 @@ static uint32_t pcihotplug_read(void *opaque, uint32_t addr)
 }
 
 #if defined(DEBUG)
-printf("pcihotplug read %lx == %lx\n", addr, val);
+printf("pcihotplug read %x == %x\n", addr, val);
 #endif
 return val;
 }
@@ -657,14 +657,14 @@ static void pcihotplug_write(void *opaque, uint32_t addr, 
uint32_t val)
}
 
 #if defined(DEBUG)
-printf("pcihotplug write %lx <== %d\n", addr, val);
+printf("pcihotplug write %x <== %d\n", addr, val);
 #endif
 }
 
 static uint32_t pciej_read(void *opaque, uint32_t addr)
 {
 #if defined(DEBUG)
-printf("pciej read %lx == %lx\n", addr, val);
+printf("pciej read %x\n", addr);
 #endif
 return 0;
 }
@@ -676,7 +676,7 @@ static void pciej_write(void *opaque, uint32_t addr, 
uint32_t val)
 device_hot_remove_success(0, slot);
 
 #if defined(DEBUG)
-printf("pciej write %lx <== %d\n", addr, val);
+printf("pciej write %x <== %d\n", addr, val);
 #endif
 }
 



-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

On Wed, 2008-05-14 at 17:49 +0200, Tomasz Chmielewski wrote:
> Dor Laor schrieb:
> 
> (...)
> 
> >> - PV Windows (network driver)
> > 
> > About 700Mb+-, there is currently extra copy that we need to omit.
> > Thanks for Anthony, we just have to change the driver.
> > 
> >> - non-PV Windows
> > 
> > What do you mean? Other fully emulated nics like e1000?
> > It does not perform as pv but depending on the guest it can do up to
> > 600Mb+-.
> 
> Just generally, how Windows PV drivers help to improve network performance.
> 
> So, a PV network driver can do about 700Mb/s, and an emulated NIC can do 
> about 
> 600 Mb/s, Windows guest to host?
> 
> That would be about 20% improvement?
> 
> 

It's work in progress, doing zero copy in the guest, adding TSO, using
virtio'd tap will drastically boot performance. There is no reason the
performance won't match Linux guest.
Also I don't exactly remember the numbers but the gain in the tx pass is
grater. 

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Robin Holt

On Wed, May 14, 2008 at 08:18:21AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 14 May 2008, Robin Holt wrote:
> >
> > Are you suggesting the sending side would not need to sleep or the
> > receiving side?
>
> One thing to realize is that most of the time (read: pretty much *always*)
> when we have the problem of wanting to sleep inside a spinlock, the
> solution is actually to just move the sleeping to outside the lock, and
> then have something else that serializes things.
>
> That way, the core code (protected by the spinlock, and in all the hot
> paths) doesn't sleep, but the special case code (that wants to sleep) can
> have some other model of serialization that allows sleeping, and that
> includes as a small part the spinlocked region.
>
> I do not know how XPMEM actually works, or how you use it, but it
> seriously sounds like that is how things *should* work. And yes, that
> probably means that the mmu-notifiers as they are now are simply not
> workable: they'd need to be moved up so that they are inside the mmap
> semaphore but not the spinlocks.

We are in the process of attempting this now.  Unfortunately for SGI,
Christoph is on vacation right now so we have been trying to work it
internally.

We are looking through two possible methods, one we add a callout to the
tlb flush paths for both the mmu_gather and flush_tlb_page locations.
The other we place a specific callout seperate from the gather callouts
in the paths we are concerned with.  We will look at both more carefully
before posting.

In either implementation, not all call paths would require the stall
to ensure data integrity.  Would it be acceptable to always put a
sleepable stall in even if the code path did not require the pages be
unwritable prior to continuing?  If we did that, I would be freed from
having a pool of invalidate threads ready for XPMEM to use for that work.
Maybe there is a better way, but the sleeping requirement we would have
on the threads make most options seem unworkable.

Thanks,
Robin

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Kelly French

On Wed, 14 May 2008, Johannes Schindelin wrote:

> Hi,
>
> On Wed, 14 May 2008, Javier Guerra wrote:
>
>> On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
>> <[EMAIL PROTECTED]> wrote:
>>>  On Wed, 14 May 2008, Javier Guerra wrote:
>>> > What about Lua?  (http://www.lua.org)
>>> >
>>> > it started up as a configuration language, and evolved into a full
>>> > programming language, while remaining _very_ light (less than 200K
>>> > with all libraries), and wonderfully easy to embed into C programs.
>>>
>>>  Okay, so much for the upsides.  Now for the downsides: a language that
>>>  nearly nobody knows, for something that is not meant to be executed (think
>>>  security implications).
>>
>> when embedded, you get to choose what libraries are available. there
>> are several examples of fairly secure settings.
>
> Why artificially make it complicated, and then have to take care of such
> issues?
>
> That's like an ex-colleague of mine, who absolutely had to rewrite the
> database engine in-RAM, and when the application was too slow over modem
> (leeching in megabytes, where it got bytes from the SQL database before),
> he tried to force Windows Terminal Services, instead of reverting his
> change.
>
> Simplicity is underrated.
>
> Ciao,
> Dscho

Why not just bypass the whole config file idea and just use enviornment 
variables?  No more parsing or dependencies on the language of the day. 
Yes, you wouldn't have the tree format that some people are asking for. 
You'd get all of the power of your favorite shell, plus maybe some 
benefits when migrating a VM to another machine.

-kf

#!/bin/sh

drive_0_file=foo.img
drive_0_if=scsi

drive_1_file=bar.img
drive_1_if=scsi

drive_2_file=wiz.img
drive_2_if=scsi

exec qemu

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

2008-05-14 Thread Tomasz Chmielewski

Dor Laor schrieb:

(...)

>> - PV Windows (network driver)
> 
> About 700Mb+-, there is currently extra copy that we need to omit.
> Thanks for Anthony, we just have to change the driver.
> 
>> - non-PV Windows
> 
> What do you mean? Other fully emulated nics like e1000?
> It does not perform as pv but depending on the guest it can do up to
> 600Mb+-.

Just generally, how Windows PV drivers help to improve network performance.

So, a PV network driver can do about 700Mb/s, and an emulated NIC can do about 
600 Mb/s, Windows guest to host?

That would be about 20% improvement?


-- 
Tomasz Chmielewski
http://wpkg.org


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Javier Guerra

On Wed, May 14, 2008 at 10:37 AM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
>  On Wed, 14 May 2008, Javier Guerra wrote:
>  > when embedded, you get to choose what libraries are available. there
>  > are several examples of fairly secure settings.
>
>  Why artificially make it complicated, and then have to take care of such
>  issues?

i should have said "Lua is secure by default, all libraries are
optional", but it's quickly turning into a bikeshed
(http://www.bikeshed.com)

my own personal preference would be to just stuff the whole command
line parameters into the qcow2 image file.

-- 
Javier

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Johannes Schindelin

Hi,

On Wed, 14 May 2008, Javier Guerra wrote:

> On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
> <[EMAIL PROTECTED]> wrote:
> >  On Wed, 14 May 2008, Javier Guerra wrote:
> >  > What about Lua?  (http://www.lua.org)
> >  >
> >  > it started up as a configuration language, and evolved into a full
> >  > programming language, while remaining _very_ light (less than 200K
> >  > with all libraries), and wonderfully easy to embed into C programs.
> >
> >  Okay, so much for the upsides.  Now for the downsides: a language that
> >  nearly nobody knows, for something that is not meant to be executed (think
> >  security implications).
> 
> when embedded, you get to choose what libraries are available. there
> are several examples of fairly secure settings.

Why artificially make it complicated, and then have to take care of such 
issues?

That's like an ex-colleague of mine, who absolutely had to rewrite the 
database engine in-RAM, and when the application was too slow over modem 
(leeching in megabytes, where it got bytes from the SQL database before), 
he tried to force Windows Terminal Services, instead of reverting his 
change.

Simplicity is underrated.

Ciao,
Dscho

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Javier Guerra

On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
>  On Wed, 14 May 2008, Javier Guerra wrote:
>  > What about Lua?  (http://www.lua.org)
>  >
>  > it started up as a configuration language, and evolved into a full
>  > programming language, while remaining _very_ light (less than 200K
>  > with all libraries), and wonderfully easy to embed into C programs.
>
>  Okay, so much for the upsides.  Now for the downsides: a language that
>  nearly nobody knows, for something that is not meant to be executed (think
>  security implications).

when embedded, you get to choose what libraries are available. there
are several examples of fairly secure settings.

personally, i find shell scripts enough for setting up parameters.  a
static config wouldn't bring much advantages.

-- 
Javier

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

2008-05-14 Thread Jan Kiszka

Jerone Young wrote:
> On Mon, 2008-05-12 at 13:34 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> before going wild with my idea, I would like to collect some comments on
>> this approach:
>>
>> While doing first kernel debugging with my debug register patches for
>> kvm, I quickly ran into the 4-breakpoints-only limitation that comes
>> from the fact that we blindly map software to hardware breakpoints.
>> Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
>> in the generic interface is not fair to arch that may support more.
>> Moreover, we do not support watchpoints although this would easily be
>> feasible. But if we supported watchpoints (via debug registers on x86),
>> we would need the break out of the 4 slots limitations even earlier. In
>> short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
>> interface is required.
> So embedded power is also limited to 4 hardware registers for break
> points. But there are 2 sepreate registers fro watch points. The reason
> to use the registers is the hardware does the work for you and (at least
> on Power) will throw an exception or trap. Then you deal with it.
> 
> But you still face the fact that you can only have a small number of
> breakpoints & watch points. Also you cannot use gdb in the guest at the
> sametime while using the gdb stub on the guest itself (as there is only
> one set of registers).

So gdb on power relies only on those few hw-breakpoints? With x86 you
can perfectly run gdb (with soft BPs) in parallel with the gdbstub
(currently based on hw-BPs, but the same would be true for soft-BPs
inserted by the gdbstub).

> 
> 
>> Why do we set breakpoints in the kernel? Why not simply catching all
>> debug traps, inserting software breakpoint ops into the guest code, and
>> handling all this stuff as normal debuggers do? And the hardware
>> breakpoints should just be pushed through the kernel interface like
>> ptrace does.
> 
> See above...But the cpu basically does the work for you. So you don't
> have to try and go through and first insert a trap into the code in
> memory. But then you have to remember the code that you replaced with
> the trap and execute it after you handle the trap. This can get a little
> hairy. 

I cannot imaging that this is so hairy. It is basically daily (x86-)
debugger business. Maybe we need to handle it differently if other
arches prefer their own way. But for x86 I don't see a need to restrict
our self to use hw-BPs _only_.

> 
> Currently I'm actually implementing breakpoint support now in Power. But
> you do have to create some mappings to handle traps and see if you put
> the trap there, and execute the code you replaced. Also what if the
> breakpoint is removed. Then you have to go back through and actually
> replace the trap code. Doesn't sound hard, but I'm not sure of all the
> pitfalls.

Again, this /should/ not be different from what gdb does to applications
or kgdb does to the kernel. (Looks like I need to get my feet wet soon. :) )

> 
>> The new KVM_DEBUG_GUEST interface I currently have in mind would look
>> like this:
>>
>> #define KVM_DBGGUEST_ENABLE  0x01
>> #define KVM_DBGGUEST_SINGLESTEP  0x02
>>
>> struct kvm_debug_guest {
>>  __u32 control;
>>  struct kvm_debug_guest_arch arch;
>> }
> 
> 
>> Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
>> userspace first, which can then decide to handle or re-inject them.
>> KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
>> would look like this:
>>
>> struct kvm_debug_guest_arch {
>>  __u32 use_hw_breakpoints;
>>  __u64 debugreg[8];
>> }
>>
>> If use_hw_breakpoints is non-zero, KVM would completely overwrite the
>> guest's debug registers with the content of debugreg, giving full
>> control of this feature to the host-side debugger (faking the content of
>> debug registers, effectively disabling them for the guest - as we now do
>> all the time).
> 
> Hmmm...so today at least the gdbstub in qemu does not inject traps and
> track code that it trapped (I could be mistaken). This whould all need
> to be implemented as well.

gdbstub inserts "virtual" traps today, ie. a call from the translated
guest code to a helper which signals the breakpoint to the stub. And I
don't want to change this. I want to add the BP injection/removal to
qemu-kvm as it already takes over breakpoint (and soon also watchpoint)
maintenance from qemu.

However, would the proposed interface for KVM_DEBUG_GUEST (with an
appropriate kvm_debug_guest_arch for power) restrict your plans in any way?

Jan



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https:/

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Daniel P. Berrange

On Wed, May 14, 2008 at 09:45:02AM -0500, Javier Guerra wrote:
> What about Lua?  (http://www.lua.org)
> 
> it started up as a configuration language, and evolved into a full
> programming language, while remaining _very_ light (less than 200K
> with all libraries), and wonderfully easy to embed into C programs.

Config files are data, not programs. Xen made this mistake originally
too just having python config files that were eval'd, but thankfully
they've defined a sensible data format now.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Linus Torvalds

On Wed, 14 May 2008, Robin Holt wrote:
> 
> Are you suggesting the sending side would not need to sleep or the
> receiving side?

One thing to realize is that most of the time (read: pretty much *always*) 
when we have the problem of wanting to sleep inside a spinlock, the 
solution is actually to just move the sleeping to outside the lock, and 
then have something else that serializes things.

That way, the core code (protected by the spinlock, and in all the hot 
paths) doesn't sleep, but the special case code (that wants to sleep) can 
have some other model of serialization that allows sleeping, and that 
includes as a small part the spinlocked region.

I do not know how XPMEM actually works, or how you use it, but it 
seriously sounds like that is how things *should* work. And yes, that 
probably means that the mmu-notifiers as they are now are simply not 
workable: they'd need to be moved up so that they are inside the mmap 
semaphore but not the spinlocks.

Can it be done? I don't know. But I do know that I'm unlikely to accept a 
noticeable slowdown in some very core code for a case that affects about 
0.1% of the population. In other words, I think you *have* to do it.

Linus

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Paul Brook

On Wednesday 14 May 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> >> the "class" field is used to select the device model. Then all the other
> >> parameters are used to initialize the device model. That way it is
> >> possible to keep the compatibility with the existing options and add a
> >> provision to instanciate arbitrary new device models, such as:
> >
> > I like the idea, but I'm not so keen on the automatic allocation. I
> > generally prefer explicit declaration over implicit things. The latter
> > makes it very easy to not notice when you make a typo.
> >
> > It sounds like what you really want is something similar to an OF device
> > tree. So you have something like:
> >
> > # pciide0 may be an alias (possibly provided by qemu)
> > # e.g. pci0.slot1.func1.ide
> > alias hda ide0.primary.master
>
> What I don't like about the ide0.primary.master syntax is that there
> isn't enough structure.  I would prefer:
>
> alias hda ide,bus=0,primary,master
>
> If you combine this with your magic variable idea, you could also do:
>
> alias hda ide,bus=0,unit=$next
>
> But you could also just fold that into Fabrice's syntax (which I prefer):

What I dislike about this is that it's a flat format, where you identify 
things by setting some combination of attributes. I really like the idea of 
having a tree structure.

Paul

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

Dor Laor wrote:
> On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
>   
> Please don't jump over me but I think it is worth mentioning OVF, at
> least for to know what's you opinions.
>
> Open Virtualization Format -
> http://www.vmware.com/appliances/learn/ovf.html
>
> It's xml based, supported by all major hypervisors, so qemu/kvm/xen
> users might eventually use a product that support OVF.
>   

xml is a non-starter for QEMU.  We go out of our way to be portable.  
Having an XML dependency that could be satisfied on Windows and Linux 
would probably require more code to support the dependency than all of 
QEMU itself.

Regards,

Anthony Liguori

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST

2008-05-14 Thread Jerone Young

On Mon, 2008-05-12 at 13:34 +0200, Jan Kiszka wrote:
> Hi,
> 
> before going wild with my idea, I would like to collect some comments on
> this approach:
> 
> While doing first kernel debugging with my debug register patches for
> kvm, I quickly ran into the 4-breakpoints-only limitation that comes
> from the fact that we blindly map software to hardware breakpoints.
> Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
> in the generic interface is not fair to arch that may support more.
> Moreover, we do not support watchpoints although this would easily be
> feasible. But if we supported watchpoints (via debug registers on x86),
> we would need the break out of the 4 slots limitations even earlier. In
> short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
> interface is required.
So embedded power is also limited to 4 hardware registers for break
points. But there are 2 sepreate registers fro watch points. The reason
to use the registers is the hardware does the work for you and (at least
on Power) will throw an exception or trap. Then you deal with it.

But you still face the fact that you can only have a small number of
breakpoints & watch points. Also you cannot use gdb in the guest at the
sametime while using the gdb stub on the guest itself (as there is only
one set of registers).

> 
> Why do we set breakpoints in the kernel? Why not simply catching all
> debug traps, inserting software breakpoint ops into the guest code, and
> handling all this stuff as normal debuggers do? And the hardware
> breakpoints should just be pushed through the kernel interface like
> ptrace does.

See above...But the cpu basically does the work for you. So you don't
have to try and go through and first insert a trap into the code in
memory. But then you have to remember the code that you replaced with
the trap and execute it after you handle the trap. This can get a little
hairy. 

Currently I'm actually implementing breakpoint support now in Power. But
you do have to create some mappings to handle traps and see if you put
the trap there, and execute the code you replaced. Also what if the
breakpoint is removed. Then you have to go back through and actually
replace the trap code. Doesn't sound hard, but I'm not sure of all the
pitfalls.

> 
> The new KVM_DEBUG_GUEST interface I currently have in mind would look
> like this:
> 
> #define KVM_DBGGUEST_ENABLE   0x01
> #define KVM_DBGGUEST_SINGLESTEP   0x02
> 
> struct kvm_debug_guest {
>   __u32 control;
>   struct kvm_debug_guest_arch arch;
> }

> Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
> userspace first, which can then decide to handle or re-inject them.
> KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
> would look like this:
> 
> struct kvm_debug_guest_arch {
>   __u32 use_hw_breakpoints;
>   __u64 debugreg[8];
> }
> 
> If use_hw_breakpoints is non-zero, KVM would completely overwrite the
> guest's debug registers with the content of debugreg, giving full
> control of this feature to the host-side debugger (faking the content of
> debug registers, effectively disabling them for the guest - as we now do
> all the time).

Hmmm...so today at least the gdbstub in qemu does not inject traps and
track code that it trapped (I could be mistaken). This whould all need
to be implemented as well.

> 
> Questions:
> - Does anyone see traps and pitfalls in this approach?
> - May I replace the existing interface with this one, or am I overseeing
>   some use case that already worked with the current code so that ABI
>   compatibility is required (most debug stuff should have been simply
>   broken so far, also due to bugs in userland)?

> 
> Jan
> 
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ___ kvm-devel mailing list 
> kvm-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/kvm-devel

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Johannes Schindelin

Hi,

On Wed, 14 May 2008, Javier Guerra wrote:

> What about Lua?  (http://www.lua.org)
> 
> it started up as a configuration language, and evolved into a full
> programming language, while remaining _very_ light (less than 200K
> with all libraries), and wonderfully easy to embed into C programs.

Okay, so much for the upsides.  Now for the downsides: a language that 
nearly nobody knows, for something that is not meant to be executed (think 
security implications).

Hth,
Dscho

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

On Wed, 2008-05-14 at 15:52 +0200, Tomasz Chmielewski wrote:
> Avi Kivity wrote:
> 
> > This is the second release of network drivers for Windows guests running
> > on a kvm host.  The drivers are intended for Windows 2000 and Windows 
> > XP, and Windows 2003.  Both x86 and x64 variants are provided.  kvm-61 
> > or later is needed in the host.  At the moment only binaries are available.
> 
> Hi,
> 
> This is great news!
> 
> Do you have any performance numbers for networking to see how it compares to 
> the 
> real hardware?
> 
> - Linux host (or: real Windows running on that host)

For host you can measure yourself but for Linux guest (to host) it
currently do about 1G, using TSO (work in progress) it can do 2.5G, and
there is also work in progress to make the kernel know virtio through
the tap interface which will further boot performance.

> - PV Windows (network driver)

About 700Mb+-, there is currently extra copy that we need to omit.
Thanks for Anthony, we just have to change the driver.

> - non-PV Windows

What do you mean? Other fully emulated nics like e1000?
It does not perform as pv but depending on the guest it can do up to
600Mb+-.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Johannes Schindelin

Hi,

On Wed, 14 May 2008, andrzej zaborowski wrote:

> What I'd love, though, but expect others will consider bloat, is that
> files are passed through cpp before interpreting.

This will add a dependency to a developer's tool on an application that 
has not much to do with development for most users.

Ciao,
Dscho

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

Paul Brook wrote:
>> the "class" field is used to select the device model. Then all the other
>> parameters are used to initialize the device model. That way it is
>> possible to keep the compatibility with the existing options and add a
>> provision to instanciate arbitrary new device models, such as:
>> 
>
> I like the idea, but I'm not so keen on the automatic allocation. I generally 
> prefer explicit declaration over implicit things. The latter makes it very 
> easy to not notice when you make a typo.
>
> It sounds like what you really want is something similar to an OF device 
> tree.  
> So you have something like:
>
> # pciide0 may be an alias (possibly provided by qemu)
> # e.g. pci0.slot1.func1.ide
> alias hda ide0.primary.master
>   

What I don't like about the ide0.primary.master syntax is that there 
isn't enough structure.  I would prefer:

alias hda ide,bus=0,primary,master

If you combine this with your magic variable idea, you could also do:

alias hda ide,bus=0,unit=$next

But you could also just fold that into Fabrice's syntax (which I prefer):

hda.class = ide,bus=0,unit=$next
hda.type = disk
hda.file = foo.img

If you then default bus, and unit, you can just write:

hda.class = ide
hda.type = disk
hda.file = foo.img

And better yet, you could even allow for something like:

hda.class = ide
hda.bus = 0
hda.unit = 0
hda.type = disk
hda.file = foo.img

So I really actually prefer Fabrice's syntax because there is much more 
structure.  I think it's a good idea to allow .class to contain multiple 
properties and to basically establish an alias.  This way, you could 
predefine a bunch of aliases for today's parameters like hda, hdb, etc.

> hda.type=disk
> hda.file=foo.img
>
> You can then define some form of magic aliases that select the next unused 
> device. e.g.
>
> alias mydrive $next_ide_disk
>
> IMHO This provides the flexibility and structure that Fabrice is talking 
> about, and with suitable aliases can be made to look a lot like the existing 
> options.
>
> This may require some internal restructuring to allow the machine 
> descriptions 
> to feed into the user config file.
>   

I think if we choose a syntax we like, we can start using that pretty 
easily.  We'll have to start adjusting option names keeping them only 
valid on the command line (for things like -m).  However, I think it 
would grow pretty well into a machine description mechanism.

Regards,

Anthony Liguori

> Thoughts?
>
> Paul
>   

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Daniel P. Berrange

On Wed, May 14, 2008 at 05:52:56PM +0300, Dor Laor wrote:
> 
> On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
> > Daniel P. Berrange wrote:
> > > That's very nearly YAML format[1], which is attractive because parsers
> > > are available in every major programming language, and it is still
> > > pretty human friendly.
> > >
> > > So my preference would be to go with the last option and make sure
> > > it really is YAML compliant so people can use standard tools for 
> > > generating and parsing the format.
> > >   
> > 
> > Using a standard format has the added benefit that things like quoting 
> > are taken care of.
> > 
> > Filenames with leading and trailing spaces, anyone?  Embedded control 
> > characters?
> > 
> 
> Please don't jump over me but I think it is worth mentioning OVF, at
> least for to know what's you opinions.

OVF is insanely overcomplicated. It is also addressing a different problem
space, that of virtual machine applinance interchange / distribution. And 
it is a disgusting format for users to deal with. 

> Open Virtualization Format -
> http://www.vmware.com/appliances/learn/ovf.html
> 
> It's xml based, supported by all major hypervisors, so qemu/kvm/xen
> users might eventually use a product that support OVF.
> Since its a new format it is open for changes and has lots of
> flexibility. As a start we don't have to be completely compatible with
> it.

It is a 'open' format defined in secret invitation only cabal by
a bunch of proprietry software vendors. No thanks.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

Avi Kivity wrote:
> Daniel P. Berrange wrote:
>> That's very nearly YAML format[1], which is attractive because parsers
>> are available in every major programming language, and it is still
>> pretty human friendly.
>>
>> So my preference would be to go with the last option and make sure
>> it really is YAML compliant so people can use standard tools for 
>> generating and parsing the format.
>>   
>
> Using a standard format has the added benefit that things like quoting 
> are taken care of.
>
> Filenames with leading and trailing spaces, anyone?  Embedded control 
> characters?

YAML is a bad choice though.  It's purpose is to model data structures 
of embedded languages (similar to JSON).  The syntax would get out of 
hand quickly because what we've been talking about so far would be 
modeled as an association whereas semantically, we want it to be a 
sequence.  To make it a sequence, we would have to prefix every line 
with '-'.

I'm not against following some sort of standard (or even best 
practice).  I just don't like YAML.

Regards,

Anthony Liguori

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> > That's very nearly YAML format[1], which is attractive because parsers
> > are available in every major programming language, and it is still
> > pretty human friendly.
> >
> > So my preference would be to go with the last option and make sure
> > it really is YAML compliant so people can use standard tools for 
> > generating and parsing the format.
> >   
> 
> Using a standard format has the added benefit that things like quoting 
> are taken care of.
> 
> Filenames with leading and trailing spaces, anyone?  Embedded control 
> characters?
> 

Please don't jump over me but I think it is worth mentioning OVF, at
least for to know what's you opinions.

Open Virtualization Format -
http://www.vmware.com/appliances/learn/ovf.html

It's xml based, supported by all major hypervisors, so qemu/kvm/xen
users might eventually use a product that support OVF.
Since its a new format it is open for changes and has lots of
flexibility. As a start we don't have to be completely compatible with
it.
It supports definition cpus, startup options, various devices (nic, ide,
scsi,...). For example:
"

  Ethernet adapter on "VM Network"
  4000
  10
  VmxNet, E1000
  true
  VM Network

  SCSI Controller 0
  1000
  6
  LsiLogic, BusLogic

  Harddisk 1
  22001
  17
  disk/vmdisk1
  1000

"

One can claim to xml is bad and ovf is outside of the scope and if one
wants ovf, mgmt tool can wrap it around qemu. Nevertheless why doubling
the effort? Qemu can reuse it and its mgmt tools.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Javier Guerra

What about Lua?  (http://www.lua.org)

it started up as a configuration language, and evolved into a full
programming language, while remaining _very_ light (less than 200K
with all libraries), and wonderfully easy to embed into C programs.

it lets you write things like:

drives = {
  hda = {if='scsi', file='hda.img'},
  hdb = {if='ide', file='hdb.img'},
}
mem = 512*MB

or, equivalently:

drives={}
drives.hda={}
drives.hda.if='scsi'
drives.hda.file='hda.img'
drives.hdb={}
drives.hdb.if='ide'
drives.hdb.file='hdb.img'
mem=512*MB

or, if you want:

drive {if='scsi', file='hda.img'}
drive {if='ide', file='hdb.img'}
mem(512*MB)

or even:

for img in lfs.dir("*.img") do
   drive{if='scsi', file=img}
end



-- 
Javier

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

Daniel P. Berrange wrote:
> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language, and it is still
> pretty human friendly.
>
> So my preference would be to go with the last option and make sure
> it really is YAML compliant so people can use standard tools for 
> generating and parsing the format.
>   

Using a standard format has the added benefit that things like quoting 
are taken care of.

Filenames with leading and trailing spaces, anyone?  Embedded control 
characters?

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread andrzej zaborowski

On 14/05/2008, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Anthony Liguori wrote:
>
> > I think this is pretty useful as-is.  I think it also gives us a
> reasonable
> > way to move forward that will keep everyone pretty happy.
> >
> > Here's a short example:
> >
> > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
> >
> > Would become `foo.qemu':
> >
> >  # Main disk image
> >  hda=/home/anthony/images/linux.img
> >
> >  # Redirect disk writes to a temporary image
> >  snapshot
> >
> >  # Make the graphical display available on port 5902
> >  vnc=:2
> >
> > With:
> >
> > qemu-system-x86_64 -config foo.qemu
> >
>
>  One thought I had, is that it would be very nice to break up the -drive
> file=foo.img,if=scsi syntax within the config file.  In general, I'm
> thinking something like:
>
>  [drive]
>  file=foo.img
>  if=scsi
>
>  or:
>
>  drive {
>   file=foo.img
>   if=scsi
>  }

I like this one and it would be nice to be able to replace the equal
sign with whitespace.

What I'd love, though, but expect others will consider bloat, is that
files are passed through cpp before interpreting.  This way the syntax
becomes not (much) less powerful than the current command line
invocation where you get variable expansion for free.  I would hate to
type in some things in as many times as there are instances of a given
hardware.  Consider some disk arrays or the once discussed -pins
switch for initial state of pins or jumpers (some machines have
hundreds of them).
-- 
Please do not print this email unless absolutely necessary. Spread
environmental awareness.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Paul Brook

> I suggested it because my original plan for the configuration file was
> based on this syntax with a strong inspiration from the OpenFirmware
> device tree. The idea was that the object name ("drive" here) had no
> hardcoded meaning, except for some predefined object names in order to
> keep a kind of backward compatibility with the current QEMU options. In
> order to create a new drive for example, you just have to do:
>
> mydrive.class=drive
> mydrive.if=scsi
> mydrive.file=abc.img
>
> the "class" field is used to select the device model. Then all the other
> parameters are used to initialize the device model. That way it is
> possible to keep the compatibility with the existing options and add a
> provision to instanciate arbitrary new device models, such as:

I like the idea, but I'm not so keen on the automatic allocation. I generally 
prefer explicit declaration over implicit things. The latter makes it very 
easy to not notice when you make a typo.

It sounds like what you really want is something similar to an OF device tree.  
So you have something like:

# pciide0 may be an alias (possibly provided by qemu)
# e.g. pci0.slot1.func1.ide
alias hda ide0.primary.master

hda.type=disk
hda.file=foo.img

You can then define some form of magic aliases that select the next unused 
device. e.g.

alias mydrive $next_ide_disk

IMHO This provides the flexibility and structure that Fabrice is talking 
about, and with suitable aliases can be made to look a lot like the existing 
options.

This may require some internal restructuring to allow the machine descriptions 
to feed into the user config file.

Thoughts?

Paul

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

Fabrice Bellard wrote:
> Avi Kivity wrote:
>> Fabrice Bellard wrote:
>>>
>>> I prefer:
>>>
>>> drive.file=foo.img
>>> drive.if=scsi
>>>
>>
>> That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested it because my original plan for the configuration file was 
> based on this syntax with a strong inspiration from the OpenFirmware 
> device tree. The idea was that the object name ("drive" here) had no 
> hardcoded meaning, except for some predefined object names in order to 
> keep a kind of backward compatibility with the current QEMU options. 
> In order to create a new drive for example, you just have to do:
>
> mydrive.class=drive
> mydrive.if=scsi
> mydrive.file=abc.img
>
> the "class" field is used to select the device model. Then all the 
> other parameters are used to initialize the device model. That way it 
> is possible to keep the compatibility with the existing options and 
> add a provision to instanciate arbitrary new device models, such as:

I like this syntax primarily because it provides a means to associate 
arbitrary data with a VM.  It also provides a sane way to keep track of 
which device is which so that the "config" can be updated while the VM 
is running.  I'll update the patch.

Regards,

Anthony Liguori

> mynetworkcard.class="ne2000pci"
> mynetworkcard.bus=1 # pci bus selection
> mynetworkcard.macaddr=00:01:02:03:04:05
> mynetworkcard.vlan=1
>
> I will strongly support configuration file formats having this property.
>
> Regards,
>
> Fabrice.
>


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

2008-05-14 Thread Tomasz Chmielewski

Avi Kivity wrote:

> This is the second release of network drivers for Windows guests running
> on a kvm host.  The drivers are intended for Windows 2000 and Windows 
> XP, and Windows 2003.  Both x86 and x64 variants are provided.  kvm-61 
> or later is needed in the host.  At the moment only binaries are available.

Hi,

This is great news!

Do you have any performance numbers for networking to see how it compares to 
the 
real hardware?

- Linux host (or: real Windows running on that host)
- PV Windows (network driver)
- non-PV Windows

-- 
Tomasz Chmielewski
http://wpkg.org

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Daniel P. Berrange

On Wed, May 14, 2008 at 02:26:40PM +0200, Fabrice Bellard wrote:
> Avi Kivity wrote:
> > Fabrice Bellard wrote:
> >>
> >> I prefer:
> >>
> >> drive.file=foo.img
> >> drive.if=scsi
> >>
> > 
> > That doesn't support multiple drives very well.
> 
> Right, I realized it afterwards !
> 
> I suggested it because my original plan for the configuration file was 
> based on this syntax with a strong inspiration from the OpenFirmware 
> device tree. The idea was that the object name ("drive" here) had no 
> hardcoded meaning, except for some predefined object names in order to 
> keep a kind of backward compatibility with the current QEMU options. In 
> order to create a new drive for example, you just have to do:
> 
> mydrive.class=drive
> mydrive.if=scsi
> mydrive.file=abc.img

With this kind of syntax, now tools generating config files need to make
up unique names for each drive. So you'll probably end up with them just
naming things based on the class name + a number appended.

   drive0.class=drive
   drive0.if=scsi
   drive0.file=foo.img

   drive1.class=drive
   drive1.if=scsi
   drive1.file=bar.img

   drive2.class=drive
   ...

Which suggests it'd be better to take your original previous syntax example
and using an explicit numeric component to represent lists of drives, eg

   drive.0.file=foo.img
   drive.0.if=scsi

   drive.1.file=bar.img
   drive.1.if=scsi

   drive.2.file=wiz.img
   drive.2.if=scsi

Thus avoiding the need for adding the 'class' setting at all

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [ kvm-Bugs-1958715 ] kvm-userspace failed to start linux kernel (kernel panic)

2008-05-14 Thread SourceForge.net

Bugs item #1958715, was opened at 2008-05-06 15:13
Message generated for change (Comment added) made by gthouvenin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958715&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: libkvm
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: gth (gthouvenin)
Assigned to: Nobody/Anonymous (nobody)
Summary: kvm-userspace failed to start linux kernel (kernel panic)

Initial Comment:
CPU: Intel Xeon (eight cpu)
KVM: kvm-68-2049-g6307419
Host kernel arch: x86_64
Guest: Ubuntu-8.04-desktop-i386 livecd
QEMU Command: qemu-system-x86_64 -cdrom 
/images_iso/ubuntu-8.04-desktop-i386.iso -boot d -m 256
KVM-USERSPACE: kvm-66-147-gc33833a

The problem doesn't go away if I'm using the -no-kvm-irqchip or -no-kvm-pit 
switch.

When I use the commit bae043c (kvm-userspace) I can start the liveCD but the 
next commit c33833a produces a kernel panic. I see the screen with different 
choice of installation but when I choose to install linux I get a kernel panic 
(see file attach).

It also happens with an old fedora that is installed on a qcow2 file. 

Regards,
Guillaume

--

>Comment By: gth (gthouvenin)
Date: 2008-05-14 15:18

Message:
Logged In: YES 
user_id=1938803
Originator: YES

The bug disappeared with commit 9ac293621d3c467f. I don't know if it's
this commit that solves the problem (probably not) but it's working now.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958715&group_id=180599

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Jack Steiner

On Tue, May 13, 2008 at 10:43:59PM -0700, Benjamin Herrenschmidt wrote:
> On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> > ea.
> > 
> > I don't see why you're bending over so far backwards to accommodate
> > this GRU thing that we don't even have numbers for and could actually
> > potentially be batched up in other ways (eg. using mmu_gather or
> > mmu_gather-like idea).
> 
> I agree, we're better off generalizing the mmu_gather batching
> instead...

Unfortunately, we are at least several months away from being able to
provide numbers to justify batching - assuming it is really needed.  We need
large systems running real user workloads. I wish we had that available
right now, but we don't.

It also depends on what you mean by "no batching". If you mean that the
notifier gets called for each pte that is removed from the page table, then
the overhead is clearly very high for some operations. Consider the unmap of
a very large object. A TLB flush per page will be too costly.

However, something based on the mmu_gather seems like it should provide
exactly what is needed to do efficient flushing of the TLB. The GRU does not
require that it be called in a sleepable context. As long as the notifier
callout provides the mmu_gather and vaddr range being flushed, the GRU can
do the efficiently do the rest.

> 
> I had some never-finished patches to use the mmu_gather for pretty much
> everything except single page faults, tho various subtle differences
> between archs and lack of time caused me to let them take the dust and
> not finish them...
> 
> I can try to dig some of that out when I'm back from my current travel,
> though it's probably worth re-doing from scratch now.
> 
> Ben.
> 

-- jack

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 1/4] Add method to send fragmented packets

Anthony Liguori wrote:
> We need to be able to send fragmented packets in KVM to avoid an extra copy
> in the TX path.  This patch adds a qemu_sendv_packet() function to send
> fragemented packets.  It also provides backwards compatibility for old clients
> that don't support the new interface.
>   

Applied all, thanks.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] s390 kvm_virtio.c build error

Christian Borntraeger wrote:
> as this patch is now in your queue, can you push this change
> ---
> commit eee4646877b748afbfd34d8dbe6ea9b454a65745
> Author: Heiko Carstens <[EMAIL PROTECTED]>
> Date:   Tue May 6 17:38:30 2008 +0300
>
> s390: KVM guest: fix compile error
> ---
>
> soon to Linus? kvm still does not compile on s390.
>   

Certainly; I plan to push my queue in a day or two.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.

Zhang, Xiantao wrote:
> Hi, Avi
>   This patch should be a fix for v2.6.26. Otherwise, guests can't
> enable networking. 
> Xiantao
>
> Subject: [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.
>
> Guest's firmware needs the viosapic with 48 pins for ia64 guests.
>   

Applied and queued, thanks.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Fabrice Bellard

Avi Kivity wrote:
> Fabrice Bellard wrote:
>>
>> I prefer:
>>
>> drive.file=foo.img
>> drive.if=scsi
>>
> 
> That doesn't support multiple drives very well.

Right, I realized it afterwards !

I suggested it because my original plan for the configuration file was 
based on this syntax with a strong inspiration from the OpenFirmware 
device tree. The idea was that the object name ("drive" here) had no 
hardcoded meaning, except for some predefined object names in order to 
keep a kind of backward compatibility with the current QEMU options. In 
order to create a new drive for example, you just have to do:

mydrive.class=drive
mydrive.if=scsi
mydrive.file=abc.img

the "class" field is used to select the device model. Then all the other 
parameters are used to initialize the device model. That way it is 
possible to keep the compatibility with the existing options and add a 
provision to instanciate arbitrary new device models, such as:

mynetworkcard.class="ne2000pci"
mynetworkcard.bus=1 # pci bus selection
mynetworkcard.macaddr=00:01:02:03:04:05
mynetworkcard.vlan=1

I will strongly support configuration file formats having this property.

Regards,

Fabrice.

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.

2008-05-14 Thread Zhang, Xiantao

Hi, Avi
This patch should be a fix for v2.6.26. Otherwise, guests can't
enable networking. 
Xiantao

>From df3a290e438b3079edb3627f2fea3e1fdd85b5f2 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 14 May 2008 19:44:57 +0800
Subject: [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.

Guest's firmware needs the viosapic with 48 pins for ia64 guests.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
 include/asm-ia64/kvm.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h
index eb2d355..f9db48e 100644
--- a/include/asm-ia64/kvm.h
+++ b/include/asm-ia64/kvm.h
@@ -29,7 +29,7 @@
 /* Architectural interrupt line count. */
 #define KVM_NR_INTERRUPTS 256

-#define KVM_IOAPIC_NUM_PINS  24
+#define KVM_IOAPIC_NUM_PINS  48

 struct kvm_ioapic_state {
__u64 base_address;
-- 
1.5.2

0002-KVM-KVM-IA64-Set-KVM_IOAPIC_NUM_PINS-to-48.patch
Description: 0002-KVM-KVM-IA64-Set-KVM_IOAPIC_NUM_PINS-to-48.patch
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 08 of 11] anon-vma-rwsem

2008-05-14 Thread Robin Holt

On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
> On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote:
> > On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> > > On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > > > In order to invalidate the remote page table entries, we need to message
> > > > (uses XPC) to the remote side.  The remote side needs to acquire the
> > > > importing process's mmap_sem and call zap_page_range().  Between the
> > > > messaging and the acquiring a sleeping lock, I would argue this will
> > > > require sleeping locks in the path prior to the mmu_notifier 
> > > > invalidate_*
> > > > callouts().
> > > 
> > > Why do you need to take mmap_sem in order to shoot down pagetables of
> > > the process? It would be nice if this can just be done without
> > > sleeping.
> > 
> > We are trying to shoot down page tables of a different process running
> > on a different instance of Linux running on Numa-link connected portions
> > of the same machine.
> 
> Right. You can zap page tables without sleeping, if you're careful. I
> don't know that we quite do that for anonymous pages at the moment, but it
> should be possible with a bit of thought, I believe.
> 
>  
> > The messaging is clearly going to require sleeping.  Are you suggesting
> > we need to rework XPC communications to not require sleeping?  I think
> > that is going to be impossible since the transfer engine requires a
> > sleeping context.
> 
> I guess that you have found a way to perform TLB flushing within coherent
> domains over the numalink interconnect without sleeping. I'm sure it would
> be possible to send similar messages between non coherent domains.

I assume by coherent domains, your are actually talking about system
images.  Our memory coherence domain on the 3700 family is 512 processors
on 128 nodes.  On the 4700 family, it is 16,384 processors on 4096 nodes.
We extend a "Read-Exclusive" mode beyond the coherence domain so any
processor is able to read any cacheline on the system.  We also provide
uncached access for certain types of memory beyond the coherence domain.

For the other partitions, the exporting partition does not know what
virtual address the imported pages are mapped.  The pages are frequently
mapped in a different order by the MPI library to help with MPI collective
operations.

For the exporting side to do those TLB flushes, we would need to replicate
all that importing information back to the exporting side.

Additionally, the hardware that does the TLB flushing is protected
by a spinlock on each system image.  We would need to change that
simple spinlock into a type of hardware lock that would work (on 3700)
outside the processors coherence domain.  The only way to do that is to
use uncached addresses with our Atomic Memory Operations which do the
cmpxchg at the memory controller.  The uncached accesses are an order
of magnitude or more slower.

> So yes, I'd much rather rework such highly specialized system to fit in
> closer with Linux than rework Linux to fit with these machines (and
> apparently slow everyone else down).

But it isn't that we are having a problem adapting to just the hardware.
One of the limiting factors is Linux on the other partition.

> > Additionally, the call to zap_page_range expects to have the mmap_sem
> > held.  I suppose we could use something other than zap_page_range and
> > atomically clear the process page tables.
> 
> zap_page_range does not expect to have mmap_sem held. I think for anon
> pages it is always called with mmap_sem, however try_to_unmap_anon is
> not (although it expects page lock to be held, I think we should be able
> to avoid that).

zap_page_range calls unmap_vmas which walks to vma->next.  Are you saying
that can be walked without grabbing the mmap_sem at least readably?
I feel my understanding of list management and locking completely
shifting.

> >  Doing that will not alleviate
> > the need to sleep for the messaging to the other partitions.
> 
> No, but I'd venture to guess that is not impossible to implement even
> on your current hardware (maybe a firmware update is needed)?

Are you suggesting the sending side would not need to sleep or the
receiving side?  Assuming you meant the sender, it spins waiting for the
remote side to acknowledge the invalidate request?  We place the data
into a previously agreed upon buffer and send an interrupt.  At this
point, we would need to start spinning and waiting for completion.
Let's assume we never run out of buffer space.

The receiving side receives an interrupt.  The interrupt currently wakes
an XPC thread to do the work of transfering and delivering the message
to XPMEM.  The transfer of the data which XPC does uses the BTE engine
which takes up to 28 seconds to timeout (hardware timeout before raising
and error) and the BTE code automatically does a retry for certain
types of failure.  We currently need to grab semaphores which _MAY_
be able to be reworked i

Re: [kvm-devel] s390 kvm_virtio.c build error

2008-05-14 Thread Christian Borntraeger

Am Montag, 5. Mai 2008 schrieb Avi Kivity:
> I can, but tell me which one.  Also, the patch (Heiko's) needs a 
> changelog entry and a signoff.

Avi,

as this patch is now in your queue, can you push this change
---
commit eee4646877b748afbfd34d8dbe6ea9b454a65745
Author: Heiko Carstens <[EMAIL PROTECTED]>
Date:   Tue May 6 17:38:30 2008 +0300

s390: KVM guest: fix compile error
---

soon to Linus? kvm still does not compile on s390.

Thank you

Christian

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

Fabrice Bellard wrote:
>
> I prefer:
>
> drive.file=foo.img
> drive.if=scsi
>

That doesn't support multiple drives very well.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Balazs Attila-Mihaly (Cd-MaN)

> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language, and it is still
> pretty human friendly.

While YAML is certainly human readable, it's not very "human writable" IMHO. I 
think that a simpler format would be more appropiate (given especially that 
there is no need for things like hashes, lists, etc, just name <-> value pairs)

Best regards



  __
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [Reminder] kvm mailing lists moving

[I forgot to do this last weekend, so it's postponed to Saturday]

During the upcoming Saturday, the various kvm lists will move to 
vger.kenel.org.  This will improve responsiveness, and reduce spam and 
advertising.

Please subscribe to the lists you are interested in as soon as
possible.  You can subscribe by sending an email to
[EMAIL PROTECTED], with the following lines in the body:

subscribe kvm
subscribe kvm-commits
subscribe kvm-ia64
subscribe kvm-ppc

Of course, omit lines for the lists you are not interested in.
Majordomo will then send further instructions.

Thanks to the vger admins for hosting the kvm lists.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [ kvm-Bugs-1885747 ] KVM halts, when starting Fedora8 SMP guest

2008-05-14 Thread SourceForge.net

Bugs item #1885747, was opened at 2008-02-03 23:34
Message generated for change (Comment added) made by xichencn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1885747&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: KVM halts, when starting Fedora8 SMP guest

Initial Comment:
This bug is similar to bug: 
[ 1885713 ] KVM crashes, when restarting Fedora8 SMP guest
http://sourceforge.net/tracker/index.php?func=detail&aid=1885713&group_id=180599&atid=893831

Host: Fedora7/x64, KVM-60, AMD.
Guest:Fedora8/x64

Qemu Command:/usr/local/bin/qemu-system-x86_64 -hda
/isos/disks-vm/alexeye/Fedora8-64.vmdk -m 1024 -smp 4 -net 
nic,macaddr=52:54:00:12:34:01,model=rtl8139 -net user -name F8-x64-SMP

During guest OS boot, the VM halts/stucks. Trying to restart that results in a 
VM crash.

Doesn't happens with single CPU.

-Technologov, 3.2.2008.

--

Comment By: Xi Chen (xichencn)
Date: 2008-05-14 17:33

Message:
Logged In: YES 
user_id=2081279
Originator: NO

Run Fedora8/x64 guest on RHEL5. kvm and kvm-u are up to date of git. AMD
8220 dual-core.
Command:qemu-system-x86_64 -hda image/fc8_x64.vmdk -m 1024 -smp 4 -net
nic,macaddr=52:54:00:12:34:01,model=rtl8139 -net user -name F8-x64-SMP

The guest works fine.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1885747&group_id=180599

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Признаки обособленного подразд еления

2008-05-14 Thread Филиалы

Филиалы и обособленные подразделения

Однодневный семинар / 21 мая 2008 г. / Москва

Программа семинара

1. Признаки обособленного подразделения по Налоговому кодексу Российской
Федерации.
2. Процедура регистрации организации в налоговых органах по месту нахождения
обособленного подразделения. Оформление документов. Требования налоговых
органов и их контрольные мероприятия в отношении филиала и представительства
3. Особенности бухгалтерского и налогового учета в организациях, имеющих
обособленные подразделения.
4. Организация документооборота операций, проводимых через обособленные
подразделения. Подтверждающие первичные документы и авизо.
5. Порядок исчисления и уплаты налогов по филиалу и головной организации.

Продолжительность обучения: с 10 до 17 часов (с перерывом на обед и кофе-паузу).
Место обучения: г. Москва, 5 мин. пешком от м. Академическая.
Стоимость обучения: 4900 руб. (с НДС).
(В стоимость входит: раздаточный материал, кофе-пауза, обед в ресторане).

Для регистрации на семинар необходимо отправить нам реквизиты организации, тему
и дату семинара, полное ФИО участников, контактный телефон и факс.

Получить подробную программу и зарегистрироваться можно
по телефону: ( 4 9 5 ) 543 8 8 4 6

[kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-2

This is the second release of network drivers for Windows guests running
on a kvm host.  The drivers are intended for Windows 2000 and Windows 
XP, and Windows 2003.  Both x86 and x64 variants are provided.  kvm-61 
or later is needed in the host.  At the moment only binaries are available.

The drivers are available from the download page of the kvm website, below.

To use, download the drivers into the guest (using one of the emulated
network cards), and unpack the package. Reboot with '-net
nic,model=virtio' instead of the usual setting, and when Windows prompts
you for a driver location, select the appropriate directory in the
package (Windows XP or Windows 2000).

Changes from kvm-guest-drivers-windows-1:
- smp support (Yan Vugenfirer)
- x64 support (Yan Vugenfirer)
- prepare for open-sourcing  (Yan Vugenfirer)

Note: Windows 2003 is supported using the Windows XP drivers.

http://kvm.qumranet.com/

-- 
Do not meddle in the internals of kernels, for they are subtle and quick
to panic.


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file

2008-05-14 Thread Fabrice Bellard

Anthony Liguori wrote:
> One thought I had, is that it would be very nice to break up the -drive 
> file=foo.img,if=scsi syntax within the config file.  In general, I'm 
> thinking something like:
> 
> [drive]
> file=foo.img
> if=scsi
> 
> or:
> 
> drive {
>   file=foo.img
>   if=scsi
> }
> 
> or even:
> 
> drive:
>   file=foo.img
>   if=scsi
> 
> Basically, I'm looking for a syntax for sub-options.  This would be 
> useful for -drive or -net but I also think would lay the foundations for 
> specifying a full machine config.
> 
> It would get very unwieldy on the command line to have a large number of 
> suboptions but it works reasonably well within a config.

I prefer:

drive.file=foo.img
drive.if=scsi

Regards,

Fabrice.


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM: kvm_vcpu_block task state race

Marcelo Tosatti wrote:
> On Sun, May 11, 2008 at 05:26:06PM +0300, Avi Kivity wrote:
>   
>>> So do you want to give wait_event_interruptible() a try or wait for that
>>> change until userspace never issues vcpu ioctl's to a possibly busy vcpu
>>> (and go with the patch above)?
>>>  
>>>   
>> Do we have anything critical that issues vcpu ioctls outside its 
>> thread?  While I much prefer wait_event_interruptible(), I don't want to 
>> break existing userspace.
>> 
>
> Well debugging can be critical, so IMO better avoid 
> wait_event_interruptible() 
> for now.
>   

The vast majority of users don't care about debugging, and debugging 
will be broken anyway if a vcpu is spinning (which might be the reason 
for debugging in the first place).

But the w_e_i() conversion can be done later, so I'll apply the patch.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM: LAPIC: ignore pending timers if LVTT is disabled

Marcelo Tosatti wrote:
> Only use the APIC pending timers count to break out of HLT emulation if
> the timer vector is enabled.
>
> Certain configurations of Windows simply mask out the vector without
> disabling the timer.
>
>   
Applied, thanks.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Protected mode transitions and big real mode... still an issue

2008-05-14 Thread Guillaume Thouvenin

On Tue, 6 May 2008 20:05:39 +0300
"Mohammed Gamal" <[EMAIL PROTECTED]> wrote:


> > > > WinXP fails with the patch applied too. Ubuntu 7.10 live CD and
> > > > FreeDOS don't boot but complain about instruction mov 0x11,sreg not
> > > > being emulated.

Mohammed, can you try the patch at the end of this mail? Here it's
working with FreeDOS now (I added the emulation of 0x90 that is an xchg
instruction). I can also boot winXP Professional X64 edition. I still
have a weird issue with Ubuntu 7.10 that crashes sometimes with the
error:

kvm_run: failed entry, reason 5
kvm_run returned -8

It's a little bit strange because this error appears very often with
the wmii window manager but never with XFCE. And with wmii, it only
occurs when I move the mouse above the Qemu/KVM window. If I wait 30s
until the automatic boot it works... 

So to give a summary, on my box:

  OpensSuse 10.3 -> OK
  WinXP Pro X64  -> OK
  FreeDOS-> OK
  Ubuntu 7.10-> NOK 

Regards,
Guillaume

---

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e94a8c3..efde223 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1287,7 +1287,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
fix_pmode_dataseg(VCPU_SREG_GS, &vcpu->arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, &vcpu->arch.rmode.fs);
 
+#if 0
vmcs_write16(GUEST_SS_SELECTOR, 0);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
 
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2648,6 +2650,73 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu, 
struct kvm_run *kvm_run)
return 1;
 }
 
+static int invalid_guest_state(struct kvm_vcpu *vcpu,
+   struct kvm_run *kvm_run, u32 failure_reason)
+{
+   u16 ss, cs;
+   u8 opcodes[4];
+   unsigned long rip = vcpu->arch.rip;
+   unsigned long rip_linear;
+
+   ss = vmcs_read16(GUEST_SS_SELECTOR);
+   cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+   if ((ss & 0x03) != (cs & 0x03)) {
+   int err;
+   rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+   emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+#if 0
+   printk(KERN_INFO "emulation at (%lx) rip %lx: %02x %02x %02x 
%02x\n",
+   rip_linear,
+   rip, opcodes[0], opcodes[1], opcodes[2], 
opcodes[3]);
+#endif
+   err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+   switch (err) {
+   case EMULATE_DONE:
+#if 0
+   printk(KERN_INFO "successfully emulated 
instruction\n");
+#endif
+   return 1;
+   case EMULATE_DO_MMIO:
+   printk(KERN_INFO "mmio?\n");
+   return 0;
+   default:
+   kvm_report_emulation_failure(vcpu, "vmentry 
failure");
+   break;
+   }
+   }
+
+   kvm_run->exit_reason = KVM_EXIT_UNKNOWN;
+   kvm_run->hw.hardware_exit_reason = failure_reason;
+   return 0;
+}
+
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run,
+ u32 failure_reason)
+{
+   unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+#if 0
+   printk(KERN_INFO "Failed vm entry (exit reason 0x%x) ", failure_reason);
+#endif
+   switch (failure_reason) {
+   case EXIT_REASON_INVALID_GUEST_STATE:
+#if 0
+   printk("invalid guest state \n");
+#endif
+   return invalid_guest_state(vcpu, kvm_run, 
failure_reason);
+   case EXIT_REASON_MSR_LOADING:
+   printk("caused by MSR entry %ld loading.\n", 
exit_qualification);
+   break;
+   case EXIT_REASON_MACHINE_CHECK:
+   printk("caused by machine check.\n");
+   break;
+   default:
+   printk("reason not known yet!\n");
+   break;
+   }
+   return 0;
+}
 /*
  * The exit handlers return 1 if the exit was handled fully and guest execution
  * may resume.  Otherwise they set the kvm_run parameter to indicate what needs
@@ -2709,6 +2778,12 @@ static int kvm_handle_exit(struct kvm_run *kvm_run, 
struct kvm_vcpu *vcpu)
exit_reason != EXIT_REASON_EPT_VIOLATION))
printk(KERN_WARNING "%s: unexpected, valid vectoring info and "
   "exit reason is 0x%x\n", __func__, exit_reason);
+
+   if ((exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY)) {
+   exit_reason &= ~VMX_EXIT_REASONS_FAILED_VMENTRY;
+   return handle_vmentry_failure(vcpu, kvm_run, exit_reason);
+   }
+
if (exit_reason < kvm_vmx_max_exit_handlers
&& kvm_vmx_exit_handlers[exit_reason])

Re: [kvm-devel] Windows PV driver for KVM