Automating Live Migration

[Sukanto Ghosh]

Hi,

What needs to be done in case I want to automate the live migration of
the guests (e.g. for load balancing) ?

I want to have some programs running on multiple nodes, which will
monitor the load on the respective hosts and in case of imbalance can
automatically migrate a guest from one host to another.

What is the interface by which this migration request/command can be
sent to the particular kvm-userspace (at source host) ?

Can this be done using userspace programs or we need kernel modules ?

Getting the destination ready for incoming migration is I guess
straightforward.


-- 
Regards,
Sukanto Ghosh
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] kvm: testsuite: Consolidate mov r, imm testing in one function

[Mohammed Gamal]

Consolidate mov r, imm testing in one function

Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
 user/test/x86/realmode.c |   51 +
 1 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/user/test/x86/realmode.c b/user/test/x86/realmode.c
index 6002909..c2f88c8 100644
--- a/user/test/x86/realmode.c
+++ b/user/test/x86/realmode.c
@@ -129,49 +129,54 @@ int regs_equal(const struct regs *r1, const struct regs 
*r2, int ignore)
); \
extern u8 insn_##name[], insn_##name##_end[]
 
-MK_INSN(mov_r32_imm_1, "mov $1234567890, %eax");
-MK_INSN(mov_r16_imm_1, "mov $1234, %ax");
-MK_INSN(mov_r8_imm_1, "mov $0x12, %ah");
-MK_INSN(mov_r8_imm_2, "mov $0x34, %al");
-MK_INSN(mov_r8_imm_3, "mov $0x12, %ah\n\t" "mov $0x34, %al\n\t");
-
-void start(void)
+void test_mov_imm(const struct regs *inregs, struct regs *outregs)
 {
-   struct regs inregs = { 0 }, outregs;
+   MK_INSN(mov_r32_imm_1, "mov $1234567890, %eax");
+   MK_INSN(mov_r16_imm_1, "mov $1234, %ax");
+   MK_INSN(mov_r8_imm_1, "mov $0x12, %ah");
+   MK_INSN(mov_r8_imm_2, "mov $0x34, %al");
+   MK_INSN(mov_r8_imm_3, "mov $0x12, %ah\n\t" "mov $0x34, %al\n\t");
 
-   print_serial("abc\n");
-   exec_in_big_real_mode(&inregs, &outregs, 0, 0);
-   if (!regs_equal(&inregs, &outregs, 0))
-   print_serial("null test: FAIL\n");
-   exec_in_big_real_mode(&inregs, &outregs,
+   exec_in_big_real_mode(inregs, outregs,
  insn_mov_r16_imm_1,
  insn_mov_r16_imm_1_end - insn_mov_r16_imm_1);
-   if (!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 1234)
+   if (!regs_equal(inregs, outregs, R_AX) || outregs->eax != 1234)
print_serial("mov test 1: FAIL\n");

/* test mov $imm, %eax */
-   exec_in_big_real_mode(&inregs, &outregs,
+   exec_in_big_real_mode(inregs, outregs,
  insn_mov_r32_imm_1,
  insn_mov_r32_imm_1_end - insn_mov_r32_imm_1);
-   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 1234567890)
+   if(!regs_equal(inregs, outregs, R_AX) || outregs->eax != 1234567890)
print_serial("mov test 2: FAIL\n");

/* test mov $imm, %al/%ah */
-   exec_in_big_real_mode(&inregs, &outregs,
+   exec_in_big_real_mode(inregs, outregs,
  insn_mov_r8_imm_1,
  insn_mov_r8_imm_1_end - insn_mov_r8_imm_1);
-   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 0x1200)
+   if(!regs_equal(inregs, outregs, R_AX) || outregs->eax != 0x1200)
print_serial("mov test 3: FAIL\n");
-   exec_in_big_real_mode(&inregs, &outregs,
+   exec_in_big_real_mode(inregs, outregs,
  insn_mov_r8_imm_2,
  insn_mov_r8_imm_2_end - insn_mov_r8_imm_2);
-   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 0x34)
+   if(!regs_equal(inregs, outregs, R_AX) || outregs->eax != 0x34)
print_serial("mov test 4: FAIL\n");
-   exec_in_big_real_mode(&inregs, &outregs,
+   exec_in_big_real_mode(inregs, outregs,
  insn_mov_r8_imm_3,
  insn_mov_r8_imm_3_end - insn_mov_r8_imm_3);
-   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 0x1234)
-   print_serial("mov test 5: FAIL\n"); 
+   if(!regs_equal(inregs, outregs, R_AX) || outregs->eax != 0x1234)
+   print_serial("mov test 5: FAIL\n");
+}
+
+void start(void)
+{
+   struct regs inregs = { 0 }, outregs;
+
+   print_serial("abc\n");
+   exec_in_big_real_mode(&inregs, &outregs, 0, 0);
+   if (!regs_equal(&inregs, &outregs, 0))
+   print_serial("null test: FAIL\n");
+   test_mov_imm(&inregs, &outregs);
exit(0);
 }
 
-- 
1.5.4.3


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resend: patch: qemu + hugetlbfs..

[john cooper]

Avi Kivity wrote:

john cooper wrote:

This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle.  Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.



What is the motivation for providing an option to disable this?  If we 
can detect mem-path is backed by huge pages somehow, I think we can 
prefault the memory unconditionally.



Pre-allocation of the entire huge page backed guest
memory avoids the nondeterministic termination but
admittedly is overly pessimistic.  As this patch does
so by default when -mem-path is specified, allowing
for disable of pre-allocation simply reverts this
change to prior behavior for use cases more tolerant
to it as well as for debug purposes.

The real fix arguably hinges on huge pages having
more general virtual memory behavior.  But that
appears to be a much longer term prospect.

-john

--
[EMAIL PROTECTED]

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] kvm: testsuite: Add mov r, imm instructions to the real mode test harness

[Mohammed Gamal]

Adds different variants of the mov r, imm instructions to the real mode
test harness.

Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
 user/test/x86/realmode.c |   30 +-
 1 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/user/test/x86/realmode.c b/user/test/x86/realmode.c
index 45cf152..6002909 100644
--- a/user/test/x86/realmode.c
+++ b/user/test/x86/realmode.c
@@ -129,7 +129,11 @@ int regs_equal(const struct regs *r1, const struct regs 
*r2, int ignore)
); \
extern u8 insn_##name[], insn_##name##_end[]
 
+MK_INSN(mov_r32_imm_1, "mov $1234567890, %eax");
 MK_INSN(mov_r16_imm_1, "mov $1234, %ax");
+MK_INSN(mov_r8_imm_1, "mov $0x12, %ah");
+MK_INSN(mov_r8_imm_2, "mov $0x34, %al");
+MK_INSN(mov_r8_imm_3, "mov $0x12, %ah\n\t" "mov $0x34, %al\n\t");
 
 void start(void)
 {
@@ -143,7 +147,31 @@ void start(void)
  insn_mov_r16_imm_1,
  insn_mov_r16_imm_1_end - insn_mov_r16_imm_1);
if (!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 1234)
-   print_serial("mov test: FAIL\n");
+   print_serial("mov test 1: FAIL\n");
+   
+   /* test mov $imm, %eax */
+   exec_in_big_real_mode(&inregs, &outregs,
+ insn_mov_r32_imm_1,
+ insn_mov_r32_imm_1_end - insn_mov_r32_imm_1);
+   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 1234567890)
+   print_serial("mov test 2: FAIL\n");
+   
+   /* test mov $imm, %al/%ah */
+   exec_in_big_real_mode(&inregs, &outregs,
+ insn_mov_r8_imm_1,
+ insn_mov_r8_imm_1_end - insn_mov_r8_imm_1);
+   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 0x1200)
+   print_serial("mov test 3: FAIL\n");
+   exec_in_big_real_mode(&inregs, &outregs,
+ insn_mov_r8_imm_2,
+ insn_mov_r8_imm_2_end - insn_mov_r8_imm_2);
+   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 0x34)
+   print_serial("mov test 4: FAIL\n");
+   exec_in_big_real_mode(&inregs, &outregs,
+ insn_mov_r8_imm_3,
+ insn_mov_r8_imm_3_end - insn_mov_r8_imm_3);
+   if(!regs_equal(&inregs, &outregs, R_AX) || outregs.eax != 0x1234)
+   print_serial("mov test 5: FAIL\n"); 
exit(0);
 }
 
-- 
1.5.4.3


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] x86 emulator: Add mov r, imm instructions (opcodes 0xb0-0xbf)

[Mohammed Gamal]

The emulator only supported one instance of mov r, imm instruction
(opcode 0xb8), this adds the rest of these instructions.

Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
 arch/x86/kvm/x86_emulate.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index bcea50a..9b0349e 100644
--- a/arch/x86/kvm/x86_emulate.c
+++ b/arch/x86/kvm/x86_emulate.c
@@ -154,9 +154,16 @@ static u16 opcode_table[256] = {
0, 0, ByteOp | ImplicitOps | Mov | String, ImplicitOps | Mov | String,
ByteOp | ImplicitOps | Mov | String, ImplicitOps | Mov | String,
ByteOp | ImplicitOps | String, ImplicitOps | String,
-   /* 0xB0 - 0xBF */
-   0, 0, 0, 0, 0, 0, 0, 0,
-   DstReg | SrcImm | Mov, 0, 0, 0, 0, 0, 0, 0,
+   /* 0xB0 - 0xB7 */
+   ByteOp | DstReg | SrcImm | Mov, ByteOp | DstReg | SrcImm | Mov,
+   ByteOp | DstReg | SrcImm | Mov, ByteOp | DstReg | SrcImm | Mov,
+   ByteOp | DstReg | SrcImm | Mov, ByteOp | DstReg | SrcImm | Mov,
+   ByteOp | DstReg | SrcImm | Mov, ByteOp | DstReg | SrcImm | Mov,
+   /* 0xB8 - 0xBF */
+   DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+   DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+   DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+   DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
/* 0xC0 - 0xC7 */
ByteOp | DstMem | SrcImm | ModRM, DstMem | SrcImmByte | ModRM,
0, ImplicitOps | Stack, 0, 0,
@@ -1698,7 +1705,7 @@ special_insn:
case 0xae ... 0xaf: /* scas */
DPRINTF("Urk! I don't handle SCAS.\n");
goto cannot_emulate;
-   case 0xb8: /* mov r, imm */
+   case 0xb0 ... 0xbf: /* mov r, imm */
goto mov;
case 0xc0 ... 0xc1:
emulate_grp2(ctxt);
-- 
1.5.4.3


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [ANNOUNCE] kvm-73 release

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Hi, Avi
>>A updated version. Please review again. Thanks.
>> Xiantao
>> From 689bdb4c0506a1b6b24e9c481634593052ee2cc0 Mon Sep 17 00:00:00
>> 2001 From: Xiantao Zhang <[EMAIL PROTECTED]>
>> Date: Tue, 26 Aug 2008 19:20:03 +0800
>> Subject: [PATCH] KVM: external module: keep kvm/ia64 compatible with
>> Linux-2.6.26 and newer version.
>> 
>> Add some compatibility hack for Linux-2.6.26 and newer versions for
>> ia64 
>> 
> 
> 
> Unfortunately it breaks x86 build (2.6.25 host).  Please test that.
Oops, my mistake!  I should put asm/msr.h after
external-module-compat-comm.h due to dependcies issue. 

> Also, please separate the x86 file movement from the ia64 additions.

Attached!  First is for x86 file movement, and the other targets for
hacking ia64 source for back-ward compatibility. 
Thanks
Xiantao


0001-KVM-External-Module-Moving-two-files-for-cross-arc.patch
Description: 0001-KVM-External-Module-Moving-two-files-for-cross-arc.patch


0002-kvm-ia64-External-module-Some-hacks-for-the-compab.patch
Description: 0002-kvm-ia64-External-module-Some-hacks-for-the-compab.patch

[ kvm-Bugs-2076615 ] Win2K does not boot anymore

[SourceForge.net]

Bugs item #2076615, was opened at 2008-08-26 22:04
Message generated for change (Comment added) made by markit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2076615&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: Marco Menardi (markit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win2K does not boot anymore

Initial Comment:
cpu: AMD Phenom(tm) 9550 Quad-Core Processor
RAM: 4GB 
kvm: 73 from sourceforge tar.gz
host kernel version/arch : 2.6.26-1-amd64
guest: Windows 2000 SP4 + 32 bit
command line:
/opt/kvm/bin/qemu-system-x86_64 -boot c -hda win2Ksp4_Tormen.img -m 640 
-localtime -net nic,model=e1000 -net user -usb -usbdevice tablet

behaviour with some switches:
normal:
blue screen and reboot never ending cycle (too fast to read error message)

-no-kvm-irqchip
blue screen  with message
INACESSIBLE_BOOT_DEVICE

-no-kvm-pit
freezes at the end of "white" initial graphical boot screen

-no-kvm switch
boots fine

Long time I don't try this image, so can't tell what KVM version broke the boot.

--

>Comment By: Marco Menardi (markit)
Date: 2008-08-26 23:00

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

Here a shot of the bluescreen I get. VM file structure is qcow2 as far as
I recall.
File Added: kvm_73_win2k_BSOD.png

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2076615&group_id=180599
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2076615 ] Win2K does not boot anymore

[SourceForge.net]

Bugs item #2076615, was opened at 2008-08-26 22:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2076615&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: Marco Menardi (markit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win2K does not boot anymore

Initial Comment:
cpu: AMD Phenom(tm) 9550 Quad-Core Processor
RAM: 4GB 
kvm: 73 from sourceforge tar.gz
host kernel version/arch : 2.6.26-1-amd64
guest: Windows 2000 SP4 + 32 bit
command line:
/opt/kvm/bin/qemu-system-x86_64 -boot c -hda win2Ksp4_Tormen.img -m 640 
-localtime -net nic,model=e1000 -net user -usb -usbdevice tablet

behaviour with some switches:
normal:
blue screen and reboot never ending cycle (too fast to read error message)

-no-kvm-irqchip
blue screen  with message
INACESSIBLE_BOOT_DEVICE

-no-kvm-pit
freezes at the end of "white" initial graphical boot screen

-no-kvm switch
boots fine

Long time I don't try this image, so can't tell what KVM version broke the boot.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2076615&group_id=180599
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-1906204 ] AMD NPT causes performance degradation

[SourceForge.net]

Bugs item #1906204, was opened at 2008-03-03 12:45
Message generated for change (Comment added) made by markit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1906204&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: AMD NPT causes performance degradation

Initial Comment:
Platform: F7/x64, AMD Barcelona K10, KVM-61.

Guest: Windows XP SP2.

By default, the new Nested Page Tables is enabled, which should accelerate 
guests.

While it *does* accelerate guests in some areas, particularly guest OS setup 
time dropped by 20% - which is great, but in other areas I see performance 
degradation.

For example:
Passmark PerformanceTest v6.1 shows
2D Graphics Marks: 78.6 (without NPT)

2D Graphics Marks: 18.9 (with NPT)

NPT was disabled using:
# rmmod kvm-amd
# modprobe kvm-amd npt=0
# dmesg | tail

and all the graphics feel more sluggish, and way slower.
I have used SDL rendering.

-Alexey, 03.03.2008.

--

Comment By: Marco Menardi (markit)
Date: 2008-08-26 21:59

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

Same here, XP has a noticeable slow down. Was faster with my AMD X2 that
is with 4 core Phenom. WIth npt=0 is fast again (as with X2 or better).
Tried with kvm 70...73, debian Sid 64 as host

--

Comment By: Anthony Liguori (aliguori)
Date: 2008-03-24 23:03

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

I am able to reproduce this although the results aren't as extreme.  The
biggest impact is coming from the passmark 2D Graphics Filled Rectangles
test.  Only about 40k exits are occurring while this benchmark is being
run.  It's not impacted by the use of large pages.  Still investigating.


--

Comment By: Technologov (technologov)
Date: 2008-03-03 16:25

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

Yes, those numbers are always reproducible, even with reloading KVM base
module too.

Just try it for yourself, the benchmark is shareware (free for 30 days) -
but VMs rarely live any longer  anyways :)

link:
http://www.passmark.com/

-Alexey, 03.03.2008.

--

Comment By: Joerg Roedel (jroedel)
Date: 2008-03-03 15:40

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

Reloading the KVM-AMD module does not disable NPT completly. You have to
reload the KVM base module too. Can you reproduce your numbers if you
reload both and disable NPT?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1906204&group_id=180599
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Alan Cox]

> Only common sense.  Non-recent machines are barely usable these days.  
> Sure they work well as a firewall or server-in-a-closet, but if you run 
> a desktop or a server that actually does useful work, you're running a 
> relatively recent machine.

Or a properly written desktop, or a thin client for desktop or ...

The really old boxes are actually not the problem, we don't try and use
ACPI on them so we won't try ACPI reboot. For those later ones it is
probably worth trying anyway - we might end up with a different blacklist
to before but there are multiple servers that really don't like old style
reboot nowdays.

Alan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Andi Kleen]

"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes:

> On Tue, 26 Aug 2008, Avi Kivity wrote:
>
>> Most machines are recent machines.
>
>  This is a bold statement I would say.  Any numbers to back it up?

You can do the math. Reasonable assumptions are ~10% growth rate
in year-by-year units shipment (that's conservative, usually it is higher) 
and that most systems are only used for 4-5 years (on commercial servers 
it's typically 4 years, on privately used systems perhaps a bit more,
laptops certainly less because they tend to break earlier). That 
is the average, of course there are systems which are used much
longer (or much shorter), but I would expect them to be the minority.

Also laptops are growing more and more compared to desktops (iirc the
cross over of more laptops than desktops shipping happened recently)
and if the assumption that they break earlier is true (it is
definitely in my experience) so it's likely that the average system
live time shrinks in the future.

With that it's reasonably easy to show that most systems are recent,
if you define recent as 1-3 years. The "ACPI is the standard validated
mode of operation" window is more like 7-8 years by now. With that
I would expect the systems with very poor ACPI implementation to
be a small minority by now.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem in real mode test harness.

[Avi Kivity]

Avi Kivity wrote:

Mohammed Gamal wrote:

When trying to run the real mode test harness with
emulate_invalid_guest_state=1. It crashes with a #GP exception, here
is the output:
---
exception 13 (0)
rax c03104d2 rbx  rcx 31664000 rdx
1000
rsi 0001 rdi  rsp 0002 rbp

r8   r9   r10  r11

r12  r13  r14  r15

rip 00100010 rflags 00010006
cs 0008 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0)
ds 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
es 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
fs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
gs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
tr  (/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
ldt  (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt f0110/17
idt 0/7ff
cr0 6011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
code: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 -->
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01
---

I wanted to take a look at the emulated instruction, so I added some
logging to the kvm-intel module, here is the dmesg output
[11343.221039] emulation failed (emulation success) rip f00de 66 b8 
10 00
[11343.221039] emulation failed (emulation success) rip f00e2 8e d8 
8e c0
[11343.222936] emulation failed (emulation success) rip f00e4 8e c0 
8e e0
[11343.222936] emulation failed (emulation success) rip f00e6 8e e0 
8e e8
[11343.222936] emulation failed (emulation success) rip f00e8 8e e8 
8e d0
[11343.222936] emulation failed (emulation success) rip f00ea 8e d0 
bc 00
[11343.222936] emulation failed (emulation success) rip f00ec bc 00 
00 02
[11343.222936] emulation failed (emulation success) rip f00f1 ea 00 
00 10
[11343.222936] emulation failed (emulation success) rip 10 b8 d2 
04 31
[11343.222936] emulation failed (emulation success) rip 15 8e d8 
8e c0
[11343.222936] emulation failed (emulation success) rip 17 8e c0 
8e d0
[11343.222936] emulation failed (emulation success) rip 19 8e d0 
b9 00
[11343.222936] emulation failed (emulation success) rip 1b b9 00 
40 66
[11343.222936] emulation failed (emulation success) rip 100010 f6 66 
89 f7
[11343.222936] emulation failed (emulation failure) rip 100010 f6 66 
89 f7

---
(Note: I am using kvm_report_emulation_failure() to report all
emulated instructions even those which succeeded)

Looking at the instruction sequence, it corresponds to the following
sequence in realmode.c
asm(
".data \n\t"
". = . + 4096 \n\t"
"stacktop: \n\t"
".text \n\t"
"init: \n\t"
"xor %ax, %ax \n\t"
"mov %ax, %ds \n\t"
"mov %ax, %es \n\t"
"mov %ax, %ss \n\t"
"mov $0x4000, %cx \n\t"
"xor %esi, %esi \n\t"

we fail at the xor %esi, %esi instruction.  I thought at first it
might be an emulation problem with xor, so I changed the instruction
to mov $0, %esi and we still fail. Another strange thing is that the
emulator reads the opcode for xor and mov instructions, but fails when
reading the operands. I looked at the emulator code but it looks OK,
so why is the exception generated?


It looks like we actually fail at the mov insn.  The insn is (rip 
1b):


   b9 00 40 mov$0x4000,%cx

three bytes long, so next rip should be 1e, but it reads 5 bytes 
and ends up in 100010.


I don't understand what the code is doing in that address range 
anyway.  Looks like it accidentally switched to 32-bit protected mode 
somehow.  Are you running realmode.c as is, or patched?




Oh, you're running it with bootstrap.flat, are you?  that enters 32-bit 
protected mode, while this code expects to run from real mode context.


Use

  user/kvmctl user/test/x86/realmode.flat

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem in real mode test harness.

[Avi Kivity]

Mohammed Gamal wrote:

When trying to run the real mode test harness with
emulate_invalid_guest_state=1. It crashes with a #GP exception, here
is the output:
---
exception 13 (0)
rax c03104d2 rbx  rcx 31664000 rdx
1000
rsi 0001 rdi  rsp 0002 rbp

r8   r9   r10  r11

r12  r13  r14  r15

rip 00100010 rflags 00010006
cs 0008 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0)
ds 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
es 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
fs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
gs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
tr  (/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
ldt  (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt f0110/17
idt 0/7ff
cr0 6011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
code: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 -->
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01
---

I wanted to take a look at the emulated instruction, so I added some
logging to the kvm-intel module, here is the dmesg output
[11343.221039] emulation failed (emulation success) rip f00de 66 b8 10 00
[11343.221039] emulation failed (emulation success) rip f00e2 8e d8 8e c0
[11343.222936] emulation failed (emulation success) rip f00e4 8e c0 8e e0
[11343.222936] emulation failed (emulation success) rip f00e6 8e e0 8e e8
[11343.222936] emulation failed (emulation success) rip f00e8 8e e8 8e d0
[11343.222936] emulation failed (emulation success) rip f00ea 8e d0 bc 00
[11343.222936] emulation failed (emulation success) rip f00ec bc 00 00 02
[11343.222936] emulation failed (emulation success) rip f00f1 ea 00 00 10
[11343.222936] emulation failed (emulation success) rip 10 b8 d2 04 31
[11343.222936] emulation failed (emulation success) rip 15 8e d8 8e c0
[11343.222936] emulation failed (emulation success) rip 17 8e c0 8e d0
[11343.222936] emulation failed (emulation success) rip 19 8e d0 b9 00
[11343.222936] emulation failed (emulation success) rip 1b b9 00 40 66
[11343.222936] emulation failed (emulation success) rip 100010 f6 66 89 f7
[11343.222936] emulation failed (emulation failure) rip 100010 f6 66 89 f7
---
(Note: I am using kvm_report_emulation_failure() to report all
emulated instructions even those which succeeded)

Looking at the instruction sequence, it corresponds to the following
sequence in realmode.c
asm(
".data \n\t"
". = . + 4096 \n\t"
"stacktop: \n\t"
".text \n\t"
"init: \n\t"
"xor %ax, %ax \n\t"
"mov %ax, %ds \n\t"
"mov %ax, %es \n\t"
"mov %ax, %ss \n\t"
"mov $0x4000, %cx \n\t"
"xor %esi, %esi \n\t"

we fail at the xor %esi, %esi instruction.  I thought at first it
might be an emulation problem with xor, so I changed the instruction
to mov $0, %esi and we still fail. Another strange thing is that the
emulator reads the opcode for xor and mov instructions, but fails when
reading the operands. I looked at the emulator code but it looks OK,
so why is the exception generated?


It looks like we actually fail at the mov insn.  The insn is (rip 1b):

   b9 00 40 mov$0x4000,%cx

three bytes long, so next rip should be 1e, but it reads 5 bytes and 
ends up in 100010.


I don't understand what the code is doing in that address range anyway.  
Looks like it accidentally switched to 32-bit protected mode somehow.  
Are you running realmode.c as is, or patched?


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Problem in real mode test harness.

[Mohammed Gamal]

When trying to run the real mode test harness with
emulate_invalid_guest_state=1. It crashes with a #GP exception, here
is the output:
---
exception 13 (0)
rax c03104d2 rbx  rcx 31664000 rdx
1000
rsi 0001 rdi  rsp 0002 rbp

r8   r9   r10  r11

r12  r13  r14  r15

rip 00100010 rflags 00010006
cs 0008 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0)
ds 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
es 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
fs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
gs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
tr  (/ p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
ldt  (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt f0110/17
idt 0/7ff
cr0 6011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
code: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 -->
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01
---

I wanted to take a look at the emulated instruction, so I added some
logging to the kvm-intel module, here is the dmesg output
[11343.221039] emulation failed (emulation success) rip f00de 66 b8 10 00
[11343.221039] emulation failed (emulation success) rip f00e2 8e d8 8e c0
[11343.222936] emulation failed (emulation success) rip f00e4 8e c0 8e e0
[11343.222936] emulation failed (emulation success) rip f00e6 8e e0 8e e8
[11343.222936] emulation failed (emulation success) rip f00e8 8e e8 8e d0
[11343.222936] emulation failed (emulation success) rip f00ea 8e d0 bc 00
[11343.222936] emulation failed (emulation success) rip f00ec bc 00 00 02
[11343.222936] emulation failed (emulation success) rip f00f1 ea 00 00 10
[11343.222936] emulation failed (emulation success) rip 10 b8 d2 04 31
[11343.222936] emulation failed (emulation success) rip 15 8e d8 8e c0
[11343.222936] emulation failed (emulation success) rip 17 8e c0 8e d0
[11343.222936] emulation failed (emulation success) rip 19 8e d0 b9 00
[11343.222936] emulation failed (emulation success) rip 1b b9 00 40 66
[11343.222936] emulation failed (emulation success) rip 100010 f6 66 89 f7
[11343.222936] emulation failed (emulation failure) rip 100010 f6 66 89 f7
---
(Note: I am using kvm_report_emulation_failure() to report all
emulated instructions even those which succeeded)

Looking at the instruction sequence, it corresponds to the following
sequence in realmode.c
asm(
".data \n\t"
". = . + 4096 \n\t"
"stacktop: \n\t"
".text \n\t"
"init: \n\t"
"xor %ax, %ax \n\t"
"mov %ax, %ds \n\t"
"mov %ax, %es \n\t"
"mov %ax, %ss \n\t"
"mov $0x4000, %cx \n\t"
"xor %esi, %esi \n\t"

we fail at the xor %esi, %esi instruction.  I thought at first it
might be an emulation problem with xor, so I changed the instruction
to mov $0, %esi and we still fail. Another strange thing is that the
emulator reads the opcode for xor and mov instructions, but fails when
reading the operands. I looked at the emulator code but it looks OK,
so why is the exception generated?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: paravirtualized windows net driver stop after some days on XP guest

[Yann Dupont]

Dor Laor a écrit :

Can you please try an update version of the windows drivers?
I also added a dummy installer you can use too:

http://kvm.qumranet.com/kvmwiki/VirtioWindowsDrivers

Regards,
Dor


Well, installation is OK.
Now running this driver on some XP & 2003 machines. So far, so good.

Time will tell if stability is ok.
Thanks for your quick answer,

Best regards,

--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.51.12.53.91 - Mail/Jabber : [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guests

[Amit Shah]

From: Or Sagi <[EMAIL PROTECTED]>
From: Nir Peleg <[EMAIL PROTECTED]>
From: Amit Shah <[EMAIL PROTECTED]>
From: Ben-Ami Yassour <[EMAIL PROTECTED]>
From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>

With this patch, we can assign a device on the host machine to a
guest.

A new command-line option, -pcidevice is added.
For example, to invoke it for a device sitting at PCI bus:dev.fn
04:08.0 with host IRQ 18, use this:

-pcidevice host=04:08.0

The host driver for the device, if any, is to be removed before
assigning the device.

This works only with the in-kernel irqchip method; to use the
userspace irqchip, a kernel module (irqhook) and some extra changes
are needed.

Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
---
 libkvm/libkvm-x86.c |   14 +
 libkvm/libkvm.h |   27 ++
 qemu/Makefile.target|1 +
 qemu/hw/device-assignment.c |  600 +++
 qemu/hw/device-assignment.h |   94 +++
 qemu/hw/isa.h   |2 +
 qemu/hw/pc.c|9 +
 qemu/hw/pci.c   |   12 +
 qemu/hw/pci.h   |1 +
 qemu/hw/piix_pci.c  |   19 ++
 qemu/vl.c   |   18 ++
 11 files changed, 797 insertions(+), 0 deletions(-)
 create mode 100644 qemu/hw/device-assignment.c
 create mode 100644 qemu/hw/device-assignment.h

diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index ea97bdd..831823b 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -126,6 +126,20 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
 }
 
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+   return ioctl(kvm->vm_fd, KVM_ASSIGN_PCI_DEVICE, assigned_dev);
+}
+
+int kvm_assign_irq(kvm_context_t kvm,
+  struct kvm_assigned_irq *assigned_irq)
+{
+   return ioctl(kvm->vm_fd, KVM_ASSIGN_IRQ, assigned_irq);
+}
+#endif
+
 int kvm_arch_create_default_phys_mem(kvm_context_t kvm,
   unsigned long phys_mem_bytes,
   void **vm_mem)
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 346eedf..b424af6 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -658,4 +658,31 @@ int kvm_s390_interrupt(kvm_context_t kvm, int slot,
 int kvm_s390_set_initial_psw(kvm_context_t kvm, int slot, psw_t psw);
 int kvm_s390_store_status(kvm_context_t kvm, int slot, unsigned long addr);
 #endif
+
+#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+/*!
+ * \brief Notifies host kernel aboud a PCI device assigned to guest
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the physical PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_dev Parameters, like bus, devfn number, etc
+ */
+int kvm_assign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev);
+
+/*!
+ * \brief Notifies host kernel about changes to a irq assignment
+ *
+ * Used for PCI device assignment, this function notifies the host
+ * kernel about the assigning of the irq for an assigned physical
+ * PCI device.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_irq Parameters, like dev id, host irq, guest irq, etc
+ */
+int kvm_assign_irq(kvm_context_t kvm,
+  struct kvm_assigned_irq *assigned_irq);
+#endif
 #endif
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 2332fe3..750ecd5 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -611,6 +611,7 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
 OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
 OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
 OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o
+OBJS+= device-assignment.o
 ifeq ($(USE_KVM_PIT), 1)
 OBJS+= i8254-kvm.o
 endif
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
new file mode 100644
index 000..8bc4e5c
--- /dev/null
+++ b/qemu/hw/device-assignment.c
@@ -0,0 +1,600 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ *
+ *  Assign a PCI device from the host to a guest VM.
+ *
+ *  Adapted for KVM by Qumranet.
+ *
+ *  Copyright (c) 2007, Neocleus, Alex No

Userspace patch for device assignment

[Amit Shah]

This patch is the userspace component to enable device assignment on kvm hosts. 
It uses the Intel IOMMU (VT-d) by default if available.

Assigning devices that share IRQ on the host is not supported yet. Attempt to 
assign a device that shares its irq with some other device results in a 
segfault in the pci_unregister_device code; I'm yet to fix that.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] kvm-73 release

[Avi Kivity]

Zhang, Xiantao wrote:
Hi, Avi 
   A updated version. Please review again. Thanks.

Xiantao
From 689bdb4c0506a1b6b24e9c481634593052ee2cc0 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2008 19:20:03 +0800
Subject: [PATCH] KVM: external module: keep kvm/ia64 compatible with
Linux-2.6.26 and newer version.

Add some compatibility hack for Linux-2.6.26 and newer versions for ia64
  



Unfortunately it breaks x86 build (2.6.25 host).  Please test that.

Also, please separate the x86 file movement from the ia64 additions.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] KVM: Device Assignment with VT-d

[Han, Weidong]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Amit Shah wrote:
>> 
>>> * On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:
>>> 
 Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to
 avoid future code move. 
 
>>> As of now, device assignment resides inside the x86 directory and is
>>> only tested in x86 environment. Once we support ia64, we'll have a
>>> lot of files moving anyway. 
>>> 
>> 
>> Just a suggestion.  Even if put it @ virt/kvm, we still can make it
>> only 
>> 
> 
> I'm fine with keeping it in x86 and moving it later, since the code is
> late already.  However if someone is willing to do the work to move it
> to virt/kvm/, I'm happy with that as well.

I think we'd better keep it in x86 at this moment. Making VT-d code
arch-independent is our goal. Moving that file is not enough, let's do
it cleanly after merging VT-d patches into upstream.

Randy (Weidong)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Maciej W. Rozycki]

On Tue, 26 Aug 2008, Pavel Machek wrote:

> reboot needs to work on servers-in-a-closet, too.

 More importantly even, I would say, as failing to do so will cost some a
drive to a remote location in the middle of the night on a weekend or some
holiday.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] KVM: Device Assignment with VT-d

[Avi Kivity]

Zhang, Xiantao wrote:

Amit Shah wrote:
  

* On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:


Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to
avoid future code move.
  

As of now, device assignment resides inside the x86 directory and is
only tested in x86 environment. Once we support ia64, we'll have a
lot of files moving anyway.



Just a suggestion.  Even if put it @ virt/kvm, we still can make it only
  


I'm fine with keeping it in x86 and moving it later, since the code is 
late already.  However if someone is willing to do the work to move it 
to virt/kvm/, I'm happy with that as well.


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VT-d support for device assignment

[Avi Kivity]

Amit Shah wrote:

-pcidevice dev=00:13.0,dma=iommu
  

Why not default to iommu if one is available?



I've set that as default now.

What should the parameter be to disable just the iommu? dma=noiommu looks 
ugly.
  


dma=none ?

Or do we not want to disable an iommu at all (even for debugging or testing 
something else, like pvdma)?


  


Good question.  Maybe it's safer to always enable it, and to let 
developers hack it out.


We must be careful of people's feet.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: paravirtualized windows net driver stop after some days on XP guest

[Yann Dupont]

Dor Laor a écrit :

Can you please try an update version of the windows drivers?


sure ! I'll do it right now.

I also added a dummy installer you can use too:

http://kvm.qumranet.com/kvmwiki/VirtioWindowsDrivers

Regards,
Dor


Thanks for the fast answer

Best regards,


--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.51.12.53.91 - Mail/Jabber : [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Maciej W. Rozycki]

On Tue, 26 Aug 2008, Avi Kivity wrote:

> Only common sense.  Non-recent machines are barely usable these days.  
> Sure they work well as a firewall or server-in-a-closet, but if you run 
> a desktop or a server that actually does useful work, you're running a 
> relatively recent machine.

 Hmm, it may have been true not so long ago, though not necessarily so
because of less affordability.  These days hardware is more and more
affordable, but for several years the performance of hardware increased at
a rate substantially higher than the demand for resources from software
did.  Therefore unless you are into HPC or use some inferior pieces of
software beyond the scope of this mailing list, older pieces of hardware
are often more than adequate to get your work done, so for some there is
little incentive to upgrade.  Especially as upgrades are not necessarily
convenient for example because suddenly you lose something you have got
used to with your older equipment which the new one does not have.

 My old x86 laptop I scrapped earlier this year was eight years old and
still up to its task and working fine except its enclosure fell apart.  
The new one has the graphic driver barely working (no resolution switching
for example, the text mode gets garbled upon switching occasionally and
sometimes the console goes off entirely), plus a number of less annoying
issues I was not really eager to have.  I would have kept the old gear if
I had had a way to replace the enclosure.

 My best MIPS64 box is five years old and still decent enough to get its
work done.  I do not seek a replacement.

 Overall I am afraid common sense can sometimes be misleading, especially
as it varies from person to person.

> If we find that the reset was wired to the launch controller after all, 
> we can back out the change (after we re-evolve technology and Linux; 
> after all we are doomed to keep reinventing it, aren't we?).

 The problem is it will work for us and then hit an unsuspecting innocent
user out there, someone not competent enough in the area of computer
hardware to have an idea what may be going wrong.  And most certainly it
won't be the launch controller (whatever the thing is -- some military
equipment?), but some other random piece of hardware it will have been
wired to by someone on a whim.

> Let's see what breaks, if any.  I understand the disgust people feel 
> when ACPI is mentioned, but we can't ignore reality.

 The disgust is expressed for future generations to get a lesson or
perish.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: paravirtualized windows net driver stop after some days on XP guest

[Dor Laor]

Can you please try an update version of the windows drivers?
I also added a dummy installer you can use too:

http://kvm.qumranet.com/kvmwiki/VirtioWindowsDrivers

Regards,
Dor

Yann Dupont wrote:

Hello. I'm using kvm whit great succes for various OS. Very good job.

In June I started using paravirtualized drivers.

Since that we encountered sporadic loss of connectivity on some Xp
guests after some days of uptime.
This was with KVM 70. I upgraded to KVM 73 4 days ago, and this morning
1 off my Xp guests had no connectivity.

Putting the interface off then on via panel control  revives network
instantly.  Seems like a bug on the windows driver side .
This is occurring on 2 Xp guests, they have moderate to low network load.

They have 1 CPU , the hal is the non acpi one (because they were
installed in KVM-23 timeframe)

I also have 2003 guests, and so far I haven't encountered the problem.

Also have linux guests, with net AND disk virtio , AND high load without
problem.
Best Regards,



--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Pavel Machek]

On Tue 2008-08-26 16:33:37, Avi Kivity wrote:
> Maciej W. Rozycki wrote:
> >On Tue, 26 Aug 2008, Avi Kivity wrote:
> >
> >  
> >>Most machines are recent machines.
> >>
> >
> > This is a bold statement I would say.  Any numbers to 
> > back it up?
> >
> >  
> 
> Only common sense.  Non-recent machines are barely 
> usable these days.  Sure they work well as a firewall or 
> server-in-a-closet, but if you run a desktop or a server 
> that actually does useful work, you're running a 
> relatively recent machine.

reboot needs to work on servers-in-a-closet, too.

Anyway, I guess the change should go in. Lets see what breaks.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VT-d support for device assignment

[Amit Shah]

* On Tuesday 26 Aug 2008 14:40:57 Avi Kivity wrote:
> Amit Shah wrote:
> > The following two patches contain VT-d support for device assignment for
> > KVM guests.
> >
> > The first patch contains the changes that are required to the generic
> > VT-d code.
> >
> > The second patch contains the changes to KVM.
> >
> > Since the last send, I've updated the 2nd patch to expose KVM_CAP_IOMMU
> > and check for the existence of an IOMMU before using one. I've also
> > preserved the 'From' field for both the patches so that the original
> > authors are credited for the patches.
> >
> > The command line currently should be invoked with the parameter:
> >
> > -pcidevice dev=00:13.0,dma=iommu
>
> Why not default to iommu if one is available?

I've set that as default now.

What should the parameter be to disable just the iommu? dma=noiommu looks 
ugly.

Or do we not want to disable an iommu at all (even for debugging or testing 
something else, like pvdma)?

> btw, -usbdevice prefixes host devices with host:, no?  maybe adopt the
> convention for -pcidevice?

Sounds ok.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Avi Kivity]

Maciej W. Rozycki wrote:

On Tue, 26 Aug 2008, Avi Kivity wrote:

  

Most machines are recent machines.



 This is a bold statement I would say.  Any numbers to back it up?

  


Only common sense.  Non-recent machines are barely usable these days.  
Sure they work well as a firewall or server-in-a-closet, but if you run 
a desktop or a server that actually does useful work, you're running a 
relatively recent machine.


If a machine has acpi, and the reset register is wired to the launch 
controller, then perhaps this change is unsafe.  Don't issue sysrq-b on 
such machines.



 If a machine has ACPI and it is broken randomly, then the results can be
arbitrary.  Hopefully not destructively.  If even such a simple thing as
wiring the reset line so that it functions correctly can be got wrong,
more so can be more complex matters.
  


If we find that the reset was wired to the launch controller after all, 
we can back out the change (after we re-evolve technology and Linux; 
after all we are doomed to keep reinventing it, aren't we?).



 Failing a better alternative, I suppose the change has to go in though.
  


Let's see what breaks, if any.  I understand the disgust people feel 
when ACPI is mentioned, but we can't ignore reality.


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Maciej W. Rozycki]

On Tue, 26 Aug 2008, Avi Kivity wrote:

> Most machines are recent machines.

 This is a bold statement I would say.  Any numbers to back it up?

> If a machine doesn't have acpi, this change is safe.
> 
> If a machine has acpi, but doesn't have the reset register set in the 
> FADT, this change is safe.
> 
> If a machine has acpi, and the reset register is set incorrectly, this 
> change is safe.
> 
> If a machine has acpi, and the reset register is wired to the launch 
> controller, then perhaps this change is unsafe.  Don't issue sysrq-b on 
> such machines.

 If a machine has ACPI and it is broken randomly, then the results can be
arbitrary.  Hopefully not destructively.  If even such a simple thing as
wiring the reset line so that it functions correctly can be got wrong,
more so can be more complex matters.

 Failing a better alternative, I suppose the change has to go in though.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Andi Kleen]

Avi Kivity <[EMAIL PROTECTED]> writes:
>
> If a machine has acpi, and the reset register is wired to the launch
> controller, then perhaps this change is unsafe.  Don't issue sysrq-b
> on such machines.

Even if it's wired to the launch controller the launch controller
would need to be quite quick to do something before the following
triple fault/keyboard reset->PCI reset stops it again.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Avi Kivity]

Alan Cox wrote:

It seems excessive.  Most machines will hardly run without acpi.



*Recent* machines.
  


Most machines are recent machines.

If a machine doesn't have acpi, this change is safe.

If a machine has acpi, but doesn't have the reset register set in the 
FADT, this change is safe.


If a machine has acpi, and the reset register is set incorrectly, this 
change is safe.


If a machine has acpi, and the reset register is wired to the launch 
controller, then perhaps this change is unsafe.  Don't issue sysrq-b on 
such machines.


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [ANNOUNCE] kvm-73 release

[Zhang, Xiantao]

Hi, Avi 
   A updated version. Please review again. Thanks.
Xiantao
>From 689bdb4c0506a1b6b24e9c481634593052ee2cc0 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2008 19:20:03 +0800
Subject: [PATCH] KVM: external module: keep kvm/ia64 compatible with
Linux-2.6.26 and newer version.

Add some compatibility hack for Linux-2.6.26 and newer versions for ia64
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
 kernel/Makefile   |4 ++--
 kernel/external-module-compat-comm.h  |1 -
 kernel/{x86 => }/external-module-compat.c |0 
 kernel/ia64/Kbuild|3 ++-
 kernel/ia64/external-module-compat.h  |   16 
 kernel/ia64/hack-module.awk   |   14 ++
 kernel/x86/Kbuild |6 +++---
 kernel/x86/external-module-compat.h   |1 +
 kernel/{ => x86}/hack-module.awk  |0 
 9 files changed, 38 insertions(+), 7 deletions(-)
 rename kernel/{x86 => }/external-module-compat.c (100%)
 create mode 100644 kernel/ia64/hack-module.awk
 rename kernel/{ => x86}/hack-module.awk (100%)

diff --git a/kernel/Makefile b/kernel/Makefile
index 6f8cc9d..3f5f6da 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -19,7 +19,7 @@ LINUX = ../linux-2.6
 version = $(shell cd $(LINUX); git describe)
 
 _hack = mv $1 $1.orig && \
-   gawk -v version=$(version) -f hack-module.awk $1.orig \
+   gawk -v version=$(version) -f $(ARCH_DIR)/hack-module.awk
$1.orig \
| sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
 
 unifdef = mv $1 $1.orig && \
@@ -29,7 +29,7 @@ unifdef = mv $1 $1.orig && \
 hack = $(call _hack,$T/$(strip $1))
 
 hack-files-x86 = kvm_main.c mmu.c vmx.c svm.c x86.c irq.h lapic.c
i8254.c
-hack-files-ia64 =
+hack-files-ia64 = kvm_main.c kvm_fw.c
 
 hack-files = $(hack-files-$(ARCH_DIR))
 
diff --git a/kernel/external-module-compat-comm.h
b/kernel/external-module-compat-comm.h
index 97e921b..2e87c57 100644
--- a/kernel/external-module-compat-comm.h
+++ b/kernel/external-module-compat-comm.h
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * 2.6.16 does not have GFP_NOWAIT
diff --git a/kernel/x86/external-module-compat.c
b/kernel/external-module-compat.c
similarity index 100%
rename from kernel/x86/external-module-compat.c
rename to kernel/external-module-compat.c
diff --git a/kernel/ia64/Kbuild b/kernel/ia64/Kbuild
index 764a493..8561476 100644
--- a/kernel/ia64/Kbuild
+++ b/kernel/ia64/Kbuild
@@ -1,6 +1,7 @@
 obj-m := kvm.o kvm-intel.o
 
-kvm-objs := kvm_main.o ioapic.o coalesced_mmio.o kvm-ia64.o kvm_fw.o
+kvm-objs := kvm_main.o ioapic.o coalesced_mmio.o kvm-ia64.o kvm_fw.o \
+   ../anon_inodes.o ../external-module-compat.o
 
 EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
 kvm-intel-objs := vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o
mmio.o \
diff --git a/kernel/ia64/external-module-compat.h
b/kernel/ia64/external-module-compat.h
index 3c4001c..2a11d39 100644
--- a/kernel/ia64/external-module-compat.h
+++ b/kernel/ia64/external-module-compat.h
@@ -2,8 +2,11 @@
  * Compatibility header for building as an external module.
  */
 
+#ifndef __ASSEMBLY__
 #include 
 
+#include "../external-module-compat-comm.h"
+
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
 #error "KVM/IA-64 Can't be compiled if kernel version < 2.6.26"
 #endif
@@ -13,3 +16,16 @@
   TODO: Implement it later! */
 #error "KVM/IA-64 depends on preempt notifiers in kernel."
 #endif
+
+/* smp_call_function() lost an argument in 2.6.27. */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)
+
+#define kvm_smp_call_function(func, info, wait) smp_call_function(func,
info, 0, wait)
+
+#else
+
+#define kvm_smp_call_function(func, info, wait) smp_call_function(func,
info, wait)
+
+#endif
+
+#endif
diff --git a/kernel/ia64/hack-module.awk b/kernel/ia64/hack-module.awk
new file mode 100644
index 000..b9b24c0
--- /dev/null
+++ b/kernel/ia64/hack-module.awk
@@ -0,0 +1,14 @@
+BEGIN { split("INIT_WORK on_each_cpu smp_call_function" , compat_apis);
}
+
+/MODULE_AUTHOR/ {
+printf("MODULE_INFO(version, \"%s\");\n", version)
+}
+
+{
+for (i in compat_apis) {
+   ident = compat_apis[i]
+   sub("\\<" ident "\\>", "kvm_" ident)
+}
+}
+
+{ print }
diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild
index ee81a1e..8dc0483 100644
--- a/kernel/x86/Kbuild
+++ b/kernel/x86/Kbuild
@@ -1,11 +1,11 @@
 obj-m := kvm.o kvm-intel.o kvm-amd.o
 kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o ../anon_inodes.o irq.o
i8259.o \
 lapic.o ioapic.o preempt.o i8254.o coalesced_mmio.o \
-external-module-compat.o
+../external-module-compat.o
 ifeq ($(CONFIG_KVM_TRACE),y)
 kvm-objs += kvm_trace.o
 endif
-kvm-intel-objs := vmx.o vmx-debug.o external-module-compat.o
-kvm-amd-objs := svm.o external-module-compat.o
+kvm-intel-objs := vmx.o vmx-debug.o ../external-module-compat.o
+kvm-amd-objs := svm.o ../external-module-compat.o
 
 CFLA

Re: [PATCH] x86: default to reboot via ACPI

[Andi Kleen]

Pavel Machek <[EMAIL PROTECTED]> writes:
>
> "ACPI" and "safe" in one sentence. 

ACPI is safe in that a lot of systems won't even boot anymore without ACPI.

> /me bets this will break lot of machines.

The ACPI reboot is just a write to a IO port with a fallback, so it
should be fairly safe even if the field should be wrong.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Alan Cox]

> Linux is used a lot in embedded systems (like routers and NAS-es and
> probably set-top boxes). I guess the # of embedded systems with some
> linux flavour on it is substantially bigger than the desktop systems.
> Most of these are ARM or MIPS based and do not support ACPI.

They also don't support VT and are not x86 boxes so the code area
involved doesn't even get compiled on them.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Ingo Molnar]

* Frans Meulenbroeks <[EMAIL PROTECTED]> wrote:

> 2008/8/26 Avi Kivity <[EMAIL PROTECTED]>:
> 
> > It seems excessive.  Most machines will hardly run without acpi.
> 
> Well, I'm fairly sure that most of the systems running linux (or some 
> variant like uclinux), do not support acpi.
> 
> Linux is used a lot in embedded systems (like routers and NAS-es and 
> probably set-top boxes). I guess the # of embedded systems with some 
> linux flavour on it is substantially bigger than the desktop systems. 
> Most of these are ARM or MIPS based and do not support ACPI.

... which is not an issue in this particular discussion, which was about 
x86 with ACPI support enabled and available, whether in that case (and 
only in that case) we should first try the ACPI reboot ports (that the 
ACPI descriptors advertise) before also trying the other methods (kdb, 
bios, triple fault, etc.) to reboot the box.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] KVM: Device Assignment with VT-d

[Zhang, Xiantao]

Amit Shah wrote:
> * On Tuesday 26 Aug 2008 16:12:56 Zhang, Xiantao wrote:
>> Amit Shah wrote:
>>> * On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:
 Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to
 avoid future code move.
>>> 
>>> As of now, device assignment resides inside the x86 directory and is
>>> only tested in x86 environment. Once we support ia64, we'll have a
>>> lot of files moving anyway.
>> 
>> Just a suggestion.  Even if put it @ virt/kvm, we still can make it
>> only compiled with x86 before eanbling it for ia64. :)
> 
> Sure; I'm fine with that :-)

>> Have you considered the cross-arch support in the current code?
> 
> I've not, since I don't know much about ia64, but Allen had mentioned
> that it shouldn't take much effort to port the current code to ia64.

Okay. Thanks for your explanation! 
Xiantao

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Frans Meulenbroeks]

2008/8/26 Avi Kivity <[EMAIL PROTECTED]>:

> It seems excessive.  Most machines will hardly run without acpi.

Well, I'm fairly sure that most of the systems running linux (or some
variant like uclinux), do not support acpi.

Linux is used a lot in embedded systems (like routers and NAS-es and
probably set-top boxes). I guess the # of embedded systems with some
linux flavour on it is substantially bigger than the desktop systems.
Most of these are ARM or MIPS based and do not support ACPI.

Frans.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] KVM: Device Assignment with VT-d

[Amit Shah]

* On Tuesday 26 Aug 2008 16:12:56 Zhang, Xiantao wrote:
> Amit Shah wrote:
> > * On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:
> >> Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to
> >> avoid future code move.
> >
> > As of now, device assignment resides inside the x86 directory and is
> > only tested in x86 environment. Once we support ia64, we'll have a
> > lot of files moving anyway.
>
> Just a suggestion.  Even if put it @ virt/kvm, we still can make it only
> compiled with x86 before eanbling it for ia64. :)

Sure; I'm fine with that :-)

> Have you considered the cross-arch support in the current code?

I've not, since I don't know much about ia64, but Allen had mentioned that it 
shouldn't take much effort to port the current code to ia64.

Amit
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Alan Cox]

> It seems excessive.  Most machines will hardly run without acpi.

*Recent* machines.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] KVM: Device Assignment with VT-d

[Zhang, Xiantao]

Amit Shah wrote:
> * On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:
>> Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to
>> avoid future code move.
> 
> As of now, device assignment resides inside the x86 directory and is
> only tested in x86 environment. Once we support ia64, we'll have a
> lot of files moving anyway.

Just a suggestion.  Even if put it @ virt/kvm, we still can make it only
compiled with x86 before eanbling it for ia64. :)
Have you considered the cross-arch support in the current code?

> However, I don't have any preference for the location of vtd.c;
> depends on what Avi thinks.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Ingo Molnar]

* Pavel Machek <[EMAIL PROTECTED]> wrote:

> On Mon 2008-08-25 13:11:27, Avi Kivity wrote:
> > Triple-fault and keyboard reset may assert INIT instead of RESET; however
> > INIT is blocked when Intel VT is enabled.  This leads to a partially reset
> > machine when invoking emergency_restart via sysrq-b: the processor is still
> > working but other parts of the system are dead.
> > 
> > Default to rebooting via ACPI, which correctly asserts RESET and reboots the
> > machine.
> > 
> > This is safe since we will fall back to keyboard reset and triple fault if
> > acpi is not enabled or if the reset is not successful.
> > 
> > Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> 
> "ACPI" and "safe" in one sentence. /me bets this will break lot of 
> machines.

maybe. OTOH, it's just about PIO accesses and those tend to be pretty 
safe. I would not be surprised if Windows used the ACPI reboot sequence 
too by default.

PIO access cannot really fail or fault (other than locking up in SMM 
mode) - it can in practice be at most non-effective (the box wont 
reboot) - in which case we'll still cycle through all the other current 
reboot methods.

So i think we are on the safe side. Not for v2.6.27 obviously, but maybe 
for v2.6.28, if all testing is a success. (which it is on a healthy 
range of x86 hardware we test -tip on)

> What about only doing that when enabling VT?

hm, i'd much rather have consistent behavior, so that we have less 
variables. If this breaks anywhere, we want to know about it ASAP and it 
should be pretty debuggable. ('box hangs/crashes during reboot')

In fact this change might unbreak some systems - we have a ton of DMI 
driven reboot quirks and i dont think they are anywhere close to 
complete. It's also very easy to revert, if it were to cause any 
trouble.

What do you think?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] KVM: Device Assignment with VT-d

[Amit Shah]

* On Tuesday 26 Aug 2008 15:58:42 Zhang, Xiantao wrote:
> Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to avoid
> future code move.

As of now, device assignment resides inside the x86 directory and is only 
tested in x86 environment. Once we support ia64, we'll have a lot of files 
moving anyway.

However, I don't have any preference for the location of vtd.c; depends on 
what Avi thinks.

Amit
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] KVM: Device Assignment with VT-d

[Zhang, Xiantao]

Maybe vtd.c should be put @ virt/kvm so that ia64 can share it to avoid
future code move.  
Thanks
Xiantao

Amit Shah wrote:
> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
> 
> Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
> 
> This patch enables PCI device assignment based on VT-d support.
> When a device is assigned to the guest, the guest memory is pinned and
> the mapping is updated in the VT-d IOMMU.
> 
> [Amit: Expose KVM_CAP_IOMMU so we can check if an IOMMU is present
> and also control enable/disable from userspace]
> 
> Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
> Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
> Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
> Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
> ---
>  arch/x86/kvm/Makefile  |3 +
>  arch/x86/kvm/vtd.c |  203
>   arch/x86/kvm/x86.c 
>  |   14 +++ include/asm-x86/kvm_host.h |3 +
>  include/linux/kvm.h|3 +
>  include/linux/kvm_host.h   |   32 +++
>  virt/kvm/kvm_main.c|9 ++-
>  7 files changed, 266 insertions(+), 1 deletions(-)
>  create mode 100644 arch/x86/kvm/vtd.c
> 
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index d0e940b..3072b17 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -12,6 +12,9 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
> 
>  kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o
>   lapic.o \ i8254.o
> +ifeq ($(CONFIG_DMAR),y)
> +kvm-objs += vtd.o
> +endif
>  obj-$(CONFIG_KVM) += kvm.o
>  kvm-intel-objs = vmx.o
>  obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
> diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
> new file mode 100644
> index 000..4336769
> --- /dev/null
> +++ b/arch/x86/kvm/vtd.c
> @@ -0,0 +1,203 @@
> +/*
> + * Copyright (c) 2006, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it + * under the terms and conditions of the GNU General
> Public License, + * version 2, as published by the Free Software
> Foundation. + *
> + * This program is distributed in the hope it will be useful, but
> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> General Public License for + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along with + * this program; if not, write to the Free Software
> Foundation, Inc., 59 Temple + * Place - Suite 330, Boston, MA
> 02111-1307 USA. + *
> + * Copyright (C) 2006-2008 Intel Corporation
> + * Copyright IBM Corporation, 2008
> + * Author: Allen M. Kay <[EMAIL PROTECTED]>
> + * Author: Weidong Han <[EMAIL PROTECTED]>
> + * Author: Ben-Ami Yassour <[EMAIL PROTECTED]>
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int kvm_iommu_unmap_memslots(struct kvm *kvm);
> +
> +int kvm_iommu_map_pages(struct kvm *kvm,
> +   gfn_t base_gfn, unsigned long npages)
> +{
> + gfn_t gfn = base_gfn;
> + pfn_t pfn;
> + int i, rc;
> + struct dmar_domain *domain = kvm->arch.intel_iommu_domain;
> +
> + /* check if iommu exists and in use */
> + if (!domain)
> + return 0;
> +
> + for (i = 0; i < npages; i++) {
> + /* check if already mapped */
> + pfn = (pfn_t)intel_iommu_iova_to_pfn(domain,
> +  gfn_to_gpa(gfn));
> + if (pfn && !is_mmio_pfn(pfn))
> + continue;
> +
> + pfn = gfn_to_pfn(kvm, gfn);
> + if (!is_mmio_pfn(pfn)) {
> + rc = intel_iommu_page_mapping(domain,
> +   gfn_to_gpa(gfn),
> +   pfn_to_hpa(pfn),
> +   PAGE_SIZE,
> +   DMA_PTE_READ |
> +   DMA_PTE_WRITE);
> + if (rc) {
> + kvm_release_pfn_clean(pfn);
> + printk(KERN_DEBUG "kvm_iommu_map_pages:"
> +"iommu failed to map pfn=%lx\n",
pfn);
> + return rc;
> + }
> + } else {
> + printk(KERN_DEBUG "kvm_iommu_map_page:"
> +"invalid pfn=%lx\n", pfn);
> + return 0;
> + }
> +
> + gfn++;
> + }
> + return 0;
> +}
> +
> +static int kvm_iommu_map_memslots(struct kvm *kvm)
> +{
> + int i, rc;
> +
> + down_read(&kvm->slots_lock);
> + for (i = 0; i < kvm->nmemslots; i++) {
> + rc = kvm_iommu_map_pages(kvm, kvm->memslots[i].base_gfn,
> +  kvm->memslots[i].npages);
> + if (rc) {
> +  

Re: [PATCH] x86: default to reboot via ACPI

[Avi Kivity]

Pavel Machek wrote:

"ACPI" and "safe" in one sentence. /me bets this will break lot of
machines.

  


We're in 2008 according to date(1).


What about only doing that when enabling VT?
Pavel

  


It seems excessive.  Most machines will hardly run without acpi.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86: default to reboot via ACPI

[Pavel Machek]

On Mon 2008-08-25 13:11:27, Avi Kivity wrote:
> Triple-fault and keyboard reset may assert INIT instead of RESET; however
> INIT is blocked when Intel VT is enabled.  This leads to a partially reset
> machine when invoking emergency_restart via sysrq-b: the processor is still
> working but other parts of the system are dead.
> 
> Default to rebooting via ACPI, which correctly asserts RESET and reboots the
> machine.
> 
> This is safe since we will fall back to keyboard reset and triple fault if
> acpi is not enabled or if the reset is not successful.
> 
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>

"ACPI" and "safe" in one sentence. /me bets this will break lot of
machines.

What about only doing that when enabling VT?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

paravirtualized windows net driver stop after some days on XP guest

[Yann Dupont]

Hello. I'm using kvm whit great succes for various OS. Very good job.

In June I started using paravirtualized drivers.

Since that we encountered sporadic loss of connectivity on some Xp
guests after some days of uptime.
This was with KVM 70. I upgraded to KVM 73 4 days ago, and this morning
1 off my Xp guests had no connectivity.

Putting the interface off then on via panel control  revives network
instantly.  Seems like a bug on the windows driver side .
This is occurring on 2 Xp guests, they have moderate to low network load.

They have 1 CPU , the hal is the non acpi one (because they were
installed in KVM-23 timeframe)

I also have 2003 guests, and so far I haven't encountered the problem.

Also have linux guests, with net AND disk virtio , AND high load without
problem.
Best Regards,

--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.51.12.53.91 - Mail/Jabber : [EMAIL PROTECTED]


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VT-d support for device assignment

[Avi Kivity]

Amit Shah wrote:

The following two patches contain VT-d support for device assignment for KVM 
guests.

The first patch contains the changes that are required to the generic VT-d code.

The second patch contains the changes to KVM.

Since the last send, I've updated the 2nd patch to expose KVM_CAP_IOMMU and 
check for the existence of an IOMMU before using one. I've also preserved the 
'From' field for both the patches so that the original authors are credited for 
the patches.

The command line currently should be invoked with the parameter:

-pcidevice dev=00:13.0,dma=iommu
  


Why not default to iommu if one is available?

btw, -usbdevice prefixes host devices with host:, no?  maybe adopt the 
convention for -pcidevice?


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] VT-d: changes to support KVM

[Amit Shah]

From: Kay, Allen M <[EMAIL PROTECTED]>

This patch extends the VT-d driver to support KVM

[Ben: fixed memory pinning]

Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
---
 drivers/pci/dmar.c  |4 +-
 drivers/pci/intel-iommu.c   |  117 ++-
 drivers/pci/intel-iommu.h   |  344 -
 drivers/pci/iova.c  |2 +-
 drivers/pci/iova.h  |   52 ---
 include/linux/intel-iommu.h |  355 +++
 include/linux/iova.h|   52 +++
 7 files changed, 523 insertions(+), 403 deletions(-)
 delete mode 100644 drivers/pci/intel-iommu.h
 delete mode 100644 drivers/pci/iova.h
 create mode 100644 include/linux/intel-iommu.h
 create mode 100644 include/linux/iova.h

diff --git a/drivers/pci/dmar.c b/drivers/pci/dmar.c
index 8bf86ae..1df28ea 100644
--- a/drivers/pci/dmar.c
+++ b/drivers/pci/dmar.c
@@ -26,8 +26,8 @@
 
 #include 
 #include 
-#include "iova.h"
-#include "intel-iommu.h"
+#include 
+#include 
 
 #undef PREFIX
 #define PREFIX "DMAR:"
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 8d0e60a..1eefc60 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -20,6 +20,7 @@
  * Author: Anil S Keshavamurthy <[EMAIL PROTECTED]>
  */
 
+#undef DEBUG
 #include 
 #include 
 #include 
@@ -33,8 +34,8 @@
 #include 
 #include 
 #include 
-#include "iova.h"
-#include "intel-iommu.h"
+#include 
+#include 
 #include  /* force_iommu in this header in x86-64*/
 #include 
 #include 
@@ -160,7 +161,7 @@ static inline void *alloc_domain_mem(void)
return iommu_kmem_cache_alloc(iommu_domain_cache);
 }
 
-static inline void free_domain_mem(void *vaddr)
+static void free_domain_mem(void *vaddr)
 {
kmem_cache_free(iommu_domain_cache, vaddr);
 }
@@ -1414,7 +1415,7 @@ static void domain_remove_dev_info(struct dmar_domain 
*domain)
  * find_domain
  * Note: we use struct pci_dev->dev.archdata.iommu stores the info
  */
-struct dmar_domain *
+static struct dmar_domain *
 find_domain(struct pci_dev *pdev)
 {
struct device_domain_info *info;
@@ -2430,3 +2431,111 @@ int __init intel_iommu_init(void)
return 0;
 }
 
+void intel_iommu_domain_exit(struct dmar_domain *domain)
+{
+   u64 end;
+
+   /* Domain 0 is reserved, so dont process it */
+   if (!domain)
+   return;
+
+   end = DOMAIN_MAX_ADDR(domain->gaw);
+   end = end & (~PAGE_MASK_4K);
+
+   /* clear ptes */
+   dma_pte_clear_range(domain, 0, end);
+
+   /* free page tables */
+   dma_pte_free_pagetable(domain, 0, end);
+
+   iommu_free_domain(domain);
+   free_domain_mem(domain);
+}
+EXPORT_SYMBOL_GPL(intel_iommu_domain_exit);
+
+struct dmar_domain *intel_iommu_domain_alloc(struct pci_dev *pdev)
+{
+   struct dmar_drhd_unit *drhd;
+   struct dmar_domain *domain;
+   struct intel_iommu *iommu;
+
+   drhd = dmar_find_matched_drhd_unit(pdev);
+   if (!drhd) {
+   printk(KERN_ERR "intel_iommu_domain_alloc: drhd == NULL\n");
+   return NULL;
+   }
+
+   iommu = drhd->iommu;
+   if (!iommu) {
+   printk(KERN_ERR
+   "intel_iommu_domain_alloc: iommu == NULL\n");
+   return NULL;
+   }
+   domain = iommu_alloc_domain(iommu);
+   if (!domain) {
+   printk(KERN_ERR
+   "intel_iommu_domain_alloc: domain == NULL\n");
+   return NULL;
+   }
+   if (domain_init(domain, DEFAULT_DOMAIN_ADDRESS_WIDTH)) {
+   printk(KERN_ERR
+   "intel_iommu_domain_alloc: domain_init() failed\n");
+   intel_iommu_domain_exit(domain);
+   return NULL;
+   }
+   return domain;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_domain_alloc);
+
+int intel_iommu_context_mapping(
+   struct dmar_domain *domain, struct pci_dev *pdev)
+{
+   int rc;
+   rc = domain_context_mapping(domain, pdev);
+   return rc;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_context_mapping);
+
+int intel_iommu_page_mapping(
+   struct dmar_domain *domain, dma_addr_t iova,
+   u64 hpa, size_t size, int prot)
+{
+   int rc;
+   rc = domain_page_mapping(domain, iova, hpa, size, prot);
+   return rc;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_page_mapping);
+
+void intel_iommu_detach_dev(struct dmar_domain *domain, u8 bus, u8 devfn)
+{
+   detach_domain_for_dev(domain, bus, devfn);
+}
+EXPORT_SYMBOL_GPL(intel_iommu_detach_dev);
+
+struct dmar_domain *
+intel_iommu_find_domain(struct pci_dev *pdev)
+{
+   return find_domain(pdev);
+}
+EXPORT_SYMBOL_GPL(intel_iommu_find_domain);
+
+int intel_iommu_found(void)
+{
+   return g_num_of_iommus;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_found);
+
+u64 intel_iommu_iova_to_pfn(struct dmar_domain *domain, 

VT-d support for device assignment

[Amit Shah]

The following two patches contain VT-d support for device assignment for KVM 
guests.

The first patch contains the changes that are required to the generic VT-d code.

The second patch contains the changes to KVM.

Since the last send, I've updated the 2nd patch to expose KVM_CAP_IOMMU and 
check for the existence of an IOMMU before using one. I've also preserved the 
'From' field for both the patches so that the original authors are credited for 
the patches.

The command line currently should be invoked with the parameter:

-pcidevice dev=00:13.0,dma=iommu
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] KVM: Device Assignment with VT-d

[Amit Shah]

From: Ben-Ami Yassour <[EMAIL PROTECTED]>

Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>

This patch enables PCI device assignment based on VT-d support.
When a device is assigned to the guest, the guest memory is pinned and
the mapping is updated in the VT-d IOMMU.

[Amit: Expose KVM_CAP_IOMMU so we can check if an IOMMU is present
and also control enable/disable from userspace]

Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
---
 arch/x86/kvm/Makefile  |3 +
 arch/x86/kvm/vtd.c |  203 
 arch/x86/kvm/x86.c |   14 +++
 include/asm-x86/kvm_host.h |3 +
 include/linux/kvm.h|3 +
 include/linux/kvm_host.h   |   32 +++
 virt/kvm/kvm_main.c|9 ++-
 7 files changed, 266 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/kvm/vtd.c

diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index d0e940b..3072b17 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,6 +12,9 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
 
 kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
i8254.o
+ifeq ($(CONFIG_DMAR),y)
+kvm-objs += vtd.o
+endif
 obj-$(CONFIG_KVM) += kvm.o
 kvm-intel-objs = vmx.o
 obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
new file mode 100644
index 000..4336769
--- /dev/null
+++ b/arch/x86/kvm/vtd.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2006, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Copyright (C) 2006-2008 Intel Corporation
+ * Copyright IBM Corporation, 2008
+ * Author: Allen M. Kay <[EMAIL PROTECTED]>
+ * Author: Weidong Han <[EMAIL PROTECTED]>
+ * Author: Ben-Ami Yassour <[EMAIL PROTECTED]>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int kvm_iommu_unmap_memslots(struct kvm *kvm);
+
+int kvm_iommu_map_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages)
+{
+   gfn_t gfn = base_gfn;
+   pfn_t pfn;
+   int i, rc;
+   struct dmar_domain *domain = kvm->arch.intel_iommu_domain;
+
+   /* check if iommu exists and in use */
+   if (!domain)
+   return 0;
+
+   for (i = 0; i < npages; i++) {
+   /* check if already mapped */
+   pfn = (pfn_t)intel_iommu_iova_to_pfn(domain,
+gfn_to_gpa(gfn));
+   if (pfn && !is_mmio_pfn(pfn))
+   continue;
+
+   pfn = gfn_to_pfn(kvm, gfn);
+   if (!is_mmio_pfn(pfn)) {
+   rc = intel_iommu_page_mapping(domain,
+ gfn_to_gpa(gfn),
+ pfn_to_hpa(pfn),
+ PAGE_SIZE,
+ DMA_PTE_READ |
+ DMA_PTE_WRITE);
+   if (rc) {
+   kvm_release_pfn_clean(pfn);
+   printk(KERN_DEBUG "kvm_iommu_map_pages:"
+  "iommu failed to map pfn=%lx\n", pfn);
+   return rc;
+   }
+   } else {
+   printk(KERN_DEBUG "kvm_iommu_map_page:"
+  "invalid pfn=%lx\n", pfn);
+   return 0;
+   }
+
+   gfn++;
+   }
+   return 0;
+}
+
+static int kvm_iommu_map_memslots(struct kvm *kvm)
+{
+   int i, rc;
+
+   down_read(&kvm->slots_lock);
+   for (i = 0; i < kvm->nmemslots; i++) {
+   rc = kvm_iommu_map_pages(kvm, kvm->memslots[i].base_gfn,
+kvm->memslots[i].npages);
+   if (rc) {
+   up_read(&kvm->slots_lock);
+   return rc;
+   }
+   }
+   up_read(&kvm->slots_lock);
+   return 0;
+}
+
+int kvm_iommu_map_guest(struct kvm *kvm,
+   struct kvm_assigned_dev_kernel *assigned_dev)
+{
+   struct pci_dev *p

Re: [PATCH 2/2] KVM: Device assignemnt with VT-d

[Avi Kivity]

Amit Shah wrote:

(1 >> 0)?

This is a userspace inteface, so use a generic name like iommu.  We also
need a KVM_CAP so userspace can check whether an iommu is present or not.



How about this?
  


Looks fine.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]IA64: KVM: Enable virtio driver for ia64 in Kconfig.

[Avi Kivity]

Zhang, Xiantao wrote:

Since userspace is ready to use virtio driver. Enable it for ia64 in
kernel. 
  


Applied, thanks.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once

[Avi Kivity]

Zhang, Xiantao wrote:

In practice, I don't expect a problem.  Most users get their kernels
from a distribution.  You should talk to ia64 distribution vendors to
make sure they enable kvm in their ia64 2.6.26+ kernels.



Agree.  Could we change default configration to make preempt_notifier
configured if no more overhead introduced ?  I noticed kvm/s390 has did
in this way.   
  


That's up to your arch maintainer.  I don't recommend it though.  I 
guess ia64 priorities are different, but for x86 we disable anything 
that isn't strictly required.


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resend: patch: qemu + hugetlbfs..

[Avi Kivity]

john cooper wrote:

This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle.  Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.



I must have missed it.  Thanks for persisting.


In a nutshell the intention here is to allow
preallocation of guest huge page backed memory at
qemu initialization time to avoid a quirk in the
kernel's huge page accounting allowing overcommit
of huge pages.  Failure of the kernel to resolve a
guest fault to overcommitted huge page memory during
runtime results in sigkill termination of the guest.
This patch provides the option of avoiding such
behavior at the cost of up-front preallocation of
physical huge pages backing the guest.



What is the motivation for providing an option to disable this?  If we 
can detect mem-path is backed by huge pages somehow, I think we can 
prefault the memory unconditionally.


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] KVM: Device assignemnt with VT-d

[Amit Shah]

* On Friday 22 Aug 2008 23:48:42 Avi Kivity wrote:
> Amit Shah wrote:
> > diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> > index d9ef7d3..2956e35 100644
> > --- a/include/linux/kvm.h
> > +++ b/include/linux/kvm.h
> > @@ -495,4 +495,6 @@ struct kvm_assigned_irq {
> > __u32 flags;
> >  };
> >
> > +#define KVM_DEV_ASSIGN_USE_VTD (1 << 1)
> > +
> >  #endif
>
> (1 >> 0)?
>
> This is a userspace inteface, so use a generic name like iommu.  We also
> need a KVM_CAP so userspace can check whether an iommu is present or not.

How about this?

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 29f94ba..38ab48b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -277,10 +277,11 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
 
list_add(&match->list, &kvm->arch.assigned_dev_head);
 
-   /* currenlty iommu is required for handling dma */
-   r = kvm_iommu_map_guest(kvm, match);
-   if (r)
-   goto out_list_del;
+   if (assigned_dev->flags & KVM_DEV_ASSIGN_ENABLE_IOMMU) {
+   r = kvm_iommu_map_guest(kvm, match);
+   if (r)
+   goto out_list_del;
+   }
 
 out:
mutex_unlock(&kvm->lock);
@@ -1154,6 +1155,9 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PV_MMU:
r = !tdp_enabled;
break;
+   case KVM_CAP_IOMMU:
+   r = intel_iommu_found();
+   break;
default:
r = 0;
break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d9ef7d3..f2eafe1 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -384,6 +384,7 @@ struct kvm_trace_rec {
 #define KVM_CAP_COALESCED_MMIO 15
 #define KVM_CAP_SYNC_MMU 16  /* Changes to host mmap are reflected in guest 
*/
 #define KVM_CAP_DEVICE_ASSIGNMENT 17
+#define KVM_CAP_IOMMU 18
 
 /*
  * ioctls for VM fds
@@ -495,4 +496,6 @@ struct kvm_assigned_irq {
__u32 flags;
 };
 
+#define KVM_DEV_ASSIGN_ENABLE_IOMMU(1 << 0)
+
 #endif
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mandrake-10 not able to boot on kvm-71-73

[Henrik Holst]

mån 2008-08-25 klockan 18:59 +0200 skrev Farkas Levente:

> the situation is more stranger (but probably another bug)
> kvm-70 (and kvm-71) with kmod-kvm-73: working if and only if i start
> mandrake-10 as the first guest, if i start other guest and after i start
> mandrake-10 (both from command line and virt-manager) i've got this (not
> too long) error:
> -
> # /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name mandrake-10 -monitor
> pty -boot c -drive
> file=/dev/VolGroup00/mandrake-10,if=ide,index=0,boot=on -net
> nic,macaddr=00:16:3e:03:37:eb,vlan=0 -net
> tap,fd=20,script=,vlan=0,ifname=vnet3 -serial none -parallel none -usb
> -vnc 127.0.0.1:0
> bind() failed

bind() failed indicates that you are trying to run more than one guest
on the same VNC port that is 127.0.0.1:0 is used on more than one guest
so the second one cannot bind to port 5900.

/Henrik Holst


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html