Re: [PATCH 7/16 v6] PCI: cleanup pcibios_allocate_resources()

[Yinghai Lu]

On Wed, Oct 22, 2008 at 1:42 AM, Yu Zhao [EMAIL PROTECTED] wrote:
 This cleanup makes pcibios_allocate_resources() easier to read.

 Cc: Alex Chiang [EMAIL PROTECTED]
 Cc: Grant Grundler [EMAIL PROTECTED]
 Cc: Greg KH [EMAIL PROTECTED]
 Cc: Ingo Molnar [EMAIL PROTECTED]
 Cc: Jesse Barnes [EMAIL PROTECTED]
 Cc: Matthew Wilcox [EMAIL PROTECTED]
 Cc: Randy Dunlap [EMAIL PROTECTED]
 Cc: Roland Dreier [EMAIL PROTECTED]
 Signed-off-by: Yu Zhao [EMAIL PROTECTED]

 ---
  arch/x86/pci/i386.c |   28 ++--
  1 files changed, 14 insertions(+), 14 deletions(-)

 diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
 index 844df0c..8729bde 100644
 --- a/arch/x86/pci/i386.c
 +++ b/arch/x86/pci/i386.c
 @@ -147,7 +147,7 @@ static void __init pcibios_allocate_bus_resources(struct 
 list_head *bus_list)
  static void __init pcibios_allocate_resources(int pass)
  {
struct pci_dev *dev = NULL;
 -   int idx, disabled;
 +   int idx, enabled;
u16 command;
struct resource *r, *pr;

 @@ -160,22 +160,22 @@ static void __init pcibios_allocate_resources(int pass)
if (!r-start)  /* Address not assigned at all 
 */
continue;
if (r-flags  IORESOURCE_IO)
 -   disabled = !(command  PCI_COMMAND_IO);
 +   enabled = command  PCI_COMMAND_IO;
else
 -   disabled = !(command  PCI_COMMAND_MEMORY);
 -   if (pass == disabled) {
 -   dev_dbg(dev-dev, resource %#08llx-%#08llx 
 (f=%lx, d=%d, p=%d)\n,
 +   enabled = command  PCI_COMMAND_MEMORY;
 +   if (pass == enabled)
 +   continue;

it seems you change the flow here for MMIO
because PCI_COMMAND_MEMORY is 2.

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

Re: [PATCH 1/1] KVM: Fix incorrect KVM_USERSPACE_IRQ_SOURCE_ID

[Avi Kivity]

Sheng Yang wrote:
(When I am curious how this have been fixed without any patch, 


I edited the patch before pushing it out.


I just saw the
add-on fix is from Xiantao, and was reverted along with the other part of that
patch...)
  


Thanks for the fix; applied.  Xiantao, please be more careful.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

Re: Bug in protected mode segments?

[Avi Kivity]

Anthony Liguori wrote:

Mathias Gottschlag wrote:


Grub inits the CPU with no paging and flat segmenting, I now activate 
segments to move the code to 0xE000 and later activate paging and 
reset the segments. When I run this code on qemu or on real hardware 
(Athlon XP), everything works well, but on kvm I get several hangs. 
For example I try to write to 0xE00B8000 to write into the VGA 
framebuffer. This addres should now get translated back to 0xB8000 by 
the segment which has the base address 0x2000, and this 
definately works on real hardware, but on kvm I only notice a hang at 
the instruction which writes at that address (kvm still responds, but 
doesn't update eip anymore, execution stops.


I looked briefly and there didn't appear to be any explicit checks for 
wrap around but I think that it will work correctly since we're always 
using at least unsigned long in the host.  My suspicion is that we're 
somehow getting something wrong with MMIO decoding.


Well, unsigned long is 64-bits on a 64-bit host, so the generated 
address will be 0x1000b8000 instead of 0xb8000.  So the problem here is 
likely to be a missing wraparound, rather than a wraparound.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

RE: [PATCH 1/1] KVM: Fix incorrect KVM_USERSPACE_IRQ_SOURCE_ID

[Zhang, Xiantao]

Avi Kivity wrote:
 Sheng Yang wrote:
 (When I am curious how this have been fixed without any patch,

 I edited the patch before pushing it out.

 I just saw the
 add-on fix is from Xiantao, and was reverted along with the other
 part of that patch...)


 Thanks for the fix; applied.  Xiantao, please be more careful.

Hi, Avi
I am also curious about this issue. In my original patch, it doesn't 
include this stuff, but don't know why it is in this commit.  Attached my 
original patch :)
Thanks
Xiantao


From 532592ce64bbebb6d824fb528c281f4f3e0ee49f Mon Sep 17 00:00:00 2001
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Mon, 13 Oct 2008 18:37:49 +0800
Subject: [PATCH] kvm/ia64: Makefile fix for forcing to re-generate asm-offsets.h

To avoid using stale asm-offsets.h.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
---
 arch/ia64/kvm/Makefile |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index bf22fb9..39e742b 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -30,7 +30,7 @@ define cmd_offsets
 echo #endif )  $@
 endef
 # We use internal rules to avoid the is up to date message from make
-arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c
+arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c FORCE
$(call if_changed_dep,cc_s_c)

 $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s
@@ -49,7 +49,6 @@ common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o 
ioapic.o \
 kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o
 obj-$(CONFIG_KVM) += kvm.o

-FORCE : $(obj)/$(offsets-file)
 EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
 kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o \
vtlb.o process.o
--
1.5.1

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

Re: [PATCH 1/1] KVM: Fix incorrect KVM_USERSPACE_IRQ_SOURCE_ID

[Avi Kivity]

Zhang, Xiantao wrote:

I am also curious about this issue. In my original patch, it doesn't 
include this stuff, but don't know why it is in this commit.  Attached my 
original patch :)
  


Then it's probably my fault.  I probably had some garbage in the git 
index which got merged into the patch when applying.  Sorry.



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

Re: [PATCH 1/1] kvm: bios: Update e820 table for EPT real mode pagetable

[Sheng Yang]

On Friday 17 October 2008 15:17:52 Sheng Yang wrote:
 I remembered I had sent this long long ago, but happened to find it missing
 in upstream...

 Signed-off-by: Sheng Yang [EMAIL PROTECTED]

Avi?
-- 
regards
Yang, Sheng

 ---
  bios/rombios.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/bios/rombios.c b/bios/rombios.c
 index 818ce63..9a1cdd6 100644
 --- a/bios/rombios.c
 +++ b/bios/rombios.c
 @@ -4578,8 +4578,9 @@ ASM_END
  return;
  break;
  case 5:
 -/* 3 pages before the bios, we map the vmx tss
 pages */ -set_e820_range(ES, regs.u.r16.di,
 0xfffbd000L, +/* 4 pages before the bios, 3 pages
 for vmx tss pages, +   * the other page for EPT real mode 
 pagetable */
 +set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
 0xfffcL, 0, 0, 2);
  regs.u.r32.ebx = 6;
  regs.u.r32.eax = 0x534D4150;


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

Re: [PATCH 7/16 v6] PCI: cleanup pcibios_allocate_resources()

[Yu Zhao]

On Thu, Oct 23, 2008 at 03:10:26PM +0800, Yinghai Lu wrote:
 On Wed, Oct 22, 2008 at 1:42 AM, Yu Zhao [EMAIL PROTECTED] wrote:
  diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
  index 844df0c..8729bde 100644
  --- a/arch/x86/pci/i386.c
  +++ b/arch/x86/pci/i386.c
  @@ -147,7 +147,7 @@ static void __init 
  pcibios_allocate_bus_resources(struct list_head *bus_list)
   static void __init pcibios_allocate_resources(int pass)
   {
 struct pci_dev *dev = NULL;
  -   int idx, disabled;
  +   int idx, enabled;
 u16 command;
 struct resource *r, *pr;
 
  @@ -160,22 +160,22 @@ static void __init pcibios_allocate_resources(int 
  pass)
 if (!r-start)  /* Address not assigned at 
  all */
 continue;
 if (r-flags  IORESOURCE_IO)
  -   disabled = !(command  PCI_COMMAND_IO);
  +   enabled = command  PCI_COMMAND_IO;
 else
  -   disabled = !(command  PCI_COMMAND_MEMORY);
  -   if (pass == disabled) {
  -   dev_dbg(dev-dev, resource 
  %#08llx-%#08llx (f=%lx, d=%d, p=%d)\n,
  +   enabled = command  PCI_COMMAND_MEMORY;
  +   if (pass == enabled)
  +   continue;
 
 it seems you change the flow here for MMIO
 because PCI_COMMAND_MEMORY is 2.
 
 YH

Nice finding! Will change it back to 'disable' next version.

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

Re: [PATCH] KVM: x86: Don't deliver PIC interrupts to disabled APICs - v2

[Jan Kiszka]

Yang, Sheng wrote:
 On Thursday 23 October 2008 04:44:48 Jan Kiszka wrote:
 Jan Kiszka wrote:
 Jan Kiszka wrote:
 Jan Kiszka wrote:
 Avi Kivity wrote:
 Jan Kiszka wrote:
 [ taking Sheng's comments into account ]

 The logic of kvm_apic_accept_pic_intr has a minor, practically hardly
 relevant incorrectness: PIC interrupts are still delivered even if
 the APIC of VPU0 (BSP) is disabled. This does not comply with the
 Virtual Wire mode according to the Intel MP spec.
 This breaks Windows XP with the Standard PC HAL, so I am unapplying
 this patch.
 Hmm, this points to either an APIC setup or BIOS bug. To my
 understanding, the Standard PC HAL should not fiddle with the APIC, so
 what the BIOS leaves behind should counts. But I think I found no
 traces of APIC manipulation in rombios32.c.
 Manipulation on UP systems. There is fiddling for SMP. But I will check
 again.
 I take everything back: For yet unknown reasons Windows' standard HAL
 actually decides to disable the APIC actively. Either there is a
 short-path around a disabled APIC for Virtual Wire mode in Real Live
 (though I fail to read this out of the spec), or Windows simply has a
 bug here (MS insists on NOT supporting the Standard HAL on APIC systems
 [1] - precisely the setup KVM is providing). Sheng, any comments on
 this? Guess we have to live with the previous version, maybe with some
 refactoring + commenting.
 I was curious and played with my corresponding qemu patch [1]: It works
 with the same Windows image that hangs under KVM. Then I looked at a
 prominent guest-visible difference: the reported CPU type. QEMU claims
 to provide a CPU called qemu64 by default. Changing this to Pentium2
 or newer makes Windows issue the lethal APIC disable command. On the
 other hand, calling kvm with -cpu pentium makes Windows boot again.

 However, I still can't tell from this if we see a Windows bug or if the
 change is incorrect (but me feeling tends to the former).
 
 Confirmed that -cpu pentium solve the problem. But...
 
 Sorry for that I've found that I neglected some info on the spec. SDM 3B 
 5.3.1 External Interrupts.
 
 When the local APIC is global/hardware disabled, these pins are configured 
 as 
 INTR and NMI pins, respectively.

Ah, that's the short-path...

 
 So, it's right to inject PIC interrupt when LAPIC is hardware disabled. I 
 think we can drop this patch...
 
 (I will be more careful on such kind of issues next time...)

Well, first of all, I brought this up. Sorry for all the fuss.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] userspace: update .gitignore

[Jan Kiszka]

Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
diff --git a/.gitignore b/.gitignore
index 0cabc17..fcdc357 100644
--- a/.gitignore
+++ b/.gitignore
@@ -51,6 +51,8 @@ kernel/x86/tss.h
 kernel/x86/x86.[ch]
 kernel/x86/coalesced_mmio.[ch]
 kernel/x86/kvm_cache_regs.h
+kernel/x86/vtd.c
+kernel/x86/irq_comm.c
 qemu/pc-bios/extboot.bin
 qemu/qemu-doc.html
 qemu/*.[18]
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND][PATCH] KVM: VMX: Report VNMI emulation

[Jan Kiszka]

In case we ever have to debug possibly NMI-related issues of the guest,
it may help to correlate them with the VNMI emulation for older VMX
CPUs.

Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
 arch/x86/kvm/vmx.c |4 
 1 file changed, 4 insertions(+)

Index: b/arch/x86/kvm/vmx.c
===
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3671,6 +3671,10 @@ static int __init vmx_init(void)
 
ept_sync_global();
 
+   if (!cpu_has_virtual_nmis())
+   printk(KERN_WARNING
+  kvm: emulating NMI window via interrupt window\n);
+
return 0;
 
 out2:

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

MTU on a virtio-net device?

[Michael Tokarev]

Right now (2.6.27), there's no way to change MTU of a
virtio-net interface, since the mtu-changing method is
not provided.  Is there a simple way to add such a
beast?

I'm asking because I'm not familiar with the internals,
and because, I think, increasing MTU (so that the
resulting skb still fits in a single page) will increase
performance significantly, at least on a internal/virtual
network -- currently there are just way too many context
switches and the like while copying data from one guest
to another or between guest and host.

Thanks!

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

Re: kvm XP P2V required ACPI-Standard PC HAL change, keep or revert to ACPI?

[Dor Laor]

Jeff Kowalczyk wrote:

I'm running a physical-to-virtual Windows XP Dell OEM instance on Ubuntu
8.04.1 kvm-62 with kvm-intel and bridged networking.

After early BSOD difficulty with the output of VMWare Converter
3.0.3, I did manage to get the XP P2V instance ready to run under
kvm after changing from the Windows XP HAL ACPI to Standard PC in device
manager under VMWare Player.

After a complete redetection of system hardware and resources (perhaps
this was the true reason it started to work), the instance must now be
activated again. It works very well, but must be shut down at the You may
now turn off the PC.

This is a headless kvm server for a few straggle windows apps, and the kvm
instance will seldom be rebooted.

Should I activate as Standard PC, or attempt to convert the HAL back to
ACPI.

  

Basically it should work. Maybe newer kvm will encounter less problems.

Is there still any performance penalty for ACPI with kvm-62?

  
Since we have the tpr optimization it should be fine. Nevertheless we 
did measure about 10%-20% performance

penalty on windows acpi.

What is the kvm shutdown behavior with an ACPI HAL?
  

It should be fine and turn off the process completely.
btw: you can install APM module on the standard HAL too and it power 
down the VM to exit completely too.

Thanks,
Jeff


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


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

Re: MTU on a virtio-net device?

[Dor Laor]

Michael Tokarev wrote:

Right now (2.6.27), there's no way to change MTU of a
virtio-net interface, since the mtu-changing method is
not provided.  Is there a simple way to add such a
beast?


It should be a nice easy patch for mtu  4k.
You can just implement a 'change_mtu' handler like:

static int virtio_change_mtu(struct net_device *netdev, int new_mtu)
{
   if(new_mtu  ETH_ZLEN || new_mtu  PAGE_SIZE)
   return -EINVAL;
   netdev-mtu = new_mtu;
   return 0;
}


I'm asking because I'm not familiar with the internals,
and because, I think, increasing MTU (so that the
resulting skb still fits in a single page) will increase
performance significantly, at least on a internal/virtual
network -- currently there are just way too many context
switches and the like while copying data from one guest
to another or between guest and host.

Thanks!

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


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

Re: MTU on a virtio-net device?

[Michael Tokarev]

Dor Laor wrote:
 Michael Tokarev wrote:
 Right now (2.6.27), there's no way to change MTU of a
 virtio-net interface, since the mtu-changing method is
 not provided.  Is there a simple way to add such a
 beast?

 It should be a nice easy patch for mtu  4k.
 You can just implement a 'change_mtu' handler like:
 
 static int virtio_change_mtu(struct net_device *netdev, int new_mtu)
 {
if(new_mtu  ETH_ZLEN || new_mtu  PAGE_SIZE)
return -EINVAL;
netdev-mtu = new_mtu;
return 0;
 }

Well, this isn't enough I think.  That is, new_mtu's upper cap should be
less than PAGE_SIZE due to various additional data structures.  But it
is enough to start playing.

I just added the above method, which allowed me to set MTU to 3500
(arbitrary).  But it still does not work.  In guest, I see the
following while pinging it from host with `ping -s2000':

16:26:57.952684 IP truncated-ip - 528 bytes missing! 81.13.33.145  
81.13.33.150: ICMP echo request, id 12869, seq 19, length 2008
16:26:58.954133 IP truncated-ip - 528 bytes missing! 81.13.33.145  
81.13.33.150: ICMP echo request, id 12869, seq 20, length 2008
...

So something else has to be changed for this to work, it seems.
That's why I wrote:

 I'm asking because I'm not familiar with the internals,
[...]

;)

Thanks!

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

Re: MTU on a virtio-net device?

[Michael Tokarev]

Dor Laor wrote:
 Michael Tokarev wrote:
 Dor Laor wrote:
   
 Michael Tokarev wrote:
 
 Right now (2.6.27), there's no way to change MTU of a
 virtio-net interface, since the mtu-changing method is
 not provided.  Is there a simple way to add such a
 beast?
   
 It should be a nice easy patch for mtu  4k.
 You can just implement a 'change_mtu' handler like:
[]
 Well, this isn't enough I think.  That is, new_mtu's upper cap should be
 less than PAGE_SIZE due to various additional data structures.  But it
 is enough to start playing.
   
 The virtio header is in a separate ring entry so no prob.

virtio header is one thing.  Ethernet frame is another.  And
so on.  From the last experiment (sending 2000bytes-payload
pings resulting in 2008 bytes total, and 528 bytes missing
with original mtu=1500), it seems like the necessary upper
cap is PAGE_SIZE-28.  Or something similar.

Also see receive_skb() routine:

receive_skb(struct net_device *dev, struct sk_buff *skb, unsigned len)
{
  if (unlikely(len  sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
/*drop*/
  }
  len -= sizeof(struct virtio_net_hdr);
  if (len = MAX_PACKET_LEN) {
  ...

So it seems that virtio_net_hdr is in here, just like
ethernet header.

[]
 So something else has to be changed for this to work, it seems.
 You're right, this was needs to be changed to:
 /* FIXME: MTU in config. */
 #define MAX_PACKET_LEN (ETH_HLEN+ETH_DATA_LEN)
 
 You can change it to PAGE_SIZE or have the current mtu.

so s/MAX_PACKET_LEN/dev-mtu/g for the whole driver, it
seems.  Plus/minus sizeof(virtio_net_hdr) - checking this now.
This constant is used in 3 places:

receive_skb(): if (len = MAX_PACKET_LEN) {
 (this one seems to be wrong, but again I don't know much
  internals of all this stuff)
 here, dev-mtu is what we want.

try_fill_recv(): skb = netdev_alloc_skb(vi-dev, MAX_PACKET_LEN);
 here, we don't have dev, but have vi-dev, should be ok too.
try_fill_recv(): skb_put(skb, MAX_PACKET_LEN);
 ditto

And by the way, what is big_packets here?

Ok, so I changed MAX_PACKET_LEN to be PAGE_SIZE (current MTU
seems to be more appropriate but PAGE_SIZE is enough for
testing anyway).  It seems to be working, and network
speed increased significantly with MTU=3500 compared with
former 1500 - it seems it's about 2 times faster (which is
quite expectable, since there's 2x less context switches,
transmissions and the like).

 I'm asking because I'm not familiar with the internals,

Still... ;)

Thanks!

/mjt

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

Re: MTU on a virtio-net device?

[Dor Laor]

Michael Tokarev wrote:

Dor Laor wrote:
  

Michael Tokarev wrote:


Dor Laor wrote:
  
  

Michael Tokarev wrote:



Right now (2.6.27), there's no way to change MTU of a
virtio-net interface, since the mtu-changing method is
not provided.  Is there a simple way to add such a
beast?
  
  

It should be a nice easy patch for mtu  4k.
You can just implement a 'change_mtu' handler like:


[]
  

Well, this isn't enough I think.  That is, new_mtu's upper cap should be
less than PAGE_SIZE due to various additional data structures.  But it
is enough to start playing.
  
  

The virtio header is in a separate ring entry so no prob.



virtio header is one thing.  Ethernet frame is another.  And
so on.  From the last experiment (sending 2000bytes-payload
pings resulting in 2008 bytes total, and 528 bytes missing
with original mtu=1500), it seems like the necessary upper
cap is PAGE_SIZE-28.  Or something similar.

Also see receive_skb() routine:

receive_skb(struct net_device *dev, struct sk_buff *skb, unsigned len)
{
  if (unlikely(len  sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
/*drop*/
  }
  len -= sizeof(struct virtio_net_hdr);
  if (len = MAX_PACKET_LEN) {
  ...

So it seems that virtio_net_hdr is in here, just like
ethernet header.

[]
  

So something else has to be changed for this to work, it seems.
  

You're right, this was needs to be changed to:
/* FIXME: MTU in config. */
#define MAX_PACKET_LEN (ETH_HLEN+ETH_DATA_LEN)

You can change it to PAGE_SIZE or have the current mtu.



so s/MAX_PACKET_LEN/dev-mtu/g for the whole driver, it
seems.  Plus/minus sizeof(virtio_net_hdr) - checking this now.
This constant is used in 3 places:

receive_skb(): if (len = MAX_PACKET_LEN) {
 (this one seems to be wrong, but again I don't know much
  internals of all this stuff)
 here, dev-mtu is what we want.

try_fill_recv(): skb = netdev_alloc_skb(vi-dev, MAX_PACKET_LEN);
 here, we don't have dev, but have vi-dev, should be ok too.
try_fill_recv(): skb_put(skb, MAX_PACKET_LEN);
 ditto

  

I was too lazy to write a complete patch.

And by the way, what is big_packets here?
  

It's a bit harder here, IIRC qemu also has a 4k limit.
Not that it can be done in a short period.

Anyway you can use GSO and achieve similar performance.

Ok, so I changed MAX_PACKET_LEN to be PAGE_SIZE (current MTU
seems to be more appropriate but PAGE_SIZE is enough for
testing anyway).  It seems to be working, and network
speed increased significantly with MTU=3500 compared with
former 1500 - it seems it's about 2 times faster (which is
quite expectable, since there's 2x less context switches,
transmissions and the like).

  

I'm asking because I'm not familiar with the internals,
  


Still... ;)

Thanks!

/mjt

  

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

[PATCH 1/2] kvm: libkvm: Unmap kvm_run struct and close vcpu fds in kvm_finalize.

[François Diakhate]

Signed-off-by: François Diakhaté [EMAIL PROTECTED]
---
 libkvm/libkvm.c |   24 +++-
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index 444b97f..44c931b 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -286,6 +286,7 @@ kvm_context_t kvm_init(struct kvm_callbacks *callbacks,
int fd;
kvm_context_t kvm;
int r;
+   int i;

fd = open(/dev/kvm, O_RDWR);
if (fd == -1) {
@@ -317,6 +318,8 @@ kvm_context_t kvm_init(struct kvm_callbacks *callbacks,
memset(kvm, 0, sizeof(*kvm));
kvm-fd = fd;
kvm-vm_fd = -1;
+   for (i = 0; i  MAX_VCPUS; ++i)
+   kvm-vcpu_fd[i] = -1;
kvm-callbacks = callbacks;
kvm-opaque = opaque;
kvm-dirty_pages_log_all = 0;
@@ -331,9 +334,16 @@ kvm_context_t kvm_init(struct kvm_callbacks *callbacks,

 void kvm_finalize(kvm_context_t kvm)
 {
-   if (kvm-vcpu_fd[0] != -1)
-   close(kvm-vcpu_fd[0]);
-   if (kvm-vm_fd != -1)
+   int i;
+   long mmap_size;
+
+   mmap_size = ioctl(kvm-fd, KVM_GET_VCPU_MMAP_SIZE, 0);
+   for(i = 0; i  MAX_VCPUS; ++i)
+   if (kvm-vcpu_fd[i] != -1){
+   close(kvm-vcpu_fd[i]);
+   munmap(kvm-run[i], mmap_size);
+   }
+   if (kvm-vm_fd != -1)
close(kvm-vm_fd);
close(kvm-fd);
free(kvm);
@@ -365,16 +375,20 @@ int kvm_create_vcpu(kvm_context_t kvm, int slot)
if (mmap_size == -1) {
r = -errno;
fprintf(stderr, get vcpu mmap size: %m\n);
-   return r;
+   goto error;
}
kvm-run[slot] = mmap(NULL, mmap_size, PROT_READ|PROT_WRITE, MAP_SHARED,
  kvm-vcpu_fd[slot], 0);
if (kvm-run[slot] == MAP_FAILED) {
r = -errno;
fprintf(stderr, mmap vcpu area: %m\n);
-   return r;
+   goto error;
}
return 0;
+error:
+   close(kvm-vcpu_fd[slot]);
+   kvm-vcpu_fd[slot] = -1;
+   return r;
 }

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

[PATCH 2/2] KVM: Fix kvm_free_physmem memory leak.

[François Diakhate]

Make sure that kvm_free_physmem actually frees memory
when a memory slot is not user allocated.

Signed-off-by: François Diakhaté [EMAIL PROTECTED]
---
 arch/x86/kvm/x86.c  |2 +-
 virt/kvm/kvm_main.c |   11 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 883c137..ae360dc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4195,7 +4195,7 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
memslot-userspace_addr = userspace_addr;
spin_unlock(kvm-mmu_lock);
} else {
-   if (!old.user_alloc  old.rmap) {
+   if (!old.user_alloc  old.rmap  current-mm) {
int ret;

down_write(current-mm-mmap_sem);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a87f45e..b0d7435 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -639,8 +639,17 @@ void kvm_free_physmem(struct kvm *kvm)
 {
int i;

-   for (i = 0; i  kvm-nmemslots; ++i)
+   for (i = 0; i  kvm-nmemslots; ++i) {
+   struct kvm_userspace_memory_region mem = {
+   .slot = i,
+   .guest_phys_addr = kvm-memslots[i].base_gfn  
PAGE_SHIFT,
+   .memory_size = 0,
+   .flags = 0,
+   };
+
+   kvm_set_memory_region(kvm, mem, kvm-memslots[i].user_alloc);
kvm_free_physmem_slot(kvm-memslots[i], NULL);
+   }
 }

 static void kvm_destroy_vm(struct kvm *kvm)
-- 
1.6.0.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] Fix memory leaks when VMs are destroyed

[François Diakhate]

Currently, due to a few oversights, when kvm_finalize is called there
are several memory
allocations which are not taken care of and are only freed when the
process exits.

- In libkvm, VCPU file descriptors are not closed and the
corresponding kvm_run structures
 are not unmapped.

- In the kvm module, VM memory which is not allocated by userspace
 (for example TSS data on x86)  is not  freed.

The following patches try to fix these issues although I don't have
much experience in
kernel developpement so please forgive me for my mistakes ;) In
particular I had to add
a test on current-mm because it seems that when a process is closed,
its address space
is released before its files are closed. I dont know if that is the
correct way to proceed...
Any comments are welcome !

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

[PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Gleb Natapov]

Hello,

This patch series adds S3 (suspend to RAM) ACPI state. Most changes
are in the BIOS code and concern themselves with preventing BIOS from
using memory available to OS.

---

Gleb Natapov (8):
  Don't power down vga card on entering S3 state.
  Add DPMS support to cirrus vga bios.
  Don't use unreserved memory in BIOS.
  Execute rombios32 code from rom address 0xe.
  Disable init of SMM.
  Add S3 state to DSDT. Handle resume event in the BIOS.
  Handle suspend in qemu.
  Move PIC initialization out of line to save space in post code area.


 bios/Makefile |1 
 bios/acpi-dsdt.dsl|   49 +++
 bios/rombios.c|  106 ++---
 bios/rombios.h|4 +-
 bios/rombios32.c  |   78 +---
 bios/rombios32.ld |8 +---
 bios/rombios32start.S |9 
 qemu/hw/acpi.c|   10 +
 qemu/hw/pc.c  |8 
 qemu/hw/pc.h  |1 
 qemu/qemu-kvm.c   |2 -
 qemu/qemu-kvm.h   |1 
 vgabios/clext.c   |   36 -
 13 files changed, 247 insertions(+), 66 deletions(-)


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

[PATCH 3/8] Add S3 state to DSDT. Handle resume event in the BIOS.

[Gleb Natapov]

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 bios/acpi-dsdt.dsl |   33 ++-
 bios/rombios.c |   35 +
 bios/rombios32.c   |   74 
 3 files changed, 130 insertions(+), 12 deletions(-)

diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 577b3fe..02f53a1 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -65,6 +65,32 @@ DefinitionBlock (
gen_processor(14, E)
 }
 
+/*
+ * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
+ * must match piix4 emulation.
+ */
+Name (\_S3, Package (0x04)
+{
+0x01,  /* PM1a_CNT.SLP_TYP */
+0x01,  /* PM1b_CNT.SLP_TYP */
+Zero,  /* reserved */
+Zero   /* reserved */
+})
+Name (\_S4, Package (0x04)
+{
+Zero,  /* PM1a_CNT.SLP_TYP */
+Zero,  /* PM1b_CNT.SLP_TYP */
+Zero,  /* reserved */
+Zero   /* reserved */
+})
+Name (\_S5, Package (0x04)
+{
+Zero,  /* PM1a_CNT.SLP_TYP */
+Zero,  /* PM1b_CNT.SLP_TYP */
+Zero,  /* reserved */
+Zero   /* reserved */
+})
+
 Scope (\)
 {
 /* Debug Output */
@@ -626,13 +652,6 @@ DefinitionBlock (
 }
 }
 
-/* S5 = power off state */
-Name (_S5, Package (4) {
-0x00, // PM1a_CNT.SLP_TYP
-0x00, // PM2a_CNT.SLP_TYP
-0x00, // reserved
-0x00, // reserved
-})
 Scope (\_GPE)
 {
 
diff --git a/bios/rombios.c b/bios/rombios.c
index 529f3bd..5c75043 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -2198,6 +2198,32 @@ debugger_off()
   outb(0xfedc, 0x00);
 }
 
+void
+s3_resume()
+{
+Bit32u s3_wakeup_vector;
+Bit8u s3_resume_flag;
+
+s3_resume_flag = read_byte(0x40, 0xb0);
+s3_wakeup_vector = read_dword(0x40, 0xb2);
+
+BX_INFO(S3 resume called %x 0x%lx\n, s3_resume_flag, s3_wakeup_vector);
+if (s3_resume_flag != 0xFE || !s3_wakeup_vector)
+   return;
+
+write_byte(0x40, 0xb0, 0);
+
+/* setup wakeup vector */
+write_word(0x40, 0xb6, (s3_wakeup_vector  0xF)); /* IP */
+write_word(0x40, 0xb8, (s3_wakeup_vector  4)); /* CS */
+
+BX_INFO(S3 resume jump to %x:%x\n, *(Bit16u*)0x04b8, *(Bit16u*)0x04b6);
+ASM_START
+mov sp, #0 ;; disable tpr patching on boot CPU 
+jmpf [0x04b6]
+ASM_END
+}
+
 #if BX_USE_ATADRV
 
 // ---
@@ -10036,6 +10062,10 @@ rombios32_05:
   ;; init the stack pointer
   mov esp, #0x0008
 
+  ;; pass pointer to s3_resume_flag and s3_resume_vector to rombios32
+  push #0x04b0
+  push #0x04b2
+
   ;; call rombios32 code
   mov eax, #0x0004
   call eax
@@ -10424,6 +10454,9 @@ normal_post:
   rep
 stosw
 
+  ;; Save shutdown status
+  mov 0x04b0, bl
+
   call _log_bios_start
 
   ;; set all interrupts to default handler
@@ -10634,6 +10667,8 @@ post_default_ints:
   mov  ax, #0xe000
   call rom_scan
 
+  call _s3_resume
+
 #if BX_ELTORITO_BOOT
   call _interactive_bootkey
 #endif // BX_ELTORITO_BOOT
diff --git a/bios/rombios32.c b/bios/rombios32.c
index a91b155..3833878 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -213,6 +213,20 @@ void *memmove(void *d1, const void *s1, size_t len)
 return d1;
 }
 
+int memcmp(const void *s1, const void *s2, size_t len)
+{
+   const int8_t *p1 = s1;
+   const int8_t *p2 = s2;
+
+   while (len--) {
+   int r = *p1++ - *p2++;
+   if(r)
+   return r;
+   }
+
+   return 0;
+}
+
 size_t strlen(const char *s)
 {
 const char *s1;
@@ -568,7 +582,6 @@ void ram_probe(void)
   ebda_cur_addr = ((*(uint16_t *)(0x40e))  4) + 0x380;
   BX_INFO(ebda_cur_addr: 0x%08lx\n, ebda_cur_addr);
 #endif
-  setup_mtrr();
 }
 
 //
@@ -756,7 +769,7 @@ static void bios_shadow_init(PCIDevice *d)
 {
 int v;
 
-if (find_bios_table_area()  0)
+if (bios_table_cur_addr == 0)
 return;
 
 /* remap the BIOS to shadow RAM an keep it read/write while we
@@ -1528,7 +1541,7 @@ void acpi_bios_init(void)
 memset(facs, 0, sizeof(*facs));
 memcpy(facs-signature, FACS, 4);
 facs-length = cpu_to_le32(sizeof(*facs));
-
+BX_INFO(Firmware waking vector %p\n, facs-firmware_waking_vector);
 /* DSDT */
 memcpy(dsdt, AmlCode, sizeof(AmlCode));
 
@@ -2099,9 +2112,40 @@ void smbios_init(void)
 BX_INFO(SMBIOS table addr=0x%08lx\n, (unsigned long)start);
 }
 
-void rombios32_init(void)
+static uint32_t find_resume_vector(void)
+{
+unsigned long addr;
+
+if (bios_table_cur_addr == 0)
+return 0;
+
+for (addr = bios_table_cur_addr; addr  bios_table_end_addr; addr++) {
+if (!memcmp((void*)addr, RSD PTR , 8)) {
+struct rsdp_descriptor *rsdp = (void*)addr;
+struct rsdt_descriptor_rev1 *rsdt = 
(void*)rsdp-rsdt_physical_address;
+ 

[PATCH 5/8] Execute rombios32 code from rom address 0xe0000.

[Gleb Natapov]

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 bios/Makefile |1 +
 bios/rombios.c|   17 +
 bios/rombios32.ld |8 +++-
 bios/rombios32start.S |9 -
 4 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/bios/Makefile b/bios/Makefile
index 48022ea..f3f2758 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -106,6 +106,7 @@ rombios32.o: rombios32.c acpi-dsdt.hex
 acpi-dsdt.hex: acpi-dsdt.dsl
cpp -P $ $.i
iasl -tc -p $@ $.i
+   sed -i -e's/^unsigned/const unsigned/' $@
rm $.i
 
 rombios32start.o: rombios32start.S
diff --git a/bios/rombios.c b/bios/rombios.c
index 5c75043..340af30 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -10052,13 +10052,6 @@ rombios32_05:
   mov gs, ax
   cld
 
-  ;; copy rombios32 code to ram (ram offset = 1MB)
-  mov esi, #0xfffe
-  mov edi, #0x0004
-  mov ecx, #0x1 / 4
-  rep
-movsd
-
   ;; init the stack pointer
   mov esp, #0x0008
 
@@ -10067,17 +10060,9 @@ rombios32_05:
   push #0x04b2
 
   ;; call rombios32 code
-  mov eax, #0x0004
+  mov eax, #0x000e
   call eax
 
-  ;; reset the memory (some boot loaders such as syslinux suppose
-  ;; that the memory is set to zero)
-  mov edi, #0x0004
-  mov ecx, #0x4 / 4
-  xor eax, eax
-  rep
-stosd
-
   ;; return to 16 bit protected mode first
   db 0xea
   dd rombios32_10
diff --git a/bios/rombios32.ld b/bios/rombios32.ld
index 4f8fcc3..c334225 100644
--- a/bios/rombios32.ld
+++ b/bios/rombios32.ld
@@ -3,18 +3,16 @@ OUTPUT_ARCH(i386)
 ENTRY(_start);
 SECTIONS
 {
-. = 0x0004;
+. = 0x000e;
 .text : { *(.text)}
 .rodata: { *(.rodata) }
 . = ALIGN(64);
 fixup_start = .;
 .fixup: { *(.fixup) }
 fixup_end = .;
-. = ALIGN(4096);
-.data : { *(.data)}
-__bss_start = . ;
-.bss  : { *(.bss) *(COMMON) }
 _end = . ;
+.data 0x700 : AT (_end) { __data_start = .; *(.data); __data_end = .;}
+.bss  : { __bss_start = .; *(.bss) *(COMMON); __bss_end = .;}
 /DISCARD/ : { *(.stab)
  *(.stabstr)
  *(.comment)
diff --git a/bios/rombios32start.S b/bios/rombios32start.S
index 4dcee3a..449a5db 100644
--- a/bios/rombios32start.S
+++ b/bios/rombios32start.S
@@ -32,10 +32,17 @@ _start:
   /* clear bss section */
   xor %eax, %eax
   mov $__bss_start, %edi
-  mov $_end, %ecx
+  mov $__bss_end, %ecx
   sub %edi, %ecx
   rep stosb
 
+  /* copy data section */
+  mov $_end, %esi
+  mov $__data_start, %edi
+  mov $__data_end, %ecx
+  sub %edi, %ecx
+  rep movsb
+
   jmp rombios32_init
 
   .code16

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

[PATCH 6/8] Don't use unreserved memory in BIOS.

[Gleb Natapov]

Use only first page and last page of low memory. OSes assumes that first
page is used by bios and last page is reserved in e820 map.

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 bios/rombios.c   |6 +++---
 bios/rombios.h   |4 ++--
 bios/rombios32.c |2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/bios/rombios.c b/bios/rombios.c
index 340af30..01f9cbb 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -4551,7 +4551,7 @@ ASM_END
 {
 case 0:
 set_e820_range(ES, regs.u.r16.di,
-   0x000L, 0x0009fc00L, 0, 0, 1);
+   0x000L, 0x0009f000L, 0, 0, 1);
 regs.u.r32.ebx = 1;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4560,7 +4560,7 @@ ASM_END
 break;
 case 1:
 set_e820_range(ES, regs.u.r16.di,
-   0x0009fc00L, 0x000aL, 0, 0, 2);
+   0x0009f000L, 0x000aL, 0, 0, 2);
 regs.u.r32.ebx = 2;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -10053,7 +10053,7 @@ rombios32_05:
   cld
 
   ;; init the stack pointer
-  mov esp, #0x0008
+  mov esp, #0x9fbf0
 
   ;; pass pointer to s3_resume_flag and s3_resume_vector to rombios32
   push #0x04b0
diff --git a/bios/rombios.h b/bios/rombios.h
index feed101..3784744 100644
--- a/bios/rombios.h
+++ b/bios/rombios.h
@@ -56,8 +56,8 @@
 #define ACPI_DATA_SIZE0x0001L
 #define PM_IO_BASE0xb000
 #define SMB_IO_BASE   0xb100
-#define CPU_COUNT_ADDR0xf000
-#define SMP_MSR_ADDR  0xf010
+#define CPU_COUNT_ADDR0x0500
+#define SMP_MSR_ADDR  0x0504
 
 #define MAX_CPUS 16
 
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 2c08bfb..a901c6a 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -60,7 +60,7 @@ typedef unsigned long long uint64_t;
 
 #define APIC_ENABLED 0x0100
 
-#define AP_BOOT_ADDR 0x1
+#define AP_BOOT_ADDR 0x9f000
 
 #define MPTABLE_MAX_SIZE  0x2000
 #define SMI_CMD_IO_ADDR   0xb2

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

[PATCH 7/8] Add DPMS support to cirrus vga bios.

[Gleb Natapov]

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 vgabios/clext.c |   36 ++--
 1 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/vgabios/clext.c b/vgabios/clext.c
index ea37ec5..c7a2ad0 100644
--- a/vgabios/clext.c
+++ b/vgabios/clext.c
@@ -510,7 +510,7 @@ cirrus_vesa:
 #ifdef CIRRUS_DEBUG
   call cirrus_debug_dump
 #endif
-  cmp al, #0x0F
+  cmp al, #0x10
   ja cirrus_vesa_not_handled
   push bx
   xor bx, bx
@@ -1196,6 +1196,37 @@ cirrus_vesa_07h_2:
   mov  ax, #0x004f
   ret
 
+cirrus_vesa_10h:
+  cmp bl, #0x00
+  jne cirrus_vesa_10h_01
+  mov bx, #0x0f30
+  mov ax, #0x004f
+  ret
+cirrus_vesa_10h_01:
+  cmp bl, #0x01
+  jne cirrus_vesa_10h_02
+  push dx
+  push ds
+  mov dx, #0x40
+  mov ds, dx
+  mov [0xb9], bh
+  pop ds
+  pop dx
+  mov ax, #0x004f
+  ret
+cirrus_vesa_10h_02:
+  cmp bl, #0x02
+  jne cirrus_vesa_unimplemented
+  push dx
+  push ds
+  mov dx, #0x40
+  mov ds, dx
+  mov bh, [0xb9]
+  pop ds
+  pop dx
+  mov ax, #0x004f
+  ret
+
 cirrus_vesa_unimplemented:
   mov ax, #0x014F ;; not implemented
   ret
@@ -1612,7 +1643,8 @@ cirrus_vesa_handlers:
   dw cirrus_vesa_unimplemented
   dw cirrus_vesa_unimplemented
   dw cirrus_vesa_unimplemented
-
+  ;; 10h
+  dw cirrus_vesa_10h
 
 
 ASM_END

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

[PATCH 4/8] Disable init of SMM.

[Gleb Natapov]

SMM initialization uses memory available for OS use.

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 bios/rombios32.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bios/rombios32.c b/bios/rombios32.c
index 3833878..2c08bfb 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -38,7 +38,7 @@ typedef unsigned long long uint64_t;
 //#define BX_USE_EBDA_TABLES
 
 /* define it if the (emulated) hardware supports SMM mode */
-#define BX_USE_SMM
+//#define BX_USE_SMM
 
 #define cpuid(index, eax, ebx, ecx, edx) \
   asm volatile (cpuid \

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

[PATCH 2/8] Handle suspend in qemu.

[Gleb Natapov]

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 qemu/hw/acpi.c  |   10 ++
 qemu/hw/pc.c|8 
 qemu/hw/pc.h|1 +
 qemu/qemu-kvm.c |2 +-
 qemu/qemu-kvm.h |1 +
 5 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 7a7a534..e6494c5 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -56,6 +56,8 @@ typedef struct PIIX4PMState {
 qemu_irq irq;
 } PIIX4PMState;
 
+#define RSM_STS (1  15)
+#define PWRBTN_STS (1  8)
 #define RTC_EN (1  10)
 #define PWRBTN_EN (1  8)
 #define GBL_EN (1  5)
@@ -154,6 +156,14 @@ static void pm_ioport_writew(void *opaque, uint32_t addr, 
uint32_t val)
 case 0: /* soft power off */
 qemu_system_shutdown_request();
 break;
+   case 1:
+   /* RSM_STS should be set on resume. Pretend that resume
+  was caused by power button */
+   s-pmsts |= (RSM_STS | PWRBTN_STS);
+   kvm_shutdown(NULL, 0);
+#if defined(TARGET_I386)
+   cmos_set_s3_resume();
+#endif
 default:
 break;
 }
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index d559f0c..37d013e 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -1183,6 +1183,14 @@ static void pc_init_isa(ram_addr_t ram_size, int 
vga_ram_size,
  initrd_filename, 0, cpu_model);
 }
 
+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
+   BIOS will read it and start S3 resume at POST Entry */
+void cmos_set_s3_resume(void)
+{
+if (rtc_state)
+rtc_set_memory(rtc_state, 0xF, 0xFE);
+}
+
 QEMUMachine pc_machine = {
 .name = pc,
 .desc = Standard PC,
diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
index 1f63678..af9071a 100644
--- a/qemu/hw/pc.h
+++ b/qemu/hw/pc.h
@@ -85,6 +85,7 @@ RTCState *rtc_init(int base, qemu_irq irq);
 RTCState *rtc_mm_init(target_phys_addr_t base, int it_shift, qemu_irq irq);
 void rtc_set_memory(RTCState *s, int addr, int val);
 void rtc_set_date(RTCState *s, const struct tm *tm);
+void cmos_set_s3_resume(void);
 
 /* pc.c */
 extern int fd_bootchk;
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index c5f3f29..80cdb40 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -721,7 +721,7 @@ static int kvm_halt(void *opaque, int vcpu)
 return kvm_arch_halt(opaque, vcpu);
 }
 
-static int kvm_shutdown(void *opaque, int vcpu)
+int kvm_shutdown(void *opaque, int vcpu)
 {
 /* stop the current vcpu from going back to guest mode */
 vcpu_info[cpu_single_env-cpu_index].stopped = 1;
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index a1d6646..f5b530c 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -72,6 +72,7 @@ void kvm_arch_update_regs_for_sipi(CPUState *env);
 void kvm_arch_cpu_reset(CPUState *env);
 
 CPUState *qemu_kvm_cpu_env(int index);
+int kvm_shutdown(void *opaque, int vcpu);
 
 void qemu_kvm_aio_wait_start(void);
 void qemu_kvm_aio_wait(void);

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

[PATCH 8/8] Don't power down vga card on entering S3 state.

[Gleb Natapov]

This is needed to fool windows to enter S3. The trick works for XP and
Windows2003, but Vista still refuse to allow S3.

Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 bios/acpi-dsdt.dsl |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 02f53a1..84af8f1 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -263,6 +263,22 @@ DefinitionBlock (
 
 Scope(\_SB.PCI0) {
 
+Device (VGA) {
+ Name (_ADR, 0x0002)
+ Method (_S1D, 0, NotSerialized)
+ {
+ Return (0x00)
+ }
+ Method (_S2D, 0, NotSerialized)
+ {
+ Return (0x00)
+ }
+ Method (_S3D, 0, NotSerialized)
+ {
+ Return (0x00)
+ }
+}
+
/* PIIX3 ISA bridge */
 Device (ISA) {
 Name (_ADR, 0x0001)

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

Re: [PATCH 8/8] Don't power down vga card on entering S3 state.

[Anthony Liguori]

Gleb Natapov wrote:

This is needed to fool windows to enter S3. The trick works for XP and
Windows2003, but Vista still refuse to allow S3.
  


This is because the Cirrus VGA card does not support suspend?  That's 
what you mean by fooling, correct?


What about std-vga?

Regards,

Anthony Liguori


Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---

 bios/acpi-dsdt.dsl |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 02f53a1..84af8f1 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -263,6 +263,22 @@ DefinitionBlock (
 
 Scope(\_SB.PCI0) {
 
+Device (VGA) {

+ Name (_ADR, 0x0002)
+ Method (_S1D, 0, NotSerialized)
+ {
+ Return (0x00)
+ }
+ Method (_S2D, 0, NotSerialized)
+ {
+ Return (0x00)
+ }
+ Method (_S3D, 0, NotSerialized)
+ {
+ Return (0x00)
+ }
+}
+
/* PIIX3 ISA bridge */
 Device (ISA) {
 Name (_ADR, 0x0001)

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


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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Anthony Liguori]

Hi Gleb,

Gleb Natapov wrote:

Hello,

This patch series adds S3 (suspend to RAM) ACPI state. Most changes
are in the BIOS code and concern themselves with preventing BIOS from
using memory available to OS.
  


I thought you initially sent this to qemu-devel.  Any reason not to push 
this through QEMU instead of in KVM?


Regards,

Anthony Liguori


---

Gleb Natapov (8):
  Don't power down vga card on entering S3 state.
  Add DPMS support to cirrus vga bios.
  Don't use unreserved memory in BIOS.
  Execute rombios32 code from rom address 0xe.
  Disable init of SMM.
  Add S3 state to DSDT. Handle resume event in the BIOS.
  Handle suspend in qemu.
  Move PIC initialization out of line to save space in post code area.


 bios/Makefile |1 
 bios/acpi-dsdt.dsl|   49 +++

 bios/rombios.c|  106 ++---
 bios/rombios.h|4 +-
 bios/rombios32.c  |   78 +---
 bios/rombios32.ld |8 +---
 bios/rombios32start.S |9 
 qemu/hw/acpi.c|   10 +
 qemu/hw/pc.c  |8 
 qemu/hw/pc.h  |1 
 qemu/qemu-kvm.c   |2 -
 qemu/qemu-kvm.h   |1 
 vgabios/clext.c   |   36 -

 13 files changed, 247 insertions(+), 66 deletions(-)


  


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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Avi Kivity]

Anthony Liguori wrote: 


I thought you initially sent this to qemu-devel.  Any reason not to 
push this through QEMU instead of in KVM?




Since it requires bios changes, it is basically unpushable to qemu.  It 
may also depend on existing kvm bios and acpi changes.


If it is possible to do this via qemu, of course I much prefer that route.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

compiling with icc: kvm.h(240): error

[Antoine Martin]

Hi,

I am testing kernel builds with Intel's ICC and got a failure on KVM 
(not that the rest was very smooth either...)
Just in case someone is interested, here it is (this kernel tree is 
loosely based on linux-next + other patches):


CC [M]  arch/x86/kvm/svm.o - due to: include/linux/bounds.h
icc -Wp,-MD,arch/x86/kvm/.svm.o.d -nostdinc -isystem icc 
-I/usr/lib/gcc/i486-pc-linux-gnu/4.3.2/include -D__KERNEL__ -Iinclude 
-I/usr/src/fastboot.git/arch/x86/include -include 
include/linux/autoconf.h -Wall-fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Os -m32   -freg-struct-return  
-mtune=generic  -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe   
-Iinclude/asm-x86/mach-default   -fno-omit-frame-pointer   -Ivirt/kvm 
-Iarch/x86/kvm -DMODULE -DKBUILD_STR(s)=#s 
-DKBUILD_BASENAME=KBUILD_STR(svm) -DKBUILD_MODNAME=KBUILD_STR(kvm_amd) 
-c -o arch/x86/kvm/.tmp_svm.o arch/x86/kvm/svm.c
icc: command line warning #10156: ignoring option '-W'; no argument 
required
include/linux/kvm.h(240): error: padding has already been declared in 
the current scope

  __u64 padding;
^

arch/x86/kvm/mmu.h(54): remark #869: parameter vcpu was never referenced
static inline int is_long_mode(struct kvm_vcpu *vcpu)
(...)

Patch following the same approach used in this file:
--- a/include/linux/kvm.h   2008-10-17 16:29:41.0 +0100
+++ b/include/linux/kvm.h 2008-10-23 17:58:15.0 +0100
@@ -234,10 +234,10 @@
/* for KVM_GET_DIRTY_LOG */
struct kvm_dirty_log {
   __u32 slot;
-   __u32 padding;
+   __u32 padding1;
   union {
   void __user *dirty_bitmap; /* one bit per page */
-   __u64 padding;
+   __u64 padding2;
   };
};

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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Anthony Liguori]

Avi Kivity wrote:

Anthony Liguori wrote:


I thought you initially sent this to qemu-devel.  Any reason not to 
push this through QEMU instead of in KVM?




Since it requires bios changes, it is basically unpushable to qemu.


Why?  As long as Gleb is willing to push those changes to Bochs, I'll 
stick them in the bios.diff for now.  The hard part is the dsdt changes 
but if the build is changed to run the dsdt through cpp first, we can 
just #ifdef BX_QEMU the qemu specific stuff.



  It may also depend on existing kvm bios and acpi changes.


How much dependency is there here?



If it is possible to do this via qemu, of course I much prefer that 
route.


I looked through the patches.  They're quite reasonable so I'd like to 
push them into QEMU if it's possible.


Regards,

Anthony Liguori

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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Anthony Liguori]

Gleb Natapov wrote:

On Thu, Oct 23, 2008 at 11:12:59AM -0500, Anthony Liguori wrote:
  

Hi Gleb,

Gleb Natapov wrote:


Hello,

This patch series adds S3 (suspend to RAM) ACPI state. Most changes
are in the BIOS code and concern themselves with preventing BIOS from
using memory available to OS.
  
  
I thought you initially sent this to qemu-devel.  Any reason not to push  
this through QEMU instead of in KVM?




90% of this patch touches BIOS code. It is easy to push QEMU bits
upstream, but BIOS part may be problematic. KVM BIOS is already
different from upstream.
  


I'm willing to expand the bios.diff that we have in QEMU as long as 
someone is submitting the patches to bochs.  In this case, I don't think 
these changes are at all controversial.


Regards,

Anthony Liguori


--
Gleb.
  


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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Anthony Liguori]

Gleb Natapov wrote:

On Thu, Oct 23, 2008 at 01:18:45PM -0500, Anthony Liguori wrote:
  

90% of this patch touches BIOS code. It is easy to push QEMU bits
upstream, but BIOS part may be problematic. KVM BIOS is already
different from upstream.
  
  
I'm willing to expand the bios.diff that we have in QEMU as long as  
someone is submitting the patches to bochs.  In this case, I don't think  
these changes are at all controversial.




I'll move BIOS changes to bochs BIOS next week. The hard part will be to
run bochs and see if it works with those changes. Can bochs read QEMU
disk images?
  


It can read raw disk images.  I've played with bochs a little bit so if 
you run into trouble let me know.


Thanks!

Regards,

Anthony Liguori


--
Gleb.
  


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

Re: [PATCH 0/2] kvm: disable virtualization on kdump

[Eduardo Habkost]

On Thu, Oct 23, 2008 at 10:28:24AM +1100, Simon Horman wrote:
 On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo Habkost wrote:
  The following two patches should make kdump work when the kvm-intel module
  is loaded. We need to disable vmx mode before booting the kdump kernel,
  so I've introduced a notifier interface where KVM can hook and disable
  virtualization on all CPUs just before they are halted.
  
  It has the same purpose of the KVM reboot notifier that gets executed
  at kexec-time. But on the kdump case, things are not as simple because
  the kernel has just crashed.
  
  The notifier interface being introduced is x86-specific. I don't know
  if an arch-independent interface would be more appropriate for this
  case.
  
  It was tested only using kvm-intel. Testing on different machines
  is welcome.
 
 These changes look fine to me from a kexec/kdump point of view.
 
 Reviewed-by: Simon Horman [EMAIL PROTECTED]

Thanks.

Considering they touch both KVM and kexec, which tree would be best way
to get them in?

(Avi: the patches were sent only to kexec and kvm mailing lists,
initially. If it's better to submit them to your address also so it gets
on your queue, please let me know)

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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Avi Kivity]

Anthony Liguori wrote:


Since it requires bios changes, it is basically unpushable to qemu.


Why?  As long as Gleb is willing to push those changes to Bochs, I'll 
stick them in the bios.diff for now.  The hard part is the dsdt 
changes but if the build is changed to run the dsdt through cpp first, 
we can just #ifdef BX_QEMU the qemu specific stuff.




I forgot bios.diff.  So yes, it's mergable into qemu.


  It may also depend on existing kvm bios and acpi changes.


How much dependency is there here?



I don't know; and that can be pulled as well (if anything needs pulling).



If it is possible to do this via qemu, of course I much prefer that 
route.


I looked through the patches.  They're quite reasonable so I'd like to 
push them into QEMU if it's possible.


That's the best way IMO as well.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)

[Sebastian Herbszt]

Gleb Natapov wrote:

Hello,

This patch series adds S3 (suspend to RAM) ACPI state. Most changes
are in the BIOS code and concern themselves with preventing BIOS from
using memory available to OS.

---

Gleb Natapov (8):
 Don't power down vga card on entering S3 state.
 Add DPMS support to cirrus vga bios.
 Don't use unreserved memory in BIOS.
 Execute rombios32 code from rom address 0xe.
 Disable init of SMM.
 Add S3 state to DSDT. Handle resume event in the BIOS.
 Handle suspend in qemu.
 Move PIC initialization out of line to save space in post code area.


Earlier this year patches were posted on xen-devel for S3 support [1].
They include qemu [2] and rombios [3] changes. It might be worth checking
them out in case you did not.

[1] [PATCH 0/4] HVM Virtual S3
http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00603.html

[2] [PATCH 2/4]: QEMU interface for HVM virtual S3
http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00605.html

[3] [PATCH 3/4] rombios interface for HVM S3
http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00606.html

- Sebastian

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

Re: [PATCH 0/2] kvm: disable virtualization on kdump

[Simon Horman]

[ Added Andrew Morton, Eric Biederman, Vivek Goyal and Haren Myneni to CC ]

On Thu, Oct 23, 2008 at 05:41:29PM -0200, Eduardo Habkost wrote:
 On Thu, Oct 23, 2008 at 10:28:24AM +1100, Simon Horman wrote:
  On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo Habkost wrote:
   The following two patches should make kdump work when the kvm-intel module
   is loaded. We need to disable vmx mode before booting the kdump kernel,
   so I've introduced a notifier interface where KVM can hook and disable
   virtualization on all CPUs just before they are halted.
   
   It has the same purpose of the KVM reboot notifier that gets executed
   at kexec-time. But on the kdump case, things are not as simple because
   the kernel has just crashed.
   
   The notifier interface being introduced is x86-specific. I don't know
   if an arch-independent interface would be more appropriate for this
   case.
   
   It was tested only using kvm-intel. Testing on different machines
   is welcome.
  
  These changes look fine to me from a kexec/kdump point of view.
  
  Reviewed-by: Simon Horman [EMAIL PROTECTED]
 
 Thanks.
 
 Considering they touch both KVM and kexec, which tree would be best way
 to get them in?

As I understand it, there is no kexec tree as such, rather
patches either get picked up by an arch tree or Andrew Morton.
I am happy to create and maintain a kexec tree if there is a need.
But in this case it seems that using the KVM tree would be best.

 (Avi: the patches were sent only to kexec and kvm mailing lists,
 initially. If it's better to submit them to your address also so it gets
 on your queue, please let me know)

I won't speak for Avi, but usually its good to CC the maintainer.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en

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

Re: [PATCH 0/2] kvm: disable virtualization on kdump

[Eric W. Biederman]

Simon Horman [EMAIL PROTECTED] writes:

 [ Added Andrew Morton, Eric Biederman, Vivek Goyal and Haren Myneni to CC ]

 On Thu, Oct 23, 2008 at 05:41:29PM -0200, Eduardo Habkost wrote:
 On Thu, Oct 23, 2008 at 10:28:24AM +1100, Simon Horman wrote:
  On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo Habkost wrote:
   The following two patches should make kdump work when the kvm-intel 
   module
   is loaded. We need to disable vmx mode before booting the kdump kernel,
   so I've introduced a notifier interface where KVM can hook and disable
   virtualization on all CPUs just before they are halted.
   
   It has the same purpose of the KVM reboot notifier that gets executed
   at kexec-time. But on the kdump case, things are not as simple because
   the kernel has just crashed.
   
   The notifier interface being introduced is x86-specific. I don't know
   if an arch-independent interface would be more appropriate for this
   case.

My preference would be to have a magic function call that compiles out when
kvm isn't present.  This is a code path that is hard to audit and test, and
get right.  A notifier chain seems to make a proper audit all but impossible.

Why do we need to disable vmx mode before booting a normal linux kernel?
Is it possible to disable vmx mode before we enable interrrupts in the
kdump kernel?

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