[kvm-devel] kvm-devel
新产品开发流程与项目管理 ● 课程对象 企业研发分管高层领导、新产品研发主管、产品经理，研发项目经理、项目组核心成员、产品开发相关职能部门（规划部、市场部，项目部、技术部、质量部、企管部，生产部）的经理领导、对新产品研发项目有兴趣者。 ● 会务报名 1.报名时间：即日起接受报名 2.费用：2680元/人（含资料、文具、午餐、点心） ● 举办时间： 2008年4月28日-29日 举办地点： 北京豪景大厦 联系方式： 深圳总部电话：0755-26075265 26075429 26075365 22008632 81069646 上海办事处电话：021-51875149 北京办事处电话：010-51293353 传真： 0755-61351396 82129209 联系人：凌小姐 曾小姐 ● 课程背景 在市场需求不断快速变化、技术迅速更新的趋势之下，企业是否具备快速、高质量、低成本地推出产品能力，已成为决定企业成败与否的关键。调查表明，在企业中，大约70％的研发项目超出了估算的时间进度，大型项目平均交付时间比原计划超出20％－50％，研发项目开发费用90％以上都超出预算。通过该课程，将使新产品开发能有效按流程进行管理，并掌握如何利用项目管理方法管理研发项目，从而有效利用资源，缩短研发周期，使企业更快、更有效地实现产品开发，不断降低研发成本和产品生命周期成本，让企业在激烈的竞争中立于不败之地。 ● 课程目标 1. 了解新产品开发管理体系框架 2. 熟悉新产品开发流程管理 3. 掌握项目项目管理方法在研发中的应用 4. 把握新产品开发过程管理与控制 ● 课程特点 案例丰富，生动活泼，深入浅出 ，理论联系实际，具有感染力，尤其与学员互动的上课风格备受好评，对于实际工作带来启发与收益。 结合企业实际的辅导式培训，全景式案例的辅导培训。（70%--80%）案例+（20%--30%）理论+分组互动研讨。 ● 课程内容 第一天 上午 一、课程背景 1.新产品开发在公司位置与价值链分析 2.新产品开发与技术研发的管理区分 3.新产品开发成功与失败因素分析 4.新产品开发管理体系框架体系 二、新产品开发流程 1.讨论:某企业新产品开发流程 2.新产品开发项目生命周期与管理过程 3.新产品开发的门径管理流程4.IPD(集成产品开发)流程 5.研发流程7要素 6.新产品开发组织环境 7.新产品开发高效团队工作方法 * 某企业研发流程案例研讨 第一天 下午 三、新产品开发中的决策流程 1.在新产品开发中决策的意义 2.在新产品开发中应决策什么――决策要素 3.高层领导在新产品开发中扮演的角色 4.在新产品开发中决策迟缓的代价 5.新产品开发中决策团队的权力和责任 6.新产品开发中决策点的设置 7.新产品开发中决策评审流程 8.企业在不同发展阶段新产品开发中决策有何不同 9.新产品开发中的技术评审 10.新产品开发的流程结构化与裁剪 * 案例研讨：新产品开发技术评审(TR1,TR2,TR3,TR4,TR5)示例介绍 第二天 上午 四、新产品研发中项目管理方法应用 1.项目管理与新产品研发管理的映射 2.新产品开发项目管理的目标与目的 3.新产品开发项目管理中存在的常见问题 4.新产品开发的阶段周期对比 5.新产品开发项目管理5个过程组映射 6.新产品开发中主要的项目管理活动 7.新产品开发项目管理领域(PMI项目管理知识体系)?案例研讨：新产品发项目生命周期案例研讨 8.新产品开发项目管理精髓之一：化繁为简 9.新产品开发项目管理精髓之二：系统思考 五、新产品研发项目规划 1.新产品开发计划的作用与要素 2.新产品开发项目计划的形式 3.新产品开发项目计划制定的原则 4.新产品开发三级计划制定的时间点 5.新产品开发计划制定的步骤和注意事项 6.新产品开发项目计划与资源计划 * 演示讲解：新产品业务计划书 7.如何让项目成员参与项目计划编制？ 8.新产品开发项目进度计划制定 * 演示：进度计划制定实例 * 随堂练习：根据新产品项目任务书，制定出新产品开发项目进度计划 9.进度比计划快怎么办？ 10.如何使计划适应变化？ 11.可指导性、可操作性和可变性计划是如何做出来的？ 12.项目进度如何满足客户要求，过程如何监督与控制，发生变化后的进度基准如何确定，对项目进度应如何评价？ 第二天 下午 六、新产品开发项目执行与控制 1.新产品开发项目变更控制组织 2.新产品开发项目变更控制流程 3.新产品开发项目中6大变更控制原则 4.新产品开发项目变更控制权限设定 5.新产品开发项目变更多级控制工作系统 6.新产品开发项目过程量化与控制 7.新产品开发控制4步法 七、新产品开发项目风险管理和问题管理 1.谁来识别风险 2.如何进行风险评审与审计 3.新产品开发项目风险责任体系 4.新产品开发项目风险检查列表演示 5.面对积极风险和消极风险的预防策略与应急措施 6.为什么对风险和问题要进行集中监控 7.新产品开发问题管理管理流程 八、新产品开发项目收尾 1.新产品开发项目人事问题 2.新产品开发项目专利与安全问题 3.新产品开发项目的评估与考核 ● 讲师介绍： 陈和兰 MBA、PMP、PMI会员。某高科技上市公司研发项目管理部总经理，资深新产品研发咨询顾问，项目管理实战专家。《项目管理技术》杂志编委，CTA（剑桥国际培训师）。陈老师多年从事企业管理，并长期分管项目管理与研发工作，积累了丰富实战经验。在公司新产品项目管理意识和规范导入，项目管理应用历程探索和实践推进，尤其是企业项目管理规范体系建设与新产品研发项目管理方面体会颇深。曾为多家公司组织编写了新产品开发项目管理方法论，方法论包括但不限于新产品开发组织设计、流程、规范、模板、指导手册和研发项目考核办法。经企业应用后，均取得良好效果和效益。 陈老师对研发创新中如何应用项目管理方法具有深刻研究,，在国内较早开发了《新产品研发项目管理》、《项目流程管理》、《项目绩效考核与管理》、《组织化项目管理》、《群组项目管理》、《PMO建设和管理》等实用性和操作性较强的精品课程。同时，多次应邀出席各种国际国内的项目管理会议，其新颖的思想与观点得到业内人士普遍关注。为近百家企业提供项目管理咨询与培训服务，其务实的培训内容及娴熟的授课技巧深受客户赞誉。 曾培训的客户： 陈老师曾提供新产品开发项目管理咨询和培训的部分客户有：中国石化、中国移动、朗讯、爱立信、NEC、宝钢国际、中国网通、夏新电子、南方路机、群鑫机械、五星集团、实达电脑、丝丽雅集团、江苏交通科学研究院、国家电力科学研究院、慧聪国际、嘉里粮油、兴业银行、中国建设银行、平安保险集团、建设银行福建省分行、潍柴动力、中航信、龙岩卷烟厂、中国食品药品监督管理局、片仔癀药业、海星电子、瑞典特瑞、佳通轮胎、柳州五菱、三安电子、山东铝业、中铝瑞闽等。 - 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] [RFC/PATCH 15/15] guest: virtio device support, and kvm hypercalls
Rusty Russell wrote:
+static int __init kvm_devices_init(void)
+{
+if (!MACHINE_IS_KVM)
+return -ENODEV;
+
+if (device_register(kvm_root) != 0)
+panic(Could not register kvm root);
+
+if (add_shared_memory((max_pfn) PAGE_SHIFT, PAGE_SIZE)) {
+device_unregister(kvm_root);
+return -ENOMEM;
+}
Hmm, panic on device_register fail, but -ENOMEM on add_shared_memory fail?
My theory was that since this is boot time, panic() is the right thing.
We can't tell whether or not this is an important device or not. Maybe
the guest is running with ramdisk as rootfs and can have a happy life
if we don't kill it here. Return the rc from device register seems to
be the right thing to me, if it was an important device we'll see
panic: cannot mount rootfs or something later.
-
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] [RFC/PATCH 15/15] guest: virtio device support, and kvm hypercalls
Am Freitag, 21. März 2008 schrieb Rusty Russell:
I'd recommend a hypercall after set_status, as well as reset. The
reason lguest doesn't do this is that we don't do feature negotiation
(assuming guest kernel matches host kernel). In general, the host
needs to know when the VIRTIO_CONFIG_S_DRIVER_OK is set so it can see
what features the guest driver accepted.
Right. Will have a look.
Overloading the notify hypercall is kind of a hack too, but it works so
no real need to change that.
+ * The root device for the kvm virtio devices.
+ * This makes them appear as /sys/devices/kvm/0,1,2
not /sys/devices/0,1,2.
+ */
+static struct device kvm_root = {
+ .parent = NULL,
+ .bus_id = kvm_s390,
+};
You mean /sys/devices/kvm_s390/0,1,2?
Yes, thanks.
+static int __init kvm_devices_init(void)
+{
+ if (!MACHINE_IS_KVM)
+ return -ENODEV;
+
+ if (device_register(kvm_root) != 0)
+ panic(Could not register kvm root);
+
+ if (add_shared_memory((max_pfn) PAGE_SHIFT, PAGE_SIZE)) {
+ device_unregister(kvm_root);
+ return -ENOMEM;
+ }
Hmm, panic on device_register fail, but -ENOMEM on add_shared_memory fail?
My theory was that since this is boot time, panic() is the right thing.
Good spot, but I agree with Carsten. Drivers should not panic. I have module
load/unload capability on my long term todo list, but I can change the
panic now.
Christian
-
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] [RFC/PATCH 05/15] KVM_MAX_VCPUS
Carsten Otte wrote: Hollis Blanchard wrote: On Thu, 2008-03-20 at 17:24 +0100, Carsten Otte wrote: Index: kvm/include/linux/kvm_host.h === --- kvm.orig/include/linux/kvm_host.h +++ kvm/include/linux/kvm_host.h @@ -24,7 +24,11 @@ #include asm/kvm_host.h +#ifdef CONFIG_S390 +#define KVM_MAX_VCPUS 64 +#else #define KVM_MAX_VCPUS 16 +#endif #define KVM_MEMORY_SLOTS 32 /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 Why don't we just define this in asm/kvm_host.h ? No problem with that, I just wanted to keep impact on common code very low and things like this seperated from the actual port. I have a few things like this that can safely be taken care about later. Since there were a few other comments, I went ahead and moved those #defines to asm-x86. -- Any sufficiently difficult bug is indistinguishable from a feature. - 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] [RFC/PATCH 00/15] kvm on big iron
Carsten Otte wrote: This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. I'm slightly worried about the changes to non arch code. Perhaps Andrea or Rik can look over the mm/ changes and ack? Other than that, and the few minor comments that popped up, this (very nice) patchset will be very easy to merge. IIRC you mentioned it is possible for me to get an s390 account; this will be very useful in avoiding breaking this port, as happens quite often with ppc and ia64. I'd like to be able to do both build and run testing. -- Any sufficiently difficult bug is indistinguishable from a feature. - 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] [RFC/PATCH 14/15] guest: detect when running on kvm
[EMAIL PROTECTED] wrote: Since when do we have symbolic names for the bits? It was always on my todo list to do a cleanup and replace the numbers we use everywhere with names. Especially since we have clashes from time to time... but that didn't hurt enough yet, obviously. But now that you volunteered to take care of this... :) Right. We only have defines for (machine_flags bit). Looks to me like the bits really should have a name on them. I've created a patch that does this, but I want to talk it over with Martin before sending that one out. - 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] [RFC/PATCH 05/15] KVM_MAX_VCPUS
Avi Kivity wrote: Carsten Otte wrote: Hollis Blanchard wrote: On Thu, 2008-03-20 at 17:24 +0100, Carsten Otte wrote: Index: kvm/include/linux/kvm_host.h === --- kvm.orig/include/linux/kvm_host.h +++ kvm/include/linux/kvm_host.h @@ -24,7 +24,11 @@ #include asm/kvm_host.h +#ifdef CONFIG_S390 +#define KVM_MAX_VCPUS 64 +#else #define KVM_MAX_VCPUS 16 +#endif #define KVM_MEMORY_SLOTS 32 /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 Why don't we just define this in asm/kvm_host.h ? No problem with that, I just wanted to keep impact on common code very low and things like this seperated from the actual port. I have a few things like this that can safely be taken care about later. Since there were a few other comments, I went ahead and moved those #defines to asm-x86. Great! I will rebase the patch series. - 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] [RFC/PATCH 06/15] kvm-s390: sie intercept handling
Avi Kivity wrote:
Carsten Otte wrote:
/* for KVM_RUN, returned by mmap(vcpu_fd, offset=0) */
struct kvm_run {
@@ -138,6 +139,14 @@ struct kvm_run {
__u32 is_write;
__u32 pad;
} tpr_access;
+/* KVM_EXIT_S390_SIEIC */
+struct {
+__u8 icptcode;
+__u64 mask; /* psw upper half */
+__u64 addr; /* psw lower half */
+__u16 ipa;
+__u32 ipb;
+} s390_sieic;
/* Fix the size of the union. */
char padding[256];
};
Do you support 32-bit userspace on 64-bit kernel? If so, this is likely
badly aligned.
32bit userspace is not pracitcal, current enterprise distributions
come with 64bit only on s390. Nevertheless, I don't get your point on
allignment. What is the problem caused by the struct, and how can I
solve it?
-
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] [RFC/PATCH 06/15] kvm-s390: sie intercept handling
Carsten Otte wrote:
/* for KVM_RUN, returned by mmap(vcpu_fd, offset=0) */
struct kvm_run {
@@ -138,6 +139,14 @@ struct kvm_run {
__u32 is_write;
__u32 pad;
} tpr_access;
+ /* KVM_EXIT_S390_SIEIC */
+ struct {
+ __u8 icptcode;
+ __u64 mask; /* psw upper half */
+ __u64 addr; /* psw lower half */
+ __u16 ipa;
+ __u32 ipb;
+ } s390_sieic;
/* Fix the size of the union. */
char padding[256];
};
Do you support 32-bit userspace on 64-bit kernel? If so, this is likely
badly aligned.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
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] [RFC/PATCH 12/15] kvm-s390: API documentation
Randy Dunlap wrote: This means that [no comma] snip Being a native speaker is cheating ;-). I've integrated your feedback, for the next round of sending out these patches. Thank you :-). - 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] [RFC/PATCH 15/15] guest: virtio device support, and kvm hypercalls
Carsten Otte wrote: Currently we dont have PCI on s390. Making virtio_pci usable for s390 seems more complicated that providing an own stub. This virtio stub is similar to the lguest one, the memory for the descriptors and the device detection is made via additional mapped memory on top of the guest storage. We use an external interrupt with extint code 1237 for host-guest notification. So, sanity won in the end. -- Any sufficiently difficult bug is indistinguishable from a feature. - 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: MMU: add KVM_ZAP_GFN ioctl
On Thu, Mar 20, 2008 at 02:09:15PM +0200, Avi Kivity wrote: Marcelo Tosatti wrote: Add an ioctl to zap all mappings to a given gfn. This allows userspace remove the QEMU process mappings and the page without causing inconsistency. I'm thinking of comitting rmap_nuke() to kvm.git, and the rest to the external module, since this is only needed on kernels without mmu notifiers. Andrea, is rmap_nuke() suitable for the mmu notifiers pte clear callback? There's the usual smp race condition. The tlb must be flushed before the final put_page in rmap_remove. And it can't be safe to call this ioctl before sys_munmap(), so this would be the final put_page. My kvm_unmap_hva takes care of that. - 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] [RFC/PATCH 00/15] kvm on big iron
Avi Kivity wrote: Carsten Otte wrote: This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. I'm slightly worried about the changes to non arch code. Perhaps Andrea or Rik can look over the mm/ changes and ack? Yea that's why I've copied linux-mm on the first two patches. Reallocating the page tables works sane and is simple, but whether or not we may export dup_mm is the real question. Other than that, and the few minor comments that popped up, this (very nice) patchset will be very easy to merge. IIRC you mentioned it is possible for me to get an s390 account; this will be very useful in avoiding breaking this port, as happens quite often with ppc and ia64. I'd like to be able to do both build and run testing. Glad to hear that you like the patchset. It would be cool if you could pull from Linus soon, because we do need a patch not yet in the kvm.git that the series is based upon. After that, we'll integrate the review feedback, rebase to latest git, and resubmit the series. I'll see what I can do to get you access to a box. We'll also be following kvm.git closely during the kernel release cycles and report regressions or submit patches to clean them up. - 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: MMU: add KVM_ZAP_GFN ioctl
On Fri, Mar 21, 2008 at 12:42:14PM +0100, Andrea Arcangeli wrote: On Thu, Mar 20, 2008 at 02:09:15PM +0200, Avi Kivity wrote: Marcelo Tosatti wrote: Add an ioctl to zap all mappings to a given gfn. This allows userspace remove the QEMU process mappings and the page without causing inconsistency. I'm thinking of comitting rmap_nuke() to kvm.git, and the rest to the external module, since this is only needed on kernels without mmu notifiers. Andrea, is rmap_nuke() suitable for the mmu notifiers pte clear callback? There's the usual smp race condition. The tlb must be flushed before the final put_page in rmap_remove. And it can't be safe to call this ioctl before sys_munmap(), so this would be the final put_page. My kvm_unmap_hva takes care of that. This is not the final put_page(). Remote TLB's are flushed here, after rmap_remove: + if (nuked) + kvm_flush_remote_tlbs(kvm); This ioctl is called before zap_page_range() is executed through sys_madvise(MADV_DONTNEED) to remove the page in question. We know that the guest will not attempt to fault in the gfn because the virtio balloon driver is synchronous (it will only attempt to release that page back to the guest OS once rmap_nuke+zap_page_range has finished). Can you be more verbose? By the way, I don't see invalidate_begin/invalidate_end hooks in the KVM part of MMU notifiers V9 patch? (meaning that zap_page_range will not zap the spte's for the pages in question). Thanks - 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] Coredump from qemu
Hi During execution of qemu I've got this crash: #0 0x00407a29 in qemu_mod_timer (ts=0x2e8cf90, expire_time=130685351465) at /usr/src/debug/kvm-63/qemu/vl.c:1073 #1 0x00425590 in pcnet_ioport_writew (opaque=0x0, addr=1836332585, val=8090216) at /usr/src/debug/kvm-63/qemu/hw/pcnet.c:1617 #2 0x00501cf1 in kvm_outw (opaque=value optimized out, addr=13865, data=29288) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:457 #3 0x0051e2a0 in kvm_run (kvm=0x2dbb030, vcpu=1) at libkvm.c:719 #4 0x00501646 in kvm_cpu_exec (env=value optimized out) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:127 #5 0x005021a5 in kvm_main_loop_cpu (env=0x2e8f010) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:307 #6 0x00502302 in ap_main_loop (_env=value optimized out) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:338 #7 0x00353420740a in start_thread () from /lib64/libpthread.so.0 #8 0x0035336e5d1d in clone () from /lib64/libc.so.6 (gdb) print alarm_timer $1 = (struct qemu_alarm_timer *) 0x0 It happend during detach of gdb and quit of the qemu itsell - I assume no all timers were probably stoped when quit_timers was executed ? Maybe check for non NULL pointer is enough qemu_mod_timer? I'm using kvm64 fedora rawhide packages. Zdenek - 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] [RFC/PATCH 14/15] guest: detect when running on kvm
On Fri, Mar 21, 2008 at 12:12:04PM +0100, Carsten Otte wrote: [EMAIL PROTECTED] wrote: Since when do we have symbolic names for the bits? It was always on my todo list to do a cleanup and replace the numbers we use everywhere with names. Especially since we have clashes from time to time... but that didn't hurt enough yet, obviously. But now that you volunteered to take care of this... :) Right. We only have defines for (machine_flags bit). Looks to me like the bits really should have a name on them. I've created a patch that does this, but I want to talk it over with Martin before sending that one out. Just introduce something like MACHINE_FLAG_KVM. The rest can be converted later. Unless you're bored and feel like fiddling around with assembly code :) - 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] [RFC/PATCH 14/15] guest: detect when running on kvm
Am Freitag, den 21.03.2008, 15:06 +0100 schrieb Heiko Carstens: Just introduce something like MACHINE_FLAG_KVM. The rest can be converted later. Unless you're bored and feel like fiddling around with assembly code :) I've done that patch this morning already, see below. I agree with HCH that we should do that, but after the kvm merge. I don't want kvm-s390 conflict with Martin's patches. This is just a beautification, and can safely wait a release cycle. --- arch/s390/kernel/early.c |6 +++--- include/asm-s390/setup.h | 32 ++-- 2 files changed, 25 insertions(+), 13 deletions(-) Index: linux-host/arch/s390/kernel/early.c === --- linux-host.orig/arch/s390/kernel/early.c +++ linux-host/arch/s390/kernel/early.c @@ -138,15 +138,15 @@ static noinline __init void detect_machi /* Running under z/VM ? */ if (cpuinfo-cpu_id.version == 0xff) - machine_flags |= 1; + machine_flags |= MACHINE_FLAG_VM; /* Running on a P/390 ? */ if (cpuinfo-cpu_id.machine == 0x7490) - machine_flags |= 4; + machine_flags |= MACHINE_FLAG_P390; /* Running under KVM ? */ if (cpuinfo-cpu_id.version == 0xfe) - machine_flags |= 64; + machine_flags |= MACHINE_FLAG_KVM; } #ifdef CONFIG_64BIT Index: linux-host/include/asm-s390/setup.h === --- linux-host.orig/include/asm-s390/setup.h +++ linux-host/include/asm-s390/setup.h @@ -59,23 +59,35 @@ extern unsigned int s390_noexec; */ extern unsigned long machine_flags; -#define MACHINE_IS_VM (machine_flags 1) -#define MACHINE_IS_P390(machine_flags 4) -#define MACHINE_HAS_MVPG (machine_flags 16) -#define MACHINE_IS_KVM (machine_flags 64) -#define MACHINE_HAS_IDTE (machine_flags 128) -#define MACHINE_HAS_DIAG9C (machine_flags 256) +#define MACHINE_FLAG_VM1 +#define MACHINE_FLAG_IEEE 2 +#define MACHINE_FLAG_P390 4 +#define MACHINE_FLAG_CSP 8 +#define MACHINE_FLAG_MVPG 16 +#define MACHINE_FLAG_DIAG4432 +#define MACHINE_FLAG_KVM 64 +#define MACHINE_FLAG_IDTE 128 +#define MACHINE_FLAG_DIAG9C256 +#define MACHINE_FLAG_MVCOS 512 + + +#define MACHINE_IS_VM (machine_flags MACHINE_FLAG_VM) +#define MACHINE_IS_KVM (machine_flags MACHINE_FLAG_KVM) +#define MACHINE_IS_P390(machine_flags MACHINE_FLAG_P390) +#define MACHINE_HAS_MVPG (machine_flags MACHINE_FLAG_MVPG) +#define MACHINE_HAS_IDTE (machine_flags MACHINE_FLAG_IDTE) +#define MACHINE_HAS_DIAG9C (machine_flags MACHINE_FLAG_DIAG9C) #ifndef __s390x__ -#define MACHINE_HAS_IEEE (machine_flags 2) -#define MACHINE_HAS_CSP(machine_flags 8) +#define MACHINE_HAS_IEEE (machine_flags MACHINE_FLAG_IEEE) +#define MACHINE_HAS_CSP(machine_flags MACHINE_FLAG_CSP) #define MACHINE_HAS_DIAG44 (1) #define MACHINE_HAS_MVCOS (0) #else /* __s390x__ */ #define MACHINE_HAS_IEEE (1) #define MACHINE_HAS_CSP(1) -#define MACHINE_HAS_DIAG44 (machine_flags 32) -#define MACHINE_HAS_MVCOS (machine_flags 512) +#define MACHINE_HAS_DIAG44 (machine_flags MACHINE_FLAG_DIAG44) +#define MACHINE_HAS_MVCOS (machine_flags MACHINE_FLAG_MVCOS) #endif /* __s390x__ */ #define MACHINE_HAS_SCLP (!MACHINE_IS_P390) - 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: MMU: add KVM_ZAP_GFN ioctl
On Fri, Mar 21, 2008 at 10:37:00AM -0300, Marcelo Tosatti wrote:
This is not the final put_page().
Remote TLB's are flushed here, after rmap_remove:
+ if (nuked)
+ kvm_flush_remote_tlbs(kvm);
This ioctl is called before zap_page_range() is executed through
sys_madvise(MADV_DONTNEED) to remove the page in question.
We know that the guest will not attempt to fault in the gfn because
the virtio balloon driver is synchronous (it will only attempt to
release that page back to the guest OS once rmap_nuke+zap_page_range has
finished).
Can you be more verbose?
Sure.
1) even if you run madvise(MADV_DONTNEED) after KVM_ZAP_GFN, the anon
page can be released by the VM at any time without any kvm-aware
lock (there will be a swap reference to it, no any more page_count
references leading to memory corruption in the host in presence of
memory pressure). This is purely theoretical of course, not sure if
timings or probabilities allows for reproducing this in real life.
2) not sure what you mean with synchronous, do you mean single
threaded? I can't see how it can be single threaded (does
ballooning stops all other vcpus?). Why are you taking the mmu_lock
around rmap_nuke if no other vcpu can take any page fault and call
into get_user_pages in between KVM_ZAP_GFN and madvise? As far as I
can tell the only possible safe ordering is madvise; KVM_ZAP_GFN,
which is emulating the mmu notifier behavior incidentally.
Note that the rmap_remove smp race (also note here smp race means
smp-host race, it will trigger even if guest is UP) might be a generic
issue with the rmap_remove logic. I didn't analyze all the possible
rmap_remove callers yet (this was in my todo list), I just made sure
that my code would be smp safe.
By the way, I don't see invalidate_begin/invalidate_end hooks in the KVM
part of MMU notifiers V9 patch? (meaning that zap_page_range will not zap
the spte's for the pages in question).
range_begin isn't needed. range_begin is needed only by secondary mmu
drivers that aren't reference counting the pages. The _end callback is
below. It could be improved to skip the whole range in a single browse
of the memslots instead of browsing it for each page in the range. The
mmu notifiers aren't merged and this code may still require changes in
terms of API if EMM is merged instead of #v9 (hope not), so I tried to
keep it simple.
+void kvm_mmu_notifier_invalidate_page(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long address)
+{
+ struct kvm *kvm = mmu_notifier_to_kvm(mn);
+ BUG_ON(mm != kvm-mm);
+ write_seqlock(kvm-arch.mmu_notifier_invalidate_lock);
+ kvm_unmap_hva(kvm, address);
+ write_sequnlock(kvm-arch.mmu_notifier_invalidate_lock);
+}
+
+void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end)
+{
+ for (; start end; start += PAGE_SIZE)
+ kvm_mmu_notifier_invalidate_page(mn, mm, start);
+}
+
+int kvm_mmu_notifier_clear_flush_young(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long address)
+{
+ struct kvm *kvm = mmu_notifier_to_kvm(mn);
+ BUG_ON(mm != kvm-mm);
+ return kvm_age_hva(kvm, address);
+}
+
+static const struct mmu_notifier_ops kvm_mmu_notifier_ops = {
+ .invalidate_page= kvm_mmu_notifier_invalidate_page,
+ .invalidate_range_end = kvm_mmu_notifier_invalidate_range_end,
+ .clear_flush_young = kvm_mmu_notifier_clear_flush_young,
+};
+
struct kvm *kvm_arch_create_vm(void)
{
struct kvm *kvm = kzalloc(sizeof(struct kvm), GFP_KERNEL);
-
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] All for Love From Mrs. Rita Benson
Hi, All for Love, I know that this letter might be a surprise to you but do consider it as emergency and this will benefit both of us. I am Mrs Rita Benson, from Liberia Monrovia, 47 years old and I reside here in London with my only son micheal Benson. We are here in United Kingdom because of the fund $4.5m(Four Million Five Hundred Thousand USD) my late husband former minister of finance during the regime of Charles Taylor deposited in the Security/finance house which we want to move out from here to your country for investment please contact me with this my private e-mail address: [EMAIL PROTECTED] as I need your assistance. I do hope to hear from you soon. Thanks. Mrs Rita Benson - 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] re
Vincent Reality holds an admission of employees for a job in Internet. The company offers you to get a high-paid position with every month salary of 2000 Euro (+ % 5) and an additional benefit gathering. Working with us you get: - High monthly salary up to 5000 Euro - Benefit receiving (daily or weekly) - Working time is no more than 3 hours a day from Monday till Friday - Saturday and Sunday are the days-offs For getting the position you need to have: - Working experience with PC - Internet access - Absence of previous convictions - Age from 21 If you are interested in getting this position, write, please,only to the Email: [EMAIL PROTECTED] (please use subject I am Interested) In your letter there should be written: 1) Your name and surname 2) Your age 3) State, City, Zip-code 4) You home and mobile telephone number 5) Your contact Email - address When the operator of our company will receive the letter with your personal data, you will be sent an immediate reply with all the further instructions for getting a job in the company. Looking forward to your reply. Vincent Reality Administration 6.00.2800.1165 - 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] [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable
On Thu, 2008-03-20 at 21:35 +0100, Carsten Otte wrote: Dave Hansen wrote: Well, and more fundamentally: do we really want dup_mm() able to be called from other code? Maybe we need a bit more detailed justification why fork() itself isn't good enough. It looks to me like they basically need an arch-specific argument to fork, telling the new process's page tables to take the fancy new bit. I'm really curious how this new stuff is going to get used. Are you basically replacing fork() when creating kvm guests? No. The trick is, that we do need bigger page tables when running guests: our page tables are usually 2k, but when running a guest they're 4k to track both guest and host dirtyreference information. This looks like this: *--* *2k PTE's * *--* *2k PGSTE * *--* We don't want to waste precious memory for all page tables. We'd like to have one kernel image that runs regular server workload _and_ guests. That makes a lot of sense. Is that layout (the shadow and regular stacked together) specified in hardware somehow, or was it just chosen? What you've done with dup_mm() is probably the brute-force way that I would have done it had I just been trying to make a proof of concept or something. I'm worried that there are a bunch of corner cases that haven't been considered. What if someone else is poking around with ptrace or something similar and they bump the mm_users: + if (tsk-mm-context.pgstes) + return 0; + if (!tsk-mm || atomic_read(tsk-mm-mm_users) 1 || + tsk-mm != tsk-active_mm || tsk-mm-ioctx_list) + return -EINVAL; HERE + tsk-mm-context.pgstes = 1;/* dirty little tricks .. */ + mm = dup_mm(tsk); It'll race, possibly fault in some other pages, and those faults will be lost during the dup_mm(). I think you need to be able to lock out all of the users of access_process_vm() before you go and do this. You also need to make sure that anyone who has looked at task-mm doesn't go and get a reference to it and get confused later when it isn't the task-mm any more. Therefore, we need to reallocate the page table after fork() once we know that task is going to be a hypervisor. That's what this code does: reallocate a bigger page table to accomondate the extra information. The task needs to be single-threaded when calling for extended page tables. Btw: at fork() time, we cannot tell whether or not the user's going to be a hypervisor. Therefore we cannot do this in fork. Can you convert the page tables at a later time without doing a wholesale replacement of the mm? It should be a bit easier to keep people off the pagetables than keep their grubby mitts off the mm itself. -- Dave - 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] buliding and testing PowerPC KVM
On Fri, 2008-03-21 at 13:02 +0200, Avi Kivity wrote: Other than that, and the few minor comments that popped up, this (very nice) patchset will be very easy to merge. IIRC you mentioned it is possible for me to get an s390 account; this will be very useful in avoiding breaking this port, as happens quite often with ppc and ia64. I'd like to be able to do both build and run testing. As for building the PowerPC code, cross-compiling is easy with http://kegel.com/crosstool . There are also a number of servers offering remote PowerPC ssh access: see http://penguinppc.org/dev/#remote . For run testing, we are only working on 440 host support right now, so you would need a board like the Sequoia (https://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D37101% 2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526LID%253D32232% 2526BID%253DDF2%2526CTP%253DEVK,00.html). In the future we should be able to run 440 guests on e.g. POWER5 hosts, but we've already got our hands full without that. -- Hollis Blanchard IBM Linux Technology Center - 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 a separate device for in-kernel PIT
On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote: Part of the feedback we received from Fabrice about the KVM patches for QEMU is that we should create a separate device for the in-kernel APIC to avoid having lots of if (kvm_enabled()) within the APIC code that were difficult to understand why there were needed. This patch separates the in-kernel PIT into a separate device. It also introduces some configure logic to only compile in support for the in-kernel PIT if it's available. The result of this is that we now only need a single if (kvm_enabled()) to determine which device to use. Besides making it more upstream friendly, I think this makes the code much easier to understand. Signed-off-by: Anthony Liguori [EMAIL PROTECTED] This patch solves annoying qemu build breakage hitting PowerPC around struct kvm_pit_state, so that's another vote in favor... -- Hollis Blanchard IBM Linux Technology Center - 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] Move kvm_get_pit to libkvm.c common code
Avi, please apply the patch at the end of this mail.
On Tue, 2008-03-11 at 15:17 -0500, Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1205266548 18000
# Branch merge
# Node ID b136c0450c0f7c6ff2262437b1beb9896b1585e3
# Parent c14fbbaee36241aa0fab0d6391e47cf9f4ac8012
Move kvm_get_pit to libkvm.c common code
This fixes compilation issues for PowerPC and other non x86 archs that
do not
have in kernel pit. The pit code is added into the kvm_context in
kvm-common.h the error causing the issue is coming from a definition
in qemu. This seems to be the proper fix as there is also a common
function:
kvm_irqchip_in_kernel
for in kernel irq that handles this the same way.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -660,12 +660,3 @@ int kvm_disable_tpr_access_reporting(kvm
}
#endif
-
-int kvm_pit_in_kernel(kvm_context_t kvm)
-{
-#ifdef KVM_CAP_PIT
- return kvm-pit_in_kernel;
-#else
- return 0;
-#endif
-}
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -962,3 +962,8 @@ int kvm_irqchip_in_kernel(kvm_context_t
{
return kvm-irqchip_in_kernel;
}
+
+int kvm_pit_in_kernel(kvm_context_t kvm)
+{
+ return kvm-pit_in_kernel;
+}
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -530,6 +530,13 @@ int kvm_set_lapic(kvm_context_t kvm, int
#endif
+/*!
+ * \brief Query wheather in kernel pit is used
+ *
+ * \param kvm Pointer to the current kvm_context
+ */
+int kvm_pit_in_kernel(kvm_context_t kvm);
+
#ifdef KVM_CAP_PIT
/*!
This doesn't fix libkvm, and qemu is even worse off:
In file included from ../qemu-kvm.h:80,
from ../hw/i8254.c:29:
/home/hollisb/source/kvm-userspace-ppc.hg/qemu/../libkvm/libkvm.h:550: warning:
struct kvm_pit_state declared inside parameter list
/home/hollisb/source/kvm-userspace-ppc.hg/qemu/../libkvm/libkvm.h:550: warning:
its scope is only this definition or declaration, which is probably not what
you want
/home/hollisb/source/kvm-userspace-ppc.hg/qemu/../libkvm/libkvm.h:561: warning:
struct kvm_pit_state declared inside parameter list
../hw/i8254.c: In function `kvm_kernel_pit_save_to_user':
../hw/i8254.c:421: error: storage size of 'pit' isn't known
../hw/i8254.c:431: error: dereferencing pointer to incomplete type
[repeated a lot]
The below patch fixes the libkvm.h issue, taking the same approach as
kvm_get/set_lapic() just above it. (I can't say I'm a fan of this
approach, but kvm-userspace is eroding my idealism.)
The qemu breakage is fixed by Anthony's PIT patch that creates
i8254-kvm.c.
Don't compile kvm_*_pit() on architectures whose currently supported
platforms do not contain a PIT.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -539,6 +539,7 @@ int kvm_pit_in_kernel(kvm_context_t kvm)
#ifdef KVM_CAP_PIT
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
/*!
* \brief Get in kernel PIT of the virtual domain
*
@@ -562,6 +563,8 @@ int kvm_set_pit(kvm_context_t kvm, struc
#endif
+#endif
+
#ifdef KVM_CAP_VAPIC
/*!
--
Hollis Blanchard
IBM Linux Technology Center
-
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] kvm.h: __user requires compiler.h
This patch breaks QEMU build when doing a 'make sync'. When you do a
top-level ./configure, libkvm is built with kerneldir pointing to
kvm-userspace/kernel/include. While linux/kvm.h is present there, there
isn't a linux/compiler.h.
The host kernelpath isn't normally part of the libkvm or QEMU build. So
we have a couple options.
1) make the host kernelpath (/lib/modules/$(uname -r)/build/include)
part of the libkvm/QEMU build.
2) Do something else about __user
Suggestions? #1 might be a pain since there may be include conflicts
between the host kernel include and kernel/include.
Regards,
Anthony Liguori
Christian Borntraeger wrote:
include/linux/kvm.h defines struct kvm_dirty_log to
[...]
union {
void __user *dirty_bitmap; /* one bit per page */
__u64 padding;
};
__user requires compiler.h to compile. Currently, this works on x86
only coincidentally due to other include files. This patch makes
kvm.h compile in all cases.
Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
---
include/linux/kvm.h |1 +
1 file changed, 1 insertion(+)
Index: kvm/include/linux/kvm.h
===
--- kvm.orig/include/linux/kvm.h
+++ kvm/include/linux/kvm.h
@@ -8,6 +8,7 @@
*/
#include asm/types.h
+#include linux/compiler.h
#include linux/ioctl.h
#include asm/kvm.h
-
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/
-
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 a separate device for in-kernel PIT
Hollis Blanchard wrote: This patch solves annoying qemu build breakage hitting PowerPC around struct kvm_pit_state, so that's another vote in favor... I have an updated version of the patch but it's breaking the build b/c something fouled up right now with configure. libkvm pulls in linux/kvm.h which wants to pull in linux/compiler.h. We don't ship a linux/compiler.h though so it's pulling from /usr/include/linux which on my system doesn't have a compiler.h. The lack of this header is causing the configure test to fail. I've attached the patch here for you to use and I'll send it out again once I figure out the fix for this linux/compiler.h. Regards, Anthony Liguori qemu:cleanup_pit.patch Description: application/mbox - 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] [RFC/PATCH 15/15] guest: virtio device support, and kvm hypercalls
On Friday 21 March 2008 19:15:47 Christian Borntraeger wrote: Am Freitag, 21. März 2008 schrieb Rusty Russell: Hmm, panic on device_register fail, but -ENOMEM on add_shared_memory fail? My theory was that since this is boot time, panic() is the right thing. Good spot, but I agree with Carsten. Drivers should not panic. I have module load/unload capability on my long term todo list, but I can change the panic now. Yep, that makes sense. For lguest, we panic: it's always at boot time so if it fails we should die early to make it easier to diagnose (and that makes sure it happens before we lose our early console). Cheers, Rusty. - 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] [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable
Dave Hansen wrote: On Thu, 2008-03-20 at 21:35 +0100, Carsten Otte wrote: Dave Hansen wrote: Well, and more fundamentally: do we really want dup_mm() able to be called from other code? Maybe we need a bit more detailed justification why fork() itself isn't good enough. It looks to me like they basically need an arch-specific argument to fork, telling the new process's page tables to take the fancy new bit. I'm really curious how this new stuff is going to get used. Are you basically replacing fork() when creating kvm guests? No. The trick is, that we do need bigger page tables when running guests: our page tables are usually 2k, but when running a guest they're 4k to track both guest and host dirtyreference information. This looks like this: *--* *2k PTE's * *--* *2k PGSTE * *--* We don't want to waste precious memory for all page tables. We'd like to have one kernel image that runs regular server workload _and_ guests. That makes a lot of sense. Is that layout (the shadow and regular stacked together) specified in hardware somehow, or was it just chosen? It's defined by hardware. The chip just adds +2k to the ptep to get to the corresponding pgste. Both pte and pgste are 64bit per page. I know Heiko and Martin have thought a lot about possible races. I'll have to leave your question on the race against pfault open for them. Btw: thanks a lot for reviewing our changes :-) cheers, Carsten - 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
