date:20100803

كورسات مهمة

2010-08-03 Thread new association2010

  المركز الأمريكي للبحوث
 A.R.C.

Tel  :  ( 00202 ) 25082727  -  2508884183
Fax No : ( 00202 ) 25082727
E-MAIL:  new.a...@ymail .com
محمول  :  162494849 - 0020


السيد / وكيل الجامعة لشئون المكتبات

يسر المركز بعرض الدراسات العلمية التطبيقية للمواضيع التالية
التصميم الهندسي

تطور نظم التصميم القائم على الكمبيوتر - حل المشكلات الهندسية بصورة
إبداعية - التصميم التخيلي والتصنيع 0

   Eالتصنيع الهندسيQ

( التصميم والتصنيع من اجل دعم التنمية - استخدام التصنيع بواسطة
الكمبيوتر في الصناعة - الية التصنيع والحلول ذات الاستجابة السريعة
لتنمية المنتج  ) 0

  
العلوم الهندسية

( التصميم الهندسي للمانع والآلآت بطريقة تقلل من الضوضاء عن طريق قياسها
ومعرفة اسبابها - تطور التصميم المرن للآلآت بالمصانع - تجنب تآكل الآلآت
والمضخات في المصانع

( الهندسة الطبية )?
تحسين تصميم المستشفيات ومعداتها وتقليل انبعاث غاز ثاني اكسيد الكربون -
تطور صناعة المفاصل الصناعية في مجال الطب - الآليات البيولوجية بزراعة
المفاصل  )

الهندسة النووية
تأكيد سلامة التكامل الهيكلي وتقييم المخاطر - تحسين كفاءة الصناعات
البتر وكيميائية الغاز والبترول - اكتساب البيانات الخاصة وتكنولوجيا
التنقيب عن البترول تحت سطح البحر

ç(  صناعات الطاقة )è

توليد الطاقة من نفايات الكربون بواسطة الحل الحراري - تكنولوجيا الطاقة
النظيفة من الطاقة الشمسية - توليد الطاقة باستخدام الغاز المستخرج من
أراضي النفايات 0

 للاستفسار يرجى الاتصال هاتفيا او عن طريق البريد
الالكتروني   مدير عام قطاع البحوث

Re: KVM Processor cache size

2010-08-03 Thread Dor Laor


On 08/03/2010 02:36 AM, Anthony Liguori wrote:

On 08/02/2010 05:42 PM, Andre Przywara wrote:

Anthony Liguori wrote:

On 08/02/2010 08:49 AM, Ulrich Drepper wrote:

glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would pollute too
much of the cache because they are large will use non-temporal
instructions. There are real performance benefits.


I imagine that there would be real performance problems from doing
live migration with -cpu host too if we don't guarantee these values
remain stable across migration...

Again, -cpu host is not meant to be migrated.


Then it needs to prevent migration from happening. Otherwise, it's a bug
waiting to happen.


There are other virtualization use cases than cloud-like server
virtualization. Sometimes users don't care about migration (or even
the live version), but want full CPU exposure for performance reasons
(think of virtualizing Windows on a Linux desktop).
I agree that -cpu host and migration should be addressed, but only to
a certain degree. And missing migration experience should not be a
road blocker for -cpu host.


When we can reasonably prevent it, we should prevent users from shooting
themselves in the foot. Honestly, I think -cpu host is exactly what you
would want to use in a cloud. A lot of private clouds and even public
clouds are largely based on homogenous hardware.


There are two good solutions for that:
a. keep adding newer -cpu definition like the Penryn, Nehalem,
   Opteron_gx, so newer models will be abstracted as similar to the
   physical properties
b. Use strict flag with -cpu host and pass the info with the live
   migration protocol.
   Our live migration protocol can do better job with validation the
   cmdline and the current set of devices/hw on the src/dst and fail
   migration if there is a diff. Today we relay on libvirt for that,
   another mechanism will surely help, especially for -cpu host.
   The goodie is that there won't be a need to wait for the non-live
   migration part, and more cpu cycles will be saved.



I actually think the case where you want to migrate between heterogenous
hardware is grossly overstated.

Regards,

Anthony Liguori



Regards,
Andre.



--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bad O_DIRECT read and write performance with small block sizes with virtio

2010-08-03 Thread Dor Laor


On 08/02/2010 11:50 PM, Stefan Hajnoczi wrote:

On Mon, Aug 2, 2010 at 6:46 PM, Anthony Liguorianth...@codemonkey.ws  wrote:

On 08/02/2010 12:15 PM, John Leach wrote:


Hi,

I've come across a problem with read and write disk IO performance when
using O_DIRECT from within a kvm guest.  With O_DIRECT, reads and writes
are much slower with smaller block sizes.  Depending on the block size
used, I've seen 10 times slower.

For example, with an 8k block size, reading directly from /dev/vdb
without O_DIRECT I see 750 MB/s, but with O_DIRECT I see 79 MB/s.

As a comparison, reading in O_DIRECT mode in 8k blocks directly from the
backend device on the host gives 2.3 GB/s.  Reading in O_DIRECT mode
from a xen guest on the same hardware manages 263 MB/s.



Stefan has a few fixes for this behavior that help a lot.  One of them
(avoiding memset) is already upstream but not in 0.12.x.

The other two are not done yet but should be on the ML in the next couple
weeks.  They involve using ioeventfd for notification and unlocking the
block queue lock while doing a kick notification.


Thanks for mentioning those patches.  The ioeventfd patch will be sent
this week, I'm checking that migration works correctly and then need
to check that vhost-net still works.


Writing is affected in the same way, and exhibits the same behaviour
with O_SYNC too.

Watching with vmstat on the host, I see the same number of blocks being
read, but about 14 times the number of context switches in O_DIRECT mode
(4500 cs vs. 63000 cs) and a little more cpu usage.

The device I'm writing to is a device-mapper zero device that generates
zeros on read and throws away writes, you can set it up
at /dev/mapper/zero like this:

echo 0 21474836480 zero | dmsetup create zero

My libvirt config for the disk is:

disk type='block' device='disk'
   driver cache='none'/
   source dev='/dev/mapper/zero'/
   target dev='vdb' bus='virtio'/
   address type='pci' domain='0x' bus='0x00' slot='0x06'
function='0x0'/
/disk

which translates to the kvm arg:

-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-drive file=/dev/mapper/zero,if=none,id=drive-virtio-disk1,cache=none


aio=native and change the io scheduler on the host to deadline should 
help as well.




I'm testing with dd:

dd if=/dev/vdb of=/dev/null bs=8k iflag=direct

As a side note, as you increase the block size read performance in
O_DIRECT mode starts to overtake non O_DIRECT mode reads (from about
150k block size). By 550k block size I'm seeing 1 GB/s reads with
O_DIRECT and 770 MB/s without.


Can you take QEMU out of the picture and run the same test on the host:

dd if=/dev/vdb of=/dev/null bs=8k iflag=direct
vs
dd if=/dev/vdb of=/dev/null bs=8k

This isn't quite the same because QEMU will use a helper thread doing
preadv.  I'm not sure what syscall dd will use.

It should be close enough to determine whether QEMU and device
emulation are involved at all though, or whether these differences are
due to the host kernel code path down to the device mapper zero device
being different for normal vs O_DIRECT.

Stefan
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kvm cleanup: Introduce sibling_pte and do cleanup for reverse map and parent_pte

2010-08-03 Thread Avi Kivity


 On 08/03/2010 05:30 AM, Lai Jiangshan wrote:

This patch is just a big cleanup. it reduces 220 lines of code.

It introduces sibling_pte array for tracking identical sptes, so the
identical sptes can be linked as a single linked list by their
corresponding sibling_pte. A reverse map or a parent_pte points at
the head of this single linked list. So we can do cleanup for
reverse map and parent_pte VERY LARGELY.

BAD:
   If most rmap have only one entry or most sp have only one parent,
   this patch may use more memory than before.


That is the case with NPT and EPT.  Each page has exactly one spte 
(except a few vga pages), and each sp has exactly one parent_pte (except 
the root pages).



GOOD:
   1) Reduce a lot of code, The functions which are in hot path becomes
  very very simple and terrifically fast.
   2) rmap_next(): O(N) -  O(1). traveling a ramp: O(N*N) -  O(N)


The existing rmap_next() is not O(N), it's O(RMAP_EXT), which is 4.  The 
data structure was chosen over a simple linked list to avoid extra cache 
misses.



   3) Remove the ugly interlayer: struct kvm_rmap_desc, struct kvm_pte_chain


kvm_rmap_desc and kvm_pte_chain are indeed ugly, but they do save a lot 
of memory and cache misses.



   4) We don't need to allocate any thing when we change the mappings.
  So we can avoid allocation when we have held kvm mmu spin lock.
  (this feature is very helpful in future).
   5) better readability.


I agree the new code is more readable.  Unfortunately it uses more 
memory and is likely to be slower.  You add a cache miss for every spte, 
while kvm_rmap_desc amortizes the cache miss among 4 sptes, and special 
cases 1 spte to have no cache misses (or extra memory requirements).


--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 3/4] Paravirtualized spinlock implementation for KVM guests

2010-08-03 Thread Avi Kivity


 On 08/02/2010 06:20 PM, Jeremy Fitzhardinge wrote:

 On 08/02/2010 01:48 AM, Avi Kivity wrote:

 On 07/26/2010 09:15 AM, Srivatsa Vaddagiri wrote:
Paravirtual spinlock implementation for KVM guests, based heavily on 
Xen guest's

spinlock implementation.


+
+static struct spinlock_stats
+{
+u64 taken;
+u32 taken_slow;
+
+u64 released;
+
+#define HISTO_BUCKETS30
+u32 histo_spin_total[HISTO_BUCKETS+1];
+u32 histo_spin_spinning[HISTO_BUCKETS+1];
+u32 histo_spin_blocked[HISTO_BUCKETS+1];
+
+u64 time_total;
+u64 time_spinning;
+u64 time_blocked;
+} spinlock_stats;


Could these be replaced by tracepoints when starting to spin/stopping 
spinning etc?  Then userspace can reconstruct the histogram as well 
as see which locks are involved and what call paths.


Unfortunately not; the tracing code uses spinlocks.

(TBH I haven't actually tried, but I did give the code an eyeball to 
this end.)


Hm.  The tracing code already uses a specialized lock (arch_spinlock_t), 
perhaps we can make this lock avoid the tracing?


It's really sad, btw, there's all those nice lockless ring buffers and 
then a spinlock for ftrace_vbprintk(), instead of a per-cpu buffer.


--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kvm IPC

2010-08-03 Thread Amit Shah

On (Thu) Jul 29 2010 [16:17:48], Nirmal Guhan wrote:
 Hi,
 
 I run Fedora 12 and guest is also Fedora 12. I use br0/tap0 for
 networking and communicate between host-guest using socket.  I do
 see some references to virtio, pci based ipc and inter-vm shared
 memory but they are not current. My question is : Is there a better
 IPC mechanism for host-guest and intern vm communication and if so
 could you provide me with pointers?

There's virtio-serial, which is a channel between a guest and the host.
You can short-circuit two host-side chardevs to get inter-VM channels as
well.

See 

https://fedoraproject.org/wiki/Features/VirtioSerial

for more info.

This is only available from F13, though.

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

Re: [PATCH 1/2] KVM: SVM: Check for nested vmrun intercept before emulating vmrun

2010-08-03 Thread Avi Kivity


 On 08/02/2010 11:33 PM, Joerg Roedel wrote:

On Mon, Aug 02, 2010 at 06:18:09PM +0300, Avi Kivity wrote:

  On 08/02/2010 05:46 PM, Joerg Roedel wrote:

This patch lets the nested vmrun fail if the L1 hypervisor
has not intercepted vmrun. This fixes the vmrun intercept
check unit test.
+
   static bool nested_svm_vmrun(struct vcpu_svm *svm)
   {
struct vmcb *nested_vmcb;
@@ -2029,6 +2037,17 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
if (!nested_vmcb)
return false;

+   if (!nested_vmcb_checks(nested_vmcb)) {
+   nested_vmcb-control.exit_code= SVM_EXIT_ERR;
+   nested_vmcb-control.exit_code_hi = 0;
+   nested_vmcb-control.exit_info_1  = 0;
+   nested_vmcb-control.exit_info_2  = 0;
+
+   nested_svm_unmap(page);
+
+   return false;
+   }
+

Don't you have to transfer an injected event to exitintinfo?

APM2 seems to be quiet about this.


Well, my copy says

The VMRUN instruction then checks the guest state just loaded. If an 
illegal state has been loaded, the

processor exits back to the host (see “#VMEXIT” on page 374).


This matches illegal state and #VMEXIT but doesn't match guest state.


I just tried it out and event_inj
still contains the event after a failed vmrun on real hardware. This
makes sense because this is no real vmexit because the vm was never
entered.


Okay; will apply the patches.

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

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

[GIT PULL] KVM updates for the 2.6.36 merge window

2010-08-03 Thread Avi Kivity


 Linus, please pull from

  git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.36

to receive the KVM updates for the 2.6.36 cycle.  No major features: 
mostly improved mmu and emulator correctness, some performance 
improvements, and support for guest XSAVE and AVX.


Alex Williamson (1):
  KVM: remove CAP_SYS_RAWIO requirement from kvm_vm_ioctl_assign_irq

Alexander Graf (5):
  KVM: PPC: Remove obsolete kvmppc_mmu_find_pte
  KVM: PPC: Use kernel hash function
  KVM: PPC: Make BAT only guest segments work
  KVM: PPC: Add generic hpte management functions
  KVM: PPC: Make use of hash based Shadow MMU

Andi Kleen (2):
  KVM: Fix KVM_SET_SIGNAL_MASK with arg == NULL
  KVM: Fix unused but set warnings

Andrea Arcangeli (1):
  KVM: MMU: fix mmu notifier invalidate handler for huge spte

Andreas Schwab (1):
  KVM: PPC: elide struct thread_struct instances from stack

Asias He (1):
  KVM: PPC: fix uninitialized variable warning in 
kvm_ppc_core_deliver_interrupts


Avi Kivity (50):
  KVM: VMX: Simplify vmx_get_nmi_mask()
  KVM: kvm_pdptr_read() may sleep
  KVM: VMX: Avoid writing HOST_CR0 every entry
  KVM: Get rid of KVM_REQ_KICK
  KVM: Document KVM_SET_IDENTITY_MAP ioctl
  KVM: Document KVM_SET_BOOT_CPU_ID
  KVM: MMU: Fix free memory accounting race in mmu_alloc_roots()
  KVM: move vcpu locking to dispatcher for generic vcpu ioctls
  KVM: x86: Lock arch specific vcpu ioctls centrally
  KVM: s390: Centrally lock arch specific vcpu ioctls
  KVM: PPC: Centralize locking of arch specific vcpu ioctls
  KVM: Consolidate arch specific vcpu ioctl locking
  KVM: Update Red Hat copyrights
  KVM: MMU: Allow spte.w=1 for gpte.w=0 and cr0.wp=0 only in shadow 
mode

  KVM: MMU: Document cr0.wp emulation
  KVM: MMU: Document large pages
  KVM: VMX: Fix incorrect rcu deref in rmode_tss_base()
  KVM: Fix mov cr0 #GP at wrong instruction
  KVM: Fix mov cr4 #GP at wrong instruction
  KVM: Fix mov cr3 #GP at wrong instruction
  KVM: Fix xsave and xcr save/restore memory leak
  KVM: Consolidate load/save temporary buffer allocation and freeing
  KVM: Remove memory alias support
  KVM: Remove kernel-allocated memory regions
  KVM: i8259: reduce excessive abstraction for pic_irq_request()
  KVM: i8259: simplify pic_irq_request() calling sequence
  KVM: Add mini-API for vcpu-requests
  KVM: Reduce atomic operations on vcpu-requests
  KVM: Keep slot ID in memory slot structure
  KVM: Prevent internal slots from being COWed
  KVM: Simplify vcpu_enter_guest() mmu reload logic slightly
  KVM: Document KVM specific review items
  KVM: MMU: Introduce drop_spte()
  KVM: MMU: Move accessed/dirty bit checks from rmap_remove() to 
drop_spte()

  KVM: MMU: Atomically check for accessed bit when dropping an spte
  KVM: MMU: Don't drop accessed bit while updating an spte
  KVM: MMU: Only indicate a fetch fault in page fault error code if 
nx is enabled

  KVM: MMU: Keep going on permission error
  KVM: Expose MCE control MSRs to userspace
  KVM: Document MCE banks non-exposure via KVM_GET_MSR_INDEX_LIST
  KVM: MMU: Add link_shadow_page() helper
  KVM: MMU: Use __set_spte to link shadow pages
  KVM: MMU: Add drop_large_spte() helper
  KVM: MMU: Add validate_direct_spte() helper
  KVM: MMU: Add gpte_valid() helper
  KVM: MMU: Simplify spte fetch() function
  KVM: MMU: Validate all gptes during fetch, not just those used 
for new pages

  KVM: MMU: Eliminate redundant temporaries in FNAME(fetch)
  KVM: Document KVM_GET_SUPPORTED_CPUID2 ioctl
  KVM: VMX: Fix host GDT.LIMIT corruption

Chris Lalancette (4):
  KVM: x86: Introduce a workqueue to deliver PIT timer interrupts
  KVM: x86: Allow any LAPIC to accept PIC interrupts
  KVM: x86: In DM_LOWEST, only deliver interrupts to vcpus with 
enabled LAPIC's

  KVM: Search the LAPIC's for one that will accept a PIC interrupt

Christian Borntraeger (2):
  KVM: s390: Fix build failure due to centralized vcpu locking patches
  KVM: s390: Don't exit SIE on SIGP sense running

Denis Kirjanov (1):
  KVM: PPC: fix build warning in kvm_arch_vcpu_ioctl_run

Dexuan Cui (1):
  KVM: VMX: Enable XSAVE/XRSTOR for guest

Dongxiao Xu (4):
  KVM: VMX: Define new functions to wrapper direct call of asm code
  KVM: VMX: Some minor changes to code structure
  KVM: VMX: VMCLEAR/VMPTRLD usage changes
  KVM: VMX: VMXON/VMXOFF usage changes

Glauber Costa (1):
  KVM: Add Documentation/kvm/msr.txt

Gleb Natapov (32):
  KVM: x86 emulator: introduce read cache
  KVM: x86 emulator: fix Move r/m16 to segment register decoding
  KVM: x86 emulator: cleanup xchg emulation
  KVM: x86 emulator: cleanup nop emulation
  KVM: x86 emulator: handle far address source operand
  KVM: x86 emulator: add (set|get)_dr

RE: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.

2010-08-03 Thread Xin, Xiaohui

-Original Message-
From: Shirley Ma [mailto:mashi...@us.ibm.com]
Sent: Friday, July 30, 2010 6:31 AM
To: Xin, Xiaohui
Cc: net...@vger.kernel.org; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
m...@redhat.com; mi...@elte.hu; da...@davemloft.net; 
herb...@gondor.apana.org.au;
jd...@linux.intel.com
Subject: Re: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.

Hello Xiaohui,

On Thu, 2010-07-29 at 19:14 +0800, xiaohui@intel.com wrote:
 The idea is simple, just to pin the guest VM user space and then
 let host NIC driver has the chance to directly DMA to it.
 The patches are based on vhost-net backend driver. We add a device
 which provides proto_ops as sendmsg/recvmsg to vhost-net to
 send/recv directly to/from the NIC driver. KVM guest who use the
 vhost-net backend may bind any ethX interface in the host side to
 get copyless data transfer thru guest virtio-net frontend.

Since vhost-net already supports macvtap/tun backends, do you think
whether it's better to implement zero copy in macvtap/tun than inducing
a new media passthrough device here?

 Our goal is to improve the bandwidth and reduce the CPU usage.
 Exact performance data will be provided later.

I did some vhost performance measurement over 10Gb ixgbe, and found that
in order to get consistent BW results, netperf/netserver, qemu, vhost
threads smp affinities are required.

Looking forward to these results for small message size comparison. For
large message size 10Gb ixgbe BW already reached by doing vhost smp
affinity w/i offloading support, we will see how much CPU utilization it
can be reduced.

Please provide latency results as well. I did some experimental on
macvtap zero copy sendmsg, what I have found that get_user_pages latency
pretty high.

May you share me with your performance results (including BW and latency)on 
vhost-net and how you get them(your configuration and especially with the 
affinity 
settings)?

Thanks
Xiaohui

Thanks
Shirley

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

Re: [PATCH] kvm cleanup: Introduce sibling_pte and do cleanup for reverse map and parent_pte

2010-08-03 Thread Lai Jiangshan

On 08/03/2010 02:51 PM, Avi Kivity wrote:
  On 08/03/2010 05:30 AM, Lai Jiangshan wrote:
 This patch is just a big cleanup. it reduces 220 lines of code.

 It introduces sibling_pte array for tracking identical sptes, so the
 identical sptes can be linked as a single linked list by their
 corresponding sibling_pte. A reverse map or a parent_pte points at
 the head of this single linked list. So we can do cleanup for
 reverse map and parent_pte VERY LARGELY.

 BAD:
If most rmap have only one entry or most sp have only one parent,
this patch may use more memory than before.
 
 That is the case with NPT and EPT.  Each page has exactly one spte
 (except a few vga pages), and each sp has exactly one parent_pte (except
 the root pages).
 
 GOOD:
1) Reduce a lot of code, The functions which are in hot path becomes
   very very simple and terrifically fast.
2) rmap_next(): O(N) -  O(1). traveling a ramp: O(N*N) -  O(N)
 
 The existing rmap_next() is not O(N), it's O(RMAP_EXT), which is 4.  The
 data structure was chosen over a simple linked list to avoid extra cache
 misses.
 
3) Remove the ugly interlayer: struct kvm_rmap_desc, struct
 kvm_pte_chain
 
 kvm_rmap_desc and kvm_pte_chain are indeed ugly, but they do save a lot
 of memory and cache misses.
 
4) We don't need to allocate any thing when we change the mappings.
   So we can avoid allocation when we have held kvm mmu spin lock.
   (this feature is very helpful in future).
5) better readability.
 
 I agree the new code is more readable.  Unfortunately it uses more
 memory and is likely to be slower.  You add a cache miss for every spte,
 while kvm_rmap_desc amortizes the cache miss among 4 sptes, and special
 cases 1 spte to have no cache misses (or extra memory requirements).
 

You are right, please omit this patch

thanks, lai.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Alt SeaBIOS SSDT cpu hotplug

2010-08-03 Thread Liu, Jinsong

Zheng, Shaohui wrote:
In our experiences, windows 2008 datacenter is the only version to
support CPU hotplug, and we did not find any official announce for
other windows, so we tested windows 2008 data center only.

Thanks for Kevin pointing out it, we will try windows7 hotplug
feature.

Thanks Regards,
Shaohui

-Original Message-
From: Kevin O'Connor [mailto:ke...@koconnor.net]
Sent: Tuesday, August 03, 2010 1:27 AM
To: Avi Kivity
Cc: Alexander Graf; Liu, Jinsong; seab...@seabios.org;
kvm@vger.kernel.org; Jiang, Yunhong; Li, Xin; Zheng, Shaohui; Zhang,
Jianwu; You, Yongkang
Subject: Re: Alt SeaBIOS SSDT cpu hotplug

On Mon, Aug 02, 2010 at 07:13:34PM +0300, Avi Kivity wrote:
On 08/02/2010 06:55 PM, Kevin O'Connor wrote:
On Mon, Aug 02, 2010 at 10:12:31AM +0200, Alexander Graf wrote:
On 02.08.2010, at 07:49, Kevin O'Connor wrote:
On Mon, Aug 02, 2010 at 10:41:39AM +0800, Liu, Jinsong wrote:
It seems the Windows acpi interpreter is significantly different
from the Linux one. The only guess I have is that Windows
doesn't like one of the ASL constructs even though they all look
valid. I'd try to debug this by commenting out parts of the ASL
until I narrowed down the parts causing the problem.
Unfortunately, I don't have Windows 2008 to do this directly.

Any other ideas?
Just grab yourself a free copy of the Hyper-V server 2008:

http://arstechnica.com/microsoft/news/2009/08/microsoft-hyper-v-server-2008-r2-arrives-for-free.ars
I downloaded and installed it, but I can't reproduce the crash. It
seems like a really stripped down version of Windows, so I can't
tell if it actually worked or not either.

I thought only the Datacenter edition supported cpu hotplug.

I just tried an old Win 7 Ultimate beta (build 7100) I had on my HD.
It looks like it supports cpu hotplug. However, I don't see any
failures - it seems to work fine. (After running cpu_set 1 online,
the event pops up in the system event log as a UserPnP event, and the
CPU appears in the system devices list.)

-Kevin

Kevin,

I just test your new patch with Windows 2008 DataCenter at my platform, it
works OK! We can hot-add new cpus and they appear at Device Manager.
(BTW, yesterday I test your new patch with linux 2.6.32 hvm, it works fine, we
can add-remove-add-remove... cpus)
Sorry for make you spend more time. It's our fault.

Thanks,
Jinsong

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

1 2 >

1 - 100 of 108 matches

Mail list logo