kvm-devel — kernel virtual machine development

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

[Balazs Attila-M. \(Cd-MaN\) <x_a...@ya...>]

> 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

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

[Avi K. <av...@qu...>]

[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
maj...@vg..., 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.

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

[SourceForge.net <no...@so...>]

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

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

[Филиалы < <tek...@te...>]

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

Однодневный семинар / 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

[Avi K. <av...@qu...>]

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.

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

[Fabrice B. <fa...@be...>]

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.

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

[Avi K. <av...@qu...>]

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

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

[Avi K. <av...@qu...>]

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

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

[Guillaume T. <gui...@ex...>]

On Tue, 6 May 2008 20:05:39 +0300
"Mohammed Gamal" <m.g...@gm...> 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])
 		return kvm_vmx_exit_handlers[exit_reason](vcpu, kvm_run);
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 79d94c6..2cebf48 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -238,7 +238,10 @@ enum vmcs_field {
 #define EXIT_REASON_IO_INSTRUCTION      30
 #define EXIT_REASON_MSR_READ            31
 #define EXIT_REASON_MSR_WRITE           32
+#define EXIT_REASON_INVALID_GUEST_STATE 33
+#define EXIT_REASON_MSR_LOADING         34
 #define EXIT_REASON_MWAIT_INSTRUCTION   36
+#define EXIT_REASON_MACHINE_CHECK       41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
 #define EXIT_REASON_EPT_VIOLATION       48
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dab3d4f..eb7db67 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3009,8 +3009,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 	return 0;
 }
 
-static void get_segment(struct kvm_vcpu *vcpu,
-			struct kvm_segment *var, int seg)
+void get_segment(struct kvm_vcpu *vcpu,
+		 struct kvm_segment *var, int seg)
 {
 	kvm_x86_ops->get_segment(vcpu, var, seg);
 }
@@ -3093,8 +3093,8 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
 	return 0;
 }
 
-static void set_segment(struct kvm_vcpu *vcpu,
-			struct kvm_segment *var, int seg)
+void set_segment(struct kvm_vcpu *vcpu,
+		 struct kvm_segment *var, int seg)
 {
 	kvm_x86_ops->set_segment(vcpu, var, seg);
 }
@@ -3252,8 +3252,8 @@ static int load_segment_descriptor_to_kvm_desct(struct kvm_vcpu *vcpu,
 	return 0;
 }
 
-static int load_segment_descriptor(struct kvm_vcpu *vcpu, u16 selector,
-				   int type_bits, int seg)
+int load_segment_descriptor(struct kvm_vcpu *vcpu, u16 selector,
+			    int type_bits, int seg)
 {
 	struct kvm_segment kvm_seg;
 
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index 8a96320..40ebb46 100644
--- a/arch/x86/kvm/x86_emulate.c
+++ b/arch/x86/kvm/x86_emulate.c
@@ -69,6 +69,7 @@
 #define GroupDual   (1<<15)     /* Alternate decoding of mod == 3 */
 #define GroupMask   0xff        /* Group number stored in bits 0:7 */
 
+int switch_perso = 0;
 enum {
 	Group1_80, Group1_81, Group1_82, Group1_83,
 	Group1A, Group3_Byte, Group3, Group4, Group5, Group7,
@@ -138,9 +139,10 @@ static u16 opcode_table[256] = {
 	/* 0x88 - 0x8F */
 	ByteOp | DstMem | SrcReg | ModRM | Mov, DstMem | SrcReg | ModRM | Mov,
 	ByteOp | DstReg | SrcMem | ModRM | Mov, DstReg | SrcMem | ModRM | Mov,
-	0, ModRM | DstReg, 0, Group | Group1A,
+	DstMem | SrcReg | ModRM | Mov, ModRM | DstReg,
+	DstReg | SrcMem | ModRM | Mov, Group | Group1A,
 	/* 0x90 - 0x9F */
-	0, 0, 0, 0, 0, 0, 0, 0,
+	ImplicitOps, 0, 0, 0, 0, 0, 0, 0,
 	0, 0, 0, 0, ImplicitOps | Stack, ImplicitOps | Stack, 0, 0,
 	/* 0xA0 - 0xA7 */
 	ByteOp | DstReg | SrcMem | Mov | MemAbs, DstReg | SrcMem | Mov | MemAbs,
@@ -152,7 +154,8 @@ static u16 opcode_table[256] = {
 	ByteOp | ImplicitOps | Mov | String, ImplicitOps | Mov | String,
 	ByteOp | ImplicitOps | String, ImplicitOps | String,
 	/* 0xB0 - 0xBF */
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	0, 0, 0, 0, 0, 0, 0, 0,
+	DstReg | SrcImm | Mov, 0, 0, 0, 0, 0, 0, 0,
 	/* 0xC0 - 0xC7 */
 	ByteOp | DstMem | SrcImm | ModRM, DstMem | SrcImmByte | ModRM,
 	0, ImplicitOps | Stack, 0, 0,
@@ -168,7 +171,7 @@ static u16 opcode_table[256] = {
 	/* 0xE0 - 0xE7 */
 	0, 0, 0, 0, 0, 0, 0, 0,
 	/* 0xE8 - 0xEF */
-	ImplicitOps | Stack, SrcImm|ImplicitOps, 0, SrcImmByte|ImplicitOps,
+	ImplicitOps | Stack, SrcImm | ImplicitOps, ImplicitOps, SrcImmByte | ImplicitOps,
 	0, 0, 0, 0,
 	/* 0xF0 - 0xF7 */
 	0, 0, 0, 0,
@@ -1246,6 +1249,19 @@ static inline int writeback(struct x86_emulate_ctxt *ctxt,
 	default:
 		break;
 	}
+#if 0	
+	if (switch_perso) {
+		printk(KERN_INFO "    writeback: dst.byte %d\n"   , c->dst.bytes);
+		printk(KERN_INFO "    writeback: dst.ptr  0x%p\n" , c->dst.ptr);
+		printk(KERN_INFO "    writeback: dst.val  0x%lx\n", c->dst.val);
+		printk(KERN_INFO "    writeback: src.ptr  0x%p\n", c->src.ptr);
+		printk(KERN_INFO "    writeback: src.val  0x%lx\n", c->src.val);
+		printk(KERN_INFO "    writeback: RAX  0x%lx\n", c->regs[VCPU_REGS_RAX]);
+		printk(KERN_INFO "    writeback: RSP  0x%lx\n", c->regs[VCPU_REGS_RSP]);
+		printk(KERN_INFO "    writeback: CS  0x%lx\n", c->regs[VCPU_SREG_CS]);
+		printk(KERN_INFO "    writeback: SS  0x%lx\n", c->regs[VCPU_SREG_SS]);
+	}
+#endif
 	return 0;
 }
 
@@ -1342,6 +1358,10 @@ special_insn:
 	switch (c->b) {
 	case 0x00 ... 0x05:
 	      add:		/* add */
+		if ((c->d & ModRM) && c->modrm_mod == 3) {
+			c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
+			c->dst.ptr =  decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
+		}
 		emulate_2op_SrcV("add", c->src, c->dst, ctxt->eflags);
 		break;
 	case 0x08 ... 0x0d:
@@ -1514,14 +1534,119 @@ special_insn:
 		break;
 	case 0x88 ... 0x8b:	/* mov */
 		goto mov;
+	case 0x8c: { /* mov r/m, sreg */
+		struct kvm_segment segreg;
+
+		if (c->modrm_mod == 0x3)
+			c->src.val = c->modrm_val;
+
+		switch ( c->modrm_reg ) {
+		case 0:
+			get_segment(ctxt->vcpu, &segreg, VCPU_SREG_ES);
+			break;
+		case 1:
+			get_segment(ctxt->vcpu, &segreg, VCPU_SREG_CS);
+			break;
+		case 2:
+			get_segment(ctxt->vcpu, &segreg, VCPU_SREG_SS);
+			break;
+		case 3:
+			get_segment(ctxt->vcpu, &segreg, VCPU_SREG_DS);
+			break;
+		case 4:
+			get_segment(ctxt->vcpu, &segreg, VCPU_SREG_FS);
+			break;
+		case 5:
+			get_segment(ctxt->vcpu, &segreg, VCPU_SREG_GS);
+			break;
+		default:
+			printk(KERN_INFO "0x8c: Invalid segreg in modrm byte 0x%02x\n",
+					 c->modrm);
+			goto cannot_emulate;
+		}
+		c->dst.val = segreg.selector;
+		c->dst.bytes = 2;
+		c->dst.ptr = (unsigned long *)decode_register(c->modrm_rm, c->regs,
+							      c->d & ByteOp);
+		break;
+	}
 	case 0x8d: /* lea r16/r32, m */
 		c->dst.val = c->modrm_ea;
 		break;
+	case 0x8e: { /* mov seg, r/m16 */
+		uint16_t sel;
+
+		sel = c->src.val;
+		switch ( c->modrm_reg ) {
+		case 0:
+			if (load_segment_descriptor(ctxt->vcpu, sel, 1, VCPU_SREG_ES) < 0)
+				goto cannot_emulate;
+			break;
+		case 1:
+			if (load_segment_descriptor(ctxt->vcpu, sel, 9, VCPU_SREG_CS) < 0)
+				goto cannot_emulate;
+			break;
+		case 2:
+			if (load_segment_descriptor(ctxt->vcpu, sel, 1, VCPU_SREG_SS) < 0)
+				goto cannot_emulate;
+			break;
+		case 3:
+			if (load_segment_descriptor(ctxt->vcpu, sel, 1, VCPU_SREG_DS) < 0)
+				goto cannot_emulate;
+			break;
+		case 4:
+			if (load_segment_descriptor(ctxt->vcpu, sel, 1, VCPU_SREG_FS) < 0)
+				goto cannot_emulate;
+			break;
+		case 5:
+			if (load_segment_descriptor(ctxt->vcpu, sel, 1, VCPU_SREG_GS) < 0)
+				goto cannot_emulate;
+			break;
+		default:
+			printk(KERN_INFO "Invalid segreg in modrm byte 0x%02x\n",
+					  c->modrm);
+			goto cannot_emulate;
+		}
+
+		c->dst.type = OP_NONE;  /* Disable writeback. */
+		break;
+	}
 	case 0x8f:		/* pop (sole member of Grp1a) */
 		rc = emulate_grp1a(ctxt, ops);
 		if (rc != 0)
 			goto done;
 		break;
+	case 0x90: /* xhcg r8, rAx */
+		c->src.ptr = & c->regs[c->b & 0x7];
+		c->dst.ptr = & c->regs[VCPU_REGS_RAX];
+
+		switch (c->op_bytes) {
+                case 2:
+			c->dst.val = *(u16*) c->dst.ptr;
+			c->src.val = *(u16*) c->src.ptr;
+			*(u16 *) c->dst.ptr = (u16) c->src.val;
+			*(u16 *) c->src.ptr = (u16) c->dst.val;
+			break;
+		case 4:
+			c->dst.val = *(u32*) c->dst.ptr;
+			c->src.val = *(u32*) c->src.ptr;
+			*(u32 *) c->dst.ptr = (u32) c->src.val;
+			*(u32 *) c->src.ptr = (u32) c->dst.val;
+			break;
+		case 8:
+			c->dst.val = *(u64*) c->dst.ptr;
+			c->src.val = *(u64*) c->src.ptr;
+			*(u64 *) c->dst.ptr = (u64) c->src.val;
+			*(u64 *) c->src.ptr = (u64) c->dst.val;
+			break;
+		default:
+			printk("xchg: op_bytes=%d is not supported.\n", c->op_bytes);
+			goto cannot_emulate;
+		}
+		c->dst.type = OP_NONE;  /* Disable writeback. */
+		break;
+	case 0xb8: /* mov r, imm */
+		goto mov;
 	case 0x9c: /* pushf */
 		c->src.val =  (unsigned long) ctxt->eflags;
 		emulate_push(ctxt);
@@ -1623,6 +1748,10 @@ special_insn:
 		DPRINTF("Urk! I don't handle SCAS.\n");
 		goto cannot_emulate;
 	case 0xc0 ... 0xc1:
+		if ((c->d & ModRM) && c->modrm_mod == 3) {
+			c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
+			c->dst.ptr =  decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
+		}
 		emulate_grp2(ctxt);
 		break;
 	case 0xc3: /* ret */
@@ -1660,6 +1789,39 @@ special_insn:
 		break;
 	}
 	case 0xe9: /* jmp rel */
+		jmp_rel(c, c->src.val);
+		c->dst.type = OP_NONE; /* Disable writeback. */
+		break;
+	case 0xea: /* jmp far */ {
+		uint32_t eip;
+		uint16_t sel;
+
+		/* enable switch_perso */
+		switch_perso = 1;
+
+		switch (c->op_bytes) {
+		case 2:
+			eip = insn_fetch(u16, 2, c->eip);
+			eip = eip & 0x0000FFFF; /* clear upper 16 bits */
+			break;
+		case 4:
+			eip = insn_fetch(u32, 4, c->eip);
+			break;
+		default:
+			DPRINTF("jmp far: Invalid op_bytes\n");
+			goto cannot_emulate;
+		}
+		sel = insn_fetch(u16, 2, c->eip);
+		if (ctxt->mode == X86EMUL_MODE_REAL)
+			eip |= (sel << 4);
+		else if (load_segment_descriptor(ctxt->vcpu, sel, 9, VCPU_SREG_CS) < 0) {
+			DPRINTF("jmp far: Failed to load CS descriptor\n");
+			goto cannot_emulate;
+		}
+
+		c->eip = eip;
+		break;
+	}
 	case 0xeb: /* jmp rel short */
 		jmp_rel(c, c->src.val);
 		c->dst.type = OP_NONE; /* Disable writeback. */
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 1466c3f..99e343e 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -494,6 +494,10 @@ int emulator_get_dr(struct x86_emulate_ctxt *ctxt, int dr,
 int emulator_set_dr(struct x86_emulate_ctxt *ctxt, int dr,
 		    unsigned long value);
 
+void set_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg);
+void get_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg);
+int load_segment_descriptor(struct kvm_vcpu *vcpu, u16 selector,
+			    int type_bits, int seg);
 int kvm_task_switch(struct kvm_vcpu *vcpu, u16 tss_selector, int reason);
 
 void kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);

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

[Dor L. <dor...@qu...>]

On Wed, 2008-05-14 at 08:55 +0800, Jiang, Yunhong wrote:
> Hi, Dor, I just checked the URL and seems it is not updated still,
> willyou update it?

Avi, since it passed regression, we can release it (also with the .pdb
file).

> 
> -- Yunhong Jiang
> 
> Dor Laor <mailto:dor...@qu...> wrote:
> > On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote:
> >> Avi Kivity <mailto:av...@qu...> wrote:
> >>> Jiang, Yunhong wrote:
> >>>> I noticed there is a windows PV driver based on virtIO in
> >>>> http://sourceforge.net/project/showfiles.php?group_id=180599
> >>>> 
> >>>> But when I enable the driver in guest, the guest will hang. I'm
> using
> >>>> changeset around April, 18. Since the driver is created in March, I
> >>>> assume the changeset in Apri should be ok.
> >>>> 
> >>>> Are there any special action needed to enable the PV driver in
> windows?
> >>>> Have anyone tried it recently?
> >>>> 
> >>> 
> >>> We are using it in production.  What HAL is the guest using?  Are
> you
> >>> running with smp?
> >> 
> >> The HAL is ACPI multipprocessor PC.
> >> It is a UP guest. But I do notice one thing strange. When I use
> device
> >> manager->Processors, I see a lot of CPU listed. But it is really a UP
> >> system and I can only get one cpu in the task manager->performance
> >> window. Not sure if that's the reason of the hang.
> >> 
> > 
> > We just fixed an smp bug for virtio (also triggered by single
> processor
> > with ACPI multiprocessor HAL). We'll publish a new binary tomorrow.
> > 
> > The reason you see multiple cpus although there is only one is that we
> > expose the maximum number in the bios. The system is actually uses the
> > required number so this behavior is ok.
> > 
> > 
> >> -- Yunhong Jiang
> >> 
> >>> 
> >>> --
> >>> Any sufficiently difficult bug is indistinguishable from a feature.
> >> 
> >> 
> > ---------------------------------------------------------------
> > ----------
> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> Don't miss this year's exciting event. There's still time to save
> $100.
> >> Use priority code J8TL2D2. 
> >> 
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.
> > sun.com/javaone
> >> _______________________________________________
> >> kvm-devel mailing list
> >> kvm...@li...
> >> https://lists.sourceforge.net/lists/listinfo/kvm-devel

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

[Colin A. <col...@go...>]

>  That's very nearly YAML format[1], which is attractive because parsers
>  are available in every major programming language,

Really?

I can't find one for Eiffel. Can you give me a pointer please?

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

[Nick P. <np...@su...>]

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...

Well, the first thing would be just to get rid of the whole start/end
idea, which completely departs from the standard Linux system of
clearing ptes, then flushing TLBs, then freeing memory.

The onus would then be on GRU to come up with some numbers to justify
batching, and a patch which works nicely with the rest of the Linux
mm. And yes, mmu-gather is *the* obvious first choice of places to
look if one wanted batching hooks.


> 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.

I always liked the idea as you know. But I don't think that should
be mixed in with the first iteration of the mmu notifiers patch
anyway. GRU actually can work without batching, but there is simply
some (unquantified to me) penalty for not batching it. I think it
is far better to first put in a clean and simple and working functionality
first. The idea that we have to unload some monster be-all-and-end-all
solution onto mainline in a single go seems counter productive to me.

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

[Benjamin H. <be...@ke...>]

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

I agree, we're better off generalizing the mmu_gather batching
instead...

I had some never-finished patches to use the mmu_gather for pretty much
everything except single page faults, tho various subtle differences
between archs and lack of time caused me to let them take the dust and
not finish them...

I can try to dig some of that out when I'm back from my current travel,
though it's probably worth re-doing from scratch now.

Ben.

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

[Marcelo T. <mto...@re...>]

Only use the APIC pending timers count to break out of HLT emulation if
the timer vector is enabled.

Certain configurations of Windows simply mask out the vector without
disabling the timer.

Signed-off-by: Marcelo Tosatti <mto...@re...>

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 7652f88..d41e34c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -961,7 +961,7 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu)
 {
 	struct kvm_lapic *lapic = vcpu->arch.apic;
 
-	if (lapic)
+	if (lapic && apic_enabled(lapic) && apic_lvt_enabled(lapic, APIC_LVTT))
 		return atomic_read(&lapic->timer.pending);
 
 	return 0;

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

[Marcelo T. <mto...@re...>]

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.

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

[Nick P. <np...@su...>]

On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote:
> On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> > On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > > In order to invalidate the remote page table entries, we need to message
> > > (uses XPC) to the remote side.  The remote side needs to acquire the
> > > importing process's mmap_sem and call zap_page_range().  Between the
> > > messaging and the acquiring a sleeping lock, I would argue this will
> > > require sleeping locks in the path prior to the mmu_notifier invalidate_*
> > > callouts().
> > 
> > Why do you need to take mmap_sem in order to shoot down pagetables of
> > the process? It would be nice if this can just be done without
> > sleeping.
> 
> We are trying to shoot down page tables of a different process running
> on a different instance of Linux running on Numa-link connected portions
> of the same machine.

Right. You can zap page tables without sleeping, if you're careful. I
don't know that we quite do that for anonymous pages at the moment, but it
should be possible with a bit of thought, I believe.

 
> The messaging is clearly going to require sleeping.  Are you suggesting
> we need to rework XPC communications to not require sleeping?  I think
> that is going to be impossible since the transfer engine requires a
> sleeping context.

I guess that you have found a way to perform TLB flushing within coherent
domains over the numalink interconnect without sleeping. I'm sure it would
be possible to send similar messages between non coherent domains.

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

 
> Additionally, the call to zap_page_range expects to have the mmap_sem
> held.  I suppose we could use something other than zap_page_range and
> atomically clear the process page tables.

zap_page_range does not expect to have mmap_sem held. I think for anon
pages it is always called with mmap_sem, however try_to_unmap_anon is
not (although it expects page lock to be held, I think we should be able
to avoid that).


>  Doing that will not alleviate
> the need to sleep for the messaging to the other partitions.

No, but I'd venture to guess that is not impossible to implement even
on your current hardware (maybe a firmware update is needed)?

Re: [kvm-devel] [patch 1/2] KVM: hlt emulation should take in-kernel APIC/PIT timers into account

[Yang, S. <she...@in...>]

On Tuesday 13 May 2008 00:40:05 Marcelo Tosatti wrote:
> On Sat, May 10, 2008 at 10:12:02AM +0800, Yang, Sheng wrote:
> > > Did you have kvm.git commit 8ae6dc90ac84d9734e343210c8ec709f50cd9d89
> > > when testing this?
> > >
> > > I believe it should fix that issue, because "ps->inject_pending" won't
> > > be set by kvm_pit_timer_intr_post() if the IRQ is masked. Please
> > > correct me if I'm wrong.
> >
> > Oh, sorry, I missed that commit. But... It just solved an half of the
> > problem. LAPIC suffered from it as well, and the current HLT emulation
> > still didn't work... And I can't find something like inject_pending in
> > LAPIC timer.
> >
> > I have to say, I think my method is more preciously, directly and
> > efficient... It also can be extended easily if we got more clock sources
> > (though I don't think this would happen in near future...). In fact, I
> > think take care of pending counts is some kind of *wrong concept*... We
> > should take care of the window, or when the increment of pending counters
> > happened, CMIIW. And it got nothing to do with the current counter number
> > (yeah, I realized it after saw the hlt behaviour in XP, not before ;) ).
>
> Sheng,
>
> The problem is that you don't want to emulate hlt if you have a pending
> timer _and_ the guest is accepting events. So for example if there are
> two apic timers pending, you inject one of them, guest execute's hlt, we
> end up in vcpu_block().
>
> Does this work for you?

Yeah. I also suggest using the consistent implement for all the 
_has_pending_timer. (in fact, if take pending counters as the interrupts 
which have to delay their injection, the explanation is well :) )

-- 
Thanks
Yang, Sheng
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 7652f88..d41e34c 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -961,7 +961,7 @@ int apic_has_pending_timer(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_lapic *lapic = vcpu->arch.apic;
>
> -	if (lapic)
> +	if (lapic && apic_enabled(lapic) && apic_lvt_enabled(lapic, APIC_LVTT))
>  		return atomic_read(&lapic->timer.pending);
>
>  	return 0;

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

[Jiang, Y. <yun...@in...>]

Hi, Dor, I just checked the URL and seems it is not updated still,
willyou update it?

-- Yunhong Jiang

Dor Laor <mailto:dor...@qu...> wrote:
> On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote:
>> Avi Kivity <mailto:av...@qu...> wrote:
>>> Jiang, Yunhong wrote:
>>>> I noticed there is a windows PV driver based on virtIO in
>>>> http://sourceforge.net/project/showfiles.php?group_id=180599
>>>> 
>>>> But when I enable the driver in guest, the guest will hang. I'm
using
>>>> changeset around April, 18. Since the driver is created in March, I
>>>> assume the changeset in Apri should be ok.
>>>> 
>>>> Are there any special action needed to enable the PV driver in
windows?
>>>> Have anyone tried it recently?
>>>> 
>>> 
>>> We are using it in production.  What HAL is the guest using?  Are
you
>>> running with smp?
>> 
>> The HAL is ACPI multipprocessor PC.
>> It is a UP guest. But I do notice one thing strange. When I use
device
>> manager->Processors, I see a lot of CPU listed. But it is really a UP
>> system and I can only get one cpu in the task manager->performance
>> window. Not sure if that's the reason of the hang.
>> 
> 
> We just fixed an smp bug for virtio (also triggered by single
processor
> with ACPI multiprocessor HAL). We'll publish a new binary tomorrow.
> 
> The reason you see multiple cpus although there is only one is that we
> expose the maximum number in the bios. The system is actually uses the
> required number so this behavior is ok.
> 
> 
>> -- Yunhong Jiang
>> 
>>> 
>>> --
>>> Any sufficiently difficult bug is indistinguishable from a feature.
>> 
>> 
> ---------------------------------------------------------------
> ----------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save
$100.
>> Use priority code J8TL2D2. 
>> 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.
> sun.com/javaone
>> _______________________________________________
>> kvm-devel mailing list
>> kvm...@li...
>> https://lists.sourceforge.net/lists/listinfo/kvm-devel

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

[Daniel P. B. <ber...@re...>]

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

Yes, that would be the main concern I have with the plain conversion
of existing command line args. It would essentially be limiting the 
expressiveness of the config file to that of the command line - flat
key,value pairs. All we'd be gaining  is avoidance of command line 
length limits and persistent storage. Two worthy goals, but IMHO it
could be worth striving for more structure, so the config can explicitly
represent arrays and hashes as concepts.

> [drive]
> file=foo.img
> if=scsi

This just feels like a bad 1/2 house compromise. Adds the complexity
of a more structured config file without giving the full benefits of
a more expressive format such as the 2 you show below.

> drive {
>    file=foo.img
>    if=scsi
> }

I like both this & the next format because they're very expressive.

> or even:
> 
> drive:
>    file=foo.img
>    if=scsi

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

So my preference would be to go with the last option and make sure
it really is YAML compliant so people can use standard tools for 
generating and parsing the format.

Regards,
Daniel

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

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

[Anthony L. <an...@co...>]

Anthony Liguori wrote:
> I think this is pretty useful as-is.  I think it also gives us a reasonable
> way to move forward that will keep everyone pretty happy.
> 
> Here's a short example:
> 
> qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
> 
> Would become `foo.qemu':
> 
>  # Main disk image
>  hda=/home/anthony/images/linux.img
> 
>  # Redirect disk writes to a temporary image
>  snapshot
> 
>  # Make the graphical display available on port 5902
>  vnc=:2
> 
> With:
> 
> qemu-system-x86_64 -config foo.qemu

One thought I had, is that it would be very nice to break up the -drive 
file=foo.img,if=scsi syntax within the config file.  In general, I'm 
thinking something like:

[drive]
file=foo.img
if=scsi

or:

drive {
   file=foo.img
   if=scsi
}

or even:

drive:
   file=foo.img
   if=scsi

Basically, I'm looking for a syntax for sub-options.  This would be 
useful for -drive or -net but I also think would lay the foundations for 
specifying a full machine config.

It would get very unwieldy on the command line to have a large number of 
suboptions but it works reasonably well within a config.

Regards,

Anthony Liguori

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

[Anthony L. <ali...@us...>]

There has been an awful lot of discussion about a configuration file with
almost no general agreement except that one is strongly desired.

I thought about it a bit, and I think a nice step would be to simply allow
the current configuration parameters to be stored in a file using a pretty
familiar format.

I think this is pretty useful as-is.  I think it also gives us a reasonable
way to move forward that will keep everyone pretty happy.

Here's a short example:

qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2

Would become `foo.qemu':

 # Main disk image
 hda=/home/anthony/images/linux.img

 # Redirect disk writes to a temporary image
 snapshot

 # Make the graphical display available on port 5902
 vnc=:2

With:

qemu-system-x86_64 -config foo.qemu

Signed-off-by: Anthony Liguori <ali...@us...>

diff --git a/qemu-doc.texi b/qemu-doc.texi
index cca483c..4861fc0 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -395,6 +395,12 @@ Sets the @var{name} of the guest.
 This name will be display in the SDL window caption.
 The @var{name} will also be used for the VNC server.
 
+@item -config @var{file}
+Reads configuration options from @var{file}.  The format of @var{file} is the
+same as the command line options, except no dash ``-'' is required.  Options
+that take an argument are in the format @var{option=value}.  A pound ``#''
+character can be used as a comment.
+
 @end table
 
 Display options:
diff --git a/vl.c b/vl.c
index 67712f0..2eb39dd 100644
--- a/vl.c
+++ b/vl.c
@@ -7276,6 +7276,7 @@ static void help(int exitcode)
            "-clock          force the use of the given methods for timer alarm.\n"
            "                To see what timers are available use -clock ?\n"
            "-startdate      select initial date of the clock\n"
+	   "-config FILE    read command line options from FILE\n"
            "\n"
            "During emulation, the following keys are useful:\n"
            "ctrl-alt-f      toggle full screen\n"
@@ -7379,6 +7380,7 @@ enum {
     QEMU_OPTION_old_param,
     QEMU_OPTION_clock,
     QEMU_OPTION_startdate,
+    QEMU_OPTION_config,
 };
 
 typedef struct QEMUOption {
@@ -7490,6 +7492,7 @@ const QEMUOption qemu_options[] = {
 #endif
     { "clock", HAS_ARG, QEMU_OPTION_clock },
     { "startdate", HAS_ARG, QEMU_OPTION_startdate },
+    { "config", HAS_ARG, QEMU_OPTION_config },
     { NULL },
 };
 
@@ -7665,9 +7668,106 @@ static BOOL WINAPI qemu_ctrl_handler(DWORD type)
 }
 #endif
 
+static char **insert_opts(char **old_argv, int *old_argc, int index,
+			  char **argv, int argc)
+{
+    char **new_argv;
+
+    /* Allocate larger array */
+    new_argv = realloc(old_argv, (*old_argc + argc) * sizeof(old_argv[0]));
+    if (new_argv == NULL) {
+	fprintf(stderr, "allocate failed in insert_opts\n");
+	exit(1);
+    }
+
+    /* move elements after insertion point to end of array */
+    memmove(new_argv+index + argc, new_argv + index,
+	    (*old_argc - index) * sizeof(argv[0]));
+
+    /* copy in new elements */
+    memcpy(new_argv + index, argv, argc * sizeof(argv[0]));
+
+    *old_argc += argc;
+
+    if (0) { /* for debugging */
+	int i;
+	printf("argv[] = {");
+	for (i = 0; i < *old_argc; i++) {
+	    if (i)
+		printf(", ");
+	    printf("\"%s\"", new_argv[i]);
+	}
+	printf("}\n");
+    }
+
+    return new_argv;
+}
+
+static char **parse_config_file(const char *file, int *pargc)
+{
+    FILE *f;
+    char buffer[4096];
+    char **argv = NULL;
+    int argc = 0;
+
+    f = fopen(file, "r");
+    if (f == NULL)
+	return NULL;
+
+    while (fgets(buffer, sizeof(buffer), f)) {
+	char *ptr = buffer;
+	char *tok, *key, *val;
+	char *targv[2];
+	int targc = 0;
+
+	/* skip whitespace */
+	while (isspace(*ptr)) ptr++;
+
+	/* skip comments or empty lines */
+	if (*ptr == '#' || *ptr == 0)
+	    continue;
+
+	/* trim new line and carriage return if necessary */
+	tok = strchr(ptr, '\n');
+	if (tok)
+	    *tok = 0;
+	tok = strchr(ptr, '\r');
+	if (tok)
+	    *tok = 0;
+
+	/* check if it has an argument */
+	tok = strchr(ptr, '=');
+	if (tok)
+	    *tok = 0;
+
+	/* add key */
+	if (asprintf(&key, "--%s", ptr) == -1)
+	    return NULL;
+	targv[targc++] = key;
+
+	/* add argument (optionally) */
+	if (tok) {
+	    if (asprintf(&val, "%s", tok + 1) == -1)
+		return NULL;
+	    targv[targc++] = val;
+	}
+
+	/* insert new arguments */
+	argv = insert_opts(argv, &argc, argc, targv, targc);
+	if (argv == NULL)
+	    return NULL;
+    }
+
+    fclose(f);
+
+    *pargc = argc;
+
+    return argv;
+}
+
 #define MAX_NET_CLIENTS 32
 
-int main(int argc, char **argv)
+int main(int orig_argc, char **orig_argv)
 {
 #ifdef CONFIG_GDBSTUB
     int use_gdbstub;
@@ -7700,6 +7800,10 @@ int main(int argc, char **argv)
     int fds[2];
     const char *pid_file = NULL;
     VLANState *vlan;
+    char **argv = NULL;
+    int argc = 0;
+
+    argv = insert_opts(argv, &argc, 0, orig_argv, orig_argc);
 
     LIST_INIT (&vm_change_state_head);
 #ifndef _WIN32
@@ -8297,6 +8401,20 @@ int main(int argc, char **argv)
                     }
                 }
                 break;
+	    case QEMU_OPTION_config: {
+		char **config_argv;
+		int config_argc;
+
+		config_argv = parse_config_file(optarg, &config_argc);
+		if (config_argv == NULL) {
+		    fprintf(stderr, "failed to parse config file `%s'\n", optarg);
+		    exit(1);
+		}
+
+		argv = insert_opts(argv, &argc, optind,
+				   config_argv, config_argc);
+		free(config_argv);
+		} break;
             }
         }
     }

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

[Anthony L. <ali...@us...>]

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

Signed-off-by: Anthony Liguori <ali...@us...>

diff --git a/qemu/net.h b/qemu/net.h
index 13daa27..5fb190e 100644
--- a/qemu/net.h
+++ b/qemu/net.h
@@ -1,12 +1,17 @@
 #ifndef QEMU_NET_H
 #define QEMU_NET_H
 
+#include <sys/uio.h>
+
 /* VLANs support */
 
+typedef ssize_t (IOReadvHandler)(void *, const struct iovec *, int);
+
 typedef struct VLANClientState VLANClientState;
 
 struct VLANClientState {
     IOReadHandler *fd_read;
+    IOReadvHandler *fd_readv;
     /* Packets may still be sent if this returns zero.  It's used to
        rate-limit the slirp code.  */
     IOCanRWHandler *fd_can_read;
@@ -30,6 +35,8 @@ VLANClientState *qemu_new_vlan_client(VLANState *vlan,
                                       void *opaque);
 int qemu_can_send_packet(VLANClientState *vc);
 void qemu_send_packet(VLANClientState *vc, const uint8_t *buf, int size);
+ssize_t qemu_sendv_packet(VLANClientState *vc, const struct iovec *iov,
+			  int iovcnt);
 void qemu_handler_true(void *opaque);
 
 void do_info_network(void);
diff --git a/qemu/vl.c b/qemu/vl.c
index 45c97af..1f0a6ac 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -3820,6 +3820,50 @@ void qemu_send_packet(VLANClientState *vc1, const uint8_t *buf, int size)
     }
 }
 
+static ssize_t vc_sendv_compat(VLANClientState *vc, const struct iovec *iov,
+			       int iovcnt)
+{
+    char buffer[4096];
+    size_t offset = 0;
+    int i;
+
+    for (i = 0; i < iovcnt; i++) {
+	size_t len;
+
+	len = MIN(sizeof(buffer) - offset, iov[i].iov_len);
+	memcpy(buffer + offset, iov[i].iov_base, len);
+	offset += len;
+    }
+
+    vc->fd_read(vc->opaque, buffer, offset);
+
+    return offset;
+}
+
+ssize_t qemu_sendv_packet(VLANClientState *vc1, const struct iovec *iov,
+			  int iovcnt)
+{
+    VLANState *vlan = vc1->vlan;
+    VLANClientState *vc;
+    ssize_t max_len = 0;
+
+    for (vc = vlan->first_client; vc != NULL; vc = vc->next) {
+	ssize_t len = 0;
+
+	if (vc == vc1)
+	    continue;
+
+	if (vc->fd_readv)
+	    len = vc->fd_readv(vc->opaque, iov, iovcnt);
+	else if (vc->fd_read)
+	    len = vc_sendv_compat(vc, iov, iovcnt);
+
+	max_len = MAX(max_len, len);
+    }
+
+    return max_len;
+}
+
 #if defined(CONFIG_SLIRP)
 
 /* slirp network adapter */

[kvm-devel] [PATCH 2/4] Add fd_readv handler to tap

[Anthony L. <ali...@us...>]

This allows fragmented packets to be sent with no additional copies over the
tap interface.

Signed-off-by: Anthony Liguori <ali...@us...>

diff --git a/qemu/vl.c b/qemu/vl.c
index 1f0a6ac..7900b76 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -4086,6 +4086,19 @@ static void tap_receive(void *opaque, const uint8_t *buf, int size)
     }
 }
 
+static ssize_t tap_readv(void *opaque, const struct iovec *iov,
+			 int iovcnt)
+{
+    TAPState *s = opaque;
+    ssize_t len;
+
+    do {
+	len = writev(s->fd, iov, iovcnt);
+    } while (len == -1 && (errno == EINTR || errno == EAGAIN));
+
+    return len;
+}
+
 static void tap_send(void *opaque)
 {
     TAPState *s = opaque;
@@ -4135,6 +4148,7 @@ static TAPState *net_tap_fd_init(VLANState *vlan, int fd)
     s->no_poll = 0;
     enable_sigio_timer(fd);
     s->vc = qemu_new_vlan_client(vlan, tap_receive, NULL, s);
+    s->vc->fd_readv = tap_readv;
     qemu_set_fd_handler2(s->fd, tap_read_poll, tap_send, NULL, s);
     snprintf(s->vc->info_str, sizeof(s->vc->info_str), "tap: fd=%d", fd);
     return s;

[kvm-devel] [PATCH 3/4] Use fragmented send for virtio

[Anthony L. <ali...@us...>]

This patch converts virtio-net to use the new fragmented send interface.
We should have always supported this.

Signed-off-by: Anthony Liguori <ali...@us...>

diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 85cc9d2..93bca1d 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -239,23 +239,15 @@ again:
 static void virtio_net_flush_tx(VirtIONet *n, VirtQueue *vq)
 {
     VirtQueueElement elem;
-    int count = 0;
 
     if (!(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK))
         return;
 
     while (virtqueue_pop(vq, &elem)) {
-	int i;
-	size_t len = 0;
+	ssize_t len = 0;
 
 	/* ignore the header for now */
-	for (i = 1; i < elem.out_num; i++) {
-	    qemu_send_packet(n->vc, elem.out_sg[i].iov_base,
-			     elem.out_sg[i].iov_len);
-	    len += elem.out_sg[i].iov_len;
-	}
-
-	count++;
+	len = qemu_sendv_packet(n->vc, &elem.out_sg[1], elem.out_num - 1);
 
 	virtqueue_push(vq, &elem, sizeof(struct virtio_net_hdr) + len);
 	virtio_notify(&n->vdev, vq);

[kvm-devel] D e ntists Database in the United States

[Lauren O R. <su...@ya...>]

Fully exportable and can be used for any purpose:

+ 164,323 D.entists 
+ 158,954 Civic Addresses
+ 163,539 Telephone Numbers
+ 77,236 Fax Numbers
+ 45,650 office emails

Until May 16 the new lowered price is $292

Please reply to joy...@ho...  




to get off please email with 84128 for a subject