[kvm-devel] [PATCH 1/2][RFC][v2] kvm: Batch writes to MMIO

[Laurent Vivier]

This patch is the kernel part of the "batch writes to MMIO" patch.

It intoduces the ioctl interface to define MMIO zone it is allowed to delay.
Inside a zone, we can define sub-part we must not delay.

If an MMIO can be delayed, it is stored in a ring buffer which common for all 
VCPUs.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 arch/x86/kvm/x86.c |  172 
 include/asm-x86/kvm.h  |7 ++
 include/asm-x86/kvm_host.h |   23 ++
 include/linux/kvm.h|   16 
 virt/kvm/kvm_main.c|3 +
 5 files changed, 221 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dab3d4f..930986b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1518,6 +1518,103 @@ out:
return r;
 }
 
+static struct kvm_delayed_mmio_zone *kvm_mmio_find_zone(struct kvm *kvm,
+   u64 addr, u32 size)
+{
+   int i;
+   struct kvm_delayed_mmio_zone *zone;
+
+   for (i = 0; i < kvm->arch.nb_mmio_zones; i++) {
+   zone = &kvm->arch.mmio_zone[i];
+
+   /* (addr,size) is fully included in
+* (zone->addr, zone->size)
+*/
+
+   if (zone->addr <= addr &&
+   addr + size <= zone->addr + zone->size)
+   return zone;
+   }
+   return NULL;
+}
+
+static struct kvm_excluded_mmio_zone *
+kvm_mmio_find_excluded(struct kvm_delayed_mmio_zone *zone, u64 addr, u32 size)
+{
+   static struct kvm_excluded_mmio_zone *excluded;
+   int i;
+
+   addr -= zone->addr;
+   for (i = 0; i < zone->nb_excluded_zones; i++) {
+   excluded = &zone->excluded[i];
+
+   if ((excluded->offset <= addr &&
+addr < excluded->offset + excluded->size) ||
+(excluded->offset < addr + size &&
+ addr + size <= excluded->offset +
+   excluded->size))
+   return excluded;
+   }
+   return NULL;
+}
+
+static int kvm_is_delayed_mmio(struct kvm *kvm, u64 addr, u32 size)
+{
+   struct kvm_delayed_mmio_zone *zone;
+   struct kvm_excluded_mmio_zone *excluded;
+
+   zone = kvm_mmio_find_zone(kvm, addr, size);
+   if (zone == NULL)
+   return 0;   /* not a delayed MMIO address */
+
+   excluded = kvm_mmio_find_excluded(zone, addr, size);
+   return excluded == NULL;
+}
+
+static int kvm_vm_ioctl_set_mmio(struct kvm *kvm,
+struct kvm_mmio_zone *zone)
+{
+   struct kvm_delayed_mmio_zone *z;
+
+   if (zone->is_delayed &&
+   kvm->arch.nb_mmio_zones >= KVM_MAX_DELAYED_MMIO_ZONE)
+   return -ENOMEM;
+
+   if (zone->is_delayed) {
+
+   /* already defined ? */
+
+   if (kvm_mmio_find_zone(kvm, zone->addr, 1) ||
+   kvm_mmio_find_zone(kvm, zone->addr + zone->size - 1, 1))
+   return 0;
+
+   z = &kvm->arch.mmio_zone[kvm->arch.nb_mmio_zones];
+   z->addr = zone->addr;
+   z->size = zone->size;
+   kvm->arch.nb_mmio_zones++;
+   return 0;
+   }
+
+   /* exclude some parts of the delayed MMIO zone */
+
+   z = kvm_mmio_find_zone(kvm, zone->addr, zone->size);
+   if (z == NULL)
+   return -EINVAL;
+
+   if (z->nb_excluded_zones >= KVM_MAX_EXCLUDED_MMIO_ZONE)
+   return -ENOMEM;
+
+   if (kvm_mmio_find_excluded(z, zone->addr, 1) ||
+   kvm_mmio_find_excluded(z, zone->addr + zone->size - 1, 1))
+   return 0;
+
+   z->excluded[z->nb_excluded_zones].offset = zone->addr - z->addr;
+   z->excluded[z->nb_excluded_zones].size = zone->size;
+   z->nb_excluded_zones++;
+
+   return 0;
+}
+
 long kvm_arch_vm_ioctl(struct file *filp,
   unsigned int ioctl, unsigned long arg)
 {
@@ -1671,6 +1768,18 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = 0;
break;
}
+   case KVM_SET_MMIO: {
+   struct kvm_mmio_zone zone;
+   r = -EFAULT;
+   if (copy_from_user(&zone, argp, sizeof zone))
+   goto out;
+   r = -ENXIO;
+   r = kvm_vm_ioctl_set_mmio(kvm, &zone);
+   if (r)
+   goto out;
+   r = 0;
+   break;
+   }
default:
;
}
@@ -2706,6 +2815,52 @@ static void vapic_exit(struct kvm_vcpu *vcpu)
mark_page_dirty(vcpu->kvm, apic->vapic_addr >> PAGE_SHIFT);
 }
 
+static int batch_mmio(struct 

[kvm-devel] [PATCH 2/2][RFC][v2] kvm-userspace: Batch writes to MMIO

[Laurent Vivier]

This patch is userspace part of the "batch writes to MMIO" patch.

It defines delayed MMIO zone using kvm_set_mmio() (for VGA and e1000).
It empties the ring buffer and process the MMIO accesses.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 libkvm/libkvm-x86.c  |   18 ++
 libkvm/libkvm.c  |   13 +
 libkvm/libkvm.h  |2 ++
 qemu/hw/cirrus_vga.c |2 ++
 qemu/hw/e1000.c  |8 
 qemu/hw/vga.c|4 
 qemu/qemu-kvm.c  |6 ++
 qemu/qemu-kvm.h  |2 ++
 8 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index d46fdcc..911e079 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -391,6 +391,24 @@ int kvm_set_pit(kvm_context_t kvm, struct kvm_pit_state *s)
 
 #endif
 
+int kvm_set_mmio(kvm_context_t kvm,
+uint8_t is_delayed, uint64_t addr, uint32_t size)
+{
+   struct kvm_mmio_zone zone;
+   int r;
+
+   zone.is_delayed = is_delayed;
+   zone.addr = addr;
+   zone.size = size;
+
+   r = ioctl(kvm->vm_fd, KVM_SET_MMIO, &zone);
+   if (r == -1) {
+   r = -errno;
+   perror("kvm_set_mmio");
+   }
+   return r;
+}
+
 void kvm_show_code(kvm_context_t kvm, int vcpu)
 {
 #define SHOW_CODE_LEN 50
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d1e95a4..b891630 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -861,6 +861,9 @@ int kvm_run(kvm_context_t kvm, int vcpu)
int r;
int fd = kvm->vcpu_fd[vcpu];
struct kvm_run *run = kvm->run[vcpu];
+#if defined(__x86_64__) || defined(__i386__)
+   struct kvm_batch *batch = (void *)run + 2 * PAGE_SIZE;
+#endif
 
 again:
if (!kvm->irqchip_in_kernel)
@@ -879,6 +882,16 @@ again:
 
post_kvm_run(kvm, vcpu);
 
+#if defined(__x86_64__) || defined(__i386__)
+   while (batch->first != batch->last) {
+   kvm->callbacks->mmio_write(kvm->opaque,
+  batch->mmio[batch->first].phys_addr,
+  &batch->mmio[batch->first].data[0],
+  batch->mmio[batch->first].len);
+   batch->first = (batch->first + 1) % KVM_MAX_BATCH;
+   }
+#endif
+
if (r == -1) {
r = handle_io_window(kvm);
goto more;
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 31c0d59..1f453e1 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -448,6 +448,8 @@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned 
long phys_addr,
  unsigned long end_addr, void *buf, void*opaque,
  int (*cb)(unsigned long start, unsigned long len,
void*bitmap, void *opaque));
+int kvm_set_mmio(kvm_context_t kvm,
+uint8_t is_delayed, uint64_t addr, uint32_t size);
 
 /*!
  * \brief Create a memory alias
diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index 2c4aeec..4ef8085 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -3291,6 +3291,8 @@ static void cirrus_init_common(CirrusVGAState * s, int 
device_id, int is_pci)
cirrus_vga_mem_write, s);
 cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
  vga_io_memory);
+if (kvm_enabled())
+qemu_kvm_set_mmio(1, isa_mem_base + 0x000a, 0x2);
 
 s->sr[0x06] = 0x0f;
 if (device_id == CIRRUS_ID_CLGD5446) {
diff --git a/qemu/hw/e1000.c b/qemu/hw/e1000.c
index 0728539..d223631 100644
--- a/qemu/hw/e1000.c
+++ b/qemu/hw/e1000.c
@@ -26,6 +26,7 @@
 #include "hw.h"
 #include "pci.h"
 #include "net.h"
+#include "qemu-kvm.h"
 
 #include "e1000_hw.h"
 
@@ -938,6 +939,13 @@ e1000_mmio_map(PCIDevice *pci_dev, int region_num,
 
 d->mmio_base = addr;
 cpu_register_physical_memory(addr, PNPMMIO_SIZE, d->mmio_index);
+
+if (kvm_enabled()) {
+qemu_kvm_set_mmio(1, addr, PNPMMIO_SIZE);
+qemu_kvm_set_mmio(0, addr + E1000_TCTL, 4);
+qemu_kvm_set_mmio(0, addr + E1000_TDT, 4);
+qemu_kvm_set_mmio(0, addr + E1000_ICR, 4);
+}
 }
 
 static int
diff --git a/qemu/hw/vga.c b/qemu/hw/vga.c
index 3a49573..844c2a7 100644
--- a/qemu/hw/vga.c
+++ b/qemu/hw/vga.c
@@ -2257,6 +2257,8 @@ void vga_init(VGAState *s)
 vga_io_memory = cpu_register_io_memory(0, vga_mem_read, vga_mem_write, s);
 cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
  vga_io_memory);
+if (kvm_enabled())
+   qemu_kvm_set_mmio(1, isa_mem_base + 0x000a, 0x2);
 }
 
 /* Memory mapped interface */
@@ -2332,6 +2334,8 @@ static void vga_mm_init(VGAState *s, target_phys_addr_t 
vram_base,
 cpu_register

[kvm-devel] [PATCH 0/2][RFC][v2] Batch writes to MMIO

[Laurent Vivier]

These two patches allow to batch writes to MMIO.

When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids to have too many context switches on operations
that can wait.

These patches introduce an ioctl() to define MMIO allowed to be delayed.

I made some bentchmark with iperf and e1000:

average on 10 runs

WITHWITHOUT
PATCH   PATCH

257.2 MB/s  193.7 MB/s  33% faster

I've measured host_state_reload on WinXP boot:

WITHWITHOUT
PATCH   PATCH

561397  739708  24% less

I've measured host_state_reload on a VGA text scroll:

WITHWITHOUT
PATCH   PATCH

3976242 1377984970% less...

[PATCH 1/2] kvm: Batch writes to MMIO
- kernel part

[PATCH 2/2] kvm-userspace: Batch writes to MMIO
- userspace part

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

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

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

[Laurent Vivier]

Le jeudi 15 mai 2008 à 15:04 +0300, Avi Kivity a écrit :
> Daniel P. Berrange wrote:
> > On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> >   
> >> Daniel P. Berrange wrote:
> >> 
> >>> With this kind of syntax, now tools generating config files need to make
> >>> up unique names for each drive. So you'll probably end up with them just
> >>> naming things based on the class name + a number appended.
> >>>  
> >>>   
> >> I would hope that tools don't have to resort to reading and writing 
> >> these config files.  Usually a management system would prefer storing 
> >> parameters in its own database, and writing a temporary config file just 
> >> to pass the data seems awkward.  I would much prefer to see the command 
> >> line and monitor retain full control over every configurable parameter.
> >> 
> >
> > I expect that libvirt will create config files - it is only a matter of
> > time before we hit the command line ARGV length limits - particularly
> > with the -net and -drive syntax. People already requesting that we support
> > guests with > 16 disks, and > 8 network cards so command lines get very
> > long. 
> >   
> 
> What are those limits, btw? ISTR 10240 words, but how many chars?

ARG_MAX - _SC_ARG_MAX
The  maximum  length  of  the arguments to the exec(3) family of
functions.  Must not be less than _POSIX_ARG_MAX (4096).

getconf ARG_MAX
131072

And from a configure log I have:

checking the maximum length of command line arguments: 98304

Regards,
Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

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

[Laurent Vivier]

Le mardi 29 avril 2008 à 19:09 +0200, Laurent Vivier a écrit :
> Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
> > Guillaume Thouvenin wrote:
> > > Hello,
> > >
> > >  This patch should solve the problem observed during protected mode
> > > transitions that appears for example during the installation of
> > > openSuse-10.3. Unfortunately there is an issue that crashes
> > > kvm-userspace. I'm not sure if it's a problem introduced by the
> > > patch or if the patch is good and raises a new issue.
> > >   
> > 
> > You still aren't emulating the instructions correctly I think.  Running 
> > your patch, I see:
> > 
> > [  979.755349] Failed vm entry (exit reason 0x21) invalid guest state
> > [  979.755354] emulation at (46e4b) rip 6e0b: ea 10 6e 18
> > [  979.755358] successfully emulated instruction
> > [  979.756105] Failed vm entry (exit reason 0x21) invalid guest state
> > [  979.756109] emulation at (46e50) rip 6e10: 66 b8 20 00
> > [  979.756111] successfully emulated instruction
> > [  979.756749] Failed vm entry (exit reason 0x21) invalid guest state
> > [  979.756752] emulation at (46e54) rip 6e14: 8e d8 8c d0
> > [  979.756755] successfully emulated instruction
> > [  979.757427] Failed vm entry (exit reason 0x21) invalid guest state
> > [  979.757430] emulation at (46e56) rip 6e16: 8c d0 81 e4
> > [  979.757433] successfully emulated instruction
> > [  979.758074] Failed vm entry (exit reason 0x21) invalid guest state
> > [  979.758077] emulation at (46e58) rip 6e18: 81 e4 ff ff
> > 
> > 
> > The corresponding gfxboot code is:
> > 
> >  16301 6E0B EA[106E]1800jmp 
> > pm_seg.prog_c32:switch_to_pm_20
> >  16302  switch_to_pm_20:
> >  16303 
> >  16304  bits 32
> >  16305 
> >  16306 6E10 66B82000mov ax,pm_seg.prog_d16
> >  16307 6E14 8ED8mov ds,ax
> >  16308 
> >  16309 6E16 8CD0mov eax,ss
> >  16310 6E18 81E4and esp,0h
> >  
> > 
> > The VT state should be correct after executing instruction an RIP 6E16 
> > (mov eax, ss).  The next instruction should not cause a vmentry 
> 
> Are you sure ? It is intel notation (opcode dst,src) , so it updates
> eax, not ss. Guillaumes gives us (with gdb notation, opcode src,dst):
> 
>   0x00046e53:  ljmp   $0x18,$0x6e18
> 
>   0x00046e58:  mov$0x20,%ax
> 
> %EAX = 0x20
> 
>   0x00046e5c:  mov%eax,%ds
> 
> %DS = 0x20
> 
>   0x00046e5e:  mov%ss,%eax
> 
> %EAX = %SS = 0x53E1 (in this particular case)
> 
> For me the issue is with instructions with "dst.byte = 0".
> for instance:
> 
> 0x00046e66:  shl$0x4,%eax
> 
> [82768.003174] emulation at (46e66) rip 6e26: c1 e0 04 01
> [82768.035153] writeback: dst.byte 0
> [82768.055174] writeback: dst.ptr  0x
> [82768.087177] writeback: dst.val  0x53e1
> [82768.78] writeback: src.ptr  0x6e28
> [82768.143157] writeback: src.val  0x4
> 
> So my questions are:
> 
> Why dst.val is not 0x53e10 ?

I can answer myself to this one:

emulate_2op_SrcB("sal", c->src, c->dst, ctxt->eflags);

does nothing if dst.byte == 0

So next question is the good question...

> Why dst.byte is 0 ?
> 
> > failure.  The fact that it is for you indicates that you're not updating 
> > guest state correctly.
> > 
> > My guess would be that load_segment_descriptor is not updating the 
> > values within the VMCS.
> > 
> > Regards,
> > 
> > Anthony Liguori
> 
> Regards
> Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

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

[Laurent Vivier]

Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
> Guillaume Thouvenin wrote:
> > Hello,
> >
> >  This patch should solve the problem observed during protected mode
> > transitions that appears for example during the installation of
> > openSuse-10.3. Unfortunately there is an issue that crashes
> > kvm-userspace. I'm not sure if it's a problem introduced by the
> > patch or if the patch is good and raises a new issue.
> >   
> 
> You still aren't emulating the instructions correctly I think.  Running 
> your patch, I see:
> 
> [  979.755349] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.755354] emulation at (46e4b) rip 6e0b: ea 10 6e 18
> [  979.755358] successfully emulated instruction
> [  979.756105] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.756109] emulation at (46e50) rip 6e10: 66 b8 20 00
> [  979.756111] successfully emulated instruction
> [  979.756749] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.756752] emulation at (46e54) rip 6e14: 8e d8 8c d0
> [  979.756755] successfully emulated instruction
> [  979.757427] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.757430] emulation at (46e56) rip 6e16: 8c d0 81 e4
> [  979.757433] successfully emulated instruction
> [  979.758074] Failed vm entry (exit reason 0x21) invalid guest state
> [  979.758077] emulation at (46e58) rip 6e18: 81 e4 ff ff
> 
> 
> The corresponding gfxboot code is:
> 
>  16301 6E0B EA[106E]1800jmp 
> pm_seg.prog_c32:switch_to_pm_20
>  16302  switch_to_pm_20:
>  16303 
>  16304  bits 32
>  16305 
>  16306 6E10 66B82000mov ax,pm_seg.prog_d16
>  16307 6E14 8ED8mov ds,ax
>  16308 
>  16309 6E16 8CD0mov eax,ss
>  16310 6E18 81E4and esp,0h
>  
> 
> The VT state should be correct after executing instruction an RIP 6E16 
> (mov eax, ss).  The next instruction should not cause a vmentry 

Are you sure ? It is intel notation (opcode dst,src) , so it updates
eax, not ss. Guillaumes gives us (with gdb notation, opcode src,dst):

  0x00046e53:  ljmp   $0x18,$0x6e18

  0x00046e58:  mov$0x20,%ax

%EAX = 0x20

  0x00046e5c:  mov%eax,%ds

%DS = 0x20

  0x00046e5e:  mov%ss,%eax

%EAX = %SS = 0x53E1 (in this particular case)

For me the issue is with instructions with "dst.byte = 0".
for instance:

0x00046e66:  shl$0x4,%eax

[82768.003174] emulation at (46e66) rip 6e26: c1 e0 04 01
[82768.035153] writeback: dst.byte 0
[82768.055174] writeback: dst.ptr  0x
[82768.087177] writeback: dst.val  0x53e1
[82768.78] writeback: src.ptr  0x6e28
[82768.143157] writeback: src.val  0x4

So my questions are:

Why dst.val is not 0x53e10 ?
Why dst.byte is 0 ?

> failure.  The fact that it is for you indicates that you're not updating 
> guest state correctly.
> 
> My guess would be that load_segment_descriptor is not updating the 
> values within the VMCS.
> 
> Regards,
> 
> Anthony Liguori

Regards
Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

Re: [kvm-devel] [PATCH 0/2] Batch writes to MMIO

[Laurent Vivier]

Le mercredi 23 avril 2008 à 11:48 -0500, Anthony Liguori a écrit :
> Laurent Vivier wrote:
> > Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
> >   
> >> Laurent Vivier wrote:
> >> 
> >>> Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
> >>> [...]
> >>>   
> >>>   
> >>>> The ne2k is pretty mmio heavy.  You should be able to observe a boost 
> >>>> with something like iperf (guest=>host) I would think if this is a real 
> >>>> savings.
> >>>> 
> >>>> 
> >>> I like your advices :-D
> >>>
> >>> I use iperf with e1000 emulation and a slightly modified patch (to
> >>> detect MMIO write in a loop), server is on the host, client on the
> >>> guest, with default values.
> >>>
> >>> RESULT WITHOUT BATCHING:
> >>>
> >>> [  4]  0.0-10.0 sec235 MBytes197 Mbits/sec
> >>> [  5]  0.0-10.0 sec194 MBytes163 Mbits/sec
> >>> [  4]  0.0-10.0 sec185 MBytes155 Mbits/sec
> >>> [  5]  0.0-10.0 sec227 MBytes190 Mbits/sec
> >>> [  4]  0.0-10.0 sec196 MBytes164 Mbits/sec
> >>> [  5]  0.0-10.0 sec194 MBytes163 Mbits/sec
> >>> [  4]  0.0-10.0 sec184 MBytes154 Mbits/sec
> >>>
> >>> RESULT WITH BATCHING:
> >>>
> >>> 
> >>> Server listening on TCP port 5001
> >>> TCP window size: 85.3 KByte (default)
> >>> 
> >>> [  4]  0.0-10.0 sec357 MBytes299 Mbits/sec
> >>> [  5]  0.0-10.1 sec418 MBytes347 Mbits/sec
> >>> [  4]  0.0-10.0 sec408 MBytes342 Mbits/sec
> >>> [  5]  0.0-10.0 sec422 MBytes353 Mbits/sec
> >>> [  4]  0.0-10.1 sec436 MBytes362 Mbits/sec
> >>> [  5]  0.0-10.0 sec416 MBytes348 Mbits/sec
> >>> [  4]  0.0-10.0 sec431 MBytes361 Mbits/sec
> >>>
> >>> Well, it's nice ?
> >>>   
> >>>   
> >> It's too good to be true.
> >>
> >> I think we're seeing two bugs cancel each other out, resulting in a 
> >> performance gain.  Linux doesn't know how to queue outgoing packets, so 
> >> it bangs on the mmio that starts the transmit after every packet.  mmio 
> >> batching doesn't know that this mmio register is critical for latency, 
> >> so it queues it up.  The result is that you you get not just mmio 
> >> batching, but also packet batching!  Which dramatically improves 
> >> performace at the expense of latency.
> >> 
> >
> > How can I check that ? How can I measure latency ?
> >   
> 
> ping (from guest to host)

I have 40 ms instead of 0.09 ms, so Avi you are right.

Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

Re: [kvm-devel] [PATCH 0/2] Batch writes to MMIO

[Laurent Vivier]

Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
> > [...]
> >   
> >> The ne2k is pretty mmio heavy.  You should be able to observe a boost 
> >> with something like iperf (guest=>host) I would think if this is a real 
> >> savings.
> >> 
> >
> > I like your advices :-D
> >
> > I use iperf with e1000 emulation and a slightly modified patch (to
> > detect MMIO write in a loop), server is on the host, client on the
> > guest, with default values.
> >
> > RESULT WITHOUT BATCHING:
> >
> > [  4]  0.0-10.0 sec235 MBytes197 Mbits/sec
> > [  5]  0.0-10.0 sec194 MBytes163 Mbits/sec
> > [  4]  0.0-10.0 sec185 MBytes155 Mbits/sec
> > [  5]  0.0-10.0 sec227 MBytes190 Mbits/sec
> > [  4]  0.0-10.0 sec196 MBytes164 Mbits/sec
> > [  5]  0.0-10.0 sec194 MBytes163 Mbits/sec
> > [  4]  0.0-10.0 sec184 MBytes154 Mbits/sec
> >
> > RESULT WITH BATCHING:
> >
> > 
> > Server listening on TCP port 5001
> > TCP window size: 85.3 KByte (default)
> > 
> > [  4]  0.0-10.0 sec357 MBytes299 Mbits/sec
> > [  5]  0.0-10.1 sec418 MBytes347 Mbits/sec
> > [  4]  0.0-10.0 sec408 MBytes342 Mbits/sec
> > [  5]  0.0-10.0 sec422 MBytes353 Mbits/sec
> > [  4]  0.0-10.1 sec436 MBytes362 Mbits/sec
> > [  5]  0.0-10.0 sec416 MBytes348 Mbits/sec
> > [  4]  0.0-10.0 sec431 MBytes361 Mbits/sec
> >
> > Well, it's nice ?
> >   
> 
> It's too good to be true.
> 
> I think we're seeing two bugs cancel each other out, resulting in a 
> performance gain.  Linux doesn't know how to queue outgoing packets, so 
> it bangs on the mmio that starts the transmit after every packet.  mmio 
> batching doesn't know that this mmio register is critical for latency, 
> so it queues it up.  The result is that you you get not just mmio 
> batching, but also packet batching!  Which dramatically improves 
> performace at the expense of latency.

How can I check that ? How can I measure latency ?
Perhaps I can swap server and client between guest and host ?

> 
> Sorry (if it's true :)
>

Thank you for your help,
Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

Re: [kvm-devel] [PATCH 0/2] Batch writes to MMIO

[Laurent Vivier]

Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
[...]
> The ne2k is pretty mmio heavy.  You should be able to observe a boost 
> with something like iperf (guest=>host) I would think if this is a real 
> savings.

I like your advices :-D

I use iperf with e1000 emulation and a slightly modified patch (to
detect MMIO write in a loop), server is on the host, client on the
guest, with default values.

RESULT WITHOUT BATCHING:

[  4]  0.0-10.0 sec235 MBytes197 Mbits/sec
[  5]  0.0-10.0 sec194 MBytes163 Mbits/sec
[  4]  0.0-10.0 sec185 MBytes155 Mbits/sec
[  5]  0.0-10.0 sec227 MBytes190 Mbits/sec
[  4]  0.0-10.0 sec196 MBytes164 Mbits/sec
[  5]  0.0-10.0 sec194 MBytes163 Mbits/sec
[  4]  0.0-10.0 sec184 MBytes154 Mbits/sec

RESULT WITH BATCHING:


Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[  4]  0.0-10.0 sec357 MBytes299 Mbits/sec
[  5]  0.0-10.1 sec418 MBytes347 Mbits/sec
[  4]  0.0-10.0 sec408 MBytes342 Mbits/sec
[  5]  0.0-10.0 sec422 MBytes353 Mbits/sec
[  4]  0.0-10.1 sec436 MBytes362 Mbits/sec
[  5]  0.0-10.0 sec416 MBytes348 Mbits/sec
[  4]  0.0-10.0 sec431 MBytes361 Mbits/sec

Well, it's nice ?

Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

Re: [kvm-devel] [PATCH 1/2] kvm: Batch writes to MMIO

[Laurent Vivier]

Le mercredi 23 avril 2008 à 17:31 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > This patch is the kernel part of the "batch writes to MMIO" patch.
> >
> > When kernel has to send MMIO writes to userspace, it stores them
> > in memory until it has to pass the hand to userspace for another
> > reason. This avoids to have too many context switches on operations
> > that can wait.
> >
> > WARNING: this breaks compatibility with old userspace part.
> >
> > Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
> > ---
> >  arch/x86/kvm/x86.c |   21 +
> >  include/asm-x86/kvm_host.h |2 ++
> >  include/linux/kvm.h|   10 +-
> >  virt/kvm/kvm_main.c|3 +++
> >  4 files changed, 35 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 0ce5563..3881056 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -2942,8 +2942,21 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, 
> > struct kvm_run *kvm_run)
> > kvm_x86_ops->decache_regs(vcpu);
> > }
> >  
> > +batch:
> > r = __vcpu_run(vcpu, kvm_run);
> >  
> > +   if (!r && vcpu->mmio_is_write &&
> > +   kvm_run->exit_reason == KVM_EXIT_MMIO &&
> > +   kvm_run->batch_count < KVM_MAX_BATCH) {
> > +   struct kvm_batch *batch = vcpu->arch.batch_data;
> > +   int i = kvm_run->batch_count++;
> > +
> > +   batch[i].phys_addr = vcpu->mmio_phys_addr;
> > +   batch[i].len = vcpu->mmio_size;
> > +   memcpy(batch[i].data, vcpu->mmio_data, batch[i].len);
> >   
> 
> This breaks ordering on smp guests. batch_data needs to be a kvm thing, 
> not a vcpu thing, and locked, of course.

- is ordering between vcpu important when we already delay operations ?
- using vcpu avoids the lock
- Why PIO (pio_data) are vcpu things and not kvm things, then ?

> Also, you don't want to queue writes which trigger I/O since that will 
> affect latency.  Userspace should tell the kernel which mmio addresses 
> are queuable.

I agree (but in my first patch it was easier to ignore this)

> > +
> > +   goto batch;
> >   
> 
> If you move this to within __vcpu_run, you won't need to loop.  Maybe 
> the best place is where we actually decide it's an mmio write.

I agree

> You also need to flush the queue each time you have an in-kernel mmio 
> write.  For example:
> 
> vcpu0 vcpu1
> 
> mmio write (queued)
> apic write -> IPI
>  doesn't see effects of write

I agree

> > +   }
> >  out:
> > if (vcpu->sigset_active)
> > sigprocmask(SIG_SETMASK, &sigsaved, NULL);
> > @@ -3830,6 +3843,13 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> > }
> > vcpu->arch.pio_data = page_address(page);
> >  
> > +   page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > +   if (!page) {
> > +   r = -ENOMEM;
> > +   goto fail;
> > +   }
> > +   vcpu->arch.batch_data = page_address(page);
> > +
> > r = kvm_mmu_create(vcpu);
> > if (r < 0)
> > goto fail_free_pio_data;
> > @@ -3857,6 +3877,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
> > kvm_mmu_destroy(vcpu);
> > up_read(&vcpu->kvm->slots_lock);
> > free_page((unsigned long)vcpu->arch.pio_data);
> > +   free_page((unsigned long)vcpu->arch.batch_data);
> >  }
> >  
> >  #define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1)
> >  #define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) & ~(X86_CR3_PWT | 
> > X86_CR3_PCD))
> > @@ -255,6 +256,7 @@ struct kvm_vcpu_arch {
> > gva_t mmio_fault_cr2;
> > struct kvm_pio_request pio;
> > void *pio_data;
> > +   void *batch_data;
> >  
> >   
> 
> It's an array of structs, no?  So it shouldn't be a void *.

Yes (I love cut&paste...)

> >  
> > +#define KVM_MAX_BATCH (PAGE_SIZE / sizeof(struct kvm_batch))
> > +struct kvm_batch {
> > +   __u64 phys_addr;
> > +   __u32 len;
> > +   __u8  data[8];
> > +};
> >   
> 
> Size is 24 on 64-bit and 20 on 32-bit.  Please pad (after len, so data 
> is nicely aligned).

OK

Thank you, 
Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

Re: [kvm-devel] [PATCH 0/2] Batch writes to MMIO

[Laurent Vivier]

Le mercredi 23 avril 2008 à 17:05 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > These two patches allow to batch writes to MMIO.
> >
> > When kernel has to send MMIO writes to userspace, it stores them
> > in memory until it has to pass the hand to userspace for another
> > reason. This avoids to have too many context switches on operations
> > that can wait.
> >
> >   
> 
> Did you obtain any measurable performance benefit?

Well, the problem is how to measure it. Really, I don't know.

But when I add traces I saw MMIO writes are batched: by group of 170
(this is the max in a page) at the beginning, and by group of 10 with XP
when we move a window.

So all comments are welcome...

> > WARNING: this breaks compatibility with old userspace part.
> >
> >   
> 
> So it's just an RFC :)

Yes... to have some comments how to manage this :)

Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

[kvm-devel] [PATCH 1/2] kvm: Batch writes to MMIO

[Laurent Vivier]

This patch is the kernel part of the "batch writes to MMIO" patch.

When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids to have too many context switches on operations
that can wait.

WARNING: this breaks compatibility with old userspace part.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 arch/x86/kvm/x86.c |   21 +
 include/asm-x86/kvm_host.h |2 ++
 include/linux/kvm.h|   10 +-
 virt/kvm/kvm_main.c|3 +++
 4 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0ce5563..3881056 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2942,8 +2942,21 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, 
struct kvm_run *kvm_run)
kvm_x86_ops->decache_regs(vcpu);
}
 
+batch:
r = __vcpu_run(vcpu, kvm_run);
 
+   if (!r && vcpu->mmio_is_write &&
+   kvm_run->exit_reason == KVM_EXIT_MMIO &&
+   kvm_run->batch_count < KVM_MAX_BATCH) {
+   struct kvm_batch *batch = vcpu->arch.batch_data;
+   int i = kvm_run->batch_count++;
+
+   batch[i].phys_addr = vcpu->mmio_phys_addr;
+   batch[i].len = vcpu->mmio_size;
+   memcpy(batch[i].data, vcpu->mmio_data, batch[i].len);
+
+   goto batch;
+   }
 out:
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &sigsaved, NULL);
@@ -3830,6 +3843,13 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
}
vcpu->arch.pio_data = page_address(page);
 
+   page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+   if (!page) {
+   r = -ENOMEM;
+   goto fail;
+   }
+   vcpu->arch.batch_data = page_address(page);
+
r = kvm_mmu_create(vcpu);
if (r < 0)
goto fail_free_pio_data;
@@ -3857,6 +3877,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
kvm_mmu_destroy(vcpu);
up_read(&vcpu->kvm->slots_lock);
free_page((unsigned long)vcpu->arch.pio_data);
+   free_page((unsigned long)vcpu->arch.batch_data);
 }
 
 struct  kvm *kvm_arch_create_vm(void)
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 9d963cd..2824652 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -26,6 +26,7 @@
 #define KVM_PRIVATE_MEM_SLOTS 4
 
 #define KVM_PIO_PAGE_OFFSET 1
+#define KVM_MMIO_PAGE_OFFSET 2
 
 #define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1)
 #define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) & ~(X86_CR3_PWT | X86_CR3_PCD))
@@ -255,6 +256,7 @@ struct kvm_vcpu_arch {
gva_t mmio_fault_cr2;
struct kvm_pio_request pio;
void *pio_data;
+   void *batch_data;
 
struct kvm_queued_exception {
bool pending;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a281afe..cf0d266 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -94,7 +94,8 @@ struct kvm_run {
__u32 exit_reason;
__u8 ready_for_interrupt_injection;
__u8 if_flag;
-   __u8 padding2[2];
+   __u8 batch_count;
+   __u8 padding2;
 
/* in (pre_kvm_run), out (post_kvm_run) */
__u64 cr8;
@@ -173,6 +174,13 @@ struct kvm_run {
};
 };
 
+#define KVM_MAX_BATCH (PAGE_SIZE / sizeof(struct kvm_batch))
+struct kvm_batch {
+   __u64 phys_addr;
+   __u32 len;
+   __u8  data[8];
+};
+
 /* for KVM_TRANSLATE */
 struct kvm_translation {
/* in */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d3cb4cc..b2234b3 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -796,6 +796,8 @@ static int kvm_vcpu_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
 #ifdef CONFIG_X86
else if (vmf->pgoff == KVM_PIO_PAGE_OFFSET)
page = virt_to_page(vcpu->arch.pio_data);
+   else if (vmf->pgoff == KVM_MMIO_PAGE_OFFSET)
+   page = virt_to_page(vcpu->arch.batch_data);
 #endif
else
return VM_FAULT_SIGBUS;
@@ -1214,6 +1216,7 @@ static long kvm_dev_ioctl(struct file *filp,
r = PAGE_SIZE; /* struct kvm_run */
 #ifdef CONFIG_X86
r += PAGE_SIZE;/* pio data page */
+   r += PAGE_SIZE;/* mmio batch page */
 #endif
break;
case KVM_TRACE_ENABLE:
-- 
1.5.2.4


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

[kvm-devel] [PATCH 0/2] Batch writes to MMIO

[Laurent Vivier]

These two patches allow to batch writes to MMIO.

When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids to have too many context switches on operations
that can wait.

WARNING: this breaks compatibility with old userspace part.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

[PATCH 1/2] kvm: Batch writes to MMIO
- kernel part

[PATCH 2/2] kvm-userspace: Batch writes to MMIO
- userspace part

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

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

[kvm-devel] [PATCH 2/2] kvm-userspace: Batch writes to MMIO

[Laurent Vivier]

This patch is userspace part of the "batch writes to MMIO" patch.

When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids too have to many context switches on operations
that can wait.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 libkvm/libkvm.c |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index 329f29f..be74477 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -864,6 +864,10 @@ int kvm_run(kvm_context_t kvm, int vcpu)
int r;
int fd = kvm->vcpu_fd[vcpu];
struct kvm_run *run = kvm->run[vcpu];
+#if defined(__x86_64__) || defined(__i386__)
+   struct kvm_batch *batch = (void *)run + 2 * PAGE_SIZE;
+   int i;
+#endif
 
 again:
if (!kvm->irqchip_in_kernel)
@@ -882,6 +886,19 @@ again:
 
post_kvm_run(kvm, vcpu);
 
+#if defined(__x86_64__) || defined(__i386__)
+   for (i = 0; i < run->batch_count; i++) {
+   if ((batch[i].phys_addr > 0xa-4 &&
+batch[i].phys_addr <= 0xa) && batch[i].len == 3)
+   continue;
+   kvm->callbacks->mmio_write(kvm->opaque,
+  batch[i].phys_addr,
+  &batch[i].data[0], batch[i].len);
+
+   }
+   run->batch_count = 0;
+#endif
+
if (r == -1) {
r = handle_io_window(kvm);
goto more;
-- 
1.5.2.4


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

Re: [kvm-devel] [Qemu-devel] Re: [RFC] linuxboot Option ROM for Linux kernel booting

[Laurent Vivier]

Le mardi 22 avril 2008 à 08:50 -0500, Anthony Liguori a écrit :
> Nguyen Anh Quynh wrote:
> > Hi,
> >
> > This should be submitted to upstream (but not to kvm-devel list), but
> > this is only the test code that I want to quickly send out for
> > comments. In case it looks OK, I will send it to upstream later.
> >
> > Inspired by extboot and conversations with Anthony and HPA, this
> > linuxboot option ROM is a simple option ROM that intercepts int19 in
> > order to execute linux setup code. This approach eliminates the need
> > to manipulate the boot sector for this purpose.
> >
> > To test it, just load linux kernel with your KVM/QEMU image using
> > -kernel option in normal way.
> >
> > I succesfully compiled and tested it with kvm-66 on Ubuntu 7.10, guest
> > Ubuntu 8.04.
> >   
> 
> For the next rounds, could you actually rebase against upstream QEMU and 
> submit to qemu-devel?  One of Paul Brook's objections to extboot had 
> historically been that it wasn't not easily sharable with other 
> architectures.  With a C version, it seems more reasonable now to do that.

Moreover add a binary version of the ROM in the pc-bios directory: it
avoids to have a cross-compiler to build ROM on non-x86 architecture.

Regards,
Laurent

> Make sure you remove all the old linux boot code too within QEMU along 
> with the -hda checks.
> 
> Regards,
> 
> Anthony Liguori
> 
> > Thanks,
> > Quynh
> >
> >
> > # diffstat linuxboot1.diff
> >  Makefile |   13 -
> >  linuxboot/Makefile   |   40 +++
> >  linuxboot/boot.S |   54 +
> >  linuxboot/farvar.h   |  130 
> > +++
> >  linuxboot/rom.c  |  104 
> >  linuxboot/signrom|binary
> >  linuxboot/signrom.c  |  128 
> > ++
> >  linuxboot/util.h |   69 +++
> >  qemu/Makefile|3 -
> >  qemu/Makefile.target |2
> >  qemu/hw/linuxboot.c  |   39 +++
> >  qemu/hw/pc.c |   22 +++-
> >  qemu/hw/pc.h |5 +
> >  13 files changed, 600 insertions(+), 9 deletions(-)
> >   
> 
> 
> 
> 
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


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

Re: [kvm-devel] extboot usage?

[Laurent Vivier]

Le vendredi 04 avril 2008 à 18:29 +0900, Jun Koi a écrit :
> On 4/3/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> > Jun Koi wrote:
> >
> > > Hi,
> > >
> > > Could someone please post some concret examples on how to use extboot?
> > > I looked around, but saw nothing.
> > >
> > >
> >
> >  Just append boot=on to your -drive parameter.
> >
> 
> OK, but the question is that when I need to have "boot=on"? Because
> without it (or "boot=off"), -drive still works in some cases, right?

You need extboot when you want to boot from a disk which is not managed
by IDE controller.

Regards,
Laurent
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] stable distro for kvm?

[Laurent Vivier]

Le jeudi 14 février 2008 à 23:46 +0200, Dor Laor a écrit :
> On Thu, 2008-02-14 at 12:08 -0500, Andrey Dmitriev wrote:
> > If I want to stick to debian, would the best way to do this be to just
> > download kvm60 source, compile the module and load it in, or does
> > kernel still require upgrading (I think latest on etch is .18 not .20)
> 
> You can stay with debain, the kvm has backward compatibility option that
> makes it possible to compile the kvm modules with kernels >2.6.16.
> You'll need to get the new userspace & kernel repositories and call
> make sync -C kernel LINUX=NEW_KERNEL_PATH.
> make -C kernel will build the modules for your kernel.

FYI,

Debian testing (Lenny) has kvm-60.

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


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

Re: [kvm-devel] kvm-59 doesn't work

[Laurent Vivier]

Le mercredi 23 janvier 2008 à 14:38 +0100, Laurent Vivier a écrit :
> Le mercredi 23 janvier 2008 à 15:29 +0200, Izik Eidus a écrit :
> > Izik Eidus wrote:
> > > Andi Kleen wrote:
> > >> On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote:
> > >>  
> > >>> Andi Kleen wrote:
> > >>>
> > >>>> FWIW it seems things are broken even without -kernel in -59 too. If 
> > >>>> I try
> > >>>> to boot an existing image with just -hda ... the VGA screen just stays
> > >>>> black while the process runs at 99% CPU. Again with -49 it works fine.
> > >>>>
> > >>>>  
> > >>>>   
> > >>> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git 
> > >>> ought to fix it.
> > >>> 
> > >>
> > >> Thanks will try later. How about the oops in 2.6.24 I reported though?
> > >>
> > >> -Andi
> > >>
> > >>   
> > > the bellow patch should fix this opss
> > > (it is targeted for  2.6.24-rc7)
> > >
> > sorry i forgat one break in this patch
> > this is the fixed patch.
> 
> 
> > if ((d & ModRM) && modrm_mod == 3) {
> > src.type = OP_REG;
> [snip]
> > break;
> > }
> > src.type = OP_MEM;
> > 
> 
> So src.type is OP_MEM and not OP_REG... is it what you want ?

Sorry, in fact it is OP_REG, and it is correct...

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


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

Re: [kvm-devel] kvm-59 doesn't work

[Laurent Vivier]

Le mercredi 23 janvier 2008 à 15:29 +0200, Izik Eidus a écrit :
> Izik Eidus wrote:
> > Andi Kleen wrote:
> >> On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote:
> >>  
> >>> Andi Kleen wrote:
> >>>
>  FWIW it seems things are broken even without -kernel in -59 too. If 
>  I try
>  to boot an existing image with just -hda ... the VGA screen just stays
>  black while the process runs at 99% CPU. Again with -49 it works fine.
> 
>   
>    
> >>> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git 
> >>> ought to fix it.
> >>> 
> >>
> >> Thanks will try later. How about the oops in 2.6.24 I reported though?
> >>
> >> -Andi
> >>
> >>   
> > the bellow patch should fix this opss
> > (it is targeted for  2.6.24-rc7)
> >
> sorry i forgat one break in this patch
> this is the fixed patch.


> if ((d & ModRM) && modrm_mod == 3) {
> src.type = OP_REG;
[snip]
> break;
> }
> src.type = OP_MEM;
> 

So src.type is OP_MEM and not OP_REG... is it what you want ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


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

Re: [kvm-devel] [PATCH] janitor: revert accidental type change

[Laurent Vivier]

Le lundi 21 janvier 2008 à 13:23 +0100, Jan Kiszka a écrit :
> While trying to reduce the warning noise (to identify warnings of
> homebrewed patches), I also came across this bogus but fortunately
> harmless type change in bdrv_commit. Fix below.
> 
> Jan

This has already been reported.

Please apply, Avi.

I'm working on a patch to be able to use snapshot=on and cache=off
together, but while I'm fighting against AIO (I've an incomprehensible
EINVAL) you should apply this fix.

Laurent

> 
> Index: kvm-userspace/qemu/block.c
> ===
> --- kvm-userspace.orig/qemu/block.c
> +++ kvm-userspace/qemu/block.c
> @@ -460,7 +460,7 @@ int bdrv_commit(BlockDriverState *bs)
>  BlockDriver *drv = bs->drv;
>  int64_t i, total_sectors;
>  int n, j;
> -unsigned char *sector[512];
> +unsigned char sector[512];
> 
>  if (!drv)
>  return -ENOMEDIUM;
> 


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

Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

Le mercredi 16 janvier 2008 à 08:57 -0600, Anthony Liguori a écrit :
> > Le mardi 15 janvier 2008 à 23:54 +, Daniel P. Berrange a écrit :
[...]
> >>> 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
> >>> easier to modify loop device driver (but perhaps you know another magic
> >>> tool ?)
> >>>   
> >> There has been some work in this area wrt to Xen - the DM-Userspace project
> >> had some working code providing a device mapper target calling out to a 
> >> userspace daemon to handle non-raw file formats like qcow. I don't
> >> know what the state of it is now wrt to upstream kernel / device-mapper,
> >> or even whether it is more than just 'proof of concept', but the project
> >> page is here with some info:
> >>
> >>   http://wiki.xensource.com/xenwiki/DmUserspace
> 
> FWIW, I still think a userspace block device is the Right Way to support 

I agree with you, it was my first idea too, but it introduces complexity
to manage communications between the kernel part of the driver and the
userspace daemon: I don't like complexity.

> these sort of things.  dm-userspace turned out to be difficult as device 
> mapper has some rather strict requirements about alignment that some 
> formats (like qcow) cannot satisfy.
> 
> The loop driver is a terrible base to start from as it does not preserve 
> data integrity.
[...]

But everyone already uses loop as it is currently, so why not to add
more supported formats for the disk image ?
Why do you say it doesn't preserve data integrity ?

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

Le mardi 15 janvier 2008 à 23:54 +, Daniel P. Berrange a écrit :
> On Wed, Jan 16, 2008 at 12:40:06AM +0100, Laurent Vivier wrote:
> > Le mardi 15 janvier 2008 à 18:27 +, Daniel P. Berrange a écrit :
> > > On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> > > > As it should be useful to be able to mount partition from a 
> > > > disk image, (and as I need a break in my bug hunting) I've 
> > > > modified the loop driver to mount raw disk image.
> > > > 
> > > > To not break original loop device, as we have to change minor 
> > > > numbers to manage partitions, a new parameter is added to the module:
> > > 
> > > I don't see the point in modifying the loop device driver when you
> > > can already access the partitions with existing device mapper
> > > functionality & tools.
> > 
> > There are two reasons:
> > 
> > 1- I didn't know kpartx (thank you for the tip)
> > 
> > but using loop device, you will be able to use all partition tables
> > known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
> > ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
> > only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
> > unixware).
> 
> This is an argument for extending kpartx to cope with the other
> partition tables :-)  I have 50/50 split between VMs using files

Good try... but IMHO, I think it is better to let the kernel decode the
partition table...

> vs VMs using LVM volumes - the loop driver patches only help you
> access partitions within a file based image, whereas kpartx can
> access the partitions within any block device, so can support 
> files (via existing loop device) & LVM vols & nested partitions.

I think you're wrong (but you seem to know the subject better than me,
so ...): you should be able to use the modified loop device on the
logical volume to decode partition table.

> 
> > 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
> > easier to modify loop device driver (but perhaps you know another magic
> > tool ?)
> 
> There has been some work in this area wrt to Xen - the DM-Userspace project
> had some working code providing a device mapper target calling out to a 
> userspace daemon to handle non-raw file formats like qcow. I don't
> know what the state of it is now wrt to upstream kernel / device-mapper,
> or even whether it is more than just 'proof of concept', but the project
> page is here with some info:
> 
>   http://wiki.xensource.com/xenwiki/DmUserspace

It seems a very good idea, but what I don't like:
- it seems very complex (like IBM guys like ;-) )
- it is one and a half year old

To be honest, if something good already exists, I take it...

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [Qemu-devel] Re: [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

Le mardi 15 janvier 2008 à 18:27 +, Daniel P. Berrange a écrit :
> On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> > As it should be useful to be able to mount partition from a 
> > disk image, (and as I need a break in my bug hunting) I've 
> > modified the loop driver to mount raw disk image.
> > 
> > To not break original loop device, as we have to change minor 
> > numbers to manage partitions, a new parameter is added to the module:
> 
> I don't see the point in modifying the loop device driver when you
> can already access the partitions with existing device mapper
> functionality & tools.

There are two reasons:

1- I didn't know kpartx (thank you for the tip)

but using loop device, you will be able to use all partition tables
known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
unixware).

2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
easier to modify loop device driver (but perhaps you know another magic
tool ?)

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk

[Laurent Vivier]

As it should be useful to be able to mount partition from a disk image, (and as 
I need a break in my bug hunting) I've modified the loop driver to mount raw 
disk image.

To not break original loop device, as we have to change minor numbers to manage 
partitions, a new parameter is added to the module:

max_part which define the maximum number of partitions by loop device.

By default max_part is equal to 1.

The patch has been created against the current KVM kernel source tree 
(2.6.24-rc6).

Example:

# insmod drivers/block/loop.ko
# ls -ld /dev/loop*
drwxr-xr-x 2 root root 60 2008-01-15 18:49 /dev/loop
brw-rw 1 root disk 7, 0 2008-01-15 19:07 /dev/loop0
brw-rw 1 root disk 7, 1 2008-01-15 19:07 /dev/loop1
brw-rw 1 root disk 7, 2 2008-01-15 19:07 /dev/loop2
brw-rw 1 root disk 7, 3 2008-01-15 19:07 /dev/loop3
brw-rw 1 root disk 7, 4 2008-01-15 19:07 /dev/loop4
brw-rw 1 root disk 7, 5 2008-01-15 19:07 /dev/loop5
brw-rw 1 root disk 7, 6 2008-01-15 19:07 /dev/loop6
brw-rw 1 root disk 7, 7 2008-01-15 19:07 /dev/loop7
# rmmod loop
# insmod drivers/block/loop.ko max_part=16
# ls -ld /dev/loop*
drwxr-xr-x 2 root root 60 2008-01-15 18:49 /dev/loop
brw-rw 1 root disk 7,   0 2008-01-15 19:08 /dev/loop0
brw-rw 1 root disk 7,  16 2008-01-15 19:08 /dev/loop1
brw-rw 1 root disk 7,  32 2008-01-15 19:08 /dev/loop2
brw-rw 1 root disk 7,  48 2008-01-15 19:08 /dev/loop3
brw-rw 1 root disk 7,  64 2008-01-15 19:08 /dev/loop4
brw-rw 1 root disk 7,  80 2008-01-15 19:08 /dev/loop5
brw-rw 1 root disk 7,  96 2008-01-15 19:08 /dev/loop6
brw-rw 1 root disk 7, 112 2008-01-15 19:08 /dev/loop7
# losetup /dev/loop0 etch.img
# ls -ld /dev/loop*
drwxr-xr-x 2 root root 60 2008-01-15 18:49 /dev/loop
brw-rw 1 root disk 7,   0 2008-01-15 19:08 /dev/loop0
brw-rw 1 root disk 7,   1 2008-01-15 19:09 /dev/loop0p1
brw-rw 1 root disk 7,   2 2008-01-15 19:09 /dev/loop0p2
brw-rw 1 root disk 7,   5 2008-01-15 19:09 /dev/loop0p5
brw-rw 1 root disk 7,  16 2008-01-15 19:08 /dev/loop1
brw-rw 1 root disk 7,  32 2008-01-15 19:08 /dev/loop2
brw-rw 1 root disk 7,  48 2008-01-15 19:08 /dev/loop3
brw-rw 1 root disk 7,  64 2008-01-15 19:08 /dev/loop4
brw-rw 1 root disk 7,  80 2008-01-15 19:08 /dev/loop5
brw-rw 1 root disk 7,  96 2008-01-15 19:08 /dev/loop6
brw-rw 1 root disk 7, 112 2008-01-15 19:08 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /m  cdrom  homelib mnt   root srv  usr
bindevinitrd  lost+found  opt   sbin sys  var
boot   etcinitrd.img  media   proc  selinux  tmp  vmlinuz
# umount /mnt
# losetup -d /dev/loop0
# rmmod loop

All comments are welcome, perhaps it is stupid idea...

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/block/loop.c |   43 ---
 1 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 56e2304..f601633 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -82,6 +82,8 @@
 static LIST_HEAD(loop_devices);
 static DEFINE_MUTEX(loop_devices_mutex);
 
+static int part_shift;
+
 /*
  * Transfer functions
  */
@@ -819,6 +821,7 @@ static int loop_set_fd(struct loop_device *lo, struct file 
*lo_file,
}
lo->lo_state = Lo_bound;
wake_up_process(lo->lo_thread);
+   ioctl_by_bdev(bdev, BLKRRPART, 0);
return 0;
 
 out_clr:
@@ -1352,6 +1355,9 @@ static struct block_device_operations lo_fops = {
 static int max_loop;
 module_param(max_loop, int, 0);
 MODULE_PARM_DESC(max_loop, "Maximum number of loop devices");
+static int max_part = 1;
+module_param(max_part, int, 0);
+MODULE_PARM_DESC(max_part, "Maximum number of partition by loop device");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
 
@@ -1404,7 +1410,7 @@ static struct loop_device *loop_alloc(int i)
if (!lo->lo_queue)
goto out_free_dev;
 
-   disk = lo->lo_disk = alloc_disk(1);
+   disk = lo->lo_disk = alloc_disk(1 << part_shift);
if (!disk)
goto out_free_queue;
 
@@ -1414,7 +1420,7 @@ static struct loop_device *loop_alloc(int i)
init_waitqueue_head(&lo->lo_event);
spin_lock_init(&lo->lo_lock);
disk->major = LOOP_MAJOR;
-   disk->first_minor   = i;
+   disk->first_minor   = i << part_shift;
disk->fops  = &lo_fops;
disk->private_data  = lo;
disk->queue = lo->lo_queue;
@@ -1466,7 +1472,7 @@ static struct kobject *loop_probe(dev_t dev, int *part, 
void *data)
struct kobject *kobj;
 
mutex_lock(&loop_devices_mutex);
-   lo = loop_init_one(dev & MINORMASK);
+   lo = loop_init_one((dev & MINORMASK) & 0x0F);
kobj = lo ? get_disk(lo->lo_disk) : ERR_PTR

Re: [kvm-devel] kvm-userspace fails to compile

[Laurent Vivier]

Le mardi 15 janvier 2008 à 15:49 +, Christoph Hellwig a écrit :
> On Mon, Jan 07, 2008 at 03:25:50PM +0100, Laurent Vivier wrote:
> > > Perhaps a ./configure is needed.
> > > 
> > > What's your HEAD?  I have a5b3d2c9b4d4ca3e02f294d14c7df016e070bda7, 
> > > which compiles fine.
> > 
> > OK, I found where is the problem: my KERNELDIR is not the good one.
> > 
> > Thank you for the answers.
> 
> Looks like you were hitting the same problem that I did.  So what's the
> correct KERNELDIR?  Care to post your ./configure line?

It was where I put my KVM kernel sources, for instance:

KERNELDIR=/home/vivierl/Projects/KVM/kvm

generated by:

./configure --kerneldir=/home/vivierl/Projects/KVM/kvm \
--with-patched-kernel

ls /home/vivierl/Projects/KVM/kvm

arch Documentation  ipc  MakefileREPORTING-BUGS
System.map
blockdriversKbuild   mm  samples usr
COPYING  fs kernel   Module.symvers  scripts
virt
CREDITS  includelib  net security
vmlinux
crypto   init   MAINTAINERS  README  sound
vmlinux.o


> I have to add that having compile of userspace code depend on a kernel
> dir is completely broken.  Any chance the kvm maintainers can fix
> userspace code to compile standalone and not depend on a kernel?  Best
> would be to have userspace and the standalone kernel module in entirely
> different repositories.

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit

[Laurent Vivier]

Well, in fact, I think you can't use snapshot with cluster filesystem:
as each qemu instance will write in its own snapshot and will not see
modifications made by other, and I don't think there is currently a way
to share snapshot between qemu instances.

Laurent

Le lundi 07 janvier 2008 à 11:42 -0500, Javier Guerra a écrit :
> On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit :
> > > hopefully, it would now work with "-cache=off", don't you think?
> >
> > Well, I don't think the problem is at the host level but at the guest
> > level, because both instances of qemu share the host cache and thus
> > first instance should see changes made by the second instance (and
> > vice-versa).
> 
> that's what a cluster filesystem is designed to cope with (and in fact 
> expects)
> 
> > There are also some caches at qemu level to emulate DMA, for instance in
> > hw/ide.c it is MAX_MULT_SECTORS (16) which is 8 kB buffer, perhaps your
> > problem is here but "cache=off" doesn't remove this.
> > Did you try to change MAX_MULT_SECTORS to 1 ?
> 
> nope, don't know enough of qemu internals...
> 
> but if those caches can be flushed from the guest, the filesystem
> should do that when writing its metadata
> 
> > What do you call a "cluster filesystem" ?
> 
> GFS, OCFS2, etc.   that is, filesystems that are designed to run on
> more than one host with shared block storage.  usually that means
> FibreChannel or iSCSI, but on VMs, a common backing could work too (at
> least in theory).
> 
> Xen manages it, at least on paravirtualized guests; hadn't tried on
> HVM guests. maybe the IDE-like emulation is too poor an interface to
> handle it.
> 
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit

[Laurent Vivier]

Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit :
> On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > "cache=off" means files is opened with "O_DIRECT" and thus there is no
> > cache in the kernel memory on the host side.
> > IMO, "cache=off" and "snapshot=on" are incompatible because a snapshot
> > can be seen like a cache.
> >
> > > so far, the only way is to setup a network block device (iSCSI, AoE,
> > > nbd). i'd like to simply specify the same backing file for two
> > > instances' hdb parameter.
> >
> > I'm sorry but I don't understand this part.
> 
> to test a cluster filesystem, i need two (virtual) machines with some
> shared storage.  i tried long ago something like this (with (k)qemu):
> 
> - create a disk image, call it hda-1.img
> - boot and install linux on it, shutdown
> - copy to hda-2.img
> - boot it (with new MAC) and change IP, hostname, little things, shutdown
> - boot both with the same bridge, check that network works between them
> - create a new disk image, call id hdb-shr.img
> - boot both VMs, sharing hdb-shr.img:
> 
> qemu -hda=hda-1.img -hdb-shr.img
> qemu -hda=hda-2.img -hdb-shr.img
> 
> - try to setup a cluster filesystem on hdb
> 
> it almost worked... but some writes didn't propagate to the other
> until some extra writes to hdb; so i guessed that each qemu instance
> had some caching on file I/O
> 
> hopefully, it would now work with "-cache=off", don't you think?

Well, I don't think the problem is at the host level but at the guest
level, because both instances of qemu share the host cache and thus
first instance should see changes made by the second instance (and
vice-versa).
There are also some caches at qemu level to emulate DMA, for instance in
hw/ide.c it is MAX_MULT_SECTORS (16) which is 8 kB buffer, perhaps your
problem is here but "cache=off" doesn't remove this.
Did you try to change MAX_MULT_SECTORS to 1 ?

What do you call a "cluster filesystem" ?
 
> > > and snapshots help a lot to go back after blowing up the on-disk 
> > > structures
> >
> > But I think if you use a snapshot there is no reason to use "cache=off"
> 
> in the above case, if both KVM instances share the snapshot without
> cacheing it, the cluster should still work, and have some rollback
> capability at the same time
> 
> or is it too much wishful thinking?

Unfortunately I guess...

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit

[Laurent Vivier]

Le lundi 07 janvier 2008 à 10:34 -0500, Javier Guerra a écrit :
> On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > What I'm wondering now is: is it really useful to have "cache=off" and
> > "snapshot=on" at the same time ?
> 
> does "cache=off" means disk cache? if so, it might be useful to test
> clustering filesystems.

"cache=off" means files is opened with "O_DIRECT" and thus there is no
cache in the kernel memory on the host side.
IMO, "cache=off" and "snapshot=on" are incompatible because a snapshot
can be seen like a cache.

> so far, the only way is to setup a network block device (iSCSI, AoE,
> nbd). i'd like to simply specify the same backing file for two
> instances' hdb parameter.

I'm sorry but I don't understand this part.

> and snapshots help a lot to go back after blowing up the on-disk structures

But I think if you use a snapshot there is no reason to use "cache=off"

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit

[Laurent Vivier]

Le lundi 07 janvier 2008 à 12:47 +0200, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> >   
> >> Carlo Marcelo Arenas Belon wrote:
> >> 
> >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> >>> redefined sector as an array of pointers to char, instead of a statically
> >>> allocated buffer of chars, that was triggering the following warnings :
> >>>
> >>> block.c: In function `bdrv_commit':
> >>> block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible 
> >>> pointer type
> >>> block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible 
> >>> pointer type
> >>>
> >>> Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
> >>>   
> >>>   
> >> Doesn't the cache=off option warrant an allocation here to ensure 
> >> alignment (or perhaps a 1K stack buffer with runtime adjustment)?
> >> 
> >
> > You're right, a good patch should be something like this (it is not
> > tested or even compiled) :
> >   
> 
> Looks good, but patch is corrupted by mail client.

What I'm wondering now is: is it really useful to have "cache=off" and
"snapshot=on" at the same time ?
If not, the patch of Carlo is good, otherwise there is more
modifications to do (in other parts of qemu).

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm-userspace fails to compile

[Laurent Vivier]

Le lundi 07 janvier 2008 à 15:57 +0200, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > but a pull doesn't resolve anything (the clone has the same effect).
> >
> > Is the correction has been pushed... ?
> >
> >   
> 
> Should be...
> 
> Perhaps a ./configure is needed.
> 
> What's your HEAD?  I have a5b3d2c9b4d4ca3e02f294d14c7df016e070bda7, 
> which compiles fine.

OK, I found where is the problem: my KERNELDIR is not the good one.

Thank you for the answers.

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm-userspace fails to compile

[Laurent Vivier]

Le lundi 07 janvier 2008 à 15:26 +0200, Dor Laor a écrit :
> On Mon, 2008-01-07 at 14:14 +0100, Laurent Vivier wrote:
> > The error is:
> > 
> > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
> > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
> > undefined reference to `kvm_enable_vapic'
> > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup':
> > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287:
> > undefined reference to `kvm_enable_tpr_access_reporting'
> > collect2: ld returned 1 exit status
> > make[2]: *** [qemu-system-x86_64] Error 1
> > make[2]: Leaving directory
> > `/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu'
> > make[1]: *** [subdir-x86_64-softmmu] Error 2
> > make[1]: Leaving directory
> > `/home/vivierl/Projects/KVM/kvm-userspace/qemu'
> > make: *** [qemu] Error 2
> > 
> > Any idea ?
> > 
> 
> Please do another pull, it was temporary broken yesterday.
> Dor

Thank you for the answer Dor,

but a pull doesn't resolve anything (the clone has the same effect).

Is the correction has been pushed... ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] kvm-userspace fails to compile

[Laurent Vivier]

The error is:

libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
undefined reference to `kvm_enable_vapic'
libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287:
undefined reference to `kvm_enable_tpr_access_reporting'
collect2: ld returned 1 exit status
make[2]: *** [qemu-system-x86_64] Error 1
make[2]: Leaving directory
`/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu'
make[1]: *** [subdir-x86_64-softmmu] Error 2
make[1]: Leaving directory
`/home/vivierl/Projects/KVM/kvm-userspace/qemu'
make: *** [qemu] Error 2

Any idea ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] kvm-userspace fails to compile

[Laurent Vivier]

The error is:

libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
undefined reference to `kvm_enable_vapic'
libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287:
undefined reference to `kvm_enable_tpr_access_reporting'
collect2: ld returned 1 exit status
make[2]: *** [qemu-system-x86_64] Error 1
make[2]: Leaving directory
`/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu'
make[1]: *** [subdir-x86_64-softmmu] Error 2
make[1]: Leaving directory
`/home/vivierl/Projects/KVM/kvm-userspace/qemu'
make: *** [qemu] Error 2

Any idea ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit

[Laurent Vivier]

Le lundi 07 janvier 2008 à 12:47 +0200, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> >   
> >> Carlo Marcelo Arenas Belon wrote:
> >> 
> >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> >>> redefined sector as an array of pointers to char, instead of a statically
> >>> allocated buffer of chars, that was triggering the following warnings :
> >>>
> >>> block.c: In function `bdrv_commit':
> >>> block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible 
> >>> pointer type
> >>> block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible 
> >>> pointer type
> >>>
> >>> Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
> >>>   
> >>>   
> >> Doesn't the cache=off option warrant an allocation here to ensure 
> >> alignment (or perhaps a 1K stack buffer with runtime adjustment)?
> >> 
> >
> > You're right, a good patch should be something like this (it is not
> > tested or even compiled) :
> >   
> 
> Looks good, but patch is corrupted by mail client.

OK, I'll resend it later (I'd like to compile it at least).

Laurent
-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit

[Laurent Vivier]

Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> Carlo Marcelo Arenas Belon wrote:
> > revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> > redefined sector as an array of pointers to char, instead of a statically
> > allocated buffer of chars, that was triggering the following warnings :
> >
> > block.c: In function `bdrv_commit':
> > block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible 
> > pointer type
> > block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible 
> > pointer type
> >
> > Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
> >   
> 
> Doesn't the cache=off option warrant an allocation here to ensure 
> alignment (or perhaps a 1K stack buffer with runtime adjustment)?

You're right, a good patch should be something like this (it is not
tested or even compiled) :

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
diff --git a/qemu/block.c b/qemu/block.c
index 519be24..c198659 100644
--- a/qemu/block.c
+++ b/qemu/block.c
@@ -460,7 +460,7 @@ int bdrv_commit(BlockDriverState *bs)
 BlockDriver *drv = bs->drv;
 int64_t i, total_sectors;
 int n, j;
-unsigned char *sector[512];
+unsigned char *sector;
 
 if (!drv)
 return -ENOMEDIUM;
@@ -473,15 +473,21 @@ int bdrv_commit(BlockDriverState *bs)
return -ENOTSUP;
 }
 
+sector = qemu_memalign(512,512);
+if (sector == NULL)
+return -ENOMEM;
+
 total_sectors = bdrv_getlength(bs) >> SECTOR_BITS;
 for (i = 0; i < total_sectors;) {
 if (drv->bdrv_is_allocated(bs, i, 65536, &n)) {
 for(j = 0; j < n; j++) {
 if (bdrv_read(bs, i, sector, 1) != 0) {
+qemu_free(sector);
 return -EIO;
 }
 
 if (bdrv_write(bs->backing_hd, i, sector, 1) != 0) {
+qemu_free(sector);
 return -EIO;
 }
 i++;
@@ -491,6 +497,7 @@ int bdrv_commit(BlockDriverState *bs)
 }
 }
 
+qemu_free(sector);
 if (drv->bdrv_make_empty)
return drv->bdrv_make_empty(bs);

-- 
- [EMAIL PROTECTED]  --
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm on hp nx6320 laptop

[Laurent Vivier]

Le mercredi 05 décembre 2007 à 01:49 +0800, 余上 a écrit :
> Hi all ,
> 
> Did someone tried kvm on this machine . I tried and got "kvm: disabled
> by bios" , but I did enable the virtulization option in BIOS . Can
> someone help me with this ?

Some machines need a power-off/power-on cycle to really enable the
option.

Laurent
-- 
- [EMAIL PROTECTED]  --
   "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH v2] kvm: Fix accounting of interrupts during guest execution on s390

[Laurent Vivier]

Le jeudi 15 novembre 2007 à 16:56 +0100, Christian Borntraeger a écrit :
> Am Donnerstag, 15. November 2007 schrieb Laurent Vivier:
> > If I remember correctly time accounting on s390 is more accurate than on
> > x86 ?
> 
> Yes. its done during context switches and resolution is microsecond.
> 
> > Because on x86, as we make the kvm_guest_exit() after local_irq_enable()
> > we can also have IRQ with PF_VCPU set... and we discussed a lot on
> > probability to know if it was good or not. And on x86 it seems good
> > because it is already working like that with system and user time (we
> > account time to the space where tick appears).
> > see http://lkml.org/lkml/2007/10/15/228
> 
> I am not sure I fully understand your point, can you try to explain?

I can try...

on x86 interrupts are accounted to guest time if they occur when PF_VCPU
is set... and this not a problem because x86 time accounting is not
really accurate (and already works like that).

So as s390 accounting is working differently, it seems normal to correct
the accounted value.

To be annoying, it should be clearer to write this like:

if ( (p->flags & PF_VCPU) &&
 !(hardirq_count() - hardirq_offset) &&
 !softirq_count() )
{
account_guest_time(p, cputime);
return;
}

as we have:

#define hardirq_count() (preempt_count() & HARDIRQ_MASK)
#define softirq_count() (preempt_count() & SOFTIRQ_MASK)
#define irq_count() (preempt_count() & (HARDIRQ_MASK |
SOFTIRQ_MASK))

and in account_system_time():

...
if (hardirq_count() - hardirq_offset)
cpustat->irq = cputime64_add(cpustat->irq, tmp);
else if (softirq_count())
cpustat->softirq = cputime64_add(cpustat->softirq, tmp);
else if (p != rq->idle) {
...

So it is easier to understand we don't account this time to guest if we
have hard irq or soft irq

But I agree with your patch.

Laurent

> My patch deals with timer ticks (see hardirq_offset). So if a only a tick
> comes in after local_irq_enable the time is accounted to guest time as 
> before.
> I made a test on x86_64 with burnP6 inside a kvm machine. top showed 100%
> guest time on an otherwise idle host. So the guest  accounting itself did
> still work. I tried some disk and network stress on the host but I did not
> manage to bring hardirq+softirq time above 5%, guest time stayed above
> 90%. At least my simple testcase did not show a bias towards irq time.
> 
> > Le jeudi 15 novembre 2007 à 15:10 +0100, Christian Borntraeger a écrit :
> > > Avi pointed out, that my first patch was broken, here is the 2nd try.
> > > I tested the patch on s390 with CONFIG_VIRT_CPU_ACCOUNTING and on x86_64.
> > > Seems to work.
> > > 
> > > Currently the scheduler checks for PF_VCPU to decide if this
> > > timeslice has to be accounted as guest time. On s390 host 
> > > interrupts are not disabled during guest execution. This causes
> > > theses interrupts to be accounted as guest time if
> > > CONFIG_VIRT_CPU_ACCOUNTING is set.
> > > Solution is to check if an interrupt triggered account_system_time.
> > > As the tick is timer interrupt based, we have to subtract
> > > hardirq_offset.
> > > 
> > > Avi, Ingo, Laurent, feedback is welcome.
> > > 
> > > CC: Ingo Molnar <[EMAIL PROTECTED]>
> > > CC: Avi Kivity <[EMAIL PROTECTED]>
> > > CC: Laurent Vivier <[EMAIL PROTECTED]>
> > > Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
> > > ---
> > >  kernel/sched.c |6 ++
> > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > > 
> > > Index: kvm/kernel/sched.c
> > > ===
> > > --- kvm.orig/kernel/sched.c
> > > +++ kvm/kernel/sched.c
> > > @@ -3395,10 +3395,8 @@ void account_system_time(struct task_str
> > >   struct rq *rq = this_rq();
> > >   cputime64_t tmp;
> > >  
> > > - if (p->flags & PF_VCPU) {
> > > - account_guest_time(p, cputime);
> > > - return;
> > > - }
> > > + if ((p->flags & PF_VCPU) && (irq_count() - hardirq_offset == 0))
> > > + return account_guest_time(p, cputime);
> > >  
> > >   p->stime = cputime_add(p->stime, cputime);
-- 
- [EMAIL PROTECTED]  --
   "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH v2] kvm: Fix accounting of interrupts during guest execution on s390

[Laurent Vivier]

If I remember correctly time accounting on s390 is more accurate than on
x86 ?

Because on x86, as we make the kvm_guest_exit() after local_irq_enable()
we can also have IRQ with PF_VCPU set... and we discussed a lot on
probability to know if it was good or not. And on x86 it seems good
because it is already working like that with system and user time (we
account time to the space where tick appears).

see http://lkml.org/lkml/2007/10/15/228

Laurent

Le jeudi 15 novembre 2007 à 15:10 +0100, Christian Borntraeger a écrit :
> Avi pointed out, that my first patch was broken, here is the 2nd try.
> I tested the patch on s390 with CONFIG_VIRT_CPU_ACCOUNTING and on x86_64.
> Seems to work.
> 
> Currently the scheduler checks for PF_VCPU to decide if this
> timeslice has to be accounted as guest time. On s390 host 
> interrupts are not disabled during guest execution. This causes
> theses interrupts to be accounted as guest time if
> CONFIG_VIRT_CPU_ACCOUNTING is set.
> Solution is to check if an interrupt triggered account_system_time.
> As the tick is timer interrupt based, we have to subtract
> hardirq_offset.
> 
> Avi, Ingo, Laurent, feedback is welcome.
> 
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: Avi Kivity <[EMAIL PROTECTED]>
> CC: Laurent Vivier <[EMAIL PROTECTED]>
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
> ---
>  kernel/sched.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> Index: kvm/kernel/sched.c
> ===
> --- kvm.orig/kernel/sched.c
> +++ kvm/kernel/sched.c
> @@ -3395,10 +3395,8 @@ void account_system_time(struct task_str
>   struct rq *rq = this_rq();
>   cputime64_t tmp;
>  
> - if (p->flags & PF_VCPU) {
> - account_guest_time(p, cputime);
> - return;
> - }
> + if ((p->flags & PF_VCPU) && (irq_count() - hardirq_offset == 0))
> + return account_guest_time(p, cputime);
>  
>   p->stime = cputime_add(p->stime, cputime);
>  
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-- 
- [EMAIL PROTECTED]  --
   "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-52 release

[Laurent Vivier]

Hi Levente,

Le mardi 13 novembre 2007 à 10:07 +0100, Farkas Levente a écrit :
> Avi Kivity wrote:
> > Farkas Levente wrote:
> >> Avi Kivity wrote:
> >>   
> >>> Farkas Levente wrote:
> >>> 
>  first of all fully update your centos (a bit newer kernel), then i use
>  these packages:
>  http://www.lfarkas.org/linux/packages/centos/5/x86_64/
>  use libvirtd and virt-manager too and start the guests from there. and
>  start them manually paralell (i used to reboot the host when i update
>  kvm, the start virt-manager and start each guests). 
>    
> >>> IIRC virt-manager uses /usr/bin/kvm as its qemu launcher.  Maybe it is
> >>> running the old userspace.  Can you ensure that you are using the new
> >>> userspace and new kernel modules at all times?
> >>> 
> >> yes, it's sure. i always run rpm -Uvh kvm... kmod-kvm... and the reboot
> >> the host (just to be sure).
> >>
> >>   
> > 
> > Installing the files means nothing.  You also need to make sure all your
> > tools use the right binaries (or use the command line directly).
> 
> ohh come on. i use linux since 94 and i use redhat/rpm since redhat 3.0
> (not rhel3) i do know how to install and use packages and which files
> are called. there is no any other kvm in the given machine. ok i
> understand that you try to find some kind of reason why it's works for
> you and not for me but that's not the reason.
> anyway it'd be useful to if i can see which version of the userspace
> running ie. give a short message into the stslog on the host about the
> userspace version may be even a warning in case of the kmod and the
> userspace version are different, but currently that's all:
> 
> [EMAIL PROTECTED] ~]# rpm -qa|grep kvm
> kmod-kvm-52-1.2.6.18_8.1.15.el5
> kvm-52-1
> [EMAIL PROTECTED] ~]# rpm -qf /usr/bin/qemu-kvm
> kvm-52-1
> [EMAIL PROTECTED] ~]# rpm -V kvm-52-1
> [EMAIL PROTECTED] ~]# modinfo kvm_intel
> filename:   /lib/modules/2.6.18-8.1.15.el5/extra/kvm/kvm-intel.ko
> license:GPL
> author: Qumranet
> version:kvm-52
> srcversion: F7E80D6C3124584F75EDAAF
> depends:kvm
> vermagic:   2.6.18-8.1.15.el5 SMP mod_unload gcc-4.1
> parm:   bypass_guest_pf:bool
[snip]

perhaps you can try:

- "rpm -ql kvm-52-1"
- "rpm -qf /lib/modules/2.6.18-8.1.15.el5/extra/kvm/kvm-intel.ko"
- "find /lib/modules -name kvm.ko"
- "find /lib/modules -name kvm-intel.ko"
- "type qemu-kvm"

Just to be sure there is no garbage on your system...

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
   "Any sufficiently advanced technology is
  indistinguishable from magic." - Arthur C. Clarke


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] 2.6.23 git current compile error on UP

[Laurent Vivier]

Le jeudi 08 novembre 2007 à 11:55 -0800, Dave Hansen a écrit :
> drivers/kvm/kvm_main.c: In function `kvm_flush_remote_tlbs':
> drivers/kvm/kvm_main.c:220: error: implicit declaration of function 
> `smp_call_function_mask'
> make[2]: *** [drivers/kvm/kvm_main.o] Error 1
> make[1]: *** [drivers/kvm] Error 2
> 
> http://sr71.net/~dave/linux/config-kvm-up
> 
> Looks like that function calls smp_call_function_mask() which is never
> defined for UP.  Nobody else uses it that way, so I'm not sure what the
> right fix is.  I'm not even sure kvm_flush_remote_tlbs() is safe with
> its raw_smp_processor_id() use.  Is there a reason it can't get
> preempted?

Avi has already posted a patch to correct this.

http://lkml.org/lkml/2007/10/24/95

Laurent


signature.asc
Description: Ceci est une partie de message	numériquement signée
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] kvm-userspace: Make tests compile on x86_64

[Laurent Vivier]

These modification are needed to allow me to compile kvm-userspace
on my x86_64 system.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 user/config-x86-common.mak |2 +-
 user/config-x86_64.mak |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak
index c4eb034..3230311 100644
--- a/user/config-x86-common.mak
+++ b/user/config-x86-common.mak
@@ -19,7 +19,7 @@ $(TEST_DIR)/%.o: CFLAGS += -std=gnu99 -ffreestanding
 $(TEST_DIR)/bootstrap: $(TEST_DIR)/bootstrap.o
$(CC) -nostdlib -o $@ -Wl,-T,bootstrap.lds $^
  
-$(TEST_DIR)/irq.flat: $(TEST_DIR)/test/print.o
+$(TEST_DIR)/irq.flat: $(TEST_DIR)/print.o
  
 $(TEST_DIR)/access.flat: $(cstart.o) $(TEST_DIR)/access.o \
$(TEST_DIR)/printf.o $(TEST_DIR)/print.o $(TEST_DIR)/smp.o
diff --git a/user/config-x86_64.mak b/user/config-x86_64.mak
index 6edcdc9..09501d8 100644
--- a/user/config-x86_64.mak
+++ b/user/config-x86_64.mak
@@ -7,6 +7,6 @@ CFLAGS += -m64
 CFLAGS += -D__x86_64__
 CFLAGS += -I $(KERNELDIR)/include
 
-tests = test/access.flat test/irq.flat test/sieve.flat test/simple.flat 
test/stringio.flat test/memtest1.flat
+tests = $(TEST_DIR)/access.flat $(TEST_DIR)/irq.flat $(TEST_DIR)/sieve.flat 
$(TEST_DIR)/simple.flat $(TEST_DIR)/stringio.flat $(TEST_DIR)/memtest1.flat
 
 include config-x86-common.mak
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] kvm-userspace: Add a target to create the tarball

[Laurent Vivier]

This patch adds a target "tar" in the Makefile of kvm-userspace
to create a tarball of kvm, including kvm kernel modules sources.

Use "make tar"
or  "make LINUX=/usr/src/linux-2.6 tar" to create kvm-snapshot-.tar.gz
with module sources from /usr/src/linux-2.6
or  "make VERSION=latest" to create "kvm-latest.tar.gz"

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 Makefile |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 1e59217..3aba0f6 100644
--- a/Makefile
+++ b/Makefile
@@ -65,6 +65,23 @@ srpm:
rpmbuild  --define="_topdir $$(pwd)" -bs $(tmpspec)
$(RM) $(tmpspec)
 
+VERSION=snapshot-$(shell date +%Y%m%d)
+TARNAME=kvm-$(VERSION)
+LINUX=$(shell pwd)/../kvm
+tar:
+   rm -fr $(TARNAME)
+   mkdir $(TARNAME)
+   (cd $(LINUX) && git log -1 | sed -n "s/^commit \(.*\)/kernel:\1/p") 
>  $(TARNAME)/SOURCES
+   git log -1 | sed -n "s/^commit \(.*\)/userspace: \1/p" >> 
$(TARNAME)/SOURCES
+   cp config.mak Makefile configure kvm kvm_stat kvm.spec \
+  Makefile.csdemo doxygen.conf $(TARNAME)
+   cp -pr bios drivers qemu user kernel scripts $(TARNAME)
+   make -C $(TARNAME)/kernel LINUX="$(LINUX)" sync
+   make -C $(TARNAME)/bios clean
+   make -C $(TARNAME) clean
+   tar czf $(TARNAME).tar.gz $(TARNAME)
+   rm -fr $(TARNAME)
+
 clean:
for i in $(if $(WANT_MODULE), kernel) user qemu; do \
make -C $$i clean; \
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 4/4] Let gcc to choose which registers to save (vmx-i386)

[Laurent Vivier]

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of intel i386.

>>> I don't know if its patch is really usefull as it replaces <<<
>>> a popa/pusha by several pop/push.  <<<

* Original code saves following registers:

eax, ebx, ecx, edx, edi, esi, ebp (using popa)

* Patched code:

  - informs GCC that we modify following registers
using the clobber description:

ebx, edi, rsi

  - doesn't save eax because it is an output operand (vmx->fail)

  - cannot put ecx in clobber description because it is an input operand,
but as we modify it and we want to keep its value (vcpu), we must
save it (pop/push)

  - ebp is saved (pop/push) because GCC seems to ignore its use the clobber
description.

  - edx is saved (pop/push) because it is reserved by GCC (REGPARM) and
cannot be put in the clobber description.

  - line "mov (%%esp), %3 \n\t" has been removed because %3
is ecx and ecx is restored just after.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/vmx.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index ec81ebc..890419a 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -2245,7 +2245,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
"push %%rdx; push %%rbp;"
"push %%rcx \n\t"
 #else
-   "pusha; push %%ecx \n\t"
+   "push %%edx; push %%ebp;"
+   "push %%ecx \n\t"
 #endif
ASM_VMX_VMWRITE_RSP_RDX "\n\t"
/* Check if vmlaunch of vmresume is needed */
@@ -2319,9 +2320,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
"mov %%ebp, %c[rbp](%3) \n\t"
"mov %%cr2, %%eax  \n\t"
"mov %%eax, %c[cr2](%3) \n\t"
-   "mov (%%esp), %3 \n\t"
 
-   "pop %%ecx; popa \n\t"
+   "pop %%ecx; pop %%ebp; pop %%edx \n\t"
 #endif
"setbe %0 \n\t"
  : "=q" (vmx->fail)
@@ -2349,6 +2349,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
 #ifdef CONFIG_X86_64
, "rbx", "rdi", "rsi"
, "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15"
+#else
+   , "ebx", "edi", "rsi"
 #endif
  );
 
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 0/4] Let gcc to choose which registers to save

[Laurent Vivier]

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU.

[PATCH 1/4] Let gcc to choose which registers to save (vmx-x86_64)

drivers/kvm/vmx.c |   21 +
1 files changed, 9 insertions(+), 12 deletions(-)

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of intel x86_64.

[PATCH 2/4] Let gcc to choose which registers to save (svm-x86_64)

drivers/kvm/svm.c |   17 -
1 files changed, 8 insertions(+), 9 deletions(-)

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of AMD x86_64.

[PATCH 3/4] Let gcc to choose which registers to save (svm-i386)

drivers/kvm/svm.c |8 
1 files changed, 4 insertions(+), 4 deletions(-)

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of AMD i386

[PATCH 4/4] Let gcc to choose which registers to save (vmx-i386)

drivers/kvm/vmx.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of intel i386.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 1/4] Let gcc to choose which registers to save (vmx-x86_64)

[Laurent Vivier]

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of intel x86_64.

* Original code saves following registers:

rax, rbx, rcx, rdx, rsi, rdi, rbp,
r8, r9, r10, r11, r12, r13, r14, r15

* Patched code:

  - informs GCC that we modify following registers 
using the clobber description:

rbx, rdi, rsi,
r8, r9, r10, r11, r12, r13, r14, r15

  - doesn't save rax because it is an output operand (vmx->fail)

  - cannot put rcx in clobber description because it is an input operand, 
but as we modify it and we want to keep its value (vcpu), we must 
save it (pop/push)

  - rbp is saved (pop/push) because GCC seems to ignore its use in the clobber
description.

  - rdx is saved (pop/push) because it is reserved by GCC (REGPARM) and
cannot be put in the clobber description.

  - line "mov (%%rsp), %3 \n\t" has been removed because %3
is rcx and rcx is restored just after.

  - line ASM_VMX_VMWRITE_RSP_RDX() is moved out of the ifdef/else/endif

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/vmx.c |   21 +
 1 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 97814e4..ec81ebc 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -2242,16 +2242,12 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
asm(
/* Store host registers */
 #ifdef CONFIG_X86_64
-   "push %%rax; push %%rbx; push %%rdx;"
-   "push %%rsi; push %%rdi; push %%rbp;"
-   "push %%r8;  push %%r9;  push %%r10; push %%r11;"
-   "push %%r12; push %%r13; push %%r14; push %%r15;"
+   "push %%rdx; push %%rbp;"
"push %%rcx \n\t"
-   ASM_VMX_VMWRITE_RSP_RDX "\n\t"
 #else
"pusha; push %%ecx \n\t"
-   ASM_VMX_VMWRITE_RSP_RDX "\n\t"
 #endif
+   ASM_VMX_VMWRITE_RSP_RDX "\n\t"
/* Check if vmlaunch of vmresume is needed */
"cmp $0, %1 \n\t"
/* Load guest registers.  Don't clobber flags. */
@@ -2310,12 +2306,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
"mov %%r15, %c[r15](%3) \n\t"
"mov %%cr2, %%rax   \n\t"
"mov %%rax, %c[cr2](%3) \n\t"
-   "mov (%%rsp), %3 \n\t"
 
-   "pop  %%rcx; pop  %%r15; pop  %%r14; pop  %%r13; pop  %%r12;"
-   "pop  %%r11; pop  %%r10; pop  %%r9;  pop  %%r8;"
-   "pop  %%rbp; pop  %%rdi; pop  %%rsi;"
-   "pop  %%rdx; pop  %%rbx; pop  %%rax \n\t"
+   "pop  %%rcx; pop  %%rbp; pop  %%rdx \n\t"
 #else
"xchg %3, (%%esp) \n\t"
"mov %%eax, %c[rax](%3) \n\t"
@@ -2353,7 +2345,12 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
[r15]"i"(offsetof(struct kvm_vcpu, regs[VCPU_REGS_R15])),
 #endif
[cr2]"i"(offsetof(struct kvm_vcpu, cr2))
- : "cc", "memory");
+ : "cc", "memory"
+#ifdef CONFIG_X86_64
+   , "rbx", "rdi", "rsi"
+   , "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15"
+#endif
+ );
 
vcpu->interrupt_window_open =
(vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & 3) == 0;
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 3/4] Let gcc to choose which registers to save (svm-i386)

[Laurent Vivier]

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of AMD i386

* Original code saves following registers:

ebx, ecx, edx, esi, edi, ebp

* Patched code:

  - informs GCC that we modify following registers
using the clobber description:

ebx, ecx, edx, esi, edi

  - rbp is saved (pop/push) because GCC seems to ignore its use in the clobber
description.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/svm.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index c69d6b6..7852d97 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1485,8 +1485,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
 #ifdef CONFIG_X86_64
"push %%rbp; \n\t"
 #else
-   "push %%ebx; push %%ecx; push %%edx;"
-   "push %%esi; push %%edi; push %%ebp;"
+   "push %%ebp; \n\t"
 #endif
 
 #ifdef CONFIG_X86_64
@@ -1557,8 +1556,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
"mov %%edi, %c[rdi](%[svm]) \n\t"
"mov %%ebp, %c[rbp](%[svm]) \n\t"
 
-   "pop  %%ebp; pop  %%edi; pop  %%esi;"
-   "pop  %%edx; pop  %%ecx; pop  %%ebx; \n\t"
+   "pop  %%ebp; \n\t"
 #endif
:
: [svm]"a"(svm),
@@ -1583,6 +1581,8 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
 #ifdef CONFIG_X86_64
, "rbx", "rcx", "rdx", "rsi", "rdi"
, "r8", "r9", "r10", "r11" , "r12", "r13", "r14", "r15"
+#else
+   , "ebx", "ecx", "edx" , "esi", "edi"
 #endif
);
 
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 2/4] Let gcc to choose which registers to save (svm-x86_64)

[Laurent Vivier]

This patch lets GCC to determine which registers to save when we
switch to/from a VCPU in the case of AMD x86_64.

* Original code saves following registers:

rbx, rcx, rdx, rsi, rdi, rbp,
r8, r9, r10, r11, r12, r13, r14, r15

* Patched code:

  - informs GCC that we modify following registers
using the clobber description:

rbx, rcx, rdx, rsi, rdi
r8, r9, r10, r11, r12, r13, r14, r15

  - rbp is saved (pop/push) because GCC seems to ignore its use in the clobber
description.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/svm.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 3cc324a..c69d6b6 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1483,10 +1483,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
 
asm volatile (
 #ifdef CONFIG_X86_64
-   "push %%rbx; push %%rcx; push %%rdx;"
-   "push %%rsi; push %%rdi; push %%rbp;"
-   "push %%r8;  push %%r9;  push %%r10; push %%r11;"
-   "push %%r12; push %%r13; push %%r14; push %%r15;"
+   "push %%rbp; \n\t"
 #else
"push %%ebx; push %%ecx; push %%edx;"
"push %%esi; push %%edi; push %%ebp;"
@@ -1551,10 +1548,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
"mov %%r14, %c[r14](%[svm]) \n\t"
"mov %%r15, %c[r15](%[svm]) \n\t"
 
-   "pop  %%r15; pop  %%r14; pop  %%r13; pop  %%r12;"
-   "pop  %%r11; pop  %%r10; pop  %%r9;  pop  %%r8;"
-   "pop  %%rbp; pop  %%rdi; pop  %%rsi;"
-   "pop  %%rdx; pop  %%rcx; pop  %%rbx; \n\t"
+   "pop  %%rbp; \n\t"
 #else
"mov %%ebx, %c[rbx](%[svm]) \n\t"
"mov %%ecx, %c[rcx](%[svm]) \n\t"
@@ -1585,7 +1579,12 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
  [r14]"i"(offsetof(struct vcpu_svm, vcpu.regs[VCPU_REGS_R14])),
  [r15]"i"(offsetof(struct vcpu_svm, vcpu.regs[VCPU_REGS_R15]))
 #endif
-   : "cc", "memory");
+   : "cc", "memory"
+#ifdef CONFIG_X86_64
+   , "rbx", "rcx", "rdx", "rsi", "rdi"
+   , "r8", "r9", "r10", "r11" , "r12", "r13", "r14", "r15"
+#endif
+   );
 
local_irq_disable();
 
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] soft lockup in kvm_flush_remote_tlbs

[Laurent Vivier]

david ahern a écrit :
> I am trying, unsuccessfully so far, to get a vm running with 4 cpus. It is 
> failing with a soft lockup:
> 
> BUG: soft lockup detected on CPU#3!
>  [] softlockup_tick+0x98/0xa6
>  [] update_process_times+0x39/0x5c
>  [] smp_apic_timer_interrupt+0x5c/0x64
>  [] apic_timer_interrupt+0x1f/0x24
>  [] kvm_flush_remote_tlbs+0xce/0xdb [kvm]
>  [] kvm_mmu_pte_write+0x1f2/0x368 [kvm]
>  [] emulator_write_emulated_onepage+0x73/0xe6 [kvm]
>  [] x86_emulate_insn+0x20d8/0x3348 [kvm]
>  [] x86_decode_insn+0x624/0x872 [kvm]
>  [] emulate_instruction+0x12b/0x258 [kvm]
>  [] handle_exception+0x163/0x23f [kvm_intel]
>  [] kvm_handle_exit+0x70/0x8a [kvm_intel]
>  [] kvm_vcpu_ioctl_run+0x234/0x339 [kvm]
>  [] kvm_vcpu_ioctl+0x0/0xa8f [kvm]
>  [] kvm_vcpu_ioctl+0xbd/0xa8f [kvm]
>  [] save_i387+0x23f/0x273
>  [] __next_cpu+0x12/0x21
>  [] find_busiest_group+0x177/0x462
>  [] setup_sigcontext+0x10d/0x190
>  [] get_page_from_freelist+0x96/0x310
>  [] get_page_from_freelist+0x2a6/0x310
>  [] flush_tlb_others+0x83/0xb3
>  [] flush_tlb_page+0x74/0x77
>  [] set_page_dirty_balance+0x8/0x35
>  [] do_wp_page+0x3a5/0x3bd
>  [] dequeue_signal+0x2d/0x9c
>  [] __handle_mm_fault+0x81b/0x87b
>  [] kvm_vcpu_ioctl+0x0/0xa8f [kvm]
>  [] do_ioctl+0x1c/0x5d
>  [] vfs_ioctl+0x24a/0x25c
>  [] sys_ioctl+0x48/0x5f
>  [] syscall_call+0x7/0xb
> 
> 
> I am working with kvm-48, but also tried the 20071020 snapshot. The stuck 
> code is kvm_flush_remote_tlbs():
> 
>   while (atomic_read(&completed) != needed) {
>   cpu_relax();
>   barrier();
>   }
> 

This part has been removed by commit 49d3bd7e2b990e717aa66e229410b8f5096c4956, 
perhaps you could try it ?

commit 49d3bd7e2b990e717aa66e229410b8f5096c4956
Author: Laurent Vivier <[EMAIL PROTECTED]>
Date:   Mon Oct 22 16:33:07 2007 +0200

 KVM: Use new smp_call_function_mask() in kvm_flush_remote_tlbs()

 In kvm_flush_remote_tlbs(), replace a loop using smp_call_function_single()
 by a single call to smp_call_function_mask() (which is new for x86_64).

 Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
 Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>

> which I take to mean one of the CPUs is not ack'ing the TLB flush request. 

Yes, it seems...

> Is this is a known bug and any options to correct it? It works fine with 2 
> vcpus, but for a comparison with xen I'd like to get the vm working with 4.
> 
> 
> Host stats:
> OS: RHEL5
> Processors: 2-Core 2 Duos (4 processors)
> KVM:  kvm-48 and kvm-20071020-1 snapshot rpms
> QEMU command:
> 
> qemu-kvm -boot c -localtime -hda /opt/kvm/images/cucm.img -m 1536 -smp 4 
> -serial file:/tmp/serial.log -net nic,macaddr=00:1a:4b:34:74:52,model=rtl8139 
> -net tap,ifname=tap0,script=/bin/true -vnc :2 -monitor stdio
> 
> 
> thanks,
> 
> david
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
> 


-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] kvm: external module: backward compatibility for smp_call_function_mask()

[Laurent Vivier]

Before kernel 2.6.24, smp_call_function_mask() is not defined for architecture
x86_64 and not for architecture i386.

This patch defines it in external-module-compat.h to emulate it for older
kernel, it uses codes from arch/x86/kernel/smp_64.c modified to call 
smp_call_single_function() (like in previous version of KVM) instead of 
send_IPI_mask().

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 kernel/external-module-compat.h |   75 +++
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/kernel/external-module-compat.h b/kernel/external-module-compat.h
index bd637db..adc5cd4 100644
--- a/kernel/external-module-compat.h
+++ b/kernel/external-module-compat.h
@@ -421,3 +421,78 @@ typedef _Bool bool;
 #ifndef PF_VCPU
 #define PF_VCPU 0
 #endif
+
+/* 
+ * smp_call_function_mask() is not defined/exported below 2.6.24
+ */
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,24)
+struct kvm_call_data_struct {
+   void (*func) (void *info);
+   void *info;
+   atomic_t started;
+   atomic_t finished;
+   int wait;
+};
+
+static void kvm_ack_smp_call(void *_data)
+{
+   struct kvm_call_data_struct *data = _data;
+   /* if wait == 0, data can be out of scope
+* after atomic_inc(info->started)
+*/
+   void (*func) (void *info) = data->func;
+   void *info = data->info;
+   int wait = data->wait;
+
+   smp_mb();
+   atomic_inc(&data->started);
+   (*func)(info);
+   if (wait) {
+   smp_mb();
+   atomic_inc(&data->finished);
+   }
+}
+
+static inline int smp_call_function_mask(cpumask_t mask, 
+   void (*func) (void *info), void *info, int wait)
+{
+   struct kvm_call_data_struct data;
+   cpumask_t allbutself;
+   int cpus;
+   int cpu;
+
+   allbutself = cpu_online_map;
+   cpu_clear(smp_processor_id(), allbutself);
+
+   cpus_and(mask, mask, allbutself);
+   cpus = cpus_weight(mask);
+
+   if (!cpus)
+   return 0;
+
+   data.func = func;
+   data.info = info;
+   atomic_set(&data.started, 0);
+   data.wait = wait;
+   if (wait)
+   atomic_set(&data.finished, 0);
+
+   for (cpu = first_cpu(mask); cpu != NR_CPUS; cpu = next_cpu(cpu, mask))
+   smp_call_function_single(cpu, kvm_ack_smp_call, &data, 1, 0);
+
+   while (atomic_read(&data.started) != cpus) {
+   cpu_relax();
+   barrier();
+   }
+
+   if (!wait)
+   return 0;
+
+   while (atomic_read(&data.finished) != cpus) {
+   cpu_relax();
+   barrier();
+   }
+   return 0;
+}
+#endif
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Build error

[Laurent Vivier]

Zhao, Yunfeng a écrit :
> Didn't see it on kvm tree. The latest commit is 20 hours ago.
> 

I mean in the mailing list.

> 
>> I think Anthony has posted a patch to correct this, the name is
>> "[kvm-devel] [PATCH] Fix external module build".
>> 
>> Laurent
>> 
>> Zhao, Yunfeng a écrit :
>>> I fails to build the latest tip. A .h file is missing. error:
>>> asm/kvm_para.h: No such file or directory
>>> 
>>> -Original Message- From: root [mailto:[EMAIL PROTECTED]
>>>  Sent: 2007年10月23日 10:49 Subject:
>>> 
>>> make -C kernel make[1]: Entering directory
> 
> 
> 
> 
> - 
> This SF.net email is sponsored by: Splunk Inc. Still grepping through log
> files to find problems?  Stop. Now Search log events and configuration files
> using AJAX and a browser. Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> 
> 
> 
> 
> ___ kvm-devel mailing list 
> kvm-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Build error

[Laurent Vivier]

I think Anthony has posted a patch to correct this, the name is "[kvm-devel] 
[PATCH] Fix external module build".

Laurent

Zhao, Yunfeng a écrit :
> I fails to build the latest tip.
> A .h file is missing.
> error: asm/kvm_para.h: No such file or directory
> 
> -Original Message-
> From: root [mailto:[EMAIL PROTECTED] 
> Sent: 2007年10月23日 10:49
> Subject: 
> 
> make -C kernel
> make[1]: Entering directory 
> `/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel'
> make -j20 -C /lib/modules/2.6.22-rc4/build M=`pwd` "$@"
> make[2]: Entering directory `/usr/src/redhat/BUILD/kernel-2.6.22rc4g85f6038f'
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/svm.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/vmx.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/vmx-debug.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/kvm_main.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/x86.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/mmu.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/x86_emulate.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/anon_inodes.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/irq.o
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/i8259.o
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:19:26:
>  error: asm/kvm_para.h: No such file or directory
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:
>  In function ‘kvm_para_has_feature’:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:23:
>  warning: implicit declaration of function ‘kvm_arch_para_features’
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/lapic.o
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:19:26:
>  error: asm/kvm_para.h: No such file or directory
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:
>  In function ‘kvm_para_has_feature’:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:23:
>  warning: implicit declaration of function ‘kvm_arch_para_features’
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/ioapic.o
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:19:26:
>  error: asm/kvm_para.h: No such file or directory
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:
>  In function ‘kvm_para_has_feature’:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:23:
>  warning: implicit declaration of function ‘kvm_arch_para_features’
>   CC [M]  
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/preempt.o
> In file included from 
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/external-module-compat.h:13,
>  from :1:
> /workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071022210124728/kvm-userspace/kernel/include/linux/kvm_para.h:19:26:
>  error: asm/kvm_para.h: No such file or directory
>

Re: [kvm-devel] [PATCH/RFC] Let gcc to choose which registers to save

[Laurent Vivier]

Avi Kivity a écrit :
> Laurent Vivier wrote:
>>  
>>> Other than that the patch is very welcome -- the excessive register 
>>> saving is very annoying to me.
>>> 
>>
>> I think we can do the same thing with svm.c, but I can't test it.
>>
>>   
> 
> I can test it for you (but a separate patch please -- these are likely 
> to cause trouble with different compilers and options, so I want them to 
> be easy to revert).
> 
> 

OK, thank you

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH/RFC] Let gcc to choose which registers to save

[Laurent Vivier]

Avi Kivity a écrit :
> Laurent Vivier wrote:
>> As x86_64 ABI defines some registers saved by the calling function, it 
>> is not
>> needed to save all registers in the called function when switching to 
>> VCPU.
>> (see http://www.x86-64.org/documentation/abi.pdf, chapter 3.2.1)
>>
>> The best way to do that is to inform GCC which registers we use and let
>> it to save only needed registers.
>>
>>   
> 
> Strange, yesterday I started to do the same thing but dropped it after I 
> got discouraged by reload errors from gcc.

In french, we say "Les beaux esprits se rencontrent" (Voltaire) ;-)
("Great minds think alike")

>> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
>> index 2c6b64a..d6c91ac 100644
>> --- a/drivers/kvm/vmx.c
>> +++ b/drivers/kvm/vmx.c
>> @@ -2243,16 +2243,12 @@ static void vmx_vcpu_run(struct kvm_vcpu 
>> *vcpu, struct kvm_run *kvm_run)
>>  asm(
>>  /* Store host registers */
>>  #ifdef CONFIG_X86_64
>> -"push %%rax; push %%rbx; push %%rdx;"
>> -"push %%rsi; push %%rdi; push %%rbp;"
>> -"push %%r8;  push %%r9;  push %%r10; push %%r11;"
>> -"push %%r12; push %%r13; push %%r14; push %%r15;"
>> +"push %%rdx; push %%rbp;"
>>  "push %%rcx \n\t"
>> -ASM_VMX_VMWRITE_RSP_RDX "\n\t"
>>  #else
>>  "pusha; push %%ecx \n\t"
>> -ASM_VMX_VMWRITE_RSP_RDX "\n\t"
>>  #endif
>> +ASM_VMX_VMWRITE_RSP_RDX "\n\t"
>>  /* Check if vmlaunch of vmresume is needed */
>>  "cmp $0, %1 \n\t"
>>  /* Load guest registers.  Don't clobber flags. */
>> @@ -2311,12 +2307,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, 
>> struct kvm_run *kvm_run)
>>  "mov %%r15, %c[r15](%3) \n\t"
>>  "mov %%cr2, %%rax   \n\t"
>>  "mov %%rax, %c[cr2](%3) \n\t"
>> -"mov (%%rsp), %3 \n\t"
>>  
>> -"pop  %%rcx; pop  %%r15; pop  %%r14; pop  %%r13; pop  %%r12;"
>> -"pop  %%r11; pop  %%r10; pop  %%r9;  pop  %%r8;"
>> -"pop  %%rbp; pop  %%rdi; pop  %%rsi;"
>> -"pop  %%rdx; pop  %%rbx; pop  %%rax \n\t"
>> +"pop  %%rcx; pop  %%rbp; pop  %%rdx \n\t"
>>  #else
>>  "xchg %3, (%%esp) \n\t"
>>  "mov %%eax, %c[rax](%3) \n\t"
>> @@ -2354,7 +2346,12 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, 
>> struct kvm_run *kvm_run)
>>  [r15]"i"(offsetof(struct kvm_vcpu, regs[VCPU_REGS_R15])),
>>  #endif
>>  [cr2]"i"(offsetof(struct kvm_vcpu, cr2))
>> -  : "cc", "memory");
>> +  : "cc", "memory",
>> +#ifdef CONFIG_X86_64
>> +"rbx", "rdi", "rsi",
>> +"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15"
>> +#endif
>> +  );
>>  
> 
> The comma after "memory" worries me.  Can you compile-test on i386?

You're right, I thought I've corrected this. I rework this and test on i386.

> Other than that the patch is very welcome -- the excessive register 
> saving is very annoying to me.

I think we can do the same thing with svm.c, but I can't test it.

Regards,
Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] kvm uses smp_call_function_mask() inkvm_flush_remote_tlbs()

[Laurent Vivier]

Dor Laor a écrit :
> Laurent Vivier wrote:
>> This patches can be applied only on kvm-updates-2.6.24 and 
>> kvm-updates-2.6.25
>> as it needs smp_call_function_mask().
>>
>> In kvm_flush_remote_tlbs(), it replaces a loop using 
>> smp_call_function_single()
>> by a single call to smp_call_function_mask().
>>
> Would you be kind enough to copy the implementation of 
> smp_call_function_mask
> into external_module_compat.h so older kernel's will still work after 
> this commited.

Yes, I can, I think the best solution is to move the old KVM code using 
smp_function_call_single() to external_module_compat.h.

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH/RFC] Let gcc to choose which registers to save

[Laurent Vivier]

As x86_64 ABI defines some registers saved by the calling function, it is not
needed to save all registers in the called function when switching to VCPU.
(see http://www.x86-64.org/documentation/abi.pdf, chapter 3.2.1)

The best way to do that is to inform GCC which registers we use and let
it to save only needed registers.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/vmx.c |   21 +
 1 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 2c6b64a..d6c91ac 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -2243,16 +2243,12 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
asm(
/* Store host registers */
 #ifdef CONFIG_X86_64
-   "push %%rax; push %%rbx; push %%rdx;"
-   "push %%rsi; push %%rdi; push %%rbp;"
-   "push %%r8;  push %%r9;  push %%r10; push %%r11;"
-   "push %%r12; push %%r13; push %%r14; push %%r15;"
+   "push %%rdx; push %%rbp;"
"push %%rcx \n\t"
-   ASM_VMX_VMWRITE_RSP_RDX "\n\t"
 #else
"pusha; push %%ecx \n\t"
-   ASM_VMX_VMWRITE_RSP_RDX "\n\t"
 #endif
+   ASM_VMX_VMWRITE_RSP_RDX "\n\t"
/* Check if vmlaunch of vmresume is needed */
"cmp $0, %1 \n\t"
/* Load guest registers.  Don't clobber flags. */
@@ -2311,12 +2307,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
"mov %%r15, %c[r15](%3) \n\t"
"mov %%cr2, %%rax   \n\t"
"mov %%rax, %c[cr2](%3) \n\t"
-   "mov (%%rsp), %3 \n\t"
 
-   "pop  %%rcx; pop  %%r15; pop  %%r14; pop  %%r13; pop  %%r12;"
-   "pop  %%r11; pop  %%r10; pop  %%r9;  pop  %%r8;"
-   "pop  %%rbp; pop  %%rdi; pop  %%rsi;"
-   "pop  %%rdx; pop  %%rbx; pop  %%rax \n\t"
+   "pop  %%rcx; pop  %%rbp; pop  %%rdx \n\t"
 #else
"xchg %3, (%%esp) \n\t"
"mov %%eax, %c[rax](%3) \n\t"
@@ -2354,7 +2346,12 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu, struct 
kvm_run *kvm_run)
[r15]"i"(offsetof(struct kvm_vcpu, regs[VCPU_REGS_R15])),
 #endif
[cr2]"i"(offsetof(struct kvm_vcpu, cr2))
- : "cc", "memory");
+ : "cc", "memory",
+#ifdef CONFIG_X86_64
+   "rbx", "rdi", "rsi",
+   "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15"
+#endif
+ );
 
vcpu->interrupt_window_open =
(vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & 3) == 0;
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] kvm uses smp_call_function_mask() in kvm_flush_remote_tlbs()

[Laurent Vivier]

This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25
as it needs smp_call_function_mask().

In kvm_flush_remote_tlbs(), it replaces a loop using smp_call_function_single() 
by a single call to smp_call_function_mask().

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm_main.c |   26 +++---
 1 files changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index bf6a86c..6f7b31e 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -200,21 +200,15 @@ void vcpu_put(struct kvm_vcpu *vcpu)
 
 static void ack_flush(void *_completed)
 {
-   atomic_t *completed = _completed;
-
-   atomic_inc(completed);
 }
 
 void kvm_flush_remote_tlbs(struct kvm *kvm)
 {
-   int i, cpu, needed;
+   int i, cpu;
cpumask_t cpus;
struct kvm_vcpu *vcpu;
-   atomic_t completed;
 
-   atomic_set(&completed, 0);
cpus_clear(cpus);
-   needed = 0;
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
vcpu = kvm->vcpus[i];
if (!vcpu)
@@ -223,23 +217,9 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
continue;
cpu = vcpu->cpu;
if (cpu != -1 && cpu != raw_smp_processor_id())
-   if (!cpu_isset(cpu, cpus)) {
-   cpu_set(cpu, cpus);
-   ++needed;
-   }
-   }
-
-   /*
-* We really want smp_call_function_mask() here.  But that's not
-* available, so ipi all cpus in parallel and wait for them
-* to complete.
-*/
-   for (cpu = first_cpu(cpus); cpu != NR_CPUS; cpu = next_cpu(cpu, cpus))
-   smp_call_function_single(cpu, ack_flush, &completed, 1, 0);
-   while (atomic_read(&completed) != needed) {
-   cpu_relax();
-   barrier();
+   cpu_set(cpu, cpus);
}
+   smp_call_function_mask(cpus, ack_flush, NULL, 1);
 }
 
 int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 00/11] KVM updates for Linux 2.6.24-rc review

[Laurent Vivier]

Avi Kivity a écrit :
> Laurent Vivier wrote:
>> Avi Kivity a écrit :
>>> Avi Kivity wrote:
>>>> The following patches fix fallout from the main 2.6.24 KVM merge.  An
>>>> exception is the movnti emulation patch, which adds support for Linux
>>>> 2.6.16 guests.
>>>>
>>>> The patches can be found in kvm.git in the branch kvm-updates-2.6.24.
>>>> There is also a branch kvm-updates-2.6.25 which will form the basis of
>>>> the next merge window submission.
>>>>
>>>> Please review the patches and let me know if something is wrong or if
>>>> a patch is missing.
>>>>
>>>>   
>>>
>>> Laurent, I believe the following patch (in kvm-updates-2.6.25) needs 
>>> to go into 2.6.24 as well.  Can you comment on this?
>> What kind of comment do you want ?
> 
> Well, whether it needs to go into .24.
> 
>> What are the requirements to go in 2.6.24 instead of 2.6.25 ?
>>
>> Is a bug correction enough ? :-P
>>
> 
> It has to fix something real-life, in a real guest.
> 
>> This patch correct a bad behavior of x86_emulate_insn() in case of 
>> error with a REP prefix.
>>
>> This patch is needed because, without it, when REP prefix is used with 
>> an instruction failing for some reasons (like IO or page fault) we 
>> don't restore all modified registers (like RSI and RDI), but only ECX 
>> and EIP, so when we re-enter in x86_emulate_insn() we modify again an 
>> already modified value. Moreover, this patch manages correctly the 
>> case where the instruction fails in writeback().
>>
> 
> Okay, I guess it is needed.  Can you backport it to the branch?  It's 
> very different from kvm-updates-2.6.24...
> 

Well, in fact it is not needed in 2.6.24, because this patch correct a bad 
behavior introduced by commit 57f4e446ebca4aad5c11364baf8477c8cfcb16a4 (which 
is 
not in kvm-update-2.6.24):

KVM: Call x86_decode_insn() only when needed

Move emulate_ctxt to kvm_vcpu to keep emulate context when we exit from kvm
module. Call x86_decode_insn() only when needed. Modify x86_emulate_insn() to
not modify the context if it must be re-entered.

So, in fact, the answer is (after correctly understanding the question): no, 
this patch is not needed in kvm-update-2.6.24.

Regards,
Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 00/11] KVM updates for Linux 2.6.24-rc review

[Laurent Vivier]

Avi Kivity a écrit :
> Avi Kivity wrote:
>> The following patches fix fallout from the main 2.6.24 KVM merge.  An
>> exception is the movnti emulation patch, which adds support for Linux
>> 2.6.16 guests.
>>
>> The patches can be found in kvm.git in the branch kvm-updates-2.6.24.
>> There is also a branch kvm-updates-2.6.25 which will form the basis of
>> the next merge window submission.
>>
>> Please review the patches and let me know if something is wrong or if
>> a patch is missing.
>>
>>   
> 
> 
> Laurent, I believe the following patch (in kvm-updates-2.6.25) needs to 
> go into 2.6.24 as well.  Can you comment on this?

What kind of comment do you want ?
What are the requirements to go in 2.6.24 instead of 2.6.25 ?

Is a bug correction enough ? :-P

This patch correct a bad behavior of x86_emulate_insn() in case of error with a 
REP prefix.

This patch is needed because, without it, when REP prefix is used with an 
instruction failing for some reasons (like IO or page fault) we don't restore 
all modified registers (like RSI and RDI), but only ECX and EIP, so when we 
re-enter in x86_emulate_insn() we modify again an already modified value. 
Moreover, this patch manages correctly the case where the instruction fails in 
writeback().


>> commit 6de232e39be372f85bea96eb741962acc7fcb1f7
>> Author: Laurent Vivier <[EMAIL PROTECTED]>
>> Date:   Mon Oct 1 11:01:06 2007 +0200
>>
>> KVM: x86 emulator: Correct management of REP prefix
>>
>> This patch corrects some errors appearing when we have an 
>> emulation failure
>> on an operation using REP prefix.
>>
>> When x86_emulate_insn() fails, saving EIP and ECX is not enough as 
>> emulation
>> should have modified other registers like RSI or RDI. Moreover, 
>> the emulation
>> can fail on the writeback, and in this case we are not able to 
>> restore
>> registers.
>>
>> At beginning of x86_emulate_insn(), we restore registers from vcpu 
>> as they were
>> not modified by x86d_decode_insn() and we save EIP to be able to 
>> restore it
>> in case of failure.
>>
> 


-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] severe bug in 2.6.23+ kvm.git

[Laurent Vivier]

Christian Borntraeger a écrit :
> Am Freitag, 19. Oktober 2007 schrieb Jan Engelhardt:
>> On Oct 19 2007 15:44, Carsten Otte wrote:
>>> Carsten Otte wrote:
 First thing we do, is figure whether or not 2.6.23.1 as released breaks our
 system too. This way, we can either focus on differences between Linus and
 Avi, or turn on the big red warning sign saying "regression".
>>> Looks like 2.6.23.1 works fine on that box. We'll leave it running over
>>> the weekend with "while true; do make; make clean; done".
>> Well, do you happen to use sata_mv?
> 
> no, we have nvidia, so its sata_nv.

Did you patch kvm.git with patch-2.6.23.1.bz2 or did you download 
linux-2.6.23.1.tar.bz2 ?

2.6.23.1 corrects nothing except sata_mv...

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] severe bug in 2.6.23+ kvm.git

[Laurent Vivier]

Carsten Otte a écrit :
> Laurent Vivier wrote:
>> How do you know the problem has been introduced by kvm ?
> I don't. In fact I think it has not been introduced by kvm. All I 
> stated, is that we experienced the problem when running the kvm.git 
> kernel after the 2.6.23 update that has not been present in the 
> kvm.git -rc8 as of last thursday.

Perhaps 2.6.23.1 corrects this ?

http://lkml.org/lkml/2007/10/12/302

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] severe bug in 2.6.23+ kvm.git

[Laurent Vivier]

Carsten Otte a écrit :
> Aurelien Jarno wrote:
>> Could you please precise what is corrupted? The guest disk image?
> As stated, we actually did not run any guests and did not load the kvm 
> kernel modules.
> The host root file system gets corrupted to an extend not correctable 
> by the file system checker (we gave it 24h to repair, then interrupted 
> it), and it's very easy to reproduce: a simple kernel make on the 
> hosts lets us reinstall the entire host operating system.

How do you know the problem has been introduced by kvm ?

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [ANNOUNCE] kvm-48 release

[Laurent Vivier]

Farkas Levente a écrit :
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>> kvm-47 had a host memory corruption bug when setting the guest pte dirty 
>>> bit, so here's kvm-48 with a fix.
>>>
>>> Note that guest time accounting, below, will only work with Linux 2.6.24+.
>> smp guests still not working with kvm-48:-( i can't image what others
>> can do to make it work. guests hang at random stage during boot. i
>> attached guests boot screenshot. setup:
>> 
>> - host:
>>   - Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz
>>   - Intel S3000AHV
>>   - 8GB RAM
>>   - CentOS-5
>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>> - guest-1:
>>   - CentOS-5
>>   - kernel-2.6.18-8.1.14.el5 i386 32bit
>> - guest-2:
>>   - CentOS-5
>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>> - guest-3:
>>   - Mandrake-9
>>   - kernel-2.4.19.16mdk-1-1mdk 32bit
>> - guest-4:
>>   - Windows XP Professional 32bit
>> 
>> i try guest-1 and huest-2 with 4 vcpu others with 1 vcpu.
>> on host the only thing i've got in dmesg:
>> 
>> Call Trace:
>>[] softlockup_tick+0xdb/0xed
>>  [] update_process_times+0x42/0x68
>>  [] smp_local_timer_interrupt+0x23/0x47
>>  [] smp_apic_timer_interrupt+0x41/0x47
>>  [] apic_timer_interrupt+0x66/0x6c
>>[] :kvm:kvm_flush_remote_tlbs+0xfb/0x109
>>  [] :kvm:kvm_flush_remote_tlbs+0xea/0x109
>>  [] :kvm:gfn_to_page+0xa3/0xd5
>>  [] :kvm:mark_page_dirty+0x9/0x2a
>>  [] :kvm:kvm_mmu_pte_write+0x1fc/0x330
>>  [] :kvm:emulator_write_emulated_onepage+0x6e/0xce
>>  [] :kvm:x86_emulate_insn+0x2b98/0x4134
>>  [] __handle_mm_fault+0x832/0xdf2
>>  [] :kvm_intel:vmcs_readl+0x17/0x1c
>>  [] :kvm:emulate_instruction+0x152/0x290
>>  [] :kvm_intel:handle_exception+0x170/0x250
>>  [] :kvm:kvm_vcpu_ioctl+0x343/0xf43
>>  [] try_to_wake_up+0x407/0x418
>>  [] __wake_up_common+0x3e/0x68
>>  [] __wake_up+0x38/0x4f
>>  [] __up_read+0x19/0x7f
>>  [] avc_has_perm+0x43/0x55
>>  [] inode_has_perm+0x56/0x63
>>  [] getnstimeofday+0x10/0x28
>>  [] default_wake_function+0x0/0xe
>>  [] file_has_perm+0x94/0xa3
>>  [] do_ioctl+0x21/0x6b
>>  [] vfs_ioctl+0x248/0x261
>>  [] sys_ioctl+0x59/0x78
>>  [] tracesys+0xd1/0xdc
>> 
> 
> the situation is even worse, the guests are hang during boot even with
> single vcpu and even with kvm-46:-( i attached another screenshot. but
> after i kill the guest and start it again it works. it seems the problem
> occurs when i start more guest at the same time (eg. after reboot the
> host). and it seems there is some kind of acpi error since all of the
> guest hang screenshot contains some kind of acpi error.

What happens if you use "-noacpi" ?

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Fix guest time accounting going faster than user time accounting

[Laurent Vivier]

Acked-by: Laurent Vivier <[EMAIL PROTECTED]>

Christian Borntraeger a écrit :
> Seems I overlooked this type while reviewing Laurents patch.
> cputime_add already adds, dont do it twice.
> 
> Avi. This should go to Linus before 2.6.24.
> 
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
> 
> ---
>  fs/proc/array.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.23/fs/proc/array.c
> ===
> --- linux-2.6.23.orig/fs/proc/array.c
> +++ linux-2.6.23/fs/proc/array.c
> @@ -446,7 +446,7 @@ static int do_task_stat(struct task_stru
>   maj_flt += sig->maj_flt;
>   utime = cputime_add(utime, sig->utime);
>   stime = cputime_add(stime, sig->stime);
> - gtime += cputime_add(gtime, sig->gtime);
> + gtime = cputime_add(gtime, sig->gtime);
>   }
>  
>   sid = signal_session(sig);
> 


-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] move kvm_guest_exit() after local_irq_enable()

[Laurent Vivier]

Avi Kivity a écrit :
> Laurent Vivier wrote:
>> According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if we 
>> move
>> it after local_irq_enable().
>>
>> http://lkml.org/lkml/2007/10/15/114
>>
>> To simplify s390 port, we don't clear it in account_system_time().
>>
>> http://lkml.org/lkml/2007/10/15/183
>>   
> 
> Applied (the kvm part), and added a fat comment on the barrier.  Can you 
> send a signed-off-by: line?
> 

Sorry, I missed it...

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] move kvm_guest_exit() after local_irq_enable()

[Laurent Vivier]

According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if we move
it after local_irq_enable().

http://lkml.org/lkml/2007/10/15/114

To simplify s390 port, we don't clear it in account_system_time().

http://lkml.org/lkml/2007/10/15/183

---
 drivers/kvm/kvm_main.c |5 -
 kernel/sched.c |1 -
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 87275be..b9cd1f0 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2194,12 +2194,15 @@ again:
 
kvm_x86_ops->run(vcpu, kvm_run);
 
-   kvm_guest_exit();
vcpu->guest_mode = 0;
local_irq_enable();
 
++vcpu->stat.exits;
 
+   barrier();
+
+   kvm_guest_exit();
+
preempt_enable();
 
/*
diff --git a/kernel/sched.c b/kernel/sched.c
index b27ab3e..57fac22 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3315,7 +3315,6 @@ void account_system_time(struct task_struct *p, int 
hardirq_offset,
 #ifdef CONFIG_GUEST_ACCOUNTING
if (p->flags & PF_VCPU) {
account_guest_time(p, cputime);
-   p->flags &= ~PF_VCPU;
return;
}
 #endif
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] Add some \n in ioapic_debug()

[Laurent Vivier]

Add new-line at end of debug strings.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/ioapic.c |   25 ++---
 1 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 3b69541..1a5e59a 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -40,8 +40,11 @@
 #include 
 #include 
 #include "irq.h"
-/* #define ioapic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg) */
+#if 0
+#define ioapic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg)
+#else
 #define ioapic_debug(fmt, arg...)
+#endif
 static void ioapic_deliver(struct kvm_ioapic *vioapic, int irq);
 
 static unsigned long ioapic_read_indirect(struct kvm_ioapic *ioapic,
@@ -113,7 +116,7 @@ static void ioapic_write_indirect(struct kvm_ioapic 
*ioapic, u32 val)
default:
index = (ioapic->ioregsel - 0x10) >> 1;
 
-   ioapic_debug("change redir index %x val %x", index, val);
+   ioapic_debug("change redir index %x val %x\n", index, val);
if (index >= IOAPIC_NUM_PINS)
return;
if (ioapic->ioregsel & 1) {
@@ -134,7 +137,7 @@ static void ioapic_inj_irq(struct kvm_ioapic *ioapic,
   struct kvm_lapic *target,
   u8 vector, u8 trig_mode, u8 delivery_mode)
 {
-   ioapic_debug("irq %d trig %d deliv %d", vector, trig_mode,
+   ioapic_debug("irq %d trig %d deliv %d\n", vector, trig_mode,
 delivery_mode);
 
ASSERT((delivery_mode == dest_Fixed) ||
@@ -151,7 +154,7 @@ static u32 ioapic_get_delivery_bitmask(struct kvm_ioapic 
*ioapic, u8 dest,
struct kvm *kvm = ioapic->kvm;
struct kvm_vcpu *vcpu;
 
-   ioapic_debug("dest %d dest_mode %d", dest, dest_mode);
+   ioapic_debug("dest %d dest_mode %d\n", dest, dest_mode);
 
if (dest_mode == 0) {   /* Physical mode. */
if (dest == 0xFF) { /* Broadcast. */
@@ -179,7 +182,7 @@ static u32 ioapic_get_delivery_bitmask(struct kvm_ioapic 
*ioapic, u8 dest,
kvm_apic_match_logical_addr(vcpu->apic, dest))
mask |= 1 << vcpu->vcpu_id;
}
-   ioapic_debug("mask %x", mask);
+   ioapic_debug("mask %x\n", mask);
return mask;
 }
 
@@ -196,12 +199,12 @@ static void ioapic_deliver(struct kvm_ioapic *ioapic, int 
irq)
int vcpu_id;
 
ioapic_debug("dest=%x dest_mode=%x delivery_mode=%x "
-"vector=%x trig_mode=%x",
+"vector=%x trig_mode=%x\n",
 dest, dest_mode, delivery_mode, vector, trig_mode);
 
deliver_bitmask = ioapic_get_delivery_bitmask(ioapic, dest, dest_mode);
if (!deliver_bitmask) {
-   ioapic_debug("no target on destination");
+   ioapic_debug("no target on destination\n");
return;
}
 
@@ -214,7 +217,7 @@ static void ioapic_deliver(struct kvm_ioapic *ioapic, int 
irq)
   trig_mode, delivery_mode);
else
ioapic_debug("null round robin: "
-"mask=%x vector=%x delivery_mode=%x",
+"mask=%x vector=%x delivery_mode=%x\n",
 deliver_bitmask, vector, dest_LowestPrio);
break;
case dest_Fixed:
@@ -304,7 +307,7 @@ static void ioapic_mmio_read(struct kvm_io_device *this, 
gpa_t addr, int len,
struct kvm_ioapic *ioapic = (struct kvm_ioapic *)this->private;
u32 result;
 
-   ioapic_debug("addr %lx", (unsigned long)addr);
+   ioapic_debug("addr %lx\n", (unsigned long)addr);
ASSERT(!(addr & 0xf));  /* check alignment */
 
addr &= 0xff;
@@ -341,8 +344,8 @@ static void ioapic_mmio_write(struct kvm_io_device *this, 
gpa_t addr, int len,
struct kvm_ioapic *ioapic = (struct kvm_ioapic *)this->private;
u32 data;
 
-   ioapic_debug("ioapic_mmio_write addr=%lx len=%d val=%p\n",
-addr, len, val);
+   ioapic_debug("ioapic_mmio_write addr=%p len=%d val=%p\n",
+(void*)addr, len, val);
ASSERT(!(addr & 0xf));  /* check alignment */
if (len == 4 || len == 8)
data = *(u32 *) val;
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] build error

[Laurent Vivier]

if you put "set -x" at line 409 of configure, perhaps we can have more 
information.

Laurent

Zhao, Yunfeng wrote:
> The same as under qemu/
> [EMAIL PROTECTED] kvm-userspace]# ./configure
> ./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
> or directory
> ERROR: "/usr/bin/gcc34" either does not exist or does not work
> 
> I am using RHEL5, and compat-gcc-34-g77-3.4.6-4 has been installed on
> it.
> This error happens since yesterday.Before the machine has no problem to
> build KVM. It should be a new regression.
> 
> Thanks
> Yunfeng
> 
>> What is the output of the top-level ./configure?
>>
>> Note you need gcc 3.x, on Red Hat systems the package is called
>> compat-gcc-32 or compat-gcc-34.
>>
>> --
>> error compiling committee.c: too many arguments to function
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
> 


-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters

[Laurent Vivier]

Dor Laor wrote:
> Laurent Vivier wrote:
>>
>> Anthony de Almeida Lopes wrote:
>> > I was curious if anyone thinks that it may be possible to get a
>> > KVM-patched QEMU to use a real video card? For example, let's say I had
>> > a second video card. Is QEMU/kvm a codebase which would support hacking
>> > in the ability to utilize this second video card (one not utilized by
>> > the host Linux)? And in the situation of a laptop, would it be possible
>> > to boot the host Linux in a way that it would not utilize the video
>> > card, but get a qemu guest to use it?
>> > Theoretically, there's no reason this isn't possible, right?
>>
>> We need something like a "PCI proxy" allowing to route some I/O to
>> virtual PCI
>> devices and others to real PCI devices. Moreover we must be able to
>> inform host
>> kernel to not manage a given PCI card (or be able to hot unplug it
>> from host
>> kernel PCI structures)
>>
> There is work in progress for pci pass through capability. Besides PCI it
> also required to have pv dma or 1-1 mapping between the guest and the host.
> Both will be released in the following month. NIC pass through works but
> I'm
> not sure about the features required from VGA pass through.
> Dor.

Perhaps if we use host IOMMU we don't need pv DMA ?
How do you say to host to not manage a PCI devices and let the guest managing 
it ?

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters

[Laurent Vivier]

Anthony de Almeida Lopes wrote:
> I was curious if anyone thinks that it may be possible to get a 
> KVM-patched QEMU to use a real video card? For example, let's say I had 
> a second video card. Is QEMU/kvm a codebase which would support hacking 
> in the ability to utilize this second video card (one not utilized by 
> the host Linux)? And in the situation of a laptop, would it be possible 
> to boot the host Linux in a way that it would not utilize the video 
> card, but get a qemu guest to use it?
> Theoretically, there's no reason this isn't possible, right?

We need something like a "PCI proxy" allowing to route some I/O to virtual PCI
devices and others to real PCI devices. Moreover we must be able to inform host
kernel to not manage a given PCI card (or be able to hot unplug it from host
kernel PCI structures)

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm-45 problems

[Laurent Vivier]

Avi Kivity wrote:
> Zhao, Yunfeng wrote:
>> This fix cannot resolve this issue.
>> Against latest kvm commits, SMP linux with 4 vcpus still cannot boot up.
>> But the issue will not happen , if adding "-smp4 -no-acpi".
>>   
> 
> Can you try the attached patch?
> 
> 
> 
> 
> 
> 
> 
> 
> diff --git a/kernel/kvm_main.c b/kernel/kvm_main.c
> index 0b2894a..61d931e 100644
> --- a/kernel/kvm_main.c
> +++ b/kernel/kvm_main.c
> @@ -235,11 +235,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>* to complete.
>*/
>   for (cpu = first_cpu(cpus); cpu != NR_CPUS; cpu = next_cpu(cpu, cpus))
> - smp_call_function_single(cpu, ack_flush, &completed, 1, 0);
> - while (atomic_read(&completed) != needed) {
> - cpu_relax();
> - barrier();
> - }
> + smp_call_function_single(cpu, ack_flush, &completed, 1, 1);
>  }
>  
>  int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)

This part will be obsolete as soon as linux will export
smp_call_function_mask(). This is already in mm tree:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/broken-out/x86_64-mm-export-i386-smp_call_function_mask-to-modules.patch
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/broken-out/x86_64-mm-implement-missing-x86_64-function-smp_call_function_mask.patch

Apply these patches and try the attached patch for KVM.

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-09-12 17:49:51.0 +0200
+++ kvm/drivers/kvm/kvm_main.c  2007-09-12 17:58:18.0 +0200
@@ -198,21 +198,15 @@ static void vcpu_put(struct kvm_vcpu *vc
 
 static void ack_flush(void *_completed)
 {
-   atomic_t *completed = _completed;
-
-   atomic_inc(completed);
 }
 
 void kvm_flush_remote_tlbs(struct kvm *kvm)
 {
-   int i, cpu, needed;
+   int i, cpu;
cpumask_t cpus;
struct kvm_vcpu *vcpu;
-   atomic_t completed;
 
-   atomic_set(&completed, 0);
cpus_clear(cpus);
-   needed = 0;
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
vcpu = kvm->vcpus[i];
if (!vcpu)
@@ -221,23 +215,9 @@ void kvm_flush_remote_tlbs(struct kvm *k
continue;
cpu = vcpu->cpu;
if (cpu != -1 && cpu != raw_smp_processor_id())
-   if (!cpu_isset(cpu, cpus)) {
-   cpu_set(cpu, cpus);
-   ++needed;
-   }
-   }
-
-   /*
-* We really want smp_call_function_mask() here.  But that's not
-* available, so ipi all cpus in parallel and wait for them
-* to complete.
-*/
-   for (cpu = first_cpu(cpus); cpu != NR_CPUS; cpu = next_cpu(cpu, cpus))
-   smp_call_function_single(cpu, ack_flush, &completed, 1, 0);
-   while (atomic_read(&completed) != needed) {
-   cpu_relax();
-   barrier();
+   cpu_set(cpu, cpus);
}
+   smp_call_function_mask(cpus, ack_flush, NULL, 1);
 }
 
 int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)


signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Avi Kivity wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>>   
>>> Aurelien Jarno wrote:
>>> 
>>>> It's actually described page 200 of the specifications (page 216 in
>>>> ACPIspec30.pdf):
>>>>
>>>>   Note: This descriptor is meant for describing interrupts that are
>>>> connected to PIC-compatible
>>>>   interrupt controllers, which can only be programmed for
>>>> Active-High-Edge-Triggered or Active-
>>>>   Low-Level-Triggered interrupts. Any other combination is illegal.
>>>> The Extended Interrupt
>>>>   Descriptor can be used to describe other combinations.
>>>>
>>>>
>>>>  
>>>>   
>>>>> Avi, if you think this anlysis is correct I can provide the patch
>>>>> changing
>>>>> "Level" to "Edge"...
>>>>>
>>>>> 
>>>>> 
>>>> It looks like the solution is either to describe the IRQ with an
>>>> "Extended Interrupt Descriptor" or to change this value to one of the
>>>> two allowed values. In the later case we have to make sure it is
>>>> consistent with the way the PIC works.
>>>>
>>>>   
>>>>   
>>> The attached patch attempts to override the pci irqs (now limited to 5,
>>> 9, 10, and 11) to be active high level triggered.  Linux boots and
>>> parses this correctly.  Freebsd still fails.
>>> 
>> FreeBSD will fail while ACPI will have Active-High and Level-triggered, 
>> except
>> if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI 
>> table.
>>
>> BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your 
>> patch
>> (as before).
>>
>> Moreover, I don't understand what this patch resolves...
> 
> I thought this was the extended interrupt descriptor; sorry my confusion.
> 
> Meanwhile I changed the dsdt to use the _real_ extended enhanced 
> advanced improved interrupt descriptor, and freebsd now boots.  FC6 and 
> Windows survived.  I'll push this after further testing.

Great !

If you send me your patch I can test it and make it run on distros I have (I can
wait the push too).

Is this THE solution to this issue or only a workaround ?

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Avi Kivity wrote:
> Aurelien Jarno wrote:
>>
>> It's actually described page 200 of the specifications (page 216 in
>> ACPIspec30.pdf):
>>
>>   Note: This descriptor is meant for describing interrupts that are
>> connected to PIC-compatible
>>   interrupt controllers, which can only be programmed for
>> Active-High-Edge-Triggered or Active-
>>   Low-Level-Triggered interrupts. Any other combination is illegal.
>> The Extended Interrupt
>>   Descriptor can be used to describe other combinations.
>>
>>
>>  
>>> Avi, if you think this anlysis is correct I can provide the patch
>>> changing
>>> "Level" to "Edge"...
>>>
>>> 
>>
>> It looks like the solution is either to describe the IRQ with an
>> "Extended Interrupt Descriptor" or to change this value to one of the
>> two allowed values. In the later case we have to make sure it is
>> consistent with the way the PIC works.
>>
>>   
> 
> The attached patch attempts to override the pci irqs (now limited to 5,
> 9, 10, and 11) to be active high level triggered.  Linux boots and
> parses this correctly.  Freebsd still fails.

FreeBSD will fail while ACPI will have Active-High and Level-triggered, except
if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI 
table.

BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your patch
(as before).

Moreover, I don't understand what this patch resolves...

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] modify makefile to add HOST_CC and to clean acpi-dsdt.hex

[Laurent Vivier]

for kvm-userspace:

Allow to compile biossums on x86_64 and remove acpi-dsdt.hex on clean.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 bios/Makefile  |4 +++-
 bios/acpi-dsdt.hex |8 
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/bios/Makefile b/bios/Makefile
index e9eadc1..7249950 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -41,6 +41,7 @@ RANLIB = ranlib
 
 BCC = bcc
 GCC = gcc -m32
+HOST_CC = gcc
 AS86 = as86
 
 BX_INCDIRS = -I.. -I$(srcdir)/.. -I../iodev -I$(srcdir)/../iodev
@@ -63,6 +64,7 @@ clean:
rm -f  *.o *.a *.s _rombios*_.c rombios*.txt rombios*.sym
rm -f  usage biossums rombios16.bin
rm -f  rombios32.bin rombios32.out
+   rm -f acpi-dsdt.hex
 
 dist-clean: clean
rm -f  Makefile
@@ -112,4 +114,4 @@ BIOS-bochs-latest: rombios16.bin rombios32.bin
cat rombios32.bin rombios16.bin > $@
 
 biossums: biossums.c
-   $(GCC) -o biossums biossums.c
+   $(HOST_CC) -o biossums biossums.c

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Avi Kivity wrote:
> Aurelien Jarno wrote:
>> On Fri, Oct 05, 2007 at 03:25:05PM +0200, Laurent Vivier wrote:
>>   
>>> Digging in the FreeBSD sources I found the origin of the problem:
>>>
>>> I added some ACPI traces:
>>>
>>>rsirq-0234 [13] RsIrqResource : Invalid interrupt 
>>> polarity/trigger in
>>>  resource list, 10
>>>
>>> Which is in /sys/contrib/dev/acpica/rsirq.c :
>>>
>>>
>>>/*
>>>  * Check for HE, LL interrupts
>>>  */
>>> switch (Temp8 & 0x09)
>>> {
>>> case 0x01: /* HE */
>>> OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE;
>>> OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH;
>>> break;
>>>
>>> case 0x08: /* LL */
>>> OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE;
>>> OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW;
>>> break;
>>>
>>> default:
>>> /*
>>>  * Only _LL and _HE polarity/trigger interrupts
>>>  * are allowed (ACPI spec, section "IRQ Format")
>>>  * so 0x00 and 0x09 are illegal.
>>>  */
>>> ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
>>> "Invalid interrupt polarity/trigger in resource list, 
>>> %X\n", Tem
>>> p8));
>>> return_ACPI_STATUS (AE_BAD_DATA);
>>> }
>>>
>>> 
>> Good catch!
>>
>>   
>>> Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", 
>>> you
>>> must have "Edge" instead of "Level":
>>>
>>> -IRQ (Level, ActiveHigh, Shared)
>>> +IRQ (Edge, ActiveHigh, Shared)
>>>
>>> But I found nothing in ACPI specification explaining the freeBSD behavior.
>>>
>>> 
>>
>> It's actually described page 200 of the specifications (page 216 in 
>> ACPIspec30.pdf):
>>
>>   Note: This descriptor is meant for describing interrupts that are 
>> connected to PIC-compatible
>>   interrupt controllers, which can only be programmed for 
>> Active-High-Edge-Triggered or Active-
>>   Low-Level-Triggered interrupts. Any other combination is illegal. The 
>> Extended Interrupt
>>   Descriptor can be used to describe other combinations.
>>
>>
>>   
>>> Avi, if you think this anlysis is correct I can provide the patch changing
>>> "Level" to "Edge"...
>>>
>>> 
>> It looks like the solution is either to describe the IRQ with an 
>> "Extended Interrupt Descriptor" or to change this value to one of the 
>> two allowed values. In the later case we have to make sure it is
>> consistent with the way the PIC works.
>>
>>   
> 
> Edge-triggered means we can't share interrupt lines.  Since we have only 
> two or three that limits the number of devices we can have.
> 
> So I'd like to try moving to active low pci interrupts, and implementing 
> polarity in the qemu ioapic.  It's probably closer to real hardware anyway.
> 

Avi,

I've two questions:

- why, when you implemented the ioapic polarity bit in kvm (commit 
0203e2d5d0d0cea6eed6e437d9456aad71135913, kvm_ioapic_set_irq()), you 
didn't implement it in qemu (in qemu/hw/apic.c ioapic_set_irq()) ?

- why implementing polarity changes active level in ACPI ?

Thanks,
Laurent


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Aurelien Jarno wrote:
> On Fri, Oct 05, 2007 at 03:25:05PM +0200, Laurent Vivier wrote:
[snip]
> It looks like the solution is either to describe the IRQ with an 
> "Extended Interrupt Descriptor" or to change this value to one of the 
> two allowed values. In the later case we have to make sure it is
> consistent with the way the PIC works.
> 

A third solution should be to restore active level to "ActiveLow" but I tested
it and it doesn't work.

Moreover, according qemu/hw/i8259.c I think i8259 works like ACPI spec expects.

But there should be more bugs in ACPI as my Debian Serge amd64 install CD (linux
2.6.8) is only able to boot with "-no-acpi".

Laurent
-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Aurelien Jarno wrote:
> Hi all,
> 
> That's not something new, but I never seen the problem mentioned here.
> FreeBSD does not work on KVM, approximately since the lapic merge.
> 
> However, that does not seem related to lapic, as using -no-kvm-irqchip
> does not help. With -no-kvm I get a page fault in kernel mode, while the
> normal QEMU (0.9.0 or CVS) does not have this problem.
> 
> This can be easily reproduced with the latest installation CD:
> ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso
> 
> Cheers,
> Aurelien
> 

Digging in the FreeBSD sources I found the origin of the problem:

I added some ACPI traces:

   rsirq-0234 [13] RsIrqResource : Invalid interrupt polarity/trigger in
 resource list, 10

Which is in /sys/contrib/dev/acpica/rsirq.c :


   /*
 * Check for HE, LL interrupts
 */
switch (Temp8 & 0x09)
{
case 0x01: /* HE */
OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE;
OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH;
break;

case 0x08: /* LL */
OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE;
OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW;
break;

default:
/*
 * Only _LL and _HE polarity/trigger interrupts
 * are allowed (ACPI spec, section "IRQ Format")
 * so 0x00 and 0x09 are illegal.
 */
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
"Invalid interrupt polarity/trigger in resource list, %X\n", Tem
p8));
return_ACPI_STATUS (AE_BAD_DATA);
}

Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", you
must have "Edge" instead of "Level":

-IRQ (Level, ActiveHigh, Shared)
+IRQ (Edge, ActiveHigh, Shared)

But I found nothing in ACPI specification explaining the freeBSD behavior.

Avi, if you think this anlysis is correct I can provide the patch changing
"Level" to "Edge"...

Laurent

-- 
 [EMAIL PROTECTED]  -
"Given enough eyeballs, all bugs are shallow" E. S. Raymond



signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Avi Kivity wrote:
> Aurelien Jarno wrote:
>> Avi Kivity a écrit :
>>   
>>> Aurelien Jarno wrote:
>>> 
 Hi all,

 That's not something new, but I never seen the problem mentioned here.
 FreeBSD does not work on KVM, approximately since the lapic merge.

 However, that does not seem related to lapic, as using -no-kvm-irqchip
 does not help. With -no-kvm I get a page fault in kernel mode, while the
 normal QEMU (0.9.0 or CVS) does not have this problem.

 This can be easily reproduced with the latest installation CD:
 ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso

   
   
>>> It complains about the RSDT checksum.  Running with -no-acpi works 
>>> around the problem (it gets to some country selection screen).  So it 
>>> looks like the ACPI tables are messed up.
>>> 
>> The RSDT checksum problem is not new, but it was harmless on previous
>> versions (like kvm-37).
>>
>> Using -no-acpi, I am able to boot the machine with -no-kvm, but the
>> guest still hang with -no-acpi and with -no-kvm-irqchip or lapic
>> enabled. At least on AMD64, I haven't tested yet on an Intel machine.
>>
>>   
> 
> Looks like there is a compiler problem that's interfering here.  A bios 
> compiled on one machine will boot fine on Intel, but on other machines 
> (unfortunately my work machines) will not.
> 
> There is a separate issue with -no-acpi on AMD.  Is there some version 
> where -no-acpi worked on AMD?
> 

I've found the first bios that is not working on my machine (intel) is at:

commit 41675d73b654bd926670d69551a0903b8a9f7fd5
Author: Avi Kivity <[EMAIL PROTECTED]>
Date:   Thu Sep 20 18:45:24 2007 +0200

kvm: bios: advertise pci irqs as active high

now that kvm emulates the ioapic polarity correctly, we must describe
the polarity correctly in the acpi tables.  otherwise pci interrupts won't
be delivered correctly.

Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>

Reverting this commit from master allows to boot again freebsd.

It works fine with and without "-no-kvm-irqchip".

But it doesn't allow to make working debian-31r0a-amd64 install CD.

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] [PATCH] Correct management of REP prefix

[Laurent Vivier]

Kamble, Nitin A wrote:
> Hi Laurent,
> This patch looks much cleaner to me. 
> 
> I see you are saving the regs like this in the patch.
>  memcpy(c->regs, ctxt->vcpu->regs, sizeof c->regs);
> 
> But I don't see any place in the patch these regs getting restored after
> failure.
> 
> Is it taken care of the code outside of the patch?

In fact, during the emulation the function works on c->regs and copy them into
ctxt->vpcu->regs on success (see label "writeback"). The result is in vcpu not
in c->regs.
If the function fails, as we didn't modify ctxt->vcpu->regs, we can re-start
with original values by copying again ctxt->vcpu->regs to c->regs.

Regargs,
Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Avi Kivity wrote:
> Aurelien Jarno wrote:
>> Hi all,
>>
>> That's not something new, but I never seen the problem mentioned here.
>> FreeBSD does not work on KVM, approximately since the lapic merge.
>>
>> However, that does not seem related to lapic, as using -no-kvm-irqchip
>> does not help. With -no-kvm I get a page fault in kernel mode, while the
>> normal QEMU (0.9.0 or CVS) does not have this problem.
>>
>> This can be easily reproduced with the latest installation CD:
>> ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso
>>
>>   
> 
> It complains about the RSDT checksum.  Running with -no-acpi works 
> around the problem (it gets to some country selection screen).  So it 
> looks like the ACPI tables are messed up.

I should have the same kind of problem with debian-31r0a-amd64-netinst.iso which
hangs on: " Loading module 'ide-disk' for 'Linux ATA DISK'..."

and "-no-acpi" resolves this too.

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] FreeBSD image hangs during boot

[Laurent Vivier]

Hi Aurélien,

did you try kvm-45 ?

Laurent

Aurelien Jarno wrote:
> Hi all,
> 
> That's not something new, but I never seen the problem mentioned here.
> FreeBSD does not work on KVM, approximately since the lapic merge.
> 
> However, that does not seem related to lapic, as using -no-kvm-irqchip
> does not help. With -no-kvm I get a page fault in kernel mode, while the
> normal QEMU (0.9.0 or CVS) does not have this problem.
> 
> This can be easily reproduced with the latest installation CD:
> ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso
> 
> Cheers,
> Aurelien
> 


-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

[kvm-devel] [PATCH] Correct management of REP prefix

[Laurent Vivier]

This patch corrects some errors appearing when we have an emulation failure
on an operation using REP prefix.

When x86_emulate_insn() fails, saving EIP and ECX is not enough as emulation
should have modified other registers like RSI or RDI. Moreover, the emulation
can fail on the writeback, and in this case we are not able to restore
registers.

At beginning of x86_emulate_insn(), we restore registers from vcpu as they were
not modified by x86d_decode_insn() and we save EIP to be able to restore it
in case of failure.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/x86_emulate.c |   35 +--
 1 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 35069e3..887de7d 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1146,10 +1146,18 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
 {
unsigned long cr2 = ctxt->cr2;
u64 msr_data;
-   unsigned long saved_rcx = 0, saved_eip = 0;
+   unsigned long saved_eip;
struct decode_cache *c = &ctxt->decode;
int rc = 0;
 
+   /* Shadow copy of register state. Committed on successful emulation.
+* NOTE: we can copy them from vcpu as x86_decode_insn() doesn't
+* modify them.
+*/
+
+   memcpy(c->regs, ctxt->vcpu->regs, sizeof c->regs);
+   saved_eip = c->eip;
+
if ((c->d & ModRM) && (c->modrm_mod != 3))
cr2 = c->modrm_ea;
 
@@ -1354,7 +1362,11 @@ writeback:
ctxt->vcpu->rip = c->eip;
 
 done:
-   return (rc == X86EMUL_UNHANDLEABLE) ? -1 : 0;
+   if (rc == X86EMUL_UNHANDLEABLE) {
+   c->eip = saved_eip;
+   return -1;
+   }
+   return 0;
 
 special_insn:
if (c->twobyte)
@@ -1396,8 +1408,10 @@ special_insn:
register_address(ctxt->es_base,
 c->regs[VCPU_REGS_RDI]),
c->rep_prefix,
-   c->regs[VCPU_REGS_RDX]) == 0)
+   c->regs[VCPU_REGS_RDX]) == 0) {
+   c->eip = saved_eip;
return -1;
+   }
return 0;
case 0x6e:  /* outsb */
case 0x6f:  /* outsw/outsd */
@@ -1412,8 +1426,10 @@ special_insn:
ctxt->ds_base,
 c->regs[VCPU_REGS_RSI]),
c->rep_prefix,
-   c->regs[VCPU_REGS_RDX]) == 0)
+   c->regs[VCPU_REGS_RDX]) == 0) {
+   c->eip = saved_eip;
return -1;
+   }
return 0;
case 0x70 ... 0x7f: /* jcc (short) */ {
int rel = insn_fetch(s8, 1, c->eip);
@@ -1441,8 +1457,6 @@ special_insn:
ctxt->vcpu->rip = c->eip;
goto done;
}
-   saved_rcx = c->regs[VCPU_REGS_RCX];
-   saved_eip = c->eip;
c->regs[VCPU_REGS_RCX]--;
c->eip = ctxt->vcpu->rip;
}
@@ -1459,10 +1473,6 @@ special_insn:
c->regs[VCPU_REGS_RSI]),
&c->dst.val,
c->dst.bytes, ctxt->vcpu)) != 0) {
-   if (c->rep_prefix) {
-   c->regs[VCPU_REGS_RCX] = saved_rcx;
-   c->eip = saved_eip;
-   }
goto done;
}
register_address_increment(c->regs[VCPU_REGS_RSI],
@@ -1491,10 +1501,6 @@ special_insn:
if ((rc = ops->read_emulated(cr2, &c->dst.val,
 c->dst.bytes,
 ctxt->vcpu)) != 0) {
-   if (c->rep_prefix) {
-   c->regs[VCPU_REGS_RCX] = saved_rcx;
-   c->eip = saved_eip;
-   }
goto done;
}
register_address_increment(c->regs[VCPU_REGS_RSI],
@@ -1762,5 +1768,6 @@ twobyte_special_insn:
 
 cannot_emulate:
DPRINTF("Cannot emulate %02x\n", c->b);
+   c->eip = saved_eip;
return -1;
 }
-- 
1.5.2.4


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

Re: [kvm-devel] [PATCH] Correct management of REP prefix

[Laurent Vivier]

Avi Kivity wrote:
> Laurent Vivier wrote:
>> This patch corrects some errors appearing when we have an emulation
>> failure
>> on an operation using REP prefix.
>>
>> When x86_emulate_insn() fails, saving EIP and ECX is not enough as
>> emulation
>> should have modified other registers like RSI or RDI. Moreover, the
>> emulation
>> can fail on the writeback, and in this case we are not able to restore
>> registers.
>>
>> This patch takes another approach: at the beginning of
>> x86_emulate_insn() we restore state we have at end of
>> x86_decode_insn(). To do that, we store EIP in
>> a new field in decode_cache, decode_eip. This field store the EIP as
>> it is at
>> the end of x86_decode_insn(); and at beginning of x86_emulate_insn(),
>> we restore
>> all registers as they are in vcpu. We can do that, because the
>> x86_decode_insn()
>> doesn't modify registers (except EIP).
>>   
> 
> How about doing it slightly differently: keep c->eip at its current
> meaning, and add c->eip_orig to revert to? That will make the patch
> smaller and reduce the changes of something being missed.

I didn't do like that because I was afraid to miss some points to restore 
orig_eip.

But a patch will follow...

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] Unable to handle kernel paging request

[Laurent Vivier]

Avi Kivity wrote:
> Laurent Vivier wrote:
>> (Yes, I know, it's again another bug I've introduced into KVM...)
>>
>>   
> 
> To avoid this, I suggest that Nitin and yourself review each other's
> patches.  While I review every patch I commit, it works much better when
> someone who's involved daily with the code reviews the patch.

I agree...

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

[kvm-devel] [PATCH] Correct management of REP prefix

[Laurent Vivier]

This patch corrects some errors appearing when we have an emulation failure
on an operation using REP prefix.

When x86_emulate_insn() fails, saving EIP and ECX is not enough as emulation
should have modified other registers like RSI or RDI. Moreover, the emulation
can fail on the writeback, and in this case we are not able to restore 
registers.

This patch takes another approach: at the beginning of x86_emulate_insn() we 
restore state we have at end of x86_decode_insn(). To do that, we store EIP in
a new field in decode_cache, decode_eip. This field store the EIP as it is at
the end of x86_decode_insn(); and at beginning of x86_emulate_insn(), we restore
all registers as they are in vcpu. We can do that, because the x86_decode_insn()
doesn't modify registers (except EIP).

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/x86_emulate.c |   71 +++-
 drivers/kvm/x86_emulate.h |1 +
 2 files changed, 38 insertions(+), 34 deletions(-)

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 35069e3..3febb58 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -526,10 +526,11 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
int mode = ctxt->mode;
int index_reg = 0, base_reg = 0, scale, rip_relative = 0;
 
-   /* Shadow copy of register state. Committed on successful emulation. */
-
memset(c, 0, sizeof(struct decode_cache));
-   c->eip = ctxt->vcpu->rip;
+
+   /* decode_eip will contain EIP after decode phase */
+
+   c->decode_eip = ctxt->vcpu->rip;
memcpy(c->regs, ctxt->vcpu->regs, sizeof c->regs);
 
switch (mode) {
@@ -552,7 +553,7 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
 
/* Legacy prefixes. */
for (;;) {
-   switch (c->b = insn_fetch(u8, 1, c->eip)) {
+   switch (c->b = insn_fetch(u8, 1, c->decode_eip)) {
case 0x66:  /* operand-size override */
c->op_bytes ^= 6;   /* switch between 2/4 bytes */
break;
@@ -620,7 +621,7 @@ done_prefixes:
/* Two-byte opcode? */
if (c->b == 0x0f) {
c->twobyte = 1;
-   c->b = insn_fetch(u8, 1, c->eip);
+   c->b = insn_fetch(u8, 1, c->decode_eip);
c->d = twobyte_table[c->b];
}
 
@@ -633,7 +634,7 @@ done_prefixes:
 
/* ModRM and SIB bytes. */
if (c->d & ModRM) {
-   c->modrm = insn_fetch(u8, 1, c->eip);
+   c->modrm = insn_fetch(u8, 1, c->decode_eip);
c->modrm_mod |= (c->modrm & 0xc0) >> 6;
c->modrm_reg |= (c->modrm & 0x38) >> 3;
c->modrm_rm |= (c->modrm & 0x07);
@@ -657,13 +658,14 @@ done_prefixes:
case 0:
if (c->modrm_rm == 6)
c->modrm_ea +=
-   insn_fetch(u16, 2, c->eip);
+ insn_fetch(u16, 2, c->decode_eip);
break;
case 1:
-   c->modrm_ea += insn_fetch(s8, 1, c->eip);
+   c->modrm_ea += insn_fetch(s8, 1, c->decode_eip);
break;
case 2:
-   c->modrm_ea += insn_fetch(u16, 2, c->eip);
+   c->modrm_ea += insn_fetch(u16, 2,
+ c->decode_eip);
break;
}
switch (c->modrm_rm) {
@@ -703,7 +705,7 @@ done_prefixes:
switch (c->modrm_rm) {
case 4:
case 12:
-   sib = insn_fetch(u8, 1, c->eip);
+   sib = insn_fetch(u8, 1, c->decode_eip);
index_reg |= (sib >> 3) & 7;
base_reg |= sib & 7;
scale = sib >> 6;
@@ -714,8 +716,8 @@ done_prefixes:
c->modrm_ea +=
c->regs[base_reg];
else
-   c->modrm_ea +=
-   insn_fetch(s32, 4, c->eip);
+   c->modrm_ea += insn_fetch(s32,
+ 

Re: [kvm-devel] Unable to handle kernel paging request

[Laurent Vivier]

Correct me if I'm wrong, perhaps it's the bug Nitin is hunting.

There is always something wrong in the management in the REP prefix.

I think what is happen is:

- we have a REP prefix, we save ECX and EIP.
- we set c->dst to emulate a "stos"
- goto writeback
- writeback: we try a "write_emulated()" with c->dst
- write_emulated failed() AND WE DON'T RESTORE ECX AND EIP -> it's bad...
- exit to QEMU
- re-enter in x86_emulate_insn() with already modified ECX and EIP.

Any comment ?
(Yes, I know, it's again another bug I've introduced into KVM...)

Laurent

Laurent Vivier wrote:
> Hi,
> 
> booting a FC6 on my intel box (xeon) with a kernel 2.6.22.5 and KVM git, I had
> the following error (not reproducible):
> 
> # kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda fc6.qcow2 -net nic
> -net tap -serial stdio -smp 4
> ...
> INIT: version 2.86 booting
> Welcome to Fedora Core
> Press 'I' to enter interactive startup.
> Setting clock  (utc): Thu Sep 27 18:06:27 CEST 2007 [  OK  ]
> Starting udev: Unable to handle kernel paging request at 880e9000 RIP:
>  [] sys_init_module+0x985/0x1786
> PGD 203067 PUD 205063 PMD 7fc4067 PTE 6b50163
> Oops: 0002 [1] SMP
> CPU 1
> Modules linked in: dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata 
> sd_mod s
> csi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
> Pid: 641, comm: modprobe Not tainted 2.6.22.5 #1
> RIP: 0010:[]  [] 
> sys_init_module+0x985/0x178
> 6
> RSP: 0018:810006399e68  EFLAGS: 00010246
> RAX:  RBX: c2090a20 RCX: 0f84
> RDX: 880e6000 RSI: 0163 RDI: 880e9000
> RBP: 0026 R08: 810007d94254 R09: 50cf
> R10:  R11: 0001 R12: c207c300
> R13: 0004 R14: c20900e0 R15: 2ab868ac2010
> FS:  2ab8690096e0() GS:810007d94280() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 880e9000 CR3: 07cfd000 CR4: 06e0
> Process modprobe (pid: 641, threadinfo 810006398000, task 
> 81000788e000)
> Stack:  000276d8   0608f340
>     
>    c20a2328 810006402000
> Call Trace:
>  [] vfs_read+0xcb/0x173
>  [] system_call+0x7e/0x83
> 
> 
> Code: f3 aa 49 89 94 24 88 01 00 00 49 8b bc 24 90 01 00 00 e8 32
> RIP  [] sys_init_module+0x985/0x1786
>  RSP 
> CR2: 880e9000
> 
> 
> The instruction at [] sys_init_module+0x985/0x1786 is:
> 
> 0x8104ebc1 :  rep stos %al,%es:(%rdi)
> 
> Any idea of what happened ?
> 
> Laurent
> 
> 
> 
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> 
> 
> 
> 
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

[kvm-devel] Unable to handle kernel paging request

[Laurent Vivier]

Hi,

booting a FC6 on my intel box (xeon) with a kernel 2.6.22.5 and KVM git, I had
the following error (not reproducible):

# kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda fc6.qcow2 -net nic
-net tap -serial stdio -smp 4
...
INIT: version 2.86 booting
Welcome to Fedora Core
Press 'I' to enter interactive startup.
Setting clock  (utc): Thu Sep 27 18:06:27 CEST 2007 [  OK  ]
Starting udev: Unable to handle kernel paging request at 880e9000 RIP:
 [] sys_init_module+0x985/0x1786
PGD 203067 PUD 205063 PMD 7fc4067 PTE 6b50163
Oops: 0002 [1] SMP
CPU 1
Modules linked in: dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata sd_mod s
csi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
Pid: 641, comm: modprobe Not tainted 2.6.22.5 #1
RIP: 0010:[]  [] sys_init_module+0x985/0x178
6
RSP: 0018:810006399e68  EFLAGS: 00010246
RAX:  RBX: c2090a20 RCX: 0f84
RDX: 880e6000 RSI: 0163 RDI: 880e9000
RBP: 0026 R08: 810007d94254 R09: 50cf
R10:  R11: 0001 R12: c207c300
R13: 0004 R14: c20900e0 R15: 2ab868ac2010
FS:  2ab8690096e0() GS:810007d94280() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 880e9000 CR3: 07cfd000 CR4: 06e0
Process modprobe (pid: 641, threadinfo 810006398000, task 81000788e000)
Stack:  000276d8   0608f340
    
   c20a2328 810006402000
Call Trace:
 [] vfs_read+0xcb/0x173
 [] system_call+0x7e/0x83


Code: f3 aa 49 89 94 24 88 01 00 00 49 8b bc 24 90 01 00 00 e8 32
RIP  [] sys_init_module+0x985/0x1786
 RSP 
CR2: 880e9000


The instruction at [] sys_init_module+0x985/0x1786 is:

0x8104ebc1 :  rep stos %al,%es:(%rdi)

Any idea of what happened ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] FYI: fixing Vista networking with rtl8139 + KVM

[Laurent Vivier]

Avi Kivity wrote:
> Farkas Levente wrote:
>> Daniel P. Berrange wrote:
>>   
>>> A Fedora user reported that Vista networking isn't working with KVM[1] and
>>> pointed to the Wiki
>>>
>>>   http://kvm.qumranet.com/kvmwiki/Vista_Networking_Workaround
>>>
>>> FYI, a patch from Xen was merged into upstream QEMU to fix this problem
>>> with rtl8139 a week or two back and works nicely with KVM+Vista...
>>>
>>>http://www.mail-archive.com/[EMAIL PROTECTED]/msg11365.html
>>>
>>> ..avoiding need for messing around with ne2k drivers as mentioned in the 
>>> wiki
>>>
>>> Regards,
>>> Dan.
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=308201
>>> 
>> does this means that in general use the ne2k driver is a better choice?
>> anyway is there a suggested network driver for the guests?
>>
>>   
> 
> No, it means I need to merge qemu-cvs.
> 
> rtl8139 performs faster than ne2000.

But adding CRC computing in RTL839 should have some impacts on performance.

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

[kvm-devel] [PATCH] On a pop instruction, don't restore ECX and EIP on error

[Laurent Vivier]

This patch corrects a mistake introduced by commit 
5d9b36eec8ca6abe03da91efdfc7b5861525bd43
and reported by Nitin A Kamble.

The pop instruction restores ECX and EIP if read_std() fails and if we have a 
REP prefix,
but at this level ECX and EIP are not saved (and not modified). We don't have 
to restore it.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/x86_emulate.c |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 585cccf..1ad500c 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1379,13 +1379,8 @@ special_insn:
pop_instruction:
if ((rc = ops->read_std(register_address(ctxt->ss_base,
c->regs[VCPU_REGS_RSP]), c->dst.ptr,
-   c->op_bytes, ctxt->vcpu)) != 0) {
-   if (c->rep_prefix) {
-   c->regs[VCPU_REGS_RCX] = saved_rcx;
-   c->eip = saved_eip;
-   }
+   c->op_bytes, ctxt->vcpu)) != 0)
goto done;
-   }
 
register_address_increment(c->regs[VCPU_REGS_RSP],
   c->op_bytes);
-- 
1.5.2.4


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

Re: [kvm-devel] use of saved_eip

[Laurent Vivier]

Nitin A Kamble wrote:
> Hi Laurent,
>   Sorry for calling by alst name. You 1st & last both names are totally
> new to me. Are these french names?

No problem. Yes, they are.

>   I understand your explanation. I was worried about code getting
> misplaced due to automatic merges.

In this case, it's not the fault of automatic merges but mine.

I'll post a patch to correct this.

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] use of saved_eip

[Laurent Vivier]

Kamble, Nitin A wrote:
> Hi Vivier, Avi,

Hi Nitin,
(BTW, my first name is Laurent)

>   In order to debug faulures in my tree, I was looking at the saved_eip 
> changes coming from your commit. I did not understand the use of 
> saved_eip properly. like why is it used in the emulation of the pop 
> instruction. Can you please help me understand it's usage?

in emulate_instruction(), we decode instructions and copy vcpu registers 
to ctxt (in x86_decode_insn()), then we really emulate the instruction 
(in x86_emulate_insn()).

In x86_emulate_insn(), if we have a REP prefix, we decrement ECX and set 
EIP to next instruction, then we try to emulate the instruction.
If the emulation fails (because this is a MMIO for instance) we have to 
restore the initial values of ECX and EIP because we will re-enter in 
x86_emulate_insn() once the IO has been managed by Qemu and thus ECX is 
decremented again and EIP set to next instruction again.

And you are right: _we_don't_have_to_do_that_for_the_pop_instruction_, 
it's a mistake because the REP prefix hasn't been processed at this 
level, it is managed (ECX and EIP are modified) later.

So, you can remove from pop_instruction:

1383 if (c->rep_prefix) {
1384 c->regs[VCPU_REGS_RCX] = saved_rcx;
1385 c->eip = saved_eip;
1386 }

Sorry for the inconvenience,

Laurent



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

Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)

[Laurent Vivier]

Daniel P. Berrange wrote:
> On Wed, Sep 26, 2007 at 05:47:20PM +0200, Laurent Vivier wrote:
>> Hi,
>>
>> I think there is a bug in qemu RTL8139.
>>
>> RTL8139 uses:
>>
>> cpu_register_physical_memory(addr + 0, 0x100, s->rtl8139_mmio_io_addr);
>>
>> But in the comment of cpu_register_physical_memory() we have:
>>
>> "'size' must be a multiple of the target page size."
>>
>> And I think 0x100 is not a multiple of target page size :-P
> 
> Latest upstream QEMU has fixed its memory handling so that MMIO regions
> do not need to be a multiple of page size. Changing RTL8139 to use a
> block of size 0x1000 is a reasonable short term hack around the problem,
> but syncing with latest QEMU is the real solution, since there are other
> places in the code which will have similar issues.
> 

So this explains why rtl8139.c from QEMU CVS always uses 0x100.

Thank you for the comment.

Avi, you know what you have to do ;-)

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)

[Laurent Vivier]

Hi,

I think there is a bug in qemu RTL8139.

RTL8139 uses:

cpu_register_physical_memory(addr + 0, 0x100, s->rtl8139_mmio_io_addr);

But in the comment of cpu_register_physical_memory() we have:

"'size' must be a multiple of the target page size."

And I think 0x100 is not a multiple of target page size :-P

The attached patch corrects the problem.

Laurent

SourceForge.net wrote:
> Bugs item #1802223, was opened at 2007-09-25 22:59
> 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=1802223&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: xeb (xebd)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: nics have same hw address (rtl8139)
> 
> Initial Comment:
> Hello!
> 
> Host:Linux 2.6.22-gentoo-r2 #2 SMP Fri Aug 3 07:01:46 MSD 2007 x86_64 AMD 
> Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux,Gentoo, 
> kvm-44
> 
> Guest:Linux 2.6.22-hardened-r4
> 
> command line:
> qemu-system-x86_64 -hda server_base_x86.img -hdc server_swap.img -localtime 
> -m 128 \
> -net nic,vlan=0,macaddr=52:54:00:12:34:56,model=rtl8139 -net 
> tap,vlan=0,ifname=tap3,script=no \
> -net nic,vlan=1,macaddr=52:54:00:12:34:57,model=rtl8139 -net 
> tap,vlan=1,ifname=tap4,script=no \
> -net nic,vlan=2,macaddr=52:54:00:12:34:58,model=rtl8139 -net 
> tap,vlan=2,ifname=tap5,script=no \
> -nographic
> 
> ifconfig on guest:
> eth0  Link encap:Ethernet  HWaddr 52:54:00:12:34:58
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>   Interrupt:11 Base address:0x4000
> 
> eth1  Link encap:Ethernet  HWaddr 52:54:00:12:34:58
>   inet addr:192.168.11.1  Bcast:192.168.11.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>   Interrupt:9 Base address:0x6100
> 
> eth2  Link encap:Ethernet  HWaddr 52:54:00:12:34:58
>   inet addr:192.168.13.1  Bcast:192.168.13.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>   Interrupt:11 Base address:0x8200
> 
> As can you see they have same hwaddr.
> With model=ne2k_pci nics have correct hw addresses 

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth


rtl8139.patch
Description: application/mbox


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

Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture

[Laurent Vivier]

Hi,

is this the same layout introduced for the powerpc port ?
Perhaps you should work together ?

Laurent

Zhang, Xiantao wrote:
> Hi Folks,
>   We are working on enabling KVM support on IA64 platform, and now
> Linux, Windows guests get stable run and achieve reasonable performance
> on KVM with Open GFW. But you know, the current KVM only considers x86
> platform, and is short of cross-architecture framework. Currently, we
> have a proposal for KVM source layout to accommodate new CPU
> architectures. Attached foil describes the detail. With our proposal, we
> can boot x86 guests based on commit
> 2e278972a11eb14f031dea242a9ed118adfa0932, also didn't see regressions.
> For IA64 side, we are rebasing our code to this framework. 
> Main changes to current source:
> 1. Add subdirectories, such as x86 and ia64 to hold arch-specific code.
> 2. Split kvm_main.c to two parts. One is still called kvm_main.c, just
> contains KVM common interfaces with user space, and basic KVM
> infrastructure. The other one is named as kvm_arch.c under sub-directory
> (eg. X86, ia64 etc), which includes arch-specific code to supplement the
> functionality of kvm_main.c
> 3. Add an "include" directory in drivers/kvm. Due to possibly complex
> code logic in KVM source, maybe many header files need to maintain for
> some architectures. If we put them under top-level include/asm-arch
> directory, it may introduce much more maintain effort. So, we put it
> under "drivers/kvm", and let it be effective when kernel configuration
> time.
> BTW, Userspace code changes are not involved in this thread. 
> Considering the readability, we didn't attach the diff file in the mail,
> due to big changes to kvm source structure, and only post the tarball
> including whole directory "drivers/kvm" instead. For comparison, I
> attached kvm_main.diff as well. 
> 
> Any comments are appreciated from you! Hope to see IA64 support on KVM
> earlier!
> 
> Thanks & Best Wishes
> Xiantao
> Intel Opensource Technology Center. 
> 
> 
> 
> 
>   
>   *
> BLOCKED FILE ALERT!*
> 
> The attachment '.kvm-intel.ko.cmd' has been blocked because it is a
> disallowed file type. The attachment has been replaced by this message.
> 
> If you feel you have received this message in error and are an Intel
> employee, then please contact the Global Service Desk
> .
> 
> More Information:
> 
> If you are an Intel employee and internal to the Intel network, visit
> Secure Intel
> 
> to learn more about E-mail attachment options.
> 
> If you are not an Intel employee, please contact your Intel sponsor for
> additional information.
>  
> 
>  Copyright © Intel Corporation, 2002-2006. All
> rights reserved.
> *Other names and brands may be claimed as the property of others.
> **Intel is not responsible for content of sites outside our intranet.
> 
> 
> 
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> 
> 
> 
> 
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

[kvm-devel] [PATCH] remove unused variable

[Laurent Vivier]

Remove unused variable introduced by commit 
5ed6627ee96f0a6802d99e71879d98610ba17e01
(I missed it, sorry)

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/x86_emulate.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 585cccf..ccdd76f 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -522,7 +522,6 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
 {
struct decode_cache *c = &ctxt->decode;
u8 sib, rex_prefix = 0;
-   unsigned int i;
int rc = 0;
int mode = ctxt->mode;
int index_reg = 0, base_reg = 0, scale, rip_relative = 0;
-- 
1.5.2.4


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

[kvm-devel] [PATCH] Any legacy prefix after a REX prefix nullifies its effect

[Laurent Vivier]

This patch modifies the management of REX prefix according behavior I saw in 
Xen 3.1.
In Xen, this modification has been introduced by Jan Beulich.

http://lists.xensource.com/archives/html/xen-changelog/2007-01/msg00081.html

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/x86_emulate.c |   23 +++
 1 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index f8516ba..585cccf 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -552,7 +552,7 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
}
 
/* Legacy prefixes. */
-   for (i = 0; i < 8; i++) {
+   for (;;) {
switch (c->b = insn_fetch(u8, 1, c->eip)) {
case 0x66:  /* operand-size override */
c->op_bytes ^= 6;   /* switch between 2/4 bytes */
@@ -583,6 +583,11 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
case 0x36:  /* SS override */
c->override_base = &ctxt->ss_base;
break;
+   case 0x40 ... 0x4f: /* REX */
+   if (mode != X86EMUL_MODE_PROT64)
+   goto done_prefixes;
+   rex_prefix = c->b;
+   continue;
case 0xf0:  /* LOCK */
c->lock_prefix = 1;
break;
@@ -593,19 +598,21 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct 
x86_emulate_ops *ops)
default:
goto done_prefixes;
}
+
+   /* Any legacy prefix after a REX prefix nullifies its effect. */
+
+   rex_prefix = 0;
}
 
 done_prefixes:
 
/* REX prefix. */
-   if ((mode == X86EMUL_MODE_PROT64) && ((c->b & 0xf0) == 0x40)) {
-   rex_prefix = c->b;
-   if (c->b & 8)
+   if (rex_prefix) {
+   if (rex_prefix & 8)
c->op_bytes = 8;/* REX.W */
-   c->modrm_reg = (c->b & 4) << 1; /* REX.R */
-   index_reg = (c->b & 2) << 2; /* REX.X */
-   c->modrm_rm = base_reg = (c->b & 1) << 3; /* REG.B */
-   c->b = insn_fetch(u8, 1, c->eip);
+   c->modrm_reg = (rex_prefix & 4) << 1;   /* REX.R */
+   index_reg = (rex_prefix & 2) << 2; /* REX.X */
+   c->modrm_rm = base_reg = (rex_prefix & 1) << 3; /* REG.B */
}
 
/* Opcode byte(s). */
-- 
1.5.2.4


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

Re: [kvm-devel] Extending VGA ram?

[Laurent Vivier]

Avi Kivity wrote:
> Heinz Ulrich Stille wrote:
>> Hi!
>>
>> I'd like to use screen resolutions of 1920x1200 to 2560x1600 at 32bpp.
>> So far I managed to raise the pixel limit, but not the memory size, and
>> 8MB is a bit low for what I want. [EMAIL PROTECTED] works fine, but 32bpp
>> results in a segfault. Increasing VGA_RAM_SIZE in qemu/vl.h doesn't help.
>> What else does this depend on?
>>
>>   
> 
> You'll need to emulate a card that supports these resolutions. I don't 
> think cirrus does.  The vmware vga display in qemu-cvs probably does, 
> but it hasn't been ported to kvm yet.  You might try that.

BTW, what is your politic about qemu: do you update qemu inside kvm on qemu
release only ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

[kvm-devel] [PATCH] Purify x86_decode_insn() error case management

[Laurent Vivier]

Purify x86_decode_insn() error case management,
the only valid case is on protected page access, other cases are errors

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm_main.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index cecdb1b..60798e3 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1272,7 +1272,7 @@ int emulate_instruction(struct kvm_vcpu *vcpu,
u16 error_code,
int no_decode)
 {
-   int r = 0;
+   int r;
 
vcpu->mmio_fault_cr2 = cr2;
kvm_x86_ops->cache_regs(vcpu);
@@ -1315,10 +1315,14 @@ int emulate_instruction(struct kvm_vcpu *vcpu,
get_segment_base(vcpu, VCPU_SREG_FS);
 
r = x86_decode_insn(&vcpu->emulate_ctxt, &emulate_ops);
+   if (r)  {
+   if (kvm_mmu_unprotect_page_virt(vcpu, cr2))
+   return EMULATE_DONE;
+   return EMULATE_FAIL;
+   }
}
 
-   if (r == 0)
-   r = x86_emulate_insn(&vcpu->emulate_ctxt, &emulate_ops);
+   r = x86_emulate_insn(&vcpu->emulate_ctxt, &emulate_ops);
 
if (vcpu->pio.string)
return EMULATE_DO_MMIO;
-- 
1.5.2.4


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

Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..

[Laurent Vivier]

Avi Kivity wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>>  
>>> Farkas Levente wrote:
>>>
>>>> hi,
>>>> it seems we've got a real tester:-) for ma all of the bellow are
>>>> serious
>>>> bugs (tomorrow i'll try to send more detail of our host crash too) and
>>>> imho the latest 'stable' version was kvm-36. wouldn't be better to
>>>> postpone all patches and infrastructure changes (virtio and others)
>>>> until these have been fixed and try to produce a new 'stable' release?
>>>> i understand then everybody (including myself) would like to see these
>>>> new features in the latest and greatest kvm release, but at the same
>>>> time i'd be nice to think about the end users too.
>>>> may some version cane be labeled as stable (eg 36) and the latest as
>>>> devel. this can help a lot for those who are not read this list.
>>>> 
>>> You can use -no-kvm-irqchip to get stability similar to kvm-36.
>>>
>>> 
>>
>> Perhaps a workaround for end user could be to disable by default kvm
>> irqchip and
>> add an option to enable it (--use-kvm-irqchip) ?
>>
>>   
> 
> I thought of it, but that would mean we wouldn't see the problems, so
> they wouldn't get fixed.

I agree: enabling by default development features allows you to have more bug
feedbacks. It's a choice...

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..

[Laurent Vivier]

Avi Kivity wrote:
> Farkas Levente wrote:
>> hi,
>> it seems we've got a real tester:-) for ma all of the bellow are serious
>> bugs (tomorrow i'll try to send more detail of our host crash too) and
>> imho the latest 'stable' version was kvm-36. wouldn't be better to
>> postpone all patches and infrastructure changes (virtio and others)
>> until these have been fixed and try to produce a new 'stable' release?
>> i understand then everybody (including myself) would like to see these
>> new features in the latest and greatest kvm release, but at the same
>> time i'd be nice to think about the end users too.
>> may some version cane be labeled as stable (eg 36) and the latest as
>> devel. this can help a lot for those who are not read this list.
>>   
> 
> You can use -no-kvm-irqchip to get stability similar to kvm-36.
>

Perhaps a workaround for end user could be to disable by default kvm irqchip and
add an option to enable it (--use-kvm-irqchip) ?

Laurent
-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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

Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..

[Laurent Vivier]

Avi Kivity wrote:
> Zhao, Yunfeng wrote:
>> Avi, 
>> I still cannot boot up the smp windows against the latest commits.
>>   
> 
> What are the symptoms, exactly? It works reliably here.

It works for me too (winXP + smp 4), but I had to update kvm-userspace to last
commits as well. Yunfeng, did you update it too ?

Laurent

-- 
- [EMAIL PROTECTED]  --
  "Software is hard" - Donald Knuth



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